On Sat, 13 Apr 2024 14:50:05 +0200 Francesco Poli wrote:

[...]
> On Fri, 12 Apr 2024 19:57:23 +0200 Johannes Schauer Marin Rodrigues
> wrote:
[...] 
> > Quoting Francesco Poli (wintermute) (2024-04-11 00:13:51)
[...]
> > > Why does sbuild-qemu insist that piuparts be installed on the *host*
> > > system?
> > 
> > Because it needs to be installed on the host. In the same way as autopkgtest
> > needs to be on the host. What can sbuild improve?
> 
> My point is that sbuild{,-qemu} should install piuparts inside the build
> environment (chroot or VM guest system) and run it from within the
> build environment, if this is possible.

If this is possible for piuparts, could you please explain why
sbuild-qemu does not do so?

Otherwise, if this is not possible, could please explain why?

> 
> Does sbuild{,-qemu} do so for lintian?
[...]

I checked: sbuild-qemu (temporarily) installs lintian inside the build
environment and runs it from within the build environment.
I think this is the best strategy, especially for lintian, as I have
previously explained.
That reinforces my opinion that the same strategy should probably be
followed for piuparts, as well...


Anyway, I am having issues in running piuparts, even after installing
it on the host.

I tried to run

  $ sbuild-qemu --boot=efi --overlay-dir=/dev/shm

with the following configuration file:

  $ cat ~/.sbuildrc 
  $source_only_changes = 1;
  $autopkgtest_require_success = 1;
  $lintian_require_success = 0;
  $piuparts_require_success = 1;
  $run_autopkgtest = 1;
  $run_lintian = 1;
  $run_piuparts = 1;
  $build_dir = "$HOME/.cache/sbuild/build";
  
  # don't remove this, Perl needs it:
  1;

It builds the package successfully, but, once it reaches the piuparts
step, sudo asks for my (host system) regular user's password.
My understanding is that it should not need to use sudo, since it should
use the QEMU virtual machine image (where it has root access).
Is that right? Or am I misunderstanding something?

The same thing happens at the autopkgtest step, where, again, sudo asks
for my regular user's password. Once again, this should not be needed:
autopkgtest should use the QEMU virtual machine as a testbed.
At least, when I manually run autopkgtest, I can use the QEMU virtual
machine and no password is asked for.

I tried to modify the configuration file:

  $ cat ~/.sbuildrc
  $source_only_changes = 1;
  $run_lintian = 1;
  $lintian_require_success = 0;
  $run_piuparts = 1;
  $piuparts_root_args = '';
  $piuparts_require_success = 1;
  $run_autopkgtest = 1;
  $autopkgtest_root_args = '';
  $autopkgtest_require_success = 1;
  $build_dir = "$HOME/.cache/sbuild/build";
  
  # don't remove this, Perl needs it:
  1;

It no longer asks for passwords, but fails to run piuparts:

  piuparts
  --------

  You need to be root to use piuparts.

  E: Piuparts run failed.

And it also fails to run autopkgtest:

  autopkgtest
  -----------
  
  autopkgtest [19:56:04]: starting date and time: 2024-05-11 19:56:04+0200
  [...]
  autopkgtest [19:56:05]: test unit_test: preparing testbed
  autopkgtest [19:56:05]: ERROR: "sh -ec
    type apt-ftparchive >/dev/null 2>&1 || DEBIAN_FRONTEND=noninteractive 
apt-get install -y apt-utils 2>&1
    (cd /tmp/autopkgtest.jrHchc/binaries; apt-ftparchive packages . > Packages; 
apt-ftparchive release . > Release)
    printf 'Package: *\nPin: origin ""\nPin-Priority: 1002\n' > 
/etc/apt/preferences.d/90autopkgtest
    echo "deb [ trusted=yes ] file:///tmp/autopkgtest.jrHchc/binaries /" 
>/etc/apt/sources.list.d/autopkgtest.list
    if [ "x`ls /var/lib/dpkg/updates`" != x ]; then
      echo >&2 "/var/lib/dpkg/updates contains some files, aargh"; exit 1
    fi
    apt-get --quiet --no-list-cleanup -o 
Dir::Etc::sourcelist=/etc/apt/sources.list.d/autopkgtest.list -o 
Dir::Etc::sourceparts=/dev/null update 2>&1
    cp /var/lib/dpkg/status /tmp/autopkgtest.jrHchc/1-apt-update.out
    " failed with stderr "sh: 4: cannot create 
/etc/apt/preferences.d/90autopkgtest: Permission denied
  "
  autopkgtest [19:56:05]: Binaries: resetting testbed apt configuration
  Reading package lists...
  E: Could not open lock file /var/lib/apt/lists/lock - open (13: Permission 
denied)
  E: Unable to lock directory /var/lib/apt/lists/
  [...]
  E: Autopkgtest run failed.

It seems to me that autopkgtest is not using the QEMU virtual machine
as testbed, or am I wrong?


Why isn't all this working out of the box?
Is there any missing setting in ~/.sbuildrc ?
If this is the case, why isn't sbuild-qemu passing those needed options
by default?

Please explain.
Thanks for your time!



-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
..................................................... Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE

Attachment: pgp1PXbWEgVnH.pgp
Description: PGP signature

Reply via email to