It seems that syncthing is stuck at version 1.17.0-1 . It has been flagged out of date since 2021-07-06 . The newest version is 1.18.0 . I noticed this when syncthing in my phone updated to 1.18.0 but on my laptop it didn’t . So does anyone know anything about this ?
I0F
July 26, 2021, 12:19pm
2
Maintainer probably on holiday or had no time to update it in general. Or there is some sort of problem with the new version when building for arch.
1 Like
I0F
July 26, 2021, 12:35pm
3
There is a an AUR binary package , that is on version 1.18. Maybe use that in the meantime.
You can also grab an updated version compiled from the Arch PKGBUILD from my repo [sig ].
1 Like
dalto
July 26, 2021, 1:40pm
5
It is odd that there is a binary package in AUR for something that is also in the repos. I thought that was against the rules?
1 Like
It is unless there are mitigating circumstances, e.g. the upstream binary is somehow compiled “differently” or there are other changes:
https://wiki.archlinux.org/title/AUR_submission_guidelines#Rules_of_submission:
The submitted PKGBUILDs must not build applications already in any of the official binary repositories under any circumstances. … Exception to this strict rule may only be packages having extra features enabled and/or patches in comparison to the official ones.
1 Like
dalto
July 26, 2021, 2:43pm
8
Well…Arch does apply this single line patch so I guess you could argue it is different.
diff -aur syncthing.old/build.go syncthing/build.go
--- syncthing.old/build.go 2019-09-07 20:03:56.466643638 +0200
+++ syncthing/build.go 2019-09-07 20:05:18.164000404 +0200
@@ -343,7 +343,6 @@
if runtime.GOARCH == "amd64" {
switch runtime.GOOS {
case "darwin", "linux", "freebsd": // , "windows": # See https://github.com/golang/go/issues/27089
- args = append(args, "-race")
}
}
1 Like
There might be an outstanding bug:
opened 11:07PM - 19 Aug 18 UTC
RaceDetector
OS-Windows
NeedsInvestigation
### What version of Go are you using (`go version`)?
go version go1.11rc1 win… dows/amd64
### Does this issue reproduce with the latest release?
- Yes, reproduces with `go 1.11rc1`
- No, doesn't reproduce with `go 1.10.3`
### What operating system and processor architecture are you using (`go env`)?
```
windows/amd64
```
```
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\jud_white\AppData\Local\go-build
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=C:\Projects\Go
set GOPROXY=
set GORACE=
set GOROOT=C:\Go
set GOTMPDIR=
set GOTOOLDIR=C:\Go\pkg\tool\windows_amd64
set GCCGO=gccgo
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=C:\Users\JUD_WH~1\AppData\Local\Temp\go-build672193350=/tmp/go-build -gno-record-gcc-switches
```
### What did you do?
```
$ go test -cpu 1,2,4 -count 1 --race ./hello/...
# runtime/cgo
exec: "gcc": executable file not found in %PATH%
FAIL git.xyz.com/{org}/{repo}/cmd/hello [build failed]
$ go test -cpu 1,2,4 -count 1 ./hello/...
ok git.xyz.com/{org}/{repo}/cmd/hello 0.105s
```
It doesn't happen for non-main packages:
```
$ go test -cpu 1,2,4 -count 1 --race ./hellopkg/...
ok git.xyz.com/{org}/{repo}/pkg/hellopkg 10.220s
```
`--race` by itself is sufficient to repro, you don't need to set the CPU count or disable caching.
### What did you expect to see?
```
ok git.xyz.com/{org}/{repo}/cmd/hello 0.XYZs
```
### What did you see instead?
```
# runtime/cgo
exec: "gcc": executable file not found in %PATH%
FAIL git.xyz.com/{org}/{repo}/cmd/hello [build failed]
```
Not sure how upstream is compiling it if there’s an issue compiling with Go… maybe a different Go version than the one in the repos?