Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
For bugs related to Red Hat Enterprise Linux 5 product line. The current stable release is 5.10. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 644129

Summary: Kernel build from source leaves kabideps file droppings in _tmppath
Product: Red Hat Enterprise Linux 5 Reporter: Quentin Barnes <qbarnes>
Component: kernelAssignee: Jarod Wilson <jarod>
Status: CLOSED ERRATA QA Contact: Hangbin Liu <haliu>
Severity: low Docs Contact:
Priority: low    
Version: 5.5CC: haliu, jcm, qcai
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-01-13 21:57:24 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
A possible fix, but probably not the best.
none
Full build log none

Description Quentin Barnes 2010-10-19 00:02:08 UTC
Created attachment 454230 [details]
A possible fix, but probably not the best.

Description of problem:
When doing an rpmbuild of the kernel source rpm, the build leaves behind
temporary files in %{_tmppath} (typically "/var/tmp") with names
matching "%{_tmppath}/kernel-%{version}-%{release}*-kabideps".

Besides a build just littering, the files can cause later builds to
fail if someone with another user ID attempts the same build since
the files aren't uniquely named and the removal of the files
owned by someone else will fail.

Version-Release number of selected component (if applicable):
kernel-2.6.18-194.17.1.el5


How reproducible:
100%

Steps to Reproduce:
1. See "Actual Results" for steps.
2.
3.
  
Actual results:
(Directions assume the kernel source RPM is already in home directory.)
To reproduce the problem:
$ mkdir -p /tmp/RedHatTest/{BUILD,{RPM,S{PEC,RPM,OURCE}}S}
$ cd /tmp/RedHatTest
$ rpm --define "_topdir $PWD" -i ~/kernel-2.6.18-194.17.1.el5.src.rpm
$ ls -l /var/tmp/kernel-2.6.18-194.17.1.el5*-kabideps
ls: /var/tmp/kernel-2.6.18-194.17.1.el5*-kabideps: No such file or directory
$ rpmbuild -bb --define "_topdir $PWD" SPECS/kernel-2.6.spec
[...Lots of output removed...]
Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.23084
+ umask 022
+ cd /tmp/RedHatTest/BUILD
+ cd kernel-2.6.18
+ rm -rf /var/tmp/kernel-2.6.18-194.17.1.el5-root
+ exit 0
$ ls -l /var/tmp/kernel-2.6.18-194.17.1.el5*-kabideps
-rw-r--r-- 1 qbarnes users 9569 Oct 17 17:09 /var/tmp/kernel-2.6.18-194.17.1.el5
debug-kabideps 
-rw-r--r-- 1 qbarnes users 9341 Oct 17 16:55 /var/tmp/kernel-2.6.18-194.17.1.el5
-kabideps
-rw-r--r-- 1 qbarnes users 9401 Oct 17 17:02 /var/tmp/kernel-2.6.18-194.17.1.el5
xen-kabideps

Expected results:
That the "ls -l /var/tmp/kernel-2.6.18-194.17.1.el5*-kabideps" after the
rpmbuild completes shows no files.

Additional info:
I've included a patch that fixes the problem, but with my limited
understanding of spec files, I consider it a hack.  Someone who knows
spec files better and the kernel-2.6.spec file will likely come up with a
better solution.

Comment 1 Jarod Wilson 2010-10-26 16:49:56 UTC
This looks sane enough to me.

Jon, do you see any kabi-related issue w/this change?

Comment 3 RHEL Program Management 2010-10-26 17:09:19 UTC
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.

Comment 4 Jarod Wilson 2010-11-01 21:00:38 UTC
in kernel-2.6.18-230.el5
You can download this test kernel (or newer) from http://people.redhat.com/jwilson/el5

Detailed testing feedback is always welcomed.

Comment 6 Jon Masters 2010-11-02 21:24:32 UTC
Oh, I meant to say before, this is fine.

Comment 7 Jon Masters 2010-11-02 21:26:19 UTC
Just make sure the RPM deps are still there after this. That file is an ugly hack to have deps around that can be read by the custom find-provides script that makes those into RPM deps. Having it in %clean should be sane, though. Just check the deps after you do a build.

Comment 8 Hangbin Liu 2010-11-26 10:58:25 UTC
can't reproduce , did the steps as "Actual Results" said with kernel 2.6.18-194.el5 and 2.6.18-229.el5 . but after rpmbuild , there is nothing in /var/tmp/


[qa@dell-pesc1425-01 RedHatTest]$ rpmbuild -bb --define "_topdir $PWD" SPECS/kernel-2.6.spec
[...Lots of output removed...]
Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.78008
+ umask 022
+ cd /tmp/RedHatTest/BUILD
+ cd kernel-2.6.18
+ rm -rf /var/tmp/kernel-2.6.18-229.el5-root
+ exit 0
[qa@dell-pesc1425-01 RedHatTest]$ ll /var/tmp
total 0
[qa@dell-pesc1425-01 RedHatTest]$ uname -r
2.6.18-229.el5


is there any other information about the bug ?

Comment 9 Quentin Barnes 2010-11-27 19:44:56 UTC
Created attachment 463267 [details]
Full build log

Comment 10 Quentin Barnes 2010-11-27 19:45:14 UTC
I'm confused.  I got an email about an update on this bug from Hangbin Liu having problems reproducing the problem, but I can't find the comment here.  What happened? Is it not visible to me for some reason, or get deleted?

If Hangbin is having trouble reproducing, I imagine that:
1) Something about my build left the files for me but not for Hangbin,
2) Something about Hangbin's build put them somewhere else that let them be cleaned up automatically,
3) Something about Hangbin's build didn't produce the files at all.

Let's see if we can figure it out.  I've attached the complete log of the build along with the commands leading up to the build and showing the files are left after the build.  Maybe if Hangbin does the same, I can go through that log.

Comment 11 Hangbin Liu 2010-11-29 05:25:20 UTC
Verified


On i386 system didn't reproduce ,but could reproduce on x86_64 system


after rpmbuild kernel-2.6.18-194.el5.src.rpm

[qa@intel-s3e3144-04 RedHatTest]$ ls -l /var/tmp
total 48
-rw-r--r-- 1 qa qa 11611 Nov 26 08:09 kernel-2.6.18-194.el5debug-kabideps
-rw-r--r-- 1 qa qa  9341 Nov 26 07:27 kernel-2.6.18-194.el5-kabideps
-rw-r--r-- 1 qa qa  9401 Nov 26 07:47 kernel-2.6.18-194.el5xen-kabideps
[qa@intel-s3e3144-04 RedHatTest]$ uname -a
Linux intel-s3e3144-04.rhts.eng.nay.redhat.com 2.6.18-194.el5 #1 SMP Tue Mar 16 21:52:39 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux


rpmbuild kernel-2.6.18-233.el5.x86_64.rpm

[qa@intel-s3e3144-04 RedHatTest]$ ls -l /var/tmp
total 0

Comment 12 Jarod Wilson 2010-11-29 23:14:59 UTC
(In reply to comment #11)
> Verified
> 
> 
> On i386 system didn't reproduce ,but could reproduce on x86_64 system

Your i386 build was kernel-headers only. For a 32-bit build, you'd need --target i686 to build the kernel binaries, which would result in the kabi droppings. (I've tested and verified this patch myself too).

Comment 13 Hangbin Liu 2010-11-30 07:33:28 UTC
did as comment #12 said and verified

$rpmbuild -bb --targer i686 --define "_topdir $PWD" SPECS/kernel-2.6.spec
$ ls -l /var/tmp
total 64
-rw-r--r-- 1 qa qa 11578 Nov 29 20:54 kernel-2.6.18-194.el5debug-kabideps
-rw-r--r-- 1 qa qa  9052 Nov 29 20:42 kernel-2.6.18-194.el5-kabideps
-rw-r--r-- 1 qa qa  9052 Nov 29 20:46 kernel-2.6.18-194.el5PAE-kabideps
-rw-r--r-- 1 qa qa  9206 Nov 29 20:50 kernel-2.6.18-194.el5xen-kabideps

Comment 14 Jon Masters 2010-11-30 18:05:11 UTC
So we're done? Great.

Comment 16 errata-xmlrpc 2011-01-13 21:57:24 UTC
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