On 2025-02-19 10:41, Jochen Sprickerhof wrote:
* Philipp Kern <pk...@debian.org> [2025-02-16 17:16]:
we observed that some builds use build-depends from incoming.d.o
which then are not made available on snapshot.d.o (nor ftp.d.o)
because another upload of them happens during the same dinstall.
#1096112 "several binNMUs for bugs found on reproduce.debian.net
amd64.reproduce.debian.net"
shows this happens surprisingly often, in the bug we request
92 binNMUs on amd64 and 66 on i386 (and other archs are still
to be investigated.)
I've no idea how to best fix that but I wanted to file a bug so
we have a place to discuss solutions.
I don't think that's anything the buildds can fix, if the archive is
not
publishing all intermediate products.
The only way on the buildds would be build failures until the next
dinstall, which would be backwards IMO.
I think the root cause here is that snapshot is not integrated with
the
archive and only sees intermediate states and no incoming. So maybe
it's
a snapshot bug, but my feeling is that the ftp-team would need to
propose on how to fix that.
I agree that it would be nice to get intermediate products on
snapshot.d.o and I think there are two ways to do it.
1. Support incoming.d.o in snapshot.d.o. I don't know much about the
technical details but at least it sounds ambitious given the temporary
nature of incoming.
wanna-build gets a trigger whenever incoming.d.o updates. snapshot.d.o
could get the same access and slurp it up from there.
2. Integrate all intermediate products from incoming into the archive.
Given that incoming could hold multiple package version between a
dinstall I think that would mean adding all of them to the archive and
keep them for at least a dinstall. Again not sure about the technical
details but maybe dinstall could clean up old packages first and then
add new ones from incoming.
I'd strongly prefer that in addition, I think. But the nature of
snapshot means that it'd need to be a full archive, so maybe that would
only work for ingesting packages, not archive files.
Note that this bug is this is quiet a problem, we currently have 190
source packages in arch:all that can't be reproduced and we can't
binNMU easily:
https://all.reproduce.debian.net/stats/#packages-missing-on-metasnap-(maybe-temporary)
So maybe the step backward would actually be a step in the right
direction till we can solve this in a better way?
I disagree with this. Reproducible builds, as important as they are,
should not hold back Debian development velocity.
Kind regards
Philipp Kern
