Official Debian packages for apt.syncthing.net?

[acolomb]

As per the announcement from @calmh, there are now official syncthing Debian packages available via the http://apt.syncthing.net repository.

These builds have the internal auto-update feature disabled at compile-time, which makes sense for distribution packages. I propose to do the same for syncthing-gtk:

1. Build a -debian version without the daemon update code.
2. Wrap up a Debian package like on the PPA, but with Depends: syncthing (correct version should be set according to the latest supported .deb release).
3. Get this package into the repository at apt.syncthing.net.

What do others think of this plan?

[calmh]

:+1:

[kozec]

Sounds like good idea, main problem I can see is that I don't know how is syncthing package built and if same method would be usable for ST-GTK. I find Debian packaging system somehow cryptic, but there is PPA with ST-GTK, so it's definitely possible.

As for auto-update, it's disabled by default on Linux, so that shouldn't be a problem.

[calmh]

Building Debian packages from source is a serious pain. I sidestepped it by just creating binary packages based on the normal build process, which is less painful. I don't know how that suits syncthing-gtk.

[acolomb]

@calmh: There is a helper component called dh-golang to ease the building of a Debian package from Go sources. See https://wiki.debian.org/MichaelStapelberg/GoPackaging and especially the examples at http://anonscm.debian.org/cgit/collab-maint/dh-golang.git/

I have never tried to make a .deb package myself, just wanted to make the suggestion to prepare packages for most Syncthing components while the project is still rather experimental. Whenever a 1.0 release stabilizes, it would then be easier to include it in Debian proper.

Building syncthing itself using dh-golang should be pretty doable and I will try to do some experiments when time permits. As for syncthing-gtk, there are many python-gtk based packages in Debian, so there should be plenty of reference sources available. However, I think that auto-update should not only be disabled by default, but completely hidden when using a distribution package that handles the dependencies.

[kozec]

@calmh Creating deb/ directory with required folder structure seems easy enough, but what command are you using to build .deb package from it? dpkg-buildpackage builds valid, completely empty package for me :(

[acolomb]

@kozec Have you had a look at the files used to build the Webupd8 PPA package? See http://ppa.launchpad.net/nilarimogard/webupd8/ubuntu/pool/main/s/syncthing-gtk/syncthing-gtk_0.7.1.1-1~webupd8~vivid0.debian.tar.xz for what is used in that build. Using that for a start would be easiest I guess?

[calmh]

@kozec I'm cheating. The folder is created with a DEBIAN dir containing (some of) the expected control files, then I just:

fakeroot sh -c 'chown -R root:root deb ; dpkg-deb -b deb .'

This happens on the build server, so not visible in the build scripts. After that there's a dpkg-sig step to sign the package.

This is not the correct way to build a Debian package though. You might want to look into using debbuild and the debhelper stuff and so on. It was just too annoying for me to sort out...

[kozec]

Ok, what I have now is "make_deb" command for setup.py that can create debian/ directory with everything needed along with source tarball required by standard Debian packaging method. Generated files are based on @hotice's debian package in WebUpd8 repo, I hope he wouldn't mind :D

Alos, sorry @acolomb, I really don't need debian/ folder in git repo and maintaining separate branch that is needed to be kept in sync is very definition of PITA in my dictionary...

Anyway, it sounds complicated, but only thing needed to make debian package now is running

./setup.py make_deb
debuild

It generates package that installs nicely on all my *buntu testing VMs.

Now I need to ask @calmh what else is needed to be done to get generated package to apt.syncthing.net manually, or, even better, automatically from some build machine.

[acolomb]

Ok, I just tried building and installing from 5f5d0b120ab4ab254d2b4840169413eda45398c4, and it works fine. Note that debuild still outputs some warnings / advices.

Some suggestions:

1. Debian has some rather strict semantic versioning rules, e.g. the packaging version follows the release version after a dash. Git revisions are usually appended before the packaging portion with a +git and the date. Don't know what makes more sense here.
2. The Debian changelog usually notes differences in packaging, in addition to stating the new upstream version. Stuff like fixing up the search path for plugins, see for example the debian/patches/ directory in the PPA package. This does not work well with the current auto-generated approach. Besides, the changelog has only the most recent version, while it should preserve past entries, and the dummy email address is of no help.
3. Right now, you don't have Debian control files within the repository to be maintained, but a script to generate them, which needs to be maintained instead. Stuff like the compat file for example is almost static and would be much easier to keep versioned in git.

In the end some of this is a matter of preference, I just think it will be hard to get this into official Debian / Ubuntu repositories with this "hacky" packaging that clearly does not conform to some policy rules. In the meantime, I'd be happy to have something that just works and is installable from apt.syncthing.net, so thank you @kozec for your effort on this!

Now is certainly not the time to target an official Debian integration and look for a package maintainer as long as both Syncthing and Syncthing-GTK are moving targets.

[kozec]

Thanks for feedback, as I said, I'm competently green in this :D

Point no.1 shouldn't be big problem to fix, plus tagged/release version should generate nice looking version number without +git part.

Point no.2 shouldn't be problem at all, as I hope that I'd be able to keep entire source in one repo, without any distro-specific patches. For example, that search path fix could be included directly, it would be just one more path to search in.

And point no.3 can be reconsidered sometimes after Syncting v1.0 or similar event :)

[mhalano]

How it's going this bug? It's unpleasant to use a external repository (WebUpd8 PPA) just to GUI once GUI is now an official project and there a repository for syncthing.

[rugk]

Any news? Currently the OpenSuse situation with their insecure, unverifiable builds. (because their public key is only downloadable over HTTP) - and the whole site staying on https - is unsatisfying.