Hi, Whilst working on the Reproducible Builds effort [0], we noticed that siso could not be built reproducibly. This is because the manpage embeds three nondetermistic values; two UUIDs and the absolute path to the build user's home directory. A hacky patch is attached that post-processes the manpage in debian/rules, although a better solution would be to modify the upstream code to calculate these values separate from "flags" module's concept of default values. [0] https://reproducible-builds.org/ Regards,
Hi Chris, I had this MR prepared to deal with this It is awaiting sponsoring from the go-team https://salsa.debian.org/go-team/packages/siso/-/merge_requests/5 Upstream we had this related CL: https://chromium-review.googlesource.com/c/build/+/7867164 not yet merged Best, Juan
Juan M. Méndez Rey <juan.mendezr@proton.me> writes: Consider bumping to compat 14. There are also some lintian complaints about missing sources for *.js files, are these real? X: siso source: source-is-missing [siso/third_party/material_web_components/components-chromium/node_modules/@lit/task/deep-equals.js] X: siso source: source-is-missing [siso/third_party/material_web_components/components-chromium/node_modules/@lit/task/task.js] X: siso source: source-is-missing [siso/third_party/material_web_components/components-chromium/node_modules/@material/web/button/internal/elevated-styles.js] X: siso source: source-is-missing [siso/third_party/material_web_components/components-chromium/node_modules/@material/web/button/internal/filled-styles.js] X: siso source: source-is-missing [siso/third_party/material_web_components/components-chromium/node_modules/@material/web/button/internal/filled-tonal-styles.js] X: siso source: source-is-missing [siso/third_party/material_web_components/components-chromium/node_modules/@material/web/button/internal/outlined-styles.js] X: siso source: source-is-missing [siso/third_party/material_web_components/components-chromium/node_modules/@material/web/button/internal/shared-elevation-styles.js] ... /Simon
[siso/third_party/material_web_components/components-chromium/node_modules/@material/web/button/internal/shared-elevation-styles.js]
Thanks, Simon!
Let's fully fix this reproducibility issue.
What would help, in order:
1. Get node-rollup-plugin-virtual (ITP https://bugs.debian.org/1141546) through
NEW. It unblocks node-lit's reproducibility fix (MR #2), which is what keeps
node-lit, and therefore siso, out of testing.
https://salsa.debian.org/mendezr/node-rollup-plugin-virtual
2. Get node-material-web (ITP https://bugs.debian.org/1140320) through NEW.
Packaged on my fork and is what clears the remaining @material/web tags.
https://salsa.debian.org/mendezr/node-material-web
New MR for siso 1.5.22+ds-1, addressing the issues you pointed out.
https://salsa.debian.org/go-team/packages/siso/-/merge_requests/6
Although I would prefer to merge this, once we can update this MR after the others have been moved in.
Thanks,
Juan
Hi Simon, Chris, all,Hi Simon, all, Thanks for uploading siso 1.5.22+ds-1, that should clear the @lit/task tags and the compat 14 point. To simplify what I asked before: siso now only needs node-lit to be reproducible and in testing. And that no longer has to wait for anything in NEW. I have opened a self-contained node-lit fix https://salsa.debian.org/homeassistant-team/js/node-lit/-/merge_requests/3 The usual js-team DD that kindly helped in previous iterations, has been unavailable for some weeks, so a sponsor here would unblock the whole chain of node-lit moving to testing and hence siso too. (node-rollup-plugin-virtual and node-material-web are still worth having, but they are source cleanup, not migration blockers, so there is no need to wait for them through NEW.) Any help to unblock those is welcome. Best, Juan
Juan M. Méndez Rey <juan.mendezr@proton.me> writes: Your reproducible fix wasn't complete, see: https://reproduce.debian.net/amd64/api/v1/builds/281531/artifacts/755699/diffoscope │ │ ├── ./usr/share/man/man1/siso.1.gz │ │ │ ├── siso.1 ... │ │ │ │ -.IP "\fB\-fs_state_compression_threads\fR=\fI6\fR" 4 │ │ │ │ +.IP "\fB\-fs_state_compression_threads\fR=\fI4\fR" 4 If you make an update, I can review and upload. My javascript/node knowledge is weak, and I'm not a member of the Home Assistant team, so I can't help with this. /Simon
Thanks Simon for spotting this. What do you think about: https://salsa.debian.org/go-team/packages/siso/-/merge_requests/7 El viernes, 21 de agosto de 2026 a las 08:25, Simon Josefsson <simon@josefsson.org> escribió:
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? Thanks, Juan
Juan Manuel Méndez Rey <juan.mendezr@proton.me> writes: The simplest is to upload a new version to trigger new (re-)builds. I see upstream 1.6.0 was just released, maybe packaging that would work? /Simon
El lunes, 14 de septiembre de 2026 a las 10:29, Simon Josefsson <simon@josefsson.org> escribió: I thought about that, but the latest siso versions come with their own set of challenges. It is definitely possible, but not as straightforward as the previous ones we got so far. I can start working on the next versions in parallel, but I wonder if there is someone that could re-trigger it, just to have siso in testing and ready (just in case...the challenges takes us a lot of time) Thanks, Juan
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?
If I'm understanding correctly, all you need is to have the existing siso package rebuilt (eg, a binNMU https://wiki.debian.org/binNMU)? Does it need to happen for all architectures?
El lunes, 14 de septiembre de 2026 a las 18:43, Andres Salomon <dilinger@queued.net> escribió: Sorry Andres for the delay, somehow this message went to the spam folder, it seems protonmail still needs to learn better. Since I don´t have maintainer rights, I went the long trip, and packaged the next siso version (1.6.2). That is major upgrade that requires also upgrading the whole golang opentelemetry packages (and testing all their rdeps), and the transition must go through experimental first. I am in coordination with members of the go team to see this through: If you are curious: https://salsa.debian.org/go-team/packages/golang-opentelemetry-otel/-/merge_requests/4 I will send you an update once these packages has been sponsored, and I might need another sponsor for the next upload of siso. Best, Juan
El jueves, 24 de septiembre de 2026 a las 02:03, Juan M. Méndez Rey <juan.mendezr@proton.me> escribió: I realize also, no matter the road taken explained in my previous message. If you could do a binNMU only for i386, I would say that would be enough for current siso version, if it is useful to have it sooner in testing. Thanks, Juan
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"
hi, sorry for the late reply... done. However the package is still blocked from migrating because of #1150132 and the autopkgtests still fail on i386 as tracker.d.o/siso shows: Issues preventing migration: ∙ ∙ Updating siso would introduce bugs in testing: #1150132 ∙ ∙ Autopkgtest for siso/1.5.22+ds-2: amd64: Pass, arm64: Pass, armhf: Pass, i386: Failed ♻, ppc64el: Pass, riscv64: Pass, s390x: Pass ^^ these ∙ ∙ siso/amd64 has unsatisfiable Built-Using on golang-github-cespare-xxhash 2.3.0-2 ∙ ∙ siso/arm64 has unsatisfiable Built-Using on golang-github-cespare-xxhash 2.3.0-2 ∙ ∙ siso/armhf has unsatisfiable Built-Using on golang-github-cespare-xxhash 2.3.0-2 ∙ ∙ siso/i386 has unsatisfiable Built-Using on golang-github-cespare-xxhash 2.3.0-2 ∙ ∙ siso/loong64 has unsatisfiable Built-Using on golang-github-cespare-xxhash 2.3.0-2 ∙ ∙ siso/ppc64el has unsatisfiable Built-Using on golang-github-cespare-xxhash 2.3.0-2 ∙ ∙ siso/riscv64 has unsatisfiable Built-Using on golang-github-cespare-xxhash 2.3.0-2 ∙ ∙ siso/s390x has unsatisfiable Built-Using on golang-github-cespare-xxhash 2.3.0-2 ^^ these also mean you need to reupload (or rebuild) Additional info (not blocking): ∙ ∙ New but not reproduced on i386 - info: siso ∙ ∙ Reproducibility issues ignored for siso on i386 as requested by jspricke ∙ ∙ Reproducibility unknown for siso but ignored on i386 as requested by jspricke ^^ this is fine.
Hello everyone, Thanks Holger for taking a look. I believe the best solution is to get the next version uploaded that already contain all the fixes. siso 1.6.4+ds-1 is packaged and green in MR !8 (https://salsa.debian.org/go-team/packages/siso/-/merge_requests/8), Fixing the otel-1.46 FTBFS (#1150132), the i386 autopkgtest, and the stale xxhash Built-Using Could another go-team DD sponsor the upload, since Simon is short on time? debian-go team is on CC: Best, Juan