Hi,

On 12/17/25 19:12, Sebastiaan Couwenberg wrote:
For packages using Testsuite: autopkgtest-pkg-perl it should because of this CI job:

     Test-Command: /usr/share/pkg-perl-autopkgtest/runner build-deps
     Depends: @, @builddeps@, pkg-perl-autopkgtest
     Features: test-name=autodep8-perl-build-deps


I just realized that for non-autodep8 packages @builddeps@ is exported to the Testsuite-Triggers, but I don't think brintey2 does anything with that (didn't check the code). That would be a bug I want to fix soon. And maybe for "Testsuite: autopkgtest-pkg-*" packages it could assume @builddeps@ in Testsuite-Triggers.

I'm afraid that a proper solution requires access to d/t/control of the source packages, are you aware what makes that difficult to make available?


I don't know, but I can imaging we don't want all the sources there if all we need is d/t/control files.

Should I start a thread on debian-admin@ about possibilities for getting that available on respighi?


Be my guest. If that would be possible, I would work on improving britney2 with that info.

Being more liberal in pulling dependencies from unstable in newer version are available could be a solution too,


I think we strike a reasonable balance.

I have a script [0] that get a lists of dependencies that have newer versions in unstable.


And I think this is too much. Then we might as well just test in unstable instead of in testing.

Jobs scheduled under your account aren't available for britney2 (if that's what you're saying).
Then what did you mean with "It already does that." in response to my suggestions to make britney2 consider the results of CI jobs scheduled by others (meaning other user accounts)?


I already replied that I misread your message. The "it already does that" was meant for something else.

My suggestion is to let DDs schedule CI jobs with additional pin for dependencies in unstable, and have britney2 consider these results for the excuses instead of only the CI jobs it scheduled itself.


In my interactions, I often had to explain what we try to achieve and why we're often asking maintainers to fix their packages. Doing the above would, I fear, leave too much room for people to paper over things we don't want to be paper over. I rather opt for you asking me for help in the cases where britney2 doesn't do the right thing.

That those results are currently not available to britney2 is just another problem to solve with patches or whatever else is required.


If we want to go that route, sure. But at least I don't want to go there.

Paul

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature

Reply via email to