Now the syncthing master branch has code to build snaps for amd64, armhf and arm64. Thanks for that, it is great for me because now I can sync all my ubuntu-core machines, even the raspberry pis, beaglebones and dragonboards
The next step is to push the snaps to the store. This will make it really simple to install syncthing on any linux distribution that supports snaps . But my favorite feature are the update channels, to make it easy to publish a daily build and get quick feedback from the early adopters.
I’ve done what I think is the correct thing here, and published an AMD64 snap to the edge and beta channels. The next release, on Tuesday, will go into the stable channel and then we can see what works and what doesn’t with that distribution method.
I would use the candidate channel instead of stable, for a little while. Just to be precautious before we tell people that they can trust their files to this package.
Ideally, we hook your CI system to make automated releases for every arch, to edge every time master (edit: it said edge before) changes, and to candidate every time you make a tag. Do you have a way to store secrets in your jenkins instance? To give you an idea, here’s how I release some of my snaps: https://github.com/elopio/hashicorp-snaps/blob/master/.travis.yml
The versioned paths are useful for updates and rollbacks. We are working on hooks that will run every time a new version is installed, so maybe later we can start thinking about migrations of data schemas and things like that.
I think it would be a nice way to get more people testing the syncthing candidate snap. Would you like to join us next Friday?
The basic idea is that during the first part you show us about syncthing, like the cool features, what’s coming, any random interesting facts that you would like to tell us. And then we show how to test and contribute to syncthing. Nothing formal, just a relaxed and open discussion, mostly.
I was on vacations yesterday and in the meantime my team mates found another project to test this Friday. We can do it with syncthing next week, or any other week that is good for you. But I really hope we do it some day soon.
@AudriusButkevicius you are welcome to join us. We don’t need people who love humanity and spread their love everywhere. But we do need people who will welcome new contributors, and guide them nicely and patiently even if they start totally lost and asking the wrong questions. Also, infinite patience is not required, I know that sometimes the battle is lost from the start
Feel free to pick any day and time that works for you. It would be great to have both, but if only one can make it that’s good too. We have one more session on December, and then we start again in January.
We usually spend one hour in the hangout. The first part is you showing your project and telling people how to contribute. The second part is us showing some tools to test it.
It is live every Friday, but the hour is always different depending on what’s best for the guest. How does January 7th sound to you?
@calmh I think you might like this: https://github.com/snapcore/snapd/pull/2442
The classic confinement is a new thing that will support dev tools that need permission to go out of their confinement to do any useful work. For example, emacs that needs to be able to edit config files. I’m not sure if classic confinement is a good thing for syncthing, but it’s an option and it solves the HOME weirdness we have in the UI.
By having that snapped syncthing would act exactly like the one you already ship in .deb packages, being able to access your $HOME and hidden files (and normal ~/.config). So this would allow anyone to use the snap without any effort in migrating settings or synced folders.
Maybe you might also create two kind of snaps for syncthing one with classic interface, the other confined for people that is more concerned about security.
But IMHO by default the snap for a such tool should be able to sync any file in the system.