-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
dkms: update to 3.0.6 and update other related packages #37139
Conversation
0dd65a0
to
1ae0908
Compare
2b8aa65
to
0f5aa33
Compare
472de9b
to
48bf6bb
Compare
Sorry for the delay, I am busy. @ahesford It makes the logic simpler IMO. I've updated the logic again, and this time I've only utilized the expected format instead of using workarounds like If you have any better suggestions, do share. I'll implement it ASAP. Thanks for the |
Reference for |
srcpkgs/zfs/patches/0001-only-build-the-module-in-dkms.conf.patch
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems acceptable, but we need to test thoroughly. Accidentally breaking DKMS with trigger and hook changes would be bad news.
1140382
to
b1b9214
Compare
Updated to latest release and rebased on |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Welp, this isn't ready to go after all. The trigger and kernel hook need some fixes.
files/kernel.d/dkms.prerm has been updated to match the kernel_prerm.d_dkms file distributed with dkms 3.0.6 Also, note that these dkms.conf directives have been deprecated since dkms 2.8.8 - MODULES_CONF - MODULES_CONF_ALIAS_TYPE - MODULES_CONF_OBSOLETES - MODULES_CONF_OBSOLETE_ONLY - REMAKE_INITRD Also, note that the output of `dkms status` was changed in version 2.8.6 old - zfs, 2.1.4, 5.15.39_1, x86_64: installed new - zfs/2.1.4, 5.15.39_1, x86_64: installed
The output format of `dkms status` has changed in v2.8.6 old - zfs, 2.1.4, 5.15.39_1, x86_64: installed new - zfs/2.1.4, 5.15.39_1, x86_64: installed So, I've re-worked the _modver and _kver detection logic. NOTE: The detection logic should ideally be identical to the detection logic in srcpkgs/dkms/files/kernel.d/dkms.prerm Also, there was a bug. If a package tried to install a dkms module that failed to build for *all* of the installed kernels, then the output of dkms status for that module would be - old - module-name, x.y.z: added new - module-name/x.y.z: added Which would cause the dkms trigger to set _kver to "added", and then the following call to `dkms remove` would set the flag `-k $_kver`, and dkms would get confused trying to find a kernel of version "added". This commit fixes that bug.
Sorry for the |
This comment was marked as off-topic.
This comment was marked as off-topic.
Hey @subnut, is there something I can help you with? |
Testing the changes
Local build testing