Hi Simon, answering here for more visibility.
* Simon McVittie <[email protected]> [2026-06-19 11:32]:
Can reproduce.debian.net jobs be retried, to see whether this might be a one-off glitch?
Non reproducible packages are retried 3 times automatically and you can always ask in #debian-reproducible. A self service is in the works. flatpak is in the queue but it is currently rather long.
Are reproduce.debian.net amd64 machines known to be significantly (orders of magnitude!) slower than official amd64 buildds, or my laptop, or even riscv64 buildds?
No, they are reasonably fast from my experience and for sure faster then riscv64.
Or does reproduce.debian.net perhaps parallelize builds of unrelated packages on the same machine, which might have caused the tests to be extra-slow?
No, they are KVM on top of Cascadelake Intel Xeon Processor with one build per VM.
I also wonder whether running the build-time test-suite is necessary for reproduce.debian.net's goals: if we're trying to prove that the binaries in the archive are genuine, it seems to me that a build with the nocheck option would be sufficient for demonstrating that. Obviously test-suites that don't always work are a bug, but perhaps that's orthogonal to whether an existing package can be reproduced?
That is surely desirable but currently the goal of reproduce.d.n is to match the Debian buildds as close as possible and not to add more variation. After all this should be a QA system and not pose more work for the maintainers. reproducible-builds.org is using nocheck and once that is well established in the archive we can also think about enabling that on reproduce.d.n.
Cheers Jochen
signature.asc
Description: PGP signature
