+++ This bug was initially created as a clone of Bug #456765 +++

Description of problem: Highly customised kernels that built successfully
(source <= kernel-2.6.18-53.1.21.el5.src.rpm) with the use of the --without
kabichk option on the rpmbuild command line now fail to build (source >=
kernel-2.6.18-92.el5.src.rpm) due to changes in kabitool. The current kabitool
(dated Nov 26 2007) has two extra lines (both sys.exit(1)) when compared with
the previous version (dated Dec 11 2006). Reverting to the earlier version of
kabitool allow custom kernels to be built.


Version-Release number of selected component (if applicable): 1.3


How reproducible: Always.


Steps to Reproduce:
1.Highly customise a kernel such that it would need to be built with the
--without kabichk on the rpmbuild command line.
2.Attempt the build.
3.
  
Actual results: Build exits with "RPM build errors"


Expected results: Built proceeds to satisfactory conclusion.


Additional info:

--- Additional comment from ajb on 2008-07-26 14:35:04 EDT ---

Created attachment 312712 [details]
The last few lines of the stdout & stderr (separated) from a failed build.

--- Additional comment from ajb on 2009-02-14 18:05:57 EST ---

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.

--- Additional comment from dzickus on 2009-02-18 11:51:02 EST ---

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

--- Additional comment from dzickus on 2009-02-18 11:54:00 EST ---

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.

--- Additional comment from ajb on 2009-02-18 12:22:16 EST ---

(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.

--- Additional comment from ajb on 2009-02-18 21:24:09 EST ---

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.

--- Additional comment from ajb on 2009-02-18 21:33:09 EST ---

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.

--- Additional comment from ajb on 2009-02-19 04:56:11 EST ---

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

--- Additional comment from ajb on 2009-02-19 04:59:04 EST ---

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.

--- Additional comment from ajb on 2009-02-19 10:52:18 EST ---

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.

--- Additional comment from ajb on 2009-02-19 18:28:56 EST ---

Created attachment 332650 [details]
Third revised patch for .spec file

--- Additional comment from ajb on 2009-02-19 18:34:47 EST ---

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.

--- Additional comment from dzickus on 2009-02-19 20:57:13 EST ---

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.

--- Additional comment from pm-rhel on 2009-03-26 12:51:14 EDT ---

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 "?".

--- Additional comment from ajb on 2009-03-26 13:00:09 EDT ---

(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?

--- Additional comment from dzickus on 2009-03-26 13:43:44 EDT ---


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

--- Additional comment from ajb on 2009-03-26 14:09:37 EDT ---

(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.

--- Additional comment from jcm on 2009-05-13 15:29:10 EDT ---

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.

--- Additional comment from ajb on 2009-05-26 08:39:53 EDT ---

(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)?

--- Additional comment from ajb on 2009-07-12 11:28:05 EDT ---

<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.

--- Additional comment from andriusb on 2009-07-13 00:45:24 EDT ---

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!

--- Additional comment from pm-rhel on 2009-11-06 13:41:47 EST ---

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 "?".

--- Additional comment from jcm on 2010-02-26 13:29:21 EST ---

Reset to "kernel" component so there's no issue with "driver-upate-program" not being on the planned update list.

--- Additional comment from pm-rhel on 2010-05-20 08:48:16 EDT ---

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.

--- Additional comment from jcm on 2010-09-03 01:44:20 EDT ---

Created attachment 442796 [details]
456765-kabi-Don-t-generate-kABI-dependencies-when-building-.patch

--- Additional comment from jcm on 2010-09-03 01:44:59 EDT ---

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.

--- Additional comment from ajb on 2010-09-03 11:00:07 EDT ---

(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.

--- Additional comment from jcm on 2010-09-07 00:09:59 EDT ---

Should do. Thanks Alan.

--- Additional comment from amyagi on 2010-09-18 16:51:33 EDT ---

Just a note to add that the patch is in the test kernel -221.

http://people.redhat.com/jwilson/el5/

Thanks, Jon.

Akemi

--- Additional comment from jarod on 2010-09-20 12:56:43 EDT ---

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.

--- Additional comment from jcm on 2010-09-21 01:08:56 EDT ---

Thanks everyone!