Re: Don't run Salsa CI in vain - a disabled CI is better than a persistently failing one

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.