DOS-style line endings in dkms.conf break dkms in unpredictable ways

[tuxedo-wse]

I tested on a fresh Fedora 39 install with dkms 3.0.13 and TUXEDO_OS with dkms 2.8.7.

Installing this dkms module: tuxedo-yt6801-1.0.28.tar.gz

Results in this error message:

$ sudo dkms install tuxedo-yt6801/1.0.28
[sudo] Passwort für test: 
Sign command: /lib/modules/6.5.6-300.fc39.x86_64/build/scripts/sign-file
Signing key: /var/lib/dkms/mok.key
Public certificate (MOK): /var/lib/dkms/mok.pub
Deprecated feature: REMAKE_INITRD (/var/lib/dkms/tuxedo-yt6801/1.0.28/source/dkms.conf)

Building module:
Cleaning build area...(bad exit status: 2)
Failed command:
make clean
Building module(s).....
.ko failed for: 6.5.6-300.fc39.x86_64 (x86_64)
Make sure the name of the generated module is correct and at the root of the
build directory, or consult make.log in the build directory
/var/lib/dkms/tuxedo-yt6801/1.0.28/build for more information.

Note the broken message .ko failed for: 6.5.6-300.fc39.x86_64 (x86_64) which should actually be Error! Build of yt6801.ko failed for: 6.5.6-300.fc39.x86_64 (x86_64)

The build of yt6801.ko actually doesn't fail, what I suspect is happening is that dkms parses the \r from DOS-style \r\n line endings as part of the module name defined in BUILT_MODULE_NAME[0], fails to find the file because of that, and outputs the \r in the middle of the error message.

Also note that when PACKAGE_NAME is yt6801 instead of tuxedo-yt6801 the content of BUILT_MODULE_NAME[0] do not matter anymore. so it seems that PACKAGE_NAME is parsed correctly even with DOS-style line endings and without knowing the ins and outs of dkms, I guess there is a fallback that when BUILT_MODULE_NAME[0] is not found it falls back on searching for a module named after PACKAGE_NAME?

Maybe there are other dkms.conf config values being parsed wrongly with DOS-style line endings.

I don't know if dkms is supposed to support DOS-style line endings. If not, a clear error message that dkms.conf needs to be converted would be helpfull (would have saved me half a day of headscratching xD).

The driver above is for a ethernet controler from motorcomm: https://www.motor-comm.com/product/ethernet-control-chip

As of the time of this writing they not yet have uploaded 1.0.28 to their website yet, but maybe soon.

Note that the original zip has PACKAGE_NAME == BUILT_MODULE_NAME[0] and therefore the bug is not visible there.

[evelikov]

I think this boils down to the fact that we assume/handle dkms.conf as if it were a (bash) shell script.

As a stop gap, we could *detect and error out if the file has the wrong line ending(s). Although in the long run, we should stop parsing the file like a shell script - see #414.