Sorry for the confusion.
The idea behind snapcrafters is we have a place (on github) where we can collect the snapcraft.yamls for projects which are currently not owned by the upstream project. Sometimes upstream don’t want to distribute a snap because they have a policy of not distributing binary builds, some just don’t have the time to get involved in it. We put them in snapcrafters so they can still be made available with automated builds.
Snapcrafters uses the build service - build.snapcraft.io under the covers. So we add a yaml (and maybe some scripts / metadata ) to a repo, hook that up to build and it gets regularly built and pushed to the store. Build is great for that use case.
In the case of Signal, it doesn’t build like that. Signal is an Electron application which is built using electron-builder. Build doesn’t (currently) cater to that use case. We’ve requested that build be able to create snaps out of electron applications easily, and the team will work on that as appropriate with their other tasks.
In the meantime we wanted to get a snap of signal-desktop working. The way it builds currently is in a clean 16.04 lxc container on a host I run. Periodically the machine checks for changes upstream ( new stable or pre-release builds at https://github.com/signalapp/Signal-Desktop/releases ) and build accordingly.
If there’s a new pre-release upstream it builds that and pushes to the edge channel in the snap store. This is done so that if anything breaks in the build process with new commits, we can spot that before a stable build is made.
If there’s a new stable release upstream, it builds that and pushes to the beta channel in the snap store. I get an email from the bot telling me that, we can then do some basic shakedown testing and push that to stable if appropriate.
In terms of what it builds, it’s what comes from upstream. I cleanly do a git clone of the repo and then checkout the right revision for whatever tagged release I’m building. The only change is done to the package.json to make electron-builder make a snap and not a deb. Like this.
},
"asarUnpack": "node_modules/spellchecker/vendor/hunspell_dictionaries",
"target": [
- "deb"
+ "snap"
],
"icon": "build/icons/png"
},
- "deb": {
- "depends": [
- "gconf2",
- "gconf-service",
- "libnotify4",
- "libappindicator1",
- "libxtst6",
- "libnss3",
- "libasound2",
- "libxss1"
- ]
+ "snap": {
+ "plugs": ["default", "desktop"]
},
Ideally we’d like this to be owned upstream, and we have had conversations with them in the past on this. In the medium term I plan to move this off of a machine I own and into travis/circleci to build in the cloud rather than on my machine.
In answer to your specific questions. The snapcrafters team consists of myself, @evan and @Wimpress who work on the Snap Advocacy Team at Canonical. There are numerous community contributors who help maintain the snaps in that repo, but effectively our team owns it. As a result only we can register snaps under that name.
There is currently no verification of developers, but I understand that work is ongoing to bring verification to the store. The source for the signal snap is the upstream source with the patch above. No changes.
Happy to answer any more questions (but I am on vacation yesterday and today which is why it took me a while to reply, sorry)