Your message dated Wed, 27 Apr 2022 14:46:38 -0400
with message-id <8735hyqs8h....@curie.anarc.at>
and subject line Re: Bug#911977: how do we correctly guess the VM name in
autopkgtest?
has caused the Debian Bug report #911977,
regarding how do we correctly guess the VM name in autopkgtest?
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
911977: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911977
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: sbuild
Version: 0.77.1-1
Severity: wishlist
One of the nice things with the schroot backend is that it
automatically guesses which schroot to use based on internal sbuild
logic. If I build a stretch-security update, it will find my stretch
chroot, for example.
This doesn't seem to work with the autopkgtest backend:
$ sbuild --chroot-mode=autopkgtest --autopkgtest-virt-server=qemu
[...]
dpkg-source: info: building gnupg2 in gnupg2_2.1.18-8~deb9u3.debian.tar.bz2
dpkg-source: info: building gnupg2 in gnupg2_2.1.18-8~deb9u3.dsc
dpkg-source: info: using options from gnupg2-2.1.18/debian/source/options:
--compression=bzip2 --compression-level=9
sbuild (Debian sbuild) 0.77.1 (10 September 2018) on curie.anarc.at
+==============================================================================+
| gnupg2 2.1.18-8~deb9u3 (amd64) Fri, 26 Oct 2018 19:13:13 +0000 |
+==============================================================================+
Package: gnupg2
Version: 2.1.18-8~deb9u3
Source Version: 2.1.18-8~deb9u3
Distribution: stretch
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64
Build Type: full
usage: autopkgtest-virt-qemu [-h] [-q QEMU_COMMAND] [-o OVERLAY_DIR] [-u USER]
[-p PASSWORD] [-c CPUS] [--ram-size RAM_SIZE]
[--timeout-reboot SECONDS] [--show-boot] [-d]
[--qemu-options QEMU_OPTIONS] [--baseimage]
[--efi]
image [image ...]
autopkgtest-virt-qemu: error: the following arguments are required: image
Undefined chroot status
E: Error creating chroot session: skipping gnupg2
Now of course I can fix this by passing the image in an argument, but
then I am hardcoding that image path which is release dependent.
Shouldn't it be better for sbuild to correctly figure that out?
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (500, 'testing'), (1, 'experimental'), (1, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8),
LANGUAGE=fr_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages sbuild depends on:
ii adduser 3.118
ii libsbuild-perl 0.77.1-1
ii perl 5.26.2-7+b1
Versions of packages sbuild recommends:
ii autopkgtest 5.6
ii debootstrap 1.0.109
ii schroot 1.6.10-5
Versions of packages sbuild suggests:
ii deborphan 1.7.30
ii kmod 25-1
ii wget 1.19.5-1
-- debconf-show failed
--- End Message ---
--- Begin Message ---
On 2022-03-09 09:36:13, Johannes Schauer Marin Rodrigues wrote:
> Hi,
>
> Quoting Andrea Pappacoda (2022-02-19 15:39:12)
>> > I have in my ~/.sbuildrc:
>> >
>> > $autopkgtest_opts = [ '--', 'schroot', '%r-%a-sbuild' ];
>> >
>> > The %r and %a escapes expand to the current distribution and architecture.
>>
>> Thanks, this works really well! Would it be possible for sbuild to pass
>> these options by default when the backend is schroot? This way users
>> would be able to simply specify --run-autopkgtest to run tests without root
>> privileges.
>
> I don't think that this would be easily possible. Whenever you let something
> have a default you must also provide a way to change the default. This becomes
> especially hairy because whichever way we implement that lets users change the
> default now must also be conditionalized with schroot being the backend or
> not.
>
> I think this is yet another sign of why sbuild running autopkgtest is a layer
> violation. Instead of sbuild running autopkgtest, piuparts and lintian, there
> should be a tool above sbuild which runs sbuild, autopkgtest, piuparts and
> lintian. Sbuild doing the job is just a convenience option because we don't
> have such a tool above sbuild yet but it would be the responsibility of that
> tool to find out that it can drive both sbuild and autopkgtest with schroot.
>
> I'm very hesitant about adding yet more duct tape to sbuild plus the necessary
> documentation plus the users that will now wonder why sbuild behaviour changed
> and they now have to somehow overwrite the default to restore the original
> functionality and so on...
I agree, and, as the original bug submitter, I'm just going to close
this issue. I'm using sbuild-qemu now and it works fine with those
wildcards.
--
We must shift America from a needs- to a desires-culture. People must
be trained to desire, to want new things, even before the old have
been entirely consumed. Man's desires must overshadow his needs.
- Paul Mazur, Lehman Brothers
--- End Message ---
