Grab it here: http://software.opensuse.org/package/syncthing
After installing, you can enable it for an user by doing (as root):
systemctl enable syncthing@username.service
systemctl start syncthing@username.service
Then go to http://127.0.0.1:8080 as usual.
The internal restart after changing configuration does not seem to play well with systemd. I will look into that. Meanwhile, restart it using systemd.
This is nice! Will you be keeping this package up to date for each release?
As long as I am using it and it keeps itself sane to build, yes 
Depending on the popularity we can also include it in the distro.
One thing I noticed is that it imports martini from the old importpath at codegangsta (it moved to go-martini org). I had to package martini with a symlinked compatibility import path.
When built using the build.sh script syncthing will use the vendored (included) martini source - there should be no need to package it separately?
Having vendored sources make it difficult for inclusion on any Linux distro, but there can be exceptions.
I haven’t tried building with build.sh. As long as it does not try to pull stuff from the network I assume we could use it. Builds have no network access.
Why?
Indeed, that’s the point of the build script; it needs nothing externally. It does however require “godep” to be installed.
In general, because it means fixing security bugs in the library and then in every package separately.
Even with static linking, you could do distro updates by just triggering a rebuild of all packages BuildRequiring Martini. But if you vendor Martini, then the package needs to be patches twice.
That sounds sensible in most cases, where you have versioned libraries and the norm is dynamic linking. However I suggest not looking at syncthing as using “libraries” in that sense.
I agree. But in a distro you are still affected by problem of updating a security vulnerability.
If I have a package go-martini, and I fix it, because syncthing has a BuildRequires, it will be automatically rebuilt, and therefore I can release a security update of go-martini and all “affected” packages.
Once you vendor that, you lose completely the work the distro does for you and each app is on its own.
Indeed. On the other hand you are suddenly building against a possibly wildly different martini that what I develop and test against, to who knows what effect.
Yes, packages sometimes do evil things.
There has to be a middle point. We can package specific git revs for a package (actually tarballs is generated from git): https://build.opensuse.org/package/view_file/home:dmacvicar:syncthing/go-martini/_service?expand=1
But that approach fails once two packages use the same dependency and start competing for a certain version.
The solution is of course to respect the godeps json file and package similar version, but it would be nice if those versions are actual releases and not specific git revisions.
Yep. But Go packages don’t exist as separate entities in that way today, and there is no way to specify depending on a given version (other than what for example godeps does).
I have updated the .service file to use STNORESTART and now restart works as expected.
This is the right link to get it:
http://software.opensuse.org/download/package?project=home:dmacvicar:syncthing&package=syncthing
Updated packages for 0.8.12. Grab them here:
http://software.opensuse.org/download/package?project=home:dmacvicar:syncthing&package=syncthing
Or, if you added my repo, just
zypper ref
zypper in syncthing
Updated packages for 0.8.14. Grab them here:
http://software.opensuse.org/download/package?project=home:dmacvicar:syncthing&package=syncthing
Or, if you added my repo, just
zypper ref
zypper in syncthing
I downloaded the v0.8.14 package, and noticed the binary is unversioned.
jb@udev2:~ $ ./syncthing -version
syncthing unknown-dev (go1.3 linux-amd64) unknown@unknown 1970-01-01 00:00:00 UTC
This makes it trickier to handle bug reports and usage data. Do you think you could tweak your build process to set the relevant variables like build.sh does?
I will put it into my TODO list.
I was actually thinking about building using build.sh and the bundled dependencies: instead of packaging all dependencies, package only godep. But I started packaging godep and it required other packages and I was not in the right moment to go down the rabbit hole.
Godep is nice, but not essential. In effect it’s a fancy wrapper for GOPATH=$(pwd)/Godeps/_workspace:$GOPATH go build .... The build script could be tweaked to not really require it.
I tried to work on the package today. Unfortunately, there are at least two new dependencies. I started with goleveldb and created a package for it, but then goleveldb wanted ginkgo and other stuff to run tests, I don’t want to go down the rabbit hole with dependencies.
I tried reworking the package, compiled godep locally just to make it pull all deps into the tarball, but I did not manage to get it working either. With “godep save” it insisted in trying to install something into the system libs.
And then time was over.