Bug#1120799: release.debian.org: CI job scheduling is not aware of transitions
On 11/24/25 9:46 PM, Paul Gevers wrote:
Thanks for your work on this.
You're welcome.
On 11/16/25 14:30, Bas Couwenberg wrote:
The dependency resolution currently uses UDD, because I didn't yet
figure out how to use python-apt's apt_pkg to do a Trivial-Only run
in forky chroot on a trixie system, pointers are very welcome.
britney2 uses apt_pkg indeed, loading the archive is done in britney2/utils.py and britney2/inputs/suiteloader.py
Thanks, I'll have a look at those and have another stab at getting apt to do the dependency resolution.
How difficult is it to setup a test instance for that?
I have a test instance of britney2 on respighi in ~elbrus/britney2. I created some directories with the right symlinks to the live data and the rest I handle in ~elbrus/bin/britney-elbrus, which is mostly about copying state from the real britney instance to some directories where my instance can write updates and to drive britney2 with my configuration (which is mainly a delta in directories and occasionally new configuration I want to try).
I'll have a look at that as well.
setting-up-britney.rst doesn't look very daunting, but I suspect it
leave out a lot of details.
Yes and no. It leaves out details on how you can further change the behavior of britney with its configuration, but it seems most of the setup is described.
Before I spend more time on this, I'd like to hear what you think of
this approach.
One thing that's important to realize is that britney2 is meant to not do any collecting of data by itself. All data sources have to be available on respighi, either via a mount by DSA or pre-fetched by britney1 (which is supposed to be rather dumb). As I think britney2 already has nearly all the information internalized that is needed, it could do a guess at which transitions are ongoing, very similar to the auto-transition script and calculate the involved packages from there.
I think I spotted that you are parsing the d/t/control file. Currently we don't have those available on respighi (and I don't think we need this for your solution to work).
I don't see how we can do without d/t/control to get the test dependencies, those tend to be similar to Build-Depends and Depends but they are not the same, and the test dependencies are not available in Sources.gz or Packages.gz
I guess you're suggesting to just limit the dependency resolution to the binary packages of the source package to be tested using Depends and Recommends from Packages.gz, that likely covers most but not autopkgtests.
Kind Regards,
Bas
--
PGP Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Reply to: