Fix dkms header install #2776
Fix dkms header install #2776
Conversation
New versions of dkms clean up the build directory after installing.
tomprince
force-pushed
the
fix-dkms-header-install
branch
from
607c17a to
feaedbb
Compare
|
@behlendorf I have tested this in a fresh Fedora 20 VM and I am confident that this fix is correct. Feel free to add your pick of my In particular, this changes the build system to move the autotools products and headers from /var/lib/dkms/spl/0.6.3/build to /var/lib/dkms/spl/0.6.3/3.16.3-200.fc20.x86_64/x86_64 right before the clean is done. That places them outside of harms way on the current Fedora Core 20 and ZoL release. That avoids a problem entirely. The second patch fixes a mistake when passing paths to make the build system look for the spl sources at |
|
@ryao Thanks guys for the quick patch and review. Let me get this tested for EL7 and merged. I'll almost certainly update the public repositories with a point fix too. |
|
@behlendorf The dkms package in the EPEL repository has not been yet updated with the upstream change, so it is presently unaffected. That will likely change in the future. |
Signed-off-by: Tom Prince <[email protected]> Signed-off-by: Richard Yao <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]> Closes #2776
|
@ryao Yes, in fact only FC20 has thus far gotten the updated packages. I'm working on pushing a point release for the stable repositories now. With a little luck it will be in place before EPEL picks up the new DKMS. |
New versions of dkms clean up the build directory after installing. It appears that this was always intended, but had rm -rf "/path/to/build/*" (note the quotes), which prevented it from working. Also, the build step is already installing stuff into the directory where these files go, so installing our stuff there as part of build rather than install makes sense. Signed-off-by: Tom Prince <[email protected]> Signed-off-by: Richard Yao <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]> Closes #2776
Signed-off-by: Tom Prince <[email protected]> Signed-off-by: Richard Yao <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]> Closes #2776
|
@ryao @tomprince the public fc 18,19,20 and el 6, 7 stable repositories have been updated with a point release which contains this fix. Full source can be found in the following branches. Thanks guys. https://github.com/zfsonlinux/spl/tree/spl-0.6.3-stable |
The source_tree variable in the previous commit had an extra $. Remove it so that source_tree is expanded properly. An identical fix has been applied in the original patch to the stable branch. Signed-off-by: Brian Behlendorf <[email protected]> Closes openzfs#2776
|
@behlendorf Is there any chance of getting new RPMs in the zfs-testing repository, with this fix? |
1 similar comment
|
@behlendorf Is there any chance of getting new RPMs in the zfs-testing repository, with this fix? |
|
@tomprince absolutely. In fact I thought this was already done. I've updated the repository accordingly. |
New versions of dkms clean up the build directory after installing. It appears that this was always intended, but had rm -rf "/path/to/build/*" (note the quotes), which prevented it from working. Also, the build step is already installing stuff into the directory where these files go, so installing our stuff there as part of build rather than install makes sense. Signed-off-by: Tom Prince <[email protected]> Signed-off-by: Richard Yao <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]> Closes openzfs#2776
Signed-off-by: Tom Prince <[email protected]> Signed-off-by: Richard Yao <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]> Closes openzfs#2776
The source_tree variable in the previous commit had an extra $. Remove it so that source_tree is expanded properly. An identical fix has been applied in the original patch to the stable branch. Signed-off-by: Brian Behlendorf <[email protected]> Closes openzfs#2776
New versions of dkms clean up the build directory after installing.
It appears that this was always intended, but had rm -rf "/path/to/build/*" (note the quotes), which prevented it from working.
This also depends on openzfs/spl#399