lttng-modules-dkms fails to build

[ranweiler]

System

• xuname:

Void 4.19.56_1 x86_64 GenuineIntel notuptodate rrrdFFFF

• package:
  lttng-modules-dkms-2.10.9_1

Expected behavior

When installing the package, the kernel modules build without error for installed kernels with headers.

Actual behavior

On installation, the kernel modules fail to build. The xbps console output includes:

Building DKMS module 'lttng-modules-2.10.9' for kernel-4.19.56_1... FAILED!
DKMS module 'lttng-modules-2.10.9' failed to build, please check /var/lib/dkms
for errors in the log file.
[...]
lttng-modules-dkms-2.10.9_1: installed successfully.

If we inspect the build log, we see:

$ cat /var/lib/dkms/lttng-modules/2.10.9/build/make.log
DKMS make.log for lttng-modules-2.10.9 for kernel 4.19.56_1 (x86_64)
Sat 29 Jun 2019 04:14:34 PM PDT
make: Entering directory '/usr/src/kernel-headers-4.19.56_1'
scripts/Makefile.build:45: /var/lib/dkms/lttng-modules/2.10.0/build/Makefile: No such file or directory
make[1]: *** No rule to make target '/var/lib/dkms/lttng-modules/2.10.0/build/Makefile'.  Stop.
make: *** [Makefile:1517: _module_/var/lib/dkms/lttng-modules/2.10.0/build] Error 2
make: Leaving directory '/usr/src/kernel-headers-4.19.56_1'

Steps to reproduce the behavior

Attempt to install the package via xbps-install -S lttng-modules-dkms.

Comments

The problem appears to be the first line of the dkms.conf file. It doesn't match the actual package/source version, so it ends up referring to a (in most cases) nonexistent directory.

I created a new (rev-bumped) package locally with that srcpkg file edited to read PACKAGE_VERSION=2.10.9. The module then builds as expected, and I was able to load it and trace kernel events.

I can open a PR with that narrow (manual) fix, but maybe there's a better way, that will ensure the file is auto-updated in the future.

[ranweiler]

AFAICT, this should have been broken for a while (since it was introduced?). But maybe there's something else that changed that made things work before. Or, maybe the old (2.10.0) src directories were always on the package maintainer's system, so the incorrect package version never caused a failure (but instead quietly built an old version repeatedly). The build failure doesn't cause an XBPS package installation failure, either, so it wouldn't be caught in a CI system that only checked for that.

cc @maxice8, who probably has some insight here.

[maxice8]

I don't work on Void Linux anymore.