Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=573151 --- Comment #9 from Dave Malcolm <dmalcolm@xxxxxxxxxx> 2010-03-17 11:53:44 EDT --- I discovered a problem with .pyc/.pyo files when attempting to rebuild python26-setuptools: on the build I did on my RHEL5 workstation, the .pyc files are incorrectly byte-compiled for 2.4, not 2.6 (the first four bytes are 6d f2 0d 0a, which is a 2.4 bytecode file, when it should be d1 f2 0d 0a for 2.6). The problem is that RHEL5's /usr/lib/rpm/redhat/macros contains a definition of %__os_install_post which invokes /usr/lib/rpm/brp-python-bytecompile without any arguments, which leads to all .py files in a package payload being byte-compiled with /usr/bin/python (rather than, say, /usr/bin/python2.6) If there's a mismatching "magic" number, Python can't used the cached bytecode, and will be forced to recompile the .py file (the bytecode _is_ incompatible), which is slow; if running as non-root the runtime will have to recompile every time, since it doesn't have permission to write back the .py file. If running as root the file will get written back, leading to noise from rpm -V and probably SELinux mislabeling woes. I believe this will affect anyone building any Python modules as RPMs for non-standard Python stacks on RHEL5. It looks like IUS builds are affected by the same problem: specifically, I looked at http://dl.iuscommunity.org/pub/ius/stable/Redhat/5/x86_64/python26-setuptools-0.6c9-1.1.ius.el5.noarch.rpm and it too has .pyc files erroneously starting with 0x6d (py2.4), not 0xd1 (py2.6). I ran into this problem with the Python 3 stack in Fedora, and I wrote an rpmlint test for it: https://bugzilla.redhat.com/show_bug.cgi?id=531102 which is in rpmlint upstream as of 0.93 We fixed it in Fedora 13 by fixing rpm-build: https://bugzilla.redhat.com/show_bug.cgi?id=531117 Changing rpm-build for this is not going to be doable in the context of EPEL, so it looks like we need to supply a script to do this. The approach I'm following is to add a new macro file: /etc/rpm/macros.python26 as part of the core "python26" package, containing a reimplementation of "__os_install_post" intended to be identical to the standard one, except that it specifies "python26" when invoking "brp-python-bytecompile". Then every python26-foo module would need to define __os_install_post to use the alternate implementation. rpm automatically looks in that directory for add-on macros, so no further work ought to be necessary. Hopefully this sounds sane. It looked like there were no lib vs lib64 differences in the implementation of the macro, but I didn't check on every architecture. I've tested this in my build of python26-setuptools, using the macro in this way in python26-setuptools.spec: %define __os_install_post %{__python26_os_install_post} and when doing so, the .pyc files in the payload correctly begin with byte 0xd1, rather than (incorrectly) with byte 0x6d. Updated specfile: http://dmalcolm.fedorapeople.org/epel-packaging/python26.spec Diff versus last specfile: http://dmalcolm.fedorapeople.org/epel-packaging/from-2.6.4-22-to-2.6.4-23.diff Updated SRPM: http://dmalcolm.fedorapeople.org/epel-packaging/python26-2.6.4-23.el5.src.rpm Scratch build in Koji: http://koji.fedoraproject.org/koji/taskinfo?taskID=2058979 Adds this rpmlint error, which is a false-positive: python26.i386: E: script-without-shebang /etc/rpm/macros.python26 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review