Bug 456765
Description
Alan Bartlett
2008-07-26 18:35:04 UTC
Created attachment 312712 [details]
The last few lines of the stdout & stderr (separated) from a failed build.
Created attachment 331945 [details]
Removes two calls to sys.exit(1) that were added on 2007/11/26 @ 18:21:15
Removes two calls to "sys.exit(1)" that were erroneously added on 2007/11/26 and also the "else:" & "print "blah"" line that preceded each of the above calls.
NAK to the patch. There was a reason why we added the sys.exit(1) lines to the kabitool. It was created to catch the situations where developers backported upstream drivers and accidentally removed kabi symbols that we promised to customers we would maintain for the entire life of RHEL-5, ie a safety net. Removing that safety net is not an option. Perhaps moving the kabichk check in the spec up a few lines to prevent the tool from running would be more appropriate. I will attach a completely untested patch, but gives the idea of what I was suggesting. -Don Created attachment 332416 [details]
don't run kabitool if disabled with kabichk
Do not run the kabitool if the user is not interested in preventing kabi problems.
I am not sure what the end result will look like and if the -devel packages need certain files on the other side, but this seems like a more workable solution.
(In reply to comment #8) > Created an attachment (id=332416) [details] > don't run kabitool if disabled with kabichk > > > Do not run the kabitool if the user is not interested in preventing kabi > problems. > I am not sure what the end result will look like and if the -devel packages > need certain files on the other side, but this seems like a more workable > solution. Thanks Don. I'll have a look at your suggested patch asap and report back my findings, in due course. Created attachment 332492 [details]
Revised patch for .spec file
NAK to your patch, Don. It needs another conditional --
%if %{with_kabichk}
mv $RPM_BUILD_ROOT/kabi_whitelist $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
%endif
I have another test build in progress, result in due course.
Created attachment 332493 [details]
The last few lines of the stderr.
After applying Don's patch to the .spec file, a test build was started using the flag "--without kabichk" on the rpmbuild command line.
The build ultimately failed. This is the last few lines of the stderr -- which provided the info for the revised patch.
Created attachment 332518 [details]
Second revised patch for .spec file
NAK to the first proposed revised patch. Build fails due to missing symsets-$KernelVer.tar.gz file.
Now trying (second revised patch) --
%if %{with_kabichk}
mv $RPM_BUILD_ROOT/kabi_whitelist $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
if [ -e $RPM_BUILD_ROOT/Module.kabi ]; then
mv $RPM_BUILD_ROOT/Module.kabi $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
fi
cp symsets-$KernelVer.tar.gz $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
%endif
I should make the comment that I'm using the latest 5.3 kernel sources, kernel-2.6.18-128.1.1.el5.src.rpm. Created attachment 332574 [details] Result of build having applied 2nd revised patch to the .spec file. A successful build occurred. However, there are three lines output to the stderr during the packaging phase that I do not like -- /usr/local/src/kernel/rpmbuild/SOURCES/find-provides: cannot locate kabideps file: /var/tmp/kernel-2.6.18-128.1.1.el5.bz456765-kabideps error: /usr/local/src/kernel/rpmbuild/SOURCES/find-provides failed error: Failed to find Provides: I would appreciate any advice as how to proceed and resolve this issue. Created attachment 332650 [details]
Third revised patch for .spec file
Created attachment 332651 [details]
Result of build having applied 3rd revised patch to the .spec file.
A successful build occurred.
The stdout was "clean". The stderr was "clean".
Please check for any latent problems and advise how you would like me to proceed.
This looks fine. I'll talk with Jon about this to make sure he is ok with it and try to bring the patch into rhel-5.4 in the next few weeks. Thanks for the patch and testing. This request was evaluated by Red Hat Product Management for inclusion, but this component is not scheduled to be updated in the current Red Hat Enterprise Linux release. If you would like this request to be reviewed for the next minor release, ask your support representative to set the next rhel-x.y flag to "?". (In reply to comment #20) > This request was evaluated by Red Hat Product Management for > inclusion, but this component is not scheduled to be updated in > the current Red Hat Enterprise Linux release. If you would like > this request to be reviewed for the next minor release, ask your > support representative to set the next rhel-x.y flag to "?". Would a human being now translate the above into English, please? Basically the automated message is saying 'we are at capacity but we can try again next update to get your fix in'. I thought we sent these messages later in the cycle. Regardless your patch is small enough and doesn't really impact anything, so maybe we can still try to bring it in for 5.4. No promises though. -Don (In reply to comment #22) > Basically the automated message is saying 'we are at capacity but we can try > again next update to get your fix in'. > > I thought we sent these messages later in the cycle. Regardless your patch is > small enough and doesn't really impact anything, so maybe we can still try to > bring it in for 5.4. No promises though. > > -Don Thanks Don. It now makes perfect sense -- as typed in your first sentence. As an Englishman, I thought I had a thorough grasp of my native language but that computer generated simulation really pushed the boundaries . . . Thanks again. I'm pretty sure I said this before, but I'm ok with the latest patch on this bug. The idea is fine, and touching an empty file if the test is off is ok too. (In reply to comment #24) > I'm pretty sure I said this before, but I'm ok with the latest patch on this > bug. The idea is fine, and touching an empty file if the test is off is ok too. Great. Thanks Jon. I couldn't find any error in my logic (no matter how hard I tried) but it really needed reviewing / testing by others. After leaving this issue alone for a while and then going through it afresh, I am still unable to find any flaw. Can that be deemed a suitable re-test (that has been requested of me)? <Big sigh.> What *does* a mere-mortal have to do to get this fix accepted? The issue was discovered as soon as 5.2 was released but it was totally ignored, despite being logged here. 5.3 was released with this defect still present and so the "bottom of the pond" was stirred with a big stick, making the water rather muddy. Having done all the required spade- & leg-work and having had the pleasure of communicating with (whom I assume to be) the two main men of the EL5 kernel -- remember, all of this was done very early after the release of 5.3 -- I naively assumed it would appear in 5.4. Having now looked at the 5.4-beta kernel-2.6.spec file, I realise what a fool I have been in making such an assumption. Quite honestly, I wonder why I bother. Alan - this fix just missed the RHEL 5.4 code freeze many months ago and has since been deferred to RHEL 5.5. We apologize for not notifying you earlier. Everyone here is fine with committing this, but not post-Beta in RHEL 5.4, therefore it will be proposed in RHEL 5.5 (since it's done, hence in MODIFIED state). Just curious though - if someone was going to run an unsupported version of a RHEL kernel, what's stopping the same person from committing this patch him/herself? Thanks! This request was evaluated by Red Hat Product Management for inclusion, but this component is not scheduled to be updated in the current Red Hat Enterprise Linux release. If you would like this request to be reviewed for the next minor release, ask your support representative to set the next rhel-x.y flag to "?". Reset to "kernel" component so there's no issue with "driver-upate-program" not being on the planned update list. This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release. Created attachment 442796 [details]
456765-kabi-Don-t-generate-kABI-dependencies-when-building-.patch
Alan, Please let me know if there are any remaining issues with this patch, and sorry again that it slipped under the radar before. Jon. (In reply to comment #36) > Alan, > > Please let me know if there are any remaining issues with this patch, and sorry > again that it slipped under the radar before. > > Jon. Jon, Thank you for this patch. Having read it twice, line by line, I can say that it will definitely resolve this issue. ;-) I just hope it makes 5.6 before the cut-off point! Alan. Should do. Thanks Alan. Just a note to add that the patch is in the test kernel -221. http://people.redhat.com/jwilson/el5/ Thanks, Jon. Akemi Ah, apologies, automated posting of the fact it was included in a test kernel escaped my tools' notice, due to a quirk of specfile-only-patches. Thanks everyone! I've tested this by patching the kernel to remove a symbol export that maches one of the ones in the kabi list. I can confirm that the patched kernel will not build unless I use the --without kabichk arguement to rpmbuild so this one can be verified. Testing was done with the 2.6.18-236 kernel source. An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2011-0017.html |