syncthing: 0.12.25 -> 0.13.4

[polendri]

Motivation for this change

See #15674. This is my attempt (as a nix newbie) to both update syncthing to 0.13.4 and use a less brittle packaging strategy going forward by using the build script from syncthing's official build instructions.

Things done

• Tested using sandboxing
  (nix.useSandbox on NixOS,
  or option build-use-sandbox in nix.conf
  on non-NixOS)
• Built on platform(s)
  • NixOS
  • OS X
  • Linux
• Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Fits CONTRIBUTING.md.

---

• Rename v0.12.25 package from 'syncthing' to 'syncthing012'
• Remove syncthing011

[polendri]

The Travis build seems to have timed out... I don't imagine my changes are responsible for that? The logs cut off as it's building mesa.

[joachifm]

@pshendry it may be due to a cold package cache; I've restarted the build.

[rycee]

I cherry-pick this into 16.03 and now run it on my system. Works great. Many thanks!

My one concern is that the only binary installed by the new 0.13.4 package seems to be synclient while the old 0.12 synclient package installed several binaries:

rycee@beta:~$ ls /nix/store/fdamfamfnr1bqpl723jn8d2k6rjbnb06-go1.5-syncthing-v0.12.19-bin/bin
stcompdirs  stfileinfo    stindex    stwatchfile
stevents    stfinddevice  stsigtool  syncthing

I've never knowingly used these other binaries but perhaps they are expected by somebody?

[polendri]

That's a fair point, thanks for noticing. I'll investigate over the weekend if no one else beats me to it.

On May 27, 2016 4:26:15 PM EDT, Robert Helgesson notifications@github.com wrote:

I cherry-pick this into 16.03 and now run it on my system. Works great.
Many thanks!

My one concern is that the only binary installed by the new 0.13.4
package seems to be synclient while the old 0.12 synclient package
installed several binaries:

rycee@beta:~$ ls
/nix/store/fdamfamfnr1bqpl723jn8d2k6rjbnb06-go1.5-syncthing-v0.12.19-bin/bin
stcompdirs  stfileinfo    stindex    stwatchfile
stevents    stfinddevice  stsigtool  syncthing

I've never knowingly used these other binaries but perhaps they are
expected by somebody?

---

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#15730 (comment)

[fpletz]

Also, syncthing doesn't show a version in the log output and the web interface:

INFO: syncthing unknown-dev "Copper Cockroach" (go1.5.3 linux-amd64) nixbld1@octobuild 2016-05-28 00:37:27 UTC

[polendri]

@rycee: I'm not sure how useful those utilities are either, but I don't want to needlessly regress on functionality here; if someone thinks those utilities are noise and should be removed/optional, they can make another ticket. I added the "all" argument to the build script invocation and changed the install phase to copy "bin/*", and now I'm getting everything you listed in my output.

@fpletz: I added a -version flag to the build script invocation which sets the version. I didn't test it in the web GUI but "syncthing --version" shows me the correct version so we ought to be all set there.

[rycee]

@pshendry, tried it out. I got this:

output path ‘/nix/store/k0jg6pqdmfca3vf5ql7gds4gfsdcsl51-syncthing’ has r:sha256 hash ‘06wy4iij48qkmnkh3caq8knpw4sq4yrrl9waxwxyx38cb69rhazh’ when ‘0aa0nqi0gmka5r5dzph4g51jlsy7w5q4ri8f4gy3qnma4pgp7pg2’ was expected

so for some reason hash of the git download has changed?

I changed the hash to 06wy… and it then installs and runs OK. All the old binaries in bin are created and the version string looks fine. If the hash is figured out I would like to see this merged.

Many thanks for your work on this @pshendry!

[joachifm]

@rycee the mismatch could be due to #15469?

[rycee]

@joachifm, ah yes! That was it. I was testing by rebasing onto 16.03. When I build on master the hash matches.

[polendri]

So if I'm understanding it right, we're merge-ready then? :)

[fpletz]

Looks good now, thanks! 🍻