rpmbuild fails reporting unpackaged .pyo and .pyc files

[Jeff Johnson]

tracker

[Rich (rich-redhat-bugs)]

Description of problem:
Occasional failure packaging python files.
I suspect brp-python-bytecompile. This also may be related to bug 468179

The symptom is not 100% reproducible.

Version-Release number of selected component (if applicable):
-bash-3.2$ rpmbuild --version
RPM version 4.4.2.3

How reproducible:
Create an architecture specific rpm delivering at least one python file.
rpmbuild. In this case it is the file /usr/lib/yum-plugins/ft-reboot-tracking.py.

Steps to Reproduce:
1.
2.
3.

Actual results:

buildrpm reports:

Checking for unpackaged file(s): /usr/lib/rpm/check-files /auto/svn/rjohnson/linux/trunk/ftl_linux/build/BUILDROOT/lsb-ft-cstools-7.0.3-104
error: Installed (but unpackaged) file(s) found:
   /usr/lib/yum-plugins/ft-reboot-tracking.pyc
   /usr/lib/yum-plugins/ft-reboot-tracking.pyo

RPM build errors:
    Installed (but unpackaged) file(s) found:
   /usr/lib/yum-plugins/ft-reboot-tracking.pyc
   /usr/lib/yum-plugins/ft-reboot-tracking.pyo

Expected results:

Since the offending files were created during %__os_install_post processing
The expected behavior is that any files created by rpmbuild's macros are either:
a) added to the %files set for management by rpm
b) ignored during packaging

Any notice of the additional files should be informational only. It should not raise an error.

Additional info:
The lack of 100% repeatability is pernicious because if one adds the .pyc and .pyo files a subsequent rpmbuild may fail to create them and then fail complaining that that specified files are missing.

One avoidance is to recast the __os_install_post macro; skipping brp_python_bytecompile

%define __os_install_post /usr/lib/rpm/redhat/brp-compress
    %{!?__debug_package:/usr/lib/rpm/redhat/brp-strip %{__strip}}
    /usr/lib/rpm/redhat/brp-strip-static-archive %{__strip}
    /usr/lib/rpm/redhat/brp-strip-comment-note %{__strip} %{__objdump}
    /usr/lib/rpm/redhat/brp-java-repack-jars
%{nil}

[Rich (rich-redhat-bugs)]

Probably not relevant, but the symptom arose creating a sub-package for an x86_64 package.

[Andrius (andrius-redhat-bugs)]

Proposing for RHEL 5.5, unless there is an extenuating business case for this to be proposed for RHEL 5.4 by Stratus.

[Nate (nate-redhat-bugs)]

Related to bug 236535

[Chris (chris-redhat-bugs)]

@Stratus,

We would like to confirm that there is commitment to test
for the resolution of this request during the RHEL 5.5 test
phase, if it is accepted into the release.

Please post a confirmation before Oct 16th, 2009,
including the contact information for testing engineers.

[Rich (rich-redhat-bugs)]

I am signed up to test from the Stratus side.

[RHEL (rhel-redhat-bugs)]

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

[Andrius (andrius-redhat-bugs)]

Deferring to RHEL 5.6 with OK from Stratus.

[Andrius (andrius-redhat-bugs)]

Rich @ Stratus: I'm getting word that this probably won't ever get fixed in RHEL 5. What's your take on this?

[Rich (rich-redhat-bugs)]

(In reply to comment #9)
> Rich @ Stratus: I'm getting word that this probably won't ever get fixed in
> RHEL 5. What's your take on this?

Not getting a fix in RHEL 5 is fine. We have a workaround.