Debian Bug report logs - #911977
how do we correctly guess the VM name in autopkgtest?

Display info messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupre <anarcat@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: how do we correctly guess the VM name in autopkgtest?

Date: Fri, 26 Oct 2018 15:23:01 -0400

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

Message #10 received at 911977@bugs.debian.org (full text, mbox, reply):

From: Johannes Schauer <josch@debian.org>

To: 911977@bugs.debian.org

Subject: Re: how do we correctly guess the VM name in autopkgtest?

Date: Fri, 04 Jan 2019 12:18:17 +0100

[Message part 1 (text/plain, inline)]

Control: tag -1 + moreinfo

Hi,

On Fri, 26 Oct 2018 15:23:01 -0400 Antoine Beaupre <anarcat@debian.org> wrote:
> 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?

Did you try using percent escapes?

For example I have in my ~/.sbuildrc:

$autopkgtest_opts = [ '--', 'schroot', '%r-%a-sbuild' ];

The %r and %a escapes expand to the current distribution and architecture. For
qemu I use:

$autopkgtest_opts = [ '--', 'qemu', '/srv/qemu/%r-%a-autopkgtest.qcow2' ];

You can read up about the percent escapes in the sbuild man page. As far as I
can see, the documentation for the --autopkgtest-opt command line argument
currently already lists that percent escapes are supported.

Do you have a different solution in mind?

Thanks!

cheers, josch

[signature.asc (application/pgp-signature, inline)]

Message #17 received at 911977@bugs.debian.org (full text, mbox, reply):

From: Andrea Pappacoda <andrea@pappacoda.it>

To: Johannes Schauer <josch@debian.org>

Cc: 911977@bugs.debian.org

Subject: Re: how do we correctly guess the VM name in autopkgtest?

Date: Sat, 19 Feb 2022 15:39:12 +0100

> 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.

-- 
OpenPGP key: 66DE F152 8299 0C21 99EF  A801 A8A1 28A8 AB1C EE49

Message #20 received at 911977@bugs.debian.org (full text, mbox, reply):

From: Johannes Schauer Marin Rodrigues <josch@debian.org>

To: Andrea Pappacoda <andrea@pappacoda.it>

Cc: 911977@bugs.debian.org

Subject: Re: how do we correctly guess the VM name in autopkgtest?

Date: Wed, 09 Mar 2022 09:36:13 +0100

[Message part 1 (text/plain, inline)]

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...

Thanks!

cheers, josch

[signature.asc (application/pgp-signature, inline)]

Message #25 received at 911977-done@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupré <anarcat@debian.org>

To: Johannes Schauer Marin Rodrigues <josch@debian.org>, Andrea Pappacoda <andrea@pappacoda.it>

Cc: 911977-done@bugs.debian.org

Subject: Re: Bug#911977: how do we correctly guess the VM name in autopkgtest?

Date: Wed, 27 Apr 2022 14:46:38 -0400

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

Send a report that this bug log contains spam.