Package: release.debian.org
User: [email protected]
Control: affects -1 + src:siso
Usertags: binnmu
Hi,
siso in sid has been unable to migrate to testing due a non-reproducible
build with i386. From bug #1141687 , it sounds like a toolchain bug that
has since been resolved; all it needs is a rebuild. I did two subsequent
uploads of siso to debusine
(https://debusine.debian.net/debian/developers/work-request/1406829/ ,
https://debusine.debian.net/debian/developers/work-request/1406880/ ),
and in both cases readelf showed the binary has having the same Build ID
(b09a642b4c6e713dddb7600f32e0bc136eb9a628).
For various reasons the new upstream release packaging is delayed, so
for now we'd appreciate a binNMU so it can finally migrate to forky. Thanks!
nmu siso_1.5.22+-2 . ANY . unstable . -m "Rebuild to make reproducible"
On 9/14/26 05:41, Nicolas Peugnet wrote:
On 13/09/2026 23:57, Juan Manuel Méndez Rey wrote:
Hi Simon,
With node-lit now in testing and the man-page fix in 1.5.22+ds-2, siso
is one
step from migrating. The only remaining blocker is i386 reproducibility;
amd64, arm64 and armhf all reproduce, autopkgtests pass everywhere,
and it is
past the age requirement.
The i386 diffoscope shows the only difference is the Go build id: the
compiled
code is byte-identical (the content-id segments match), only the
build-input
hash and what derives from it differ. -trimpath is applied, and the
failing
rebuild is a week after the original, so this looks like toolchain
skew rather
than a packaging defect. It is not general to Go on i386 (restic, hugo,
syncthing, prometheus, gopls are GOOD), though docker.io is also BAD.
https://reproduce.debian.net/i386/api/v1/builds/233849/
artifacts/596446/diffoscope
Does the i386 result hard-block migration? If a fresh rebuild would
likely
clear it, can you trigger one, or who can?
I added @holger in CC as his e-mail is listed in the footer of
reproduce.debian.net, maybe he can do something about it?
