Bug#1123074: release.debian.org: Help doxygen migrate to testing
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
Reply to: