On Sat, Jul 25, 2026 at 07:20:50AM +0200, Jochen Sprickerhof wrote:
* Chris Hofstaedtler <[email protected]> [2026-07-24 13:20]:
Thanks. Indeed I wondered if there is a "design issue" with this
job: given the package was -just built- and thus all necessary data
should be available, the job should not need to rely on metasnap at
all?
This is a frequent annoyance for me too.
Note that debrebuild/debootstrap uses unstable and metasnap to find
packages. I ran the pipeline three more times:
https://salsa.debian.org/debian/pdns-recursor/-/jobs/10006412
https://salsa.debian.org/debian/pdns-recursor/-/jobs/10007298
https://salsa.debian.org/debian/pdns-recursor/-/jobs/10007534
And the third time it succeeded, while the missing packages are still
not available on metasnap right now, as it has a 24 hour delay. So my
hypothesis is that debrebuild did get an older unstable archive then
the sbuild job before, even hours after the dinstall run. I tried some
custom jobs to debug this but they did not show the same behaviour.
Currently I have no idea how to debug this further so would be happy
about any insights.
I've seen some cases where debsnap can't find the package yet because
it's still in incoming. For example, compare:
https://salsa.debian.org/python-team/packages/cryptodatahub/-/jobs/10019166
Get:1 http://incoming.debian.org/debian-buildd buildd-unstable/main amd64
linux-libc-dev all 7.1.5-1 [2021 kB]
https://salsa.debian.org/python-team/packages/cryptodatahub/-/jobs/10019173
cannot find:
linux-libc-dev:amd64=7.1.5-1
Could debrebuild perhaps try incoming as well as debsnap? I think that
would help in some common cases.
--
Colin Watson (he/him) [[email protected]]
