On 12/17/25 6:51 PM, Paul Gevers wrote:
On 12/17/25 18:37, Sebastiaan Couwenberg wrote:
As I told you there, britney2 would need to get access to d/t/control. The
infrastructure for that isn't in place.
The source package build dependencies are binary dependencies are available,
which should suffice in this case.
We can have a debate if britney2 should take Build-Depends into consideration
for autopkgtesting. But so far I've always thought it shouldn't.
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
https://manpages.debian.org/trixie/autodep8/autodep8.1.en.html#perl_(libtest-most-perl).
It does that for most cases (that I'm aware of), but not for versioned *test*
dependencies.
The test dependencies in this case get populated from Build-Depends-Indep by
autodep8:
Right, so this feels like a variant of bug 1070040. I haven't come up with a
decent solution for the magic that autodep8 does viewed from britney2's angle.
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?
Should I start a thread on debian-admin@ about possibilities for getting that
available on respighi?
Being more liberal in pulling dependencies from unstable in newer version are
available could be a solution too, I have a script [0] that get a lists of
dependencies that have newer versions in unstable.
For analizo this included:
Newer Dependencies:
src:analizo
- analizo (1.25.5-3)
src:doxygen
- doxygen-doxyparse (1.15.0+ds1-1+b1)
But also all transitive dependencies down to glibc.
[0]
https://salsa.debian.org/sebastic/release.debian.org/-/blob/transition-autopkgtest/bin/newer-dependencies-in-unstable.py?ref_type=heads
Because the jobs I schedule don't get reflected as successes in the excuses.
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)?
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.
That those results are currently not available to britney2 is just another
problem to solve with patches or whatever else is required.
Kind Regards,
Bas
--
PGP Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
