Open tuxedo-wse opened 4 months ago
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 https://github.com/dell/dkms/issues/414.
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:
Note the broken message
.ko failed for: 6.5.6-300.fc39.x86_64 (x86_64)
which should actually beError! 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.