[Piuparts-devel] need help reproducing piuparts.debian.org failure

[Andreas Beckmann]

On 12/04/2020 18.22, Benjamin Kaduk wrote:
> Hi all,
> 
> While working on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956358 I
> of course ended up looking at the logs at
> https://piuparts.debian.org/sid/fail/openafs-modules-dkms_1.8.6~pre1-3.log,
> which show that the DKMS module build was attempted but failed:
> 
>   Error! Bad return status for module build on kernel: 5.4.0-4-amd64 (x86_64)
>   Consult /var/lib/dkms/openafs/1.8.6pre1/build/make.log for more information.
>   dpkg: error processing package openafs-modules-dkms (--configure):
>    installed openafs-modules-dkms package post-installation script subprocess returned error exit status 10
>   Processing triggers for libc-bin (2.30-4) ...
>   Errors were encountered while processing:
>    openafs-modules-dkms
>   E: Sub-process /usr/bin/dpkg returned an error code (1)
> 0m30.7s ERROR: Command failed (status=100): ['chroot', '/srv/piuparts.debian.org/tmp/tmpn24bd7yb', 'apt-get', '-y', 'install', 'openafs-modules-dkms=1.8.6~pre1-3']

> The most obvious difference to me between my local run and the
> piuparts.debian.org run is that piuparts.debian.org is providing a base
> tarball, /srv/piuparts.debian.org/slave/basetgz/sid_amd64.tar.gz.  Is that
> something that's publicly available?  If not, how can I get more information
> about what it contains?

If you don't supply that tarball, the chroot will be created on the fly
with the same contents. (There are piuparts options to save the tarball)

But the tarball is not your problem. You are missing
  --scriptsdir /etc/piuparts/scripts
which causes dkms and a kernel-headers metapackage to be installed first
(if the package to be tested matches *-dkms), s.t. a module build is
attempted after installation.
(I'm not sure if the script catches a .deb given on the command line, I
only tested it with packages from the archive - if it doesn't work,
'--extra-old-packages dkms,linux-headers-amd64' might help (or a
similarily named option).)

IIRC, the problem was that your configure script is looking for gcc, but
that is not installed. You shouldn't build the module with gcc anyway,
but with the kernel's compiler (which is not always the same as the
default gcc). You somehow need to query the kernel buildsystem for the
compiler to use ...
(This works out-of-the-box for modules just using kbuild).

Andreas