* 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?
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/10007534And 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.
Regarding the design issue: For a build against unstable the job assumes that it can get at least the same archive state as the sbuild job before. It would also be possible to cache the build dependency packages between the jobs but we don't have enough storage for that. For builds against other suites or distributions we discussed to make the apt repos in debrebuild/debootstrap configurable but I am not aware of a patch yet.
Cheers Jochen
signature.asc
Description: PGP signature
