You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Autoinstall of module zfs/2.2.7 for kernel 6.12.13-cloud-arm64 (aarch64)
Running the pre_build script... done.
Cleaning build area.... done.
Building module(s)... done.
Signing module /var/lib/dkms/zfs/2.2.7/build/module/zfs.ko
Signing module /var/lib/dkms/zfs/2.2.7/build/module/spl.ko
Running the post_build script... done.
Cleaning build area.... done.
Installing /lib/modules/6.12.13-cloud-arm64/updates/dkms/zfs.ko.xz
Installing /lib/modules/6.12.13-cloud-arm64/updates/dkms/spl.ko.xz
Running depmod............... done.
Is the 'Cleaning' after 'pre_build' a good idea? Isn't it possible that this will clean up stuff generated by the pre_build that would be needed by the build process?
I'm a bit reluctant to move the first Cleaning before pre_build as this could break modules out in the wild relying on the current behavior...
The text was updated successfully, but these errors were encountered:
I can't answer as I never used a DKMS module with a "pre" script. Would be nice to have some "large" list of projects using DKMS so we can have a look while making changes.
We can probably add a few entries in a "wiki" section.
I just looked at the history of the two clean calls. They have been there from the very beginning. But in the first version imported into Git (v0.22.04, 25fddac), building still happened in the source tree, so cleaning before building was a good idea. The second commit (v0.23.18, ce6cafe) imported a version that created a clean build tree and built there, thus cleaning before building should have been a no-op since then. I'm just going to eliminate the first clean. Will test this in my Debian test setup first.
In Debian we have roughly 45 different dkms modules (+ a few nvidia flavors) packaged, these are my dkms torturing set ;-)
I just noticed
Is the 'Cleaning' after 'pre_build' a good idea? Isn't it possible that this will clean up stuff generated by the pre_build that would be needed by the build process?
I'm a bit reluctant to move the first Cleaning before pre_build as this could break modules out in the wild relying on the current behavior...
The text was updated successfully, but these errors were encountered: