On Sun, Aug 04, 2024 at 01:00:38PM +0200, Paul Gevers wrote:
> Hi Wouter,
>
> On Sat, 3 Aug 2024 20:07:14 +0200 Wouter Verhelst <wou...@debian.org> wrote:
> > In the nbd autopkgtest, I need to do a debootstrap of "whatever we are
> > currently running". That code starts off with "parse os-release", and
> > then falls back to a horrible horrible perl script that parses
> > apt-cache policy output if os-release looks like testing or unstable,
> > because the autopkgtest needs to test the version that we're running,
> > not "always unstable", and this is just a pain. If os-release were to
> > distinguish "unstable" from "testing", then I would be able to get rid
> > of that perl script (and good riddance)
>
> If I read correctly then what you describe here you fell in the trap that
> helmut mentioned earlier (but maybe you realized and implemented it
> correctly). You should run in the same environment that is prepared as your
> testbed.
This is off-topic for the ctte discussion, but: this part of the
autopkgtest is about testing the initrd scripts in the nbd package,
which you can only do by booting a VM image. This requires us to
generate something that can be booted over an NBD connection, which we
do by way of "debvm-create" (whose implementation uses debootstrap).
We then export this generated image through the nbd server that is
installed in the testbed, and then use "debvm-run" to boot the image
over NBD.
This is very much a corner case, but *in order* for me to test what the
testbed provides, I need to know what it is, exactly, that it is
providing, and that does not appear to be in the autopkgtest API beyond
the "use what is installed", and that just doesn't work when I need to
generate a bootable image.
Perhaps if autopkgtest were to pass debootstrap arguments to be used for
creation of a chroot if the test requires it, then I could stop using my
script, but in the mean time...
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
I will have a Tin-Actinium-Potassium mixture, thanks.
