[ISSUE] `lttng-modules-dkms` fails to build

[voidlinux-github@inbox.vuxu.org]

[-- Attachment #1: Type: text/plain, Size: 2136 bytes --]

New issue by ranweiler on void-packages repository

https://github.com/void-linux/void-packages/issues/12751
Description: ### 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](https://github.com/void-linux/void-packages/blob/master/srcpkgs/lttng-modules-dkms/files/dkms.conf#L1). 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.