Syncthing: Update to v2.0.12

[mreid-tt]

Description

This PR includes the following:

1. Update Syncthing to v2.0.12 (built with Go 1.25).
2. Drop legacy ARMv5 models that required the Go 1.23 compiler.

Fixes #6721

Checklist

• Build rule all-supported completed successfully
• New installation of package completed successfully
• Package upgrade completed successfully (Manually install the package again)
• Package functionality was tested
• Any needed documentation is updated/created

Type of change

• Package update

[hgy59]

@mreid-tt please let @acolomb join in.

see #6721 (comment)

AFAICR a package update has to ensure that syncthing was autoupdated to 2.x before the update.

[hgy59]

@mreid-tt there is no need for such "staging sqlite"
only depend on cross/sqlite
and use

	  CGO_CFLAGS="-I$(STAGING_INSTALL_PREFIX)/include" \
	  CGO_LDFLAGS="-L$(STAGING_INSTALL_PREFIX)/lib -Wl,-rpath,\$$ORIGIN/../lib -Wl,--rpath-link,$(STAGING_INSTALL_PREFIX)/lib -lsqlite3 -lz" \

No need to install sqlite libraries, those are already installed into workdir/install/...

The real issue here is, that cgo (the go c compiler) defines an argument -m64 that is invalid for all cross compilers (except x64).

I faced a similar issue in cross/helix, but this was with rust and I had to patch the compiler crate to fix this. I have no idea how the cgo works and didn't find a way so far to make the build verbose to find the cause...

[hgy59]

@mreid-tt we can't build syncthing with dependency to libsqlite.so

The syncthing build does not support builds with CGO_ENABLED (despite the dev docs say so).
I tried several approaches like build build.go for host and run it to build the target, patching build.go, ...

BUT even if we could cross compile, it is worth nothing, because of the autoupdate.
The packages installed by autoupdate do not depend on libsqlite either.

BTW we need to create syncthing v2.0.11 to test the autoupdate at first installation (and dont't forget to test a package update with an installation that already is auto updated to v2.0.12 to verify that it does not downgrade).

@acolomb is there really an sqlite performance issue with the official syncthing binaries?

[acolomb]

@acolomb is there really an sqlite performance issue with the official syncthing binaries?

Not that I know of, quite the contrary. The official builds have been configured to use the best-performing variant. I've read reports about some Docker images which were produced and distributed by third parties, where the performance was less than optimal. IIRC they ended up with the "modernc" build, see e.g. here.

I don't see any need to make sure the installed version has previously auto-updated to v2 before installing the new package. What we do need to avoid is "upgrading" to an SPK containing an older version than the one already obtained through auto-upgrades. But that is already handled for a few years, by simply not replacing the binary if it's already newer.

We should check again how that version check works though, as some early v2.0.x versions didn't accept --version, see syncthing/syncthing#10269.

I think we're fine building the way we did so far. As a "trust anchor", the SPK contains a version built from verified source. That one should use the cross-compiled libsqlite, which probably won't require installation on the system though, as the Go binaries are statically linked IIRC. The internal upgrader then replaces that trusted binary with a newer one, while keeping the trust chain intact through its internal signature verification. The trust basically shifts from Syncthing's source code + SynoCommunity's build scripts to solely the digitally signed binaries from the Syncthing Foundation.

What part in that scenario are you having build troubles with?