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
