Publish snap packags in the Ubuntu store

Hello,

For those who don’t know about snaps, please look here: http://snapcraft.io/

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 :slight_smile:

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 [1]. 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.

Can somebody register the snap with an official account? https://myapps.developer.ubuntu.com/dev/click-apps/register-name/

pura vida.

[1] http://snapcraft.io/docs/core/install

2 Likes

I’ll take care of it.

4 Likes

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.

@elopio It appears the default sync directory and config is versioned with the snap version. I’m pretty sure this is the wrong thing to do?

jb@ubuntu:~ $ syncthing  -paths
Configuration file:
	/home/jb/snap/syncthing/3/.config/syncthing/config.xml

Database directory:
	/home/jb/snap/syncthing/3/.config/syncthing/index-v0.14.0.db

Device private key & certificate files:
	/home/jb/snap/syncthing/3/.config/syncthing/key.pem
	/home/jb/snap/syncthing/3/.config/syncthing/cert.pem

HTTPS private key & certificate files:
	/home/jb/snap/syncthing/3/.config/syncthing/https-key.pem
	/home/jb/snap/syncthing/3/.config/syncthing/https-cert.pem

Log file:
	/home/jb/snap/syncthing/3/.config/syncthing/syncthing.log

GUI override directory:
	/home/jb/snap/syncthing/3/.config/syncthing/gui

Default sync folder directory:
	/home/jb/snap/syncthing/3/Sync

jb@ubuntu:~ $ 

I think we’ll need a wrapper script to set some environment variables or the -home flag.

Thanks @calmh.

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

About the paths, you are right, some of those dirs shouldn’t be versioned. Do you think this simple fix is ok? https://github.com/syncthing/syncthing/pull/3730

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.

Yeah the releases are doable. For the time being, manual as part of the same process that pushes github releases and debs is fine.

Discussing the PR in the PR.

Hey @calmh, we are hosting the ubuntu testing days on Fridays:

https://wiki.ubuntu.com/Testing/UbuntuTestingDay

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.

2 Likes

That sounds neat, but unfortunately I cannot. Perhaps someone else would like to speak on our behalf. :slight_smile:

2 Likes

What does this involve? What time does it happen and how long does it take?

Also, as everyone is probably already aware I am not the most people loving person around.

3 Likes

Hello,

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 :slight_smile:

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.

pura vida.

1 Like

So is this a pre-recorded thing (given the “pick any day and time” bit) or a live thing every friday?

Yes, I value new contributors more than anything else.

1 Like

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.

2 Likes

@calmh using symlinks otherwise is an option, but… In case you want syncthing to behave the same way it would when not snapped, you probably want this.

Let me know if a PR for that is appreciated or you prefer continue the way it is now.

Hm? I’m missing the context, even after scrollback.

@calmh check @elopio’s comment, where he talks about the classic snap confinment (read more).

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.

Is “classic” supported by the things that consume snaps now?

Yeah, snapd 2.20 includes it, and it’s available in all the releases that ships it (including Ubuntu 16.04 LTS).

You can check it here

2 Likes

I’ve just started the call for testing with the Ubuntu community:

My offer to show syncthing in one of our Friday’s testing days still stands :smiley:

I received very good comments about syncthing in the forum and in the Ubuntu community :slight_smile:

@calmh @AudriusButkevicius: would you like to write a post for https://insights.ubuntu.com/ ? It has a huge amount of traffic, so it’s a very good way to get more people to know and use syncthing.

1 Like

Sure, I can put something together. Are you thinking mostly about the snapifying experience or something more general?

1 Like