Debian 11 Source DKMS Build Fails Due to 'alien' and 'dh'

[LukeShortCloud]

System information

Type	Version/Name
Distribution Name	Debian
Distribution Version	11 Bullseye/Testing (Soft Freeze)
Linux Kernel	5.10.0-3-amd64
Architecture	amd64
ZFS Version	2.0.3
SPL Version	Unknown

Describe the problem you're observing

On a fresh installation of Debian 11 Testing (currently in a Soft Freeze), it is impossible to build the required *.deb packages due to an error with alien (which actually shows an error from dh). Apparently the build process first creates RPMs (regardless of the distribution) and then tries (and fails) to convert them to other formats.

On a somewhat related note, I was able to build OpenZFS 2.0.0 in the past on Debian 10 Buster/Stable without any issues.

Describe how to reproduce the problem

I am following the Debian and Ubuntu DKMS installation guide. Download OpenZFS 2.0.3 on Debian 11 and build with these settings:

$ ./configure --enable-systemd
$ make -j $(nproc) deb-utils deb-dkms

Include any warning/errors/backtraces from the system logs

Here is the actual error reported by the make command:

make[1]: Entering directory '/root/zfs-2.0.3/zfs-dkms-2.0.3'
dh
dh: error: specify a sequence to run
make[1]: *** [debian/rules:7: binary] Error 25
make[1]: Leaving directory '/root/zfs-2.0.3/zfs-dkms-2.0.3'
make: *** [Makefile:1695: deb-dkms] Error 1

This error also occurs when using the alien command manually. Is this the official alien project? It has been untouched since 2011.

$ alien zfs-2.0.3-1.x86_64.rpm
Warning: Skipping conversion of scripts in package zfs: postinst postrm prerm
Warning: Use the --scripts parameter to include the scripts.
Package build failed. Here's the log:
dh
dh: error: specify a sequence to run
make: *** [debian/rules:7: binary] Error 25

As an alternative, I tried using fpm but it failed to properly convert the packages. Various errors existed with the *.deb packages it created.

$ for i in $(ls -1 | grep -P '\.rpm' | grep -v -P '\.src'); do fpm -s rpm -t deb $i; done
$ sudo dpkg -i ./*.deb
dpkg: error processing archive ./libnvpair3_2.0.3-1_amd64.deb (--install):
 parsing file '/var/lib/dpkg/tmp.ci/control' near line 7 package 'libnvpair3':
 'Depends' field, invalid package name '/sbin/ldconfig': must start with an alphanumeric character
dpkg: error processing archive ./libuutil3_2.0.3-1_amd64.deb (--install):
 parsing file '/var/lib/dpkg/tmp.ci/control' near line 7 package 'libuutil3':
 'Depends' field, invalid package name '/sbin/ldconfig': must start with an alphanumeric character
dpkg: error processing archive ./libzfs4_2.0.3-1_amd64.deb (--install):
 parsing file '/var/lib/dpkg/tmp.ci/control' near line 7 package 'libzfs4':
 'Depends' field, invalid package name '/sbin/ldconfig': must start with an alphanumeric character
dpkg: warning: parsing file '/var/lib/dpkg/tmp.ci/control' near line 7 package 'libzfs4-devel':
 'Depends' field, reference to 'rpmlib':
 implicit exact match on version number, suggest using '=' instead
dpkg: error processing archive ./libzfs4-devel_2.0.3-1_amd64.deb (--install):
 parsing file '/var/lib/dpkg/tmp.ci/control' near line 7 package 'libzfs4-devel':
 'Depends' field, reference to 'rpmlib': version 'CompressedFileNames': version number does not start with digit
dpkg: error processing archive ./libzpool4_2.0.3-1_amd64.deb (--install):
 parsing file '/var/lib/dpkg/tmp.ci/control' near line 7 package 'libzpool4':
 'Depends' field, invalid package name '/sbin/ldconfig': must start with an alphanumeric character
dpkg: warning: parsing file '/var/lib/dpkg/tmp.ci/control' near line 7 package 'python3-pyzfs':
 'Depends' field, reference to 'rpmlib':
 implicit exact match on version number, suggest using '=' instead
dpkg: error processing archive ./python3-pyzfs_2.0.3-1_all.deb (--install):
 parsing file '/var/lib/dpkg/tmp.ci/control' near line 7 package 'python3-pyzfs':
 'Depends' field, reference to 'rpmlib': version 'CompressedFileNames': version number does not start with digit
dpkg: error processing archive ./zfs-dkms_2.0.3-1_all.deb (--install):
 parsing file '/var/lib/dpkg/tmp.ci/control' near line 7 package 'zfs-dkms':
 'Depends' field, invalid package name '/bin/sh': must start with an alphanumeric character
dpkg: error processing archive ./zfs-dracut_2.0.3-1_all.deb (--install):
 parsing file '/var/lib/dpkg/tmp.ci/control' near line 7 package 'zfs-dracut':
 'Depends' field, invalid package name '/bin/sh': must start with an alphanumeric character
dpkg: error processing archive ./zfs-initramfs_2.0.3-1_amd64.deb (--install):
 parsing file '/var/lib/dpkg/tmp.ci/control' near line 7 package 'zfs-initramfs':
 'Depends' field, invalid package name '/bin/sh': must start with an alphanumeric character
dpkg: warning: parsing file '/var/lib/dpkg/tmp.ci/control' near line 7 package 'zfs-test':
 'Depends' field, reference to 'rpmlib':
 implicit exact match on version number, suggest using '=' instead
dpkg: error processing archive ./zfs-test_2.0.3-1_amd64.deb (--install):
 parsing file '/var/lib/dpkg/tmp.ci/control' near line 7 package 'zfs-test':
 'Depends' field, reference to 'rpmlib': version 'CompressedFileNames': version number does not start with digit
Errors were encountered while processing:
 ./libnvpair3_2.0.3-1_amd64.deb
 ./libuutil3_2.0.3-1_amd64.deb
 ./libzfs4_2.0.3-1_amd64.deb
 ./libzfs4-devel_2.0.3-1_amd64.deb
 ./libzpool4_2.0.3-1_amd64.deb
 ./python3-pyzfs_2.0.3-1_all.deb
 ./zfs-dkms_2.0.3-1_all.deb
 ./zfs-dracut_2.0.3-1_all.deb
 ./zfs-initramfs_2.0.3-1_amd64.deb
 ./zfs-test_2.0.3-1_amd64.deb

[ghost]

I've noticed this same error in the truenas/zfs CI builds for TrueNAS SCALE. Strangely, the same commit was previously building just fine, but upon rebuilding today, it fails.

Here it was working 9 days ago: https://github.com/truenas/zfs/actions/runs/569652024

And here is the same commit failing today: https://github.com/truenas/zfs/actions/runs/549063961

It passed when it was pushed 16 days ago, but I pressed the re-run button today and it failed.

[rincebrain]

Disregard the top bit, it's inaccurate, skip to "One more edit"
In quickly trying to reproduce this by installing backported things on buster:

• alien 8.95 + debhelper 12.1.1 (basic buster setup) works
• alien 8.95.3 + debhelper 12.1.1 works
• alien 8.95.3 + debhelper 13.3.1 breaks
• alien 8.95 + debhelper 13.3.1 works

So something about the specific combination of alien+debhelper versions is required for this breakage; either version on its own is not sufficient. Unfortunately, this doesn't exactly narrow down who's to blame, and manually invoking alien with --veryverbose isn't verbose enough to reveal what's being done differently.

edit: Well, after a quick hackaround to examine the generated debian/rules from alien 8.95.3 and alien 8.95, alien 8.95.3 generates just a call to "dh" for most commands, while 8.95 generates a more explicit debian/rules that does not invoke "dh", just various helpers.

Also, I may be mad, because I just tried alien 8.95.3 and debhelper 12.1.1 again, and it broke. :( So I guess this is a bug in alien, and should probably be reported as such, except alien is orphaned and in need of a new maintainer in Debian, so it's not particularly likely to get fixed anytime soon?

One more edit: It seems like the bug is that alien is emitting, in debian/rules:

%:
        dh

when what it wants to be emitting is:

%:
        dh $@

Patching debian/rules in an emitted debian/ directory from alien lets the package build successfully.

The actual patch to alien is pretty simple too:

--- ./blib/lib/Alien/Package/Deb.pm.old 2021-02-24 20:25:49.896411306 -0500
+++ ./blib/lib/Alien/Package/Deb.pm     2021-02-24 20:26:06.868446646 -0500
@@ -472,7 +472,7 @@
 PACKAGE=\$(shell dh_listpackages)

 %:
-       dh $@
+       dh \$\@

 override_dh_clean:
        dh_clean -d

one final edit: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983492

[averyfreeman]

I am experiencing this problem in Debian bullseye/testing, as well. I get this right after make attempts dh + alien:

fakeroot alien --bump=0 --scripts --to-deb --target=$debarch \
    $pkg1 $pkg2 $pkg3 $pkg4 $pkg5 $pkg6 $pkg7 \
    $pkg8 $pkg9 $pkg10 || exit 1; \
rm -f ${path_prepend}/dh_shlibdeps; \
rmdir ${path_prepend}; \
rm -f $pkg1 $pkg2 $pkg3 $pkg4 $pkg5 $pkg6 $pkg7 \
    $pkg8 $pkg9 $pkg10;
Package build failed. Here's the log:
make[1]: warning: jobserver unavailable: using -j1.  Add '+' to parent make rule.
make[1]: Entering directory '/home/avery/build/kernels/z2.0.4-k5.11.6/zfs-2.0.4-k5.11.6/zfs-2.0.4'
dh 
dh: error: specify a sequence to run
make[1]: *** [debian/rules:7: binary] Error 25
make[1]: Leaving directory '/home/avery/build/kernels/z2.0.4-k5.11.6/zfs-2.0.4-k5.11.6/zfs-2.0.4'
make: *** [Makefile:1706: deb-utils] Error 1

Here's the package versions:

$ apt-show-versions | egrep 'alien|debhelper'

alien:all/bullseye 8.95.3 uptodate
debhelper:all/bullseye 13.3.4 uptodate
libdebhelper-perl:all/bullseye 13.3.4 uptodate

It didn't help my problem with Debian that I copied the directories to an Ubuntu machine and finished compiling there, but at least it got done.

[rincebrain]

I don't recommend trying to actually patch it that way, I just did it while debugging.

The simplest way to fix this would be to patch /usr/share/perl5/Alien/Package/Deb.pm with the patch outlined in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983492 .

edited to add: I am pretty surprised that running alien on an Ubuntu system worked; AFAICT they have the same bug in their alien source tree.

[ghost]

@rincebrain I've recently been trying to use an alien version built with your suggested patch, but it seems the debs generated have installed the headers in /include instead of /usr/include. I'm thinking there may be other problems with this version of alien, even if things do at least build now.

[rincebrain]

@freqlabs Neat. I'm 95% sure that's not the patch's fault, given its simplicity, so I wonder how it's broken. I'll see if I can reproduce that.

[ghost]

Reverting 9b5622f8f289613ce806f390aa8fa4622d2a9a5c in https://salsa.debian.org/debian/alien works.

[bghira]

also, it would be nice to just not use alien for making debian packages.

debian upstream downstream has packaging, why not import that?

[rincebrain]

@freqlabs I created a patch which fixes this for me, you can find it attached to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985835 . I'm not entirely happy with it, but it works.

[LukeShortCloud]

I can confirm that building the DEB packages now works again in Debian 11 Bullseye RC1! The upstream issue with alien has been resolved.