Package Details: syncthing-discosrv 1:1.20.2-1

Git Clone URL: https://aur.archlinux.org/syncthing-discosrv.git (read-only, click to copy)
Package Base: syncthing-discosrv
Description: Discover server for the syncthing P2P synchronization utility
Upstream URL: http://syncthing.net
Licenses: MIT
Submitter: prurigro
Maintainer: prurigro
Last Packager: prurigro
Votes: 11
Popularity: 0.000001
First Submitted: 2014-06-13 06:45 (UTC)
Last Updated: 2022-06-08 18:32 (UTC)

Latest Comments

mqs commented on 2020-06-26 17:21 (UTC)

@prurigo I just had an issue where my AUR helper(or even makepkg, I couldn't see it that well) tried to remove the previous build directory including the src/pkg folder. Some subdirectories in there are sadly marked read-only due to https://github.com/golang/go/issues/27161.

To prevent this, please add -modcacherw to the go commands (and consider also adding the other flags from the go packaging guidelines

prurigro commented on 2018-11-09 01:01 (UTC)

@hucsmn: Nice find! This is definitely the way to go here-- no need to worry about de-synchronized deps and way fewer make dependencies. Pulled your changes into the package. Thanks!

hucsmn commented on 2018-11-08 15:18 (UTC)

@prurigro I've just looked into the tarball release and found that it brings a correct copy of dependencies under the vendor directory. Vendor mechanism is supported since go 1.6, it requires the package to be located under GOPATH to enable package searching for vendor directory. Therefore there is no need to apply my previous dummy patch to fix those dependency problems introduced by go get. Just make a fake GOPATH and move the source code into $GOPATH/src/github/syncthing/syncthing to satisfy go toolchain, then it successfully build. The modified PKGBUILD is here: <http://sprunge.us/zJ1be3>. Redundant build dependencies (git, godep, mercurial) were also removed.

prurigro commented on 2018-11-08 00:11 (UTC)

Aha-- OK, hucsmn's patch works but an out of date $srcdir/src breaks things.

I released an update to v0.14.52 including the patch by hucsmn and the additional install instructions and systemd service fix provided by Iiridayn (credits included in the PKGBUILD- thanks!)

prurigro commented on 2018-11-06 03:29 (UTC)

@hucsmn: The build is still failing for me with your patch. Is this intending to fix 0.14.51 or the ALARM build? (I tested unsuccessfully on the former). If it's a versioning issue with go get, thoughts on having the package manually download dependencies with specified commits?

hucsmn commented on 2018-11-05 15:53 (UTC) (edited on 2018-11-05 15:53 (UTC) by hucsmn)

It failed to build because go get has no proper version control mechanism. Try this patch to work around: <http://sprunge.us/J2Vztx>, inserting the following line of code to build(): curl sprunge.us/J2Vztx | patch -p1 -d $_pkgname-$pkgver/cmd/$_binname

btw, 0.14.51 is available now.

jce3eSGPet2VJnpt commented on 2018-10-26 20:21 (UTC)

@prurigro I also get that same error on Arch ARM.

prurigro commented on 2018-10-02 20:18 (UTC) (edited on 2018-10-02 20:18 (UTC) by prurigro)

Hmm, I haven't tested the build on ALARM in a while-- is everyone else hitting that error on ALARM as well?

d9jWbb42kC3 commented on 2018-09-27 20:52 (UTC)

@mqs same error

edacval commented on 2018-09-17 01:53 (UTC)

@mqs same error

mqs commented on 2018-09-16 19:24 (UTC) (edited on 2018-09-16 19:25 (UTC) by mqs)

I had the following error while building:

[...]
cd /home/mqus/.cache/pacaur/syncthing-discosrv/src/syncthing-0.14.50/cmd/stdiscosrv
/usr/lib/go/pkg/tool/linux_arm/compile -o $WORK/b001/_pkg_.a -trimpath $WORK/b001 -p main -complete -buildid RAE0lcTwVVhM2gPCHMFJ/RAE0lcTwVVhM2gPCHMFJ -goversion go1.11 -D _/home/mqus/.cache/pacaur/syncthing-discosrv/src/syncthing-0.14.50/cmd/stdiscosrv -importcfg $WORK/b001/importcfg -pack -c=4 ./apisrv.go ./database.go ./database.pb.go ./main.go ./replication.go ./stats.go
# _/home/mqus/.cache/pacaur/syncthing-discosrv/src/syncthing-0.14.50/cmd/stdiscosrv
./stats.go:112:56: too many arguments in call to prometheus.NewProcessCollector
    have (int, string)
    want (prometheus.ProcessCollectorOpts)

Did I do something wrong? Edit: System is a raspberrypi 3 with archlinuxarm

Iiridayn commented on 2018-06-21 17:08 (UTC)

These steps were not 100% obvious to me.

I generated the keys with: openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 3650 -nodes

I then fixed ownership: chown -R syncthing:syncthing /var/discosrv

I ran systemctl edit syncthing-discosrv.service and added this:

[Service]
ExecStart=
ExecStart=/usr/bin/syncthing-discosrv -db-dir /var/discosrv/discosrv.db -cert /var/discosrv/cert.pem -key /var/discosrv/key.pem

prurigro commented on 2016-06-20 22:43 (UTC)

When I started this package there were no release tags, but I'll switch it over now that there are!

allspark commented on 2016-05-10 12:10 (UTC)

Hi, please orphan or change to releases

Siosm commented on 2016-04-27 04:27 (UTC)

As per https://wiki.archlinux.org/index.php/VCS_package_guidelines, packages building directly from git should be name pkgname-git. Please reupload this package with the correct name (syncthing-discosrv-git) and ask for the merge of this one with the new one to keep comments. This package should only be based on the release tags.

prurigro commented on 2015-09-14 23:47 (UTC)

@rumpelsepp: Interesting! Thanks for the FYI- I guess I'll have to wait for 0.12 to come out before upgrading

rumpelsepp commented on 2015-09-11 07:27 (UTC)

@prurigro: It does not connect because the master branch speaks the v0.12 discovery protocol; also it listens in a differnet port. I am too lazy to search this now, but it is somewhere documented. :)

prurigro commented on 2015-09-11 05:58 (UTC)

Alright, I just pushed an update that builds and runs via systemd service, and it should continue to work as things get updated upstream now that it's using go get. For some reason though, syncthing doesn't seem to want to connect to the server while it's running. Downgrading to a build from 10 days earlier does work, and one of the build between the two was built using the old way but still had the issue where it wouldn't connect, so I'm assuming this is an upstream problem... The version that works is 20150809, if anyone wants to force the package to build that commit. Let me know if you figure out a solution on that note!

prurigro commented on 2015-09-10 23:01 (UTC)

@rumpelsepp: Thanks for the link! Now that I know I can use go get, I'm rewriting the package to follow a similar strategy as the one used by the build.sh script. Stand by for a working update.

ThecaTTony commented on 2015-09-08 09:55 (UTC)

Again there is a missing github repo: git+https://github.com/golang/net.git Add an additional skip under sha512sums and under prepare() the following line: install -d src/golang.org/x mv crypto src/golang.org/x + mv net src/golang.org/x But the build don't compile anything, and the package by mistake takes the file src/github.com/syncthing/discosrv/main.go as syncthing-dircosvr A workaraund (ugly): cd /tmp git clone https://aur.archlinux.org/syncthing-discosrv.git cd syncthing-discosrv makepkg (and wait until fail to build) cd src/src/github.com/syncthing/discosrv export GOPATH=/tmp/syncthing-discosrv ./build.sh (as normal user) tar xvf discosrv-linux-amd64.tar.gz mv discosrv-linux-amd64/discosrv ./ cd $GOPATH nano PKGBUILD [change /main to /discosrv under last line of package()] makepkg -R sudo pacman -U syncthing-discosrv-20150820.r41.0dd76f7-1-x86_64.pkg.tar

timski commented on 2015-08-25 21:05 (UTC)

tried downgrading go to 1.4.2, same issue

timski commented on 2015-08-24 16:43 (UTC)

I fails to build on my machines ../syncthing/lib/beacon/multicast.go:14:2: cannot find package "golang.org/x/net/ipv6" in any of: /usr/lib/go/src/golang.org/x/net/ipv6 (from $GOROOT) /tmp/yaourt-tmp-tim/aur-syncthing-discosrv/src/src/golang.org/x/net/ipv6 (from $GOPATH) this seems to have been appeared after the last go upgrade

rumpelsepp commented on 2015-08-20 18:18 (UTC)

@prurigro: You said I should ping you when I have additional comments. I have just discovered that wiki article: https://wiki.archlinux.org/index.php/Go_package_guidelines#Using_go_get Since "go get" seems to be the recommended way of packaging go stuff, maybe you should reconsider using it. :) It also simplifies the PKGBUILD.

tech commented on 2015-08-06 20:51 (UTC)

@ThecaTTony This worked, thanks!

ThecaTTony commented on 2015-08-06 20:00 (UTC)

@tech Add this to sources: 'git+https://github.com/golang/snappy.git' An additional 'SKIP' to sha512sums and change this: install -d src/github.com/golang mv groupcache src/github.com/golang/ To this: install -d src/github.com/golang mv groupcache src/github.com/golang/ mv snappy src/github.com/golang/

tech commented on 2015-07-22 00:47 (UTC)

Hi, This fails to build on my system. I'm running 64 bit Arch Linux and have installed all the dependencies. ==> Starting build()... ../../syndtr/goleveldb/leveldb/table/reader.go:17:2: cannot find package "github .com/golang/snappy" in any of: /usr/lib/go/src/github.com/golang/snappy (from $GOROOT) /tmp/pkgbuild-1000/syncthing-discosrv/syncthing-discosrv/src/src/github. com/golang/snappy (from $GOPATH) ==> ERROR: A failure occurred in build(). Aborting... -> Status built (1): syncthing-discosrv

prurigro commented on 2015-06-18 18:16 (UTC)

Hmm, that won't work for people running both on their system eh? I might have to change back

rumpelsepp commented on 2015-06-18 07:32 (UTC)

Syncthing does not support gcc-go; it may be the same for the discosrv as well. https://github.com/syncthing/syncthing/issues/1889

prurigro commented on 2015-06-18 06:20 (UTC)

@Voice: I've updated the package to use gcc-go, thanks for letting me know!

Voice commented on 2015-05-27 23:43 (UTC)

We now have core/gcc-go vs. community/go. Perhaps the makedep could change to the more "official" language package. Notes: http://stackoverflow.com/questions/25811445/what-are-the-primary-differences-between-gc-and-gccgo (1) "Compared to gc, gccgo is slower to compile code but supports more powerful optimizations, so a CPU-bound program built by gccgo will usually run faster." (2) "The gc compiler supports only ... x86 (32-bit and 64-bit) and ARM. Gccgo, however, supports all the processors that GCC supports." (3) Update for my i686 glitch, it traced to Go language use of SSE2 on AMD. PKGBUILD for community/go says it enables i686 SSE2 against Arch Linux convention. https://projects.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/go So on i686 AMD you need local Arch Build System recompilation. It works fine and the claim about slowness rings hollow. I think the devs didn't tune their i686 system. Of course core/gcc-go would produce more optimized code than community/go. I suppose core/gcc-go also follows Arch convention (no SSE2 on i686).

rumpelsepp commented on 2015-04-10 23:25 (UTC)

Great! I'll have a look tomorrow or so. :) Thanks a lot! :)

prurigro commented on 2015-04-10 23:03 (UTC)

@rumpelsepp: Hey, thanks for the pointers! Let me respond to each: * All downloads are supposed to be handled by the PKGBUILD and not scripts or tools (ie: npm, cabal, gem, etc.), though I do break this rule sometimes when it gets really hairy :) * When I wrote this I wasn't aware of getent, and I hadn't looked in the .install in quite some time- this has been changed. Your script tries to create the user and group separately, but this isn't necessary (both are created with useradd) * The user is no longer removed, and I took out the systemctl daemon-reload too since that's also a security issue. I'm leaving the user/group name the same in this package so there are no conflicts for people updating. * I've pulled your .service in aside from the update to the user/group name. * ^^ same response as above * I went with a .install closer to yours, though did things a bit differently. * The license started out being MIT, then appears to have become GPLv3 for a while, so you were right when you made your post, but it appears to have returned to MIT since then :) https://github.com/syncthing/discosrv/blob/master/LICENSE * I switched the syncthing user's shell to /bin/nologin Thanks for the tips, and feel free to make additional comments if you have any. I'll post my updated package once I've tested it- Cheers!

rumpelsepp commented on 2015-03-23 22:07 (UTC)

Hi, a few things: * why do you not use "go get"? * why do you parse /etc/passwd? * why do you remove the user after removing the package? This is a security issue: https://www.archlinux.org/todo/usergroup-management/ * The service file can gain a few security features. * Add SuccessExitStatus=2 to the service, as it prevents failed stops. * No need to call systemd-tmpfiles --create syncthing-discosrv.conf after every update. After install it's fine. * License is wrong -> GPL * Don't use /bin/false, use /bin/nologin instead. There were some reasons for that on the mailing list, I don't remember them at the moment. If you are interested google it. So that's it. I have improved the scripts here: https://gitlab.sevenbyte.org/rumpelsepp/aur_packages/tree/master/syncthing-discosrv

Voice commented on 2014-12-05 00:53 (UTC)

syncthing-discosrv i686 build fail 20141021.r29.fcba610-3 http://mypastebin.com/EdhsvLDM3eto Still i686 AMD failure today - go language issues I guess

prurigro commented on 2014-11-29 00:28 (UTC)

Whoops, forgot to bump the pkgrel

prurigro commented on 2014-11-29 00:27 (UTC)

@Anthony25: Ahh, I saw your email pop up and fixed the issue before checking to see what it said (not realizing you'd supplied the fix yourself), but I would have totally used yours otherwise; thanks for doing it up! On a side note, I think I need to go ahead and add an attempt at building to my package update checking system because it clearly breaks more often than a new version comes out :)

Anthony25 commented on 2014-11-29 00:08 (UTC)

Hello, I fixed the issue with gosnappy and syndtr : https://gist.github.com/Anthony25/2353cff59c383885ec3b

prurigro commented on 2014-11-12 14:32 (UTC)

@Voice: Thanks for pointing that out- the difficulty with packages that rely on a ton of git deps like this one is that the requirements can change without the upstream project changing anything. I suppose I could hardcode the commits, but that's a headache in a different direction :) In any case, the build should work now- let me know if you still have problems!

Voice commented on 2014-11-11 06:47 (UTC)

syncthing-discosrv i686 build fail 20141021.r29.fcba610-1 http://mypastebin.com/sc3tjKOJC4tX AMD CPU

Voice commented on 2014-10-23 01:51 (UTC)

syncthing-discosrv i686 build fail http://mypastebin.com/JUV7mP1SsLfx

prurigro commented on 2014-10-06 11:33 (UTC)

@XenGi: Thanks-- turns out the devs aren't really pushing updates for discosrv that reflect the client versions, and trying to use a specific client to build from would break as soon as they updated the discosrv repo, so instead the package will now use the git master of the discosrv repo and build against whatever the current master for syncthing is. This should reduce the likelihood of things breaking in the future :)

XenGi commented on 2014-09-30 16:45 (UTC)

Build fails with version 0.9.18-1. ==> Starting build()... main.go:33:2: cannot find package "github.com/syncthing/syncthing/internal/discover" in any of: /usr/lib/go/src/pkg/github.com/syncthing/syncthing/internal/discover (from $GOROOT) /tmp/yaourt-tmp-xengi/aur-syncthing-discosrv/src/src/github.com/syncthing/syncthing/internal/discover (from $GOPATH) main.go:34:2: cannot find package "github.com/syncthing/syncthing/internal/protocol" in any of: /usr/lib/go/src/pkg/github.com/syncthing/syncthing/internal/protocol (from $GOROOT) /tmp/yaourt-tmp-xengi/aur-syncthing-discosrv/src/src/github.com/syncthing/syncthing/internal/protocol (from $GOPATH)

DaveCode commented on 2014-07-24 05:33 (UTC)

Get in touch with http://jasonwryan.com/blog/2014/05/10/syncthing/

prurigro commented on 2014-06-22 08:53 (UTC)

To use a custom discovery server with a syncthing client, you need to manually edit ~/.config/syncthing/config.xml and change the contents of <globalAnnounceServer> to the address of your server.