Bug 573151 (Python26EPEL5)

I am not sure if I will have time to review soon, but I will see what I can do. :)

For reference, the merge review for python is bug 226342, and the python3 review was bug 526126 (and briefly bug 554799 for the purposes of import).

I would be interested/capable of being a co-maintainer if necessary as I've been maintaining python26 for EL5 via the IUS Community Project [1] for a while now.  

 [1] http://iuscommunity.org, http://dl.iuscommunity.org/pub/ius


Should this go through, IUS would no longer maintain python26 but rather rely on it from EPEL (as it relies on EPEL already).

With the recommended 

 %__arch_install_post   /usr/lib/rpm/check-rpaths   /usr/lib/rpm/check-buildroot

as you mention above:

the build fails with

*    0x0001 ... standard RPATHs (e.g. /usr/lib); such RPATHs are a minor
*               issue but are introducing redundant searchpaths without
*               providing a benefit. They can also cause errors in multilib
*               environments.

ERROR   0001: file '/usr/lib64/python2.6/lib-dynload/_sqlite3.so' contains a standard rpath '/usr/lib64' in [/usr/lib64]

As you know the F13 python3 has a patch for this by the looks of things.

(In reply to comment #3)
> I would be interested/capable of being a co-maintainer if necessary as I've
> been maintaining python26 for EL5 via the IUS Community Project [1] for a while
> now.  
> 
>  [1] http://iuscommunity.org, http://dl.iuscommunity.org/pub/ius
> 
> 
> Should this go through, IUS would no longer maintain python26 but rather rely
> on it from EPEL (as it relies on EPEL already).    

I'm keen on having comaintainers.

I'm interested in maintaining python26.el5 versions of some modules; these modules are a subset of the ones that you've already packaged within IUS.  I'm most interested in distribute/setuptools, nosetests, and the db connectors for the postgres and mysql versions shipped in RHEL5.

Would you be OK with me taking some of your SRPMS from IUS and filing review requests for them within EPEL5?

(In reply to comment #4)
> With the recommended 
> 
>  %__arch_install_post   /usr/lib/rpm/check-rpaths  
> /usr/lib/rpm/check-buildroot
> 
> as you mention above:
> 
> the build fails with
> 
> *    0x0001 ... standard RPATHs (e.g. /usr/lib); such RPATHs are a minor
> *               issue but are introducing redundant searchpaths without
> *               providing a benefit. They can also cause errors in multilib
> *               environments.
> 
> ERROR   0001: file '/usr/lib64/python2.6/lib-dynload/_sqlite3.so' contains a
> standard rpath '/usr/lib64' in [/usr/lib64]
> 
> As you know the F13 python3 has a patch for this by the looks of things.    

Yes, thanks for the pointer.

Updated specfile: http://dmalcolm.fedorapeople.org/epel-packaging/python26.spec
Diff versus last specfile: http://dmalcolm.fedorapeople.org/epel-packaging/from-2.6.4-21-to-2.6.4-22.diff
Updated SRPM: http://dmalcolm.fedorapeople.org/epel-packaging/python26-2.6.4-22.el5.src.rpm

Scratch build in Koji
http://koji.fedoraproject.org/koji/taskinfo?taskID=2056639

New rpmlint output:
http://dmalcolm.fedorapeople.org/epel-packaging/rpmlint-results-task-2056641-python26-2.6.4-22-x86_64.txt

This fixes the rpath and the stray .bat file

(In reply to comment #5)
> ...
> 
> Would you be OK with me taking some of your SRPMS from IUS and filing review
> requests for them within EPEL5?    

Absolutely, that's why I mentioned it.  Once python26 is approved, we [IUS] will begin the EOL process of removing python26 from IUS (because IUS relies on and is meant to be installed with EPEL.. not conflict with it).

Thanks Dave.

(In reply to comment #7)
> Absolutely, that's why I mentioned it.  Once python26 is approved, we [IUS]
> will begin the EOL process of removing python26 from IUS (because IUS relies on
> and is meant to be installed with EPEL.. not conflict with it).
> 
> Thanks Dave.    

... as well as begin moving the python26-xxxxxx sub modules over to EPEL... let me know which ones you want to maintain, and I'll submit for the others.

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

(In reply to comment #9)
> time, since it doesn't have permission to write back the .py file.  If running
"the .pyc file", I meant to write

I had no idea...  I think that sounds sane and not a big deal if all the packagers need to do is define __os_install_post.  I assume python26-devel would provide the macros file?

(In reply to comment #11)
> I had no idea...  I think that sounds sane and not a big deal if all the
> packagers need to do is define __os_install_post.  I assume python26-devel
> would provide the macros file?    
I actually added it to the core "python26" subpackage.


I've opened a review request for python26-setuptools; see bug 574506 (marked as depending on this one)

I've opened a review request for python26-nose; see bug 574531 (marked as depending on bug 574506)

Likewise, I've opened a review request for python26-mysqldb; see bug 574545 (again, marked as depending on bug 574506)

Created attachment 400877 [details]
Clean rpmlint on .spec file.

This is  cosmetic but cleans up:

python26.spec:342: W: unversioned-explicit-obsoletes Distutils
python26.spec:343: W: unversioned-explicit-provides Distutils
python26.spec:344: W: unversioned-explicit-obsoletes python2
python26.spec:415: W: unversioned-explicit-obsoletes python2-devel
python26.spec:436: W: unversioned-explicit-obsoletes python2-tools
python26.spec:451: W: unversioned-explicit-obsoletes tkinter2
python26.spec:730: E: hardcoded-library-path in %{buildroot}/usr/lib/python%{pybasever}/site-packages
python26.spec:789: E: hardcoded-library-path in %{_prefix}/lib/debug/%{_libdir}
python26.spec:956: E: hardcoded-library-path in %{_prefix}/lib/python%{pybasever}
python26.spec:957: E: hardcoded-library-path in %{_prefix}/lib/python%{pybasever}/site-packages
python26.spec: W: mixed-use-of-spaces-and-tabs (spaces: line 27, tab: line 159)
python26.spec: W: %ifarch-applied-patch Patch101: python-2.3.4-lib64-regex.patch

to

python26.spec:728: E: hardcoded-library-path in %{buildroot}/usr/lib/python%{pybasever}/site-packages
python26.spec:787: E: hardcoded-library-path in %{_prefix}/lib/debug/%{_libdir}
python26.spec:954: E: hardcoded-library-path in %{_prefix}/lib/python%{pybasever}
python26.spec:955: E: hardcoded-library-path in %{_prefix}/lib/python%{pybasever}/site-packages
python26.spec: W: %ifarch-applied-patch Patch101: python-2.3.4-lib64-regex.patch

The hardcoded-lib-paths are easily justified. I leave to someone else
to decide if that last patch is safe on other archs.

Changing
install %{SOURCE5} %{buildroot}%{_sysconfdir}/rpm/macros.python26
to
install -p -m 644 %{SOURCE5} %{buildroot}%{_sysconfdir}/rpm/macros.python26

will remove the  
python26.i386: E: script-without-shebang /etc/rpm/macros.python26

Dave: Any thoughts on Steve's changes from comment 15/16? 

I'm going to try and review this sometime this week, but an updated package would be good. ;)

Sorry about the delay.

2.6.5 was released on Friday, so I've bumped the version to this.

(In reply to comment #16)
> Changing
> install %{SOURCE5} %{buildroot}%{_sysconfdir}/rpm/macros.python26
> to
> install -p -m 644 %{SOURCE5} %{buildroot}%{_sysconfdir}/rpm/macros.python26
> 
> will remove the  
> python26.i386: E: script-without-shebang /etc/rpm/macros.python26    

Thanks!  I've made this change.

The comment from patch 15 contained some whitespace cleanup, which I'd prefer not to apply: I'm trying to keep this specfile as in-sync as possible with the Fedora python specfile
The other aspects I applied in order to reduce the noise from rpmlint, although they're all in the %if %{main_python} section, which should always be false (again, I'm trying to keep this in-sync with the Fedora specfile); I changed the "< 2.6.4" to "< 2.6.5"

As for patch 101, it's from the Fedora specfile, and merely adds a new selftest for http://bugs.python.org/issue931848
python26.spec: W: %ifarch-applied-patch Patch101: python-2.3.4-lib64-regex.patch

I did some archaeology here; looking at the internal RH CVS server this patch used to do more for the first day of its existance 2004-05-7, but the rest of it went upstream as part of what became http://bugs.python.org/issue931848 a day later, and hasn't needed to be arch specific in that time, I believe.

So I've made 101 not be arch-specific.


New specfile:
http://dmalcolm.fedorapeople.org/epel-packaging/python26.spec

Diff from last SRPM:
http://dmalcolm.fedorapeople.org/epel-packaging/from-python26-2.6.4-23-to-2.6.5-1.diff

New SRPM:
http://dmalcolm.fedorapeople.org/epel-packaging/python26-2.6.5-1.el5.src.rpm

Koji scratch build:
http://koji.fedoraproject.org/koji/taskinfo?taskID=2068956

(In reply to comment #18)

> The comment from patch 15 contained some whitespace cleanup, which I'd prefer
> not to apply: I'm trying to keep this specfile as in-sync as possible with the

yes of course the white space changes are fine to leave I would say,
they are all in your comments anyway.

ok. I am going to take a stab at reviewing this... Look for a review here in a while.

OK - Package meets naming and packaging guidelines
OK - Spec file matches base package name. 
OK - Spec has consistant macro usage. 
OK - Meets Packaging Guidelines. 
OK - License (python)
OK - License field in spec matches
OK - License file included in package
OK - Spec in American English
OK - Spec is legible.
OK - Sources match upstream md5sum:
6bef0417e71a1a1737ccf5750420fdb3  Python-2.6.5.tar.bz2
6bef0417e71a1a1737ccf5750420fdb3  Python-2.6.5.tar.bz2.orig

OK - BuildRequires correct
See below - Package has %defattr and permissions on files is good. 
OK - Package has a correct %clean section. 
OK - Package has correct buildroot
OK - Package is code or permissible content. 
OK - Doc subpackage needed/used. 
OK - Packages %doc files don't affect runtime. 
OK - Package has rm -rf RPM_BUILD_ROOT at top of %install

OK - Headers/static libs in -devel subpackage. 
OK - Spec has needed ldconfig in post and postun
OK - .so files in -devel subpackage.
OK - -devel package Requires: %{name} = %{version}-%{release}

OK - Package compiles and builds on at least one arch. 
See below - Package has no duplicate files in %files. 
OK - Package doesn't own any directories other packages own. 
OK - Package owns all the directories it creates. 
OK - Package obey's FHS standard (except for 2 exceptions)
See below - No rpmlint output. 
 - final provides and requires are sane.

SHOULD Items:

OK - Should build in mock. 
OK - Should function as described. 
OK - Should have sane scriptlets. 
OK - Should have subpackages require base package with fully versioned depend. 
OK - Should have dist tag
OK - Should package latest version
OK - Should not use file requires outside of /etc, /bin, /sbin, /usr/bin, or /usr/sbin

Notes: 

This is a long and complex spec, but it's very readable. :) 
I really appreciate the patches descriptions in particular. 

Issues/comments: 

1. It there any value in running some of the tests shipped in python26-test at build 
time in %test? Or are those more standalone testing framework files?
(They look like they might be unit tests, but not sure how easily they would be run)

2. Looks like there are some files listed twice?

warning: File listed twice: /usr/lib/python2.6/config/Setup
warning: File listed twice: /usr/lib/python2.6/config/Setup.config
warning: File listed twice: /usr/lib/python2.6/config/Setup.local
warning: File listed twice: /usr/lib/python2.6/config/config.c
warning: File listed twice: /usr/lib/python2.6/config/config.c.in
warning: File listed twice: /usr/lib/python2.6/config/install-sh
warning: File listed twice: /usr/lib/python2.6/config/libpython2.6.so
warning: File listed twice: /usr/lib/python2.6/config/makesetup
warning: File listed twice: /usr/lib/python2.6/config/python.o

3. Does the %{?_isa} dep with the devel package work in el5? 
I think RHEL5 rpm is basically just ignoring this: 

rpm -qp python26-devel-2.6.5-1.el5.x86_64.rpm --requires
python26 = 2.6.5-1.el5

4. rpmlint says a lot of things. Most of which can be ignored. 

Ignore/non blocker: 

python26.src: W: strange-permission pythondeps.sh 0775L
python26.src:728: E: hardcoded-library-path in %{buildroot}/usr/lib/python%{pybasever}/site-packages
python26.src:787: E: hardcoded-library-path in %{_prefix}/lib/debug/%{_libdir}
python26.src:956: E: hardcoded-library-path in %{_prefix}/lib/python%{pybasever}
python26.src:957: E: hardcoded-library-path in %{_prefix}/lib/python%{pybasever}/site-packages
python26.src:181: W: mixed-use-of-spaces-and-tabs (spaces: line 181, tab: line 159)
python26.src: W: invalid-url Source1: libpython-36a517ef7848cbd0b3dcc7371f32e47ac4c87eba.tar.gz

I suppose these should be 755? 

python26.x86_64: E: non-standard-executable-perm /usr/lib64/python2.6/lib-dynload/_ssl.so 0555L
python26.x86_64: E: non-standard-executable-perm /usr/lib64/python2.6/lib-dynload/grpmodule.so 0555L
python26.x86_64: E: non-standard-executable-perm /usr/lib64/python2.6/lib-dynload/_md5module.so 0555L
python26.x86_64: E: non-standard-executable-perm /usr/lib64/python2.6/lib-dynload/timemodule.so 0555L
python26.x86_64: E: non-standard-executable-perm /usr/lib64/python2.6/lib-dynload/_csv.so 0555L
python26.x86_64: E: non-standard-executable-perm /usr/lib64/python2.6/lib-dynload/dlmodule.so 0555L
python26.x86_64: E: non-standard-executable-perm /usr/lib64/python2.6/lib-dynload/cStringIO.so 0555L
python26.x86_64: E: non-standard-executable-perm /usr/lib64/python2.6/lib-dynload/termios.so 0555L
python26.x86_64: E: non-standard-executable-perm /usr/lib64/python2.6/lib-dynload/binascii.so 0555L
python26.x86_64: E: non-standard-executable-perm /usr/lib64/python2.6/lib-dynload/mathmodule.so 0555L
python26.x86_64: E: non-standard-executable-perm /usr/lib64/python2.6/lib-dynload/zlibmodule.so 0555L
python26.x86_64: E: non-standard-executable-perm /usr/lib64/python2.6/lib-dynload/_shamodule.so 0555L
python26.x86_64: E: non-standard-executable-perm /usr/lib64/python2.6/lib-dynload/_codecs_cn.so 0555L
python26.x86_64: W: devel-file-in-non-devel-package /usr/include/python2.6/pyconfig-64.h
python26.x86_64: E: non-standard-executable-perm /usr/lib64/python2.6/lib-dynload/_bsddb.so 0555L
python26.x86_64: E: non-standard-executable-perm /usr/lib64/python2.6/lib-dynload/nismodule.so 0555L
python26.x86_64: E: non-standard-executable-perm /usr/lib64/python2.6/lib-dynload/_collectionsmodule.so 0555L
python26.x86_64: E: non-standard-executable-perm /usr/lib64/python2.6/lib-dynload/imageop.so 0555L
python26.x86_64: E: non-standard-executable-perm /usr/lib64/python2.6/lib-dynload/linuxaudiodev.so 0555L
python26.x86_64: E: non-standard-executable-perm /usr/lib64/python2.6/lib-dynload/operator.so 0555L
python26.x86_64: E: non-standard-executable-perm /usr/lib64/python2.6/lib-dynload/_weakref.so 0555L
python26.x86_64: E: non-standard-executable-perm /usr/lib64/python2.6/lib-dynload/_sha256module.so 0555L
python26.x86_64: E: non-standard-executable-perm /usr/lib64/python2.6/lib-dynload/fcntlmodule.so 0555L
python26.x86_64: E: non-standard-executable-perm /usr/lib64/python2.6/lib-dynload/mmapmodule.so 0555L
python26.x86_64: E: non-standard-executable-perm /usr/lib64/python2.6/lib-dynload/cPickle.so 0555L
python26.x86_64: E: non-standard-executable-perm /usr/lib64/python2.6/lib-dynload/stropmodule.so 0555L
python26.x86_64: E: non-standard-executable-perm /usr/lib64/python2.6/lib-dynload/_bisectmodule.so 0555L
python26.x86_64: E: non-standard-executable-perm /usr/lib64/python2.6/lib-dynload/audioop.so 0555L
python26.x86_64: E: non-standard-executable-perm /usr/lib64/python2.6/lib-dynload/_socketmodule.so 0555L
python26.x86_64: E: non-standard-executable-perm /usr/lib64/python2.6/lib-dynload/spwdmodule.so 0555L
python26.x86_64: E: non-standard-executable-perm /usr/lib64/python2.6/lib-dynload/cmathmodule.so 0555L
python26.x86_64: E: non-standard-executable-perm /usr/lib64/python2.6/lib-dynload/gdbmmodule.so 0555L
python26.x86_64: E: non-standard-executable-perm /usr/lib64/python2.6/lib-dynload/_codecs_iso2022.so 0555L
python26.x86_64: E: non-standard-executable-perm /usr/lib64/python2.6/lib-dynload/_codecs_kr.so 0555L
python26.x86_64: E: non-standard-executable-perm /usr/lib64/python2.6/lib-dynload/_multibytecodecmodule.so 0555L
python26.x86_64: E: non-standard-executable-perm /usr/lib64/python2.6/lib-dynload/selectmodule.so 0555L
python26.x86_64: E: non-standard-executable-perm /usr/lib64/python2.6/lib-dynload/resource.so 0555L
python26.x86_64: E: non-standard-executable-perm /usr/lib64/python2.6/lib-dynload/_localemodule.so 0555L
python26.x86_64: E: non-standard-executable-perm /usr/lib64/python2.6/lib-dynload/_codecs_hk.so 0555L
python26.x86_64: E: non-standard-executable-perm /usr/lib64/python2.6/lib-dynload/_codecs_jp.so 0555L
python26.x86_64: E: non-standard-executable-perm /usr/lib64/python2.6/lib-dynload/cryptmodule.so 0555L
python26.x86_64: E: non-standard-executable-perm /usr/lib64/python2.6/lib-dynload/timingmodule.so 0555L
python26.x86_64: E: non-standard-executable-perm /usr/lib64/python2.6/lib-dynload/_struct.so 0555L
python26.x86_64: E: non-standard-executable-perm /usr/lib64/python2.6/lib-dynload/parsermodule.so 0555L
python26.x86_64: E: non-standard-executable-perm /usr/lib64/python2.6/lib-dynload/_codecs_tw.so 0555L
python26.x86_64: E: non-standard-executable-perm /usr/lib64/python2.6/lib-dynload/xxsubtype.so 0555L
python26.x86_64: E: non-standard-executable-perm /usr/lib64/python2.6/lib-dynload/itertoolsmodule.so 0555L
python26.x86_64: E: non-standard-executable-perm /usr/lib64/python2.6/lib-dynload/unicodedata.so 0555L
python26.x86_64: E: non-standard-executable-perm /usr/lib64/python2.6/lib-dynload/readline.so 0555L
python26.x86_64: E: non-standard-executable-perm /usr/lib64/python2.6/lib-dynload/_randommodule.so 0555L
python26.x86_64: E: non-standard-executable-perm /usr/lib64/python2.6/lib-dynload/_functoolsmodule.so 0555L
python26.x86_64: E: non-standard-executable-perm /usr/lib64/python2.6/lib-dynload/arraymodule.so 0555L
python26.x86_64: E: non-standard-executable-perm /usr/lib64/python2.6/lib-dynload/_sha512module.so 0555L
python26-libs.x86_64: W: spelling-error Summary(en_US) runtime -> run time, run-time, untimely
python26-libs.x86_64: E: non-standard-executable-perm /usr/lib64/libpython2.6.so.1.0 0555L
python26-test.x86_64: W: spelling-error %description -l en_US unittest -> unit test, unit-test, unattested
python26-test.x86_64: W: spelling-error %description -l en_US py -> pt, p, y
python26-test.x86_64: W: no-documentation
python26-test.x86_64: E: non-standard-executable-perm /usr/lib64/python2.6/lib-dynload/_testcapimodule.so 0555L
python26-test.x86_64: E: zero-length /usr/lib64/python2.6/test/nullcert.pem
python26-test.x86_64: W: uncompressed-zip /usr/lib64/python2.6/test/zipdir.zip
python26-tools.x86_64: W: spelling-error %description -l en_US gettext -> get text, get-text, getting
python26-tools.x86_64: W: spelling-error %description -l en_US pygettext -> hypertext, Bridgette, courgette
python26-tools.x86_64: W: spelling-error %description -l en_US py -> pt, p, y

chmod these to 644 ?

python26-tools.x86_64: E: script-without-shebang /usr/lib64/python2.6/Demo/tix/bitmaps/filebox.xbm
python26-tools.x86_64: E: script-without-shebang /usr/lib64/python2.6/Tools/README
python26-tools.x86_64: E: script-without-shebang /usr/lib64/python2.6/Demo/tix/bitmaps/combobox.xpm.1
python26-tools.x86_64: E: script-without-shebang /usr/lib64/python2.6/Demo/scripts/newslist.doc
python26-tools.x86_64: E: script-without-shebang /usr/lib64/python2.6/Demo/tix/bitmaps/centerj.xbm
python26-tools.x86_64: E: script-without-shebang /usr/lib64/python2.6/Demo/tix/bitmaps/netw.xpm
python26-tools.x86_64: E: script-without-shebang /usr/lib64/python2.6/Demo/tix/bitmaps/optmenu.xpm
python26-tools.x86_64: E: script-without-shebang /usr/lib64/python2.6/Demo/tix/bitmaps/netw.xbm
python26-tools.x86_64: W: devel-file-in-non-devel-package /usr/lib64/python2.6/Demo/embed/demo.c
python26-tools.x86_64: E: script-without-shebang /usr/lib64/python2.6/Demo/tix/bitmaps/select.xpm
python26-tools.x86_64: E: script-without-shebang /usr/lib64/python2.6/Demo/tix/bitmaps/bold.xbm
python26-tools.x86_64: W: devel-file-in-non-devel-package /usr/lib64/python2.6/Demo/embed/importexc.c
python26-tools.x86_64: E: script-without-shebang /usr/lib64/python2.6/Demo/tix/bitmaps/leftj.xbm
python26-tools.x86_64: E: script-without-shebang /usr/lib64/python2.6/Demo/tix/bitmaps/about.xpm
python26-tools.x86_64: E: script-without-shebang /usr/lib64/python2.6/Demo/tix/bitmaps/capital.xbm
python26-tools.x86_64: E: script-without-shebang /usr/lib64/python2.6/Demo/comparisons/patterns
python26-tools.x86_64: W: devel-file-in-non-devel-package /usr/lib64/python2.6/Demo/embed/loop.c
python26-tools.x86_64: E: script-without-shebang /usr/lib64/python2.6/Demo/tix/bitmaps/italic.xbm
python26-tools.x86_64: E: script-without-shebang /usr/lib64/python2.6/Demo/tix/bitmaps/exit.xpm
python26-tools.x86_64: E: script-without-shebang /usr/lib64/python2.6/Demo/tix/bitmaps/combobox.xpm
python26-tools.x86_64: E: script-without-shebang /usr/lib64/python2.6/Demo/tix/bitmaps/underline.xbm
python26-tools.x86_64: E: script-without-shebang /usr/lib64/python2.6/Demo/tix/bitmaps/combobox.xbm
python26-tools.x86_64: E: script-without-shebang /usr/lib64/python2.6/Demo/md5test/foo
python26-tools.x86_64: E: script-without-shebang /usr/lib64/python2.6/Demo/tix/bitmaps/justify.xbm
python26-tools.x86_64: E: script-without-shebang /usr/lib64/python2.6/Demo/tix/bitmaps/rightj.xbm
python26-tools.x86_64: W: devel-file-in-non-devel-package /usr/lib64/python2.6/Demo/pysvr/pysvr.c
python26-tools.x86_64: E: script-without-shebang /usr/lib64/python2.6/Demo/tix/bitmaps/drivea.xpm
python26-tools.x86_64: E: script-without-shebang /usr/lib64/python2.6/Demo/rpc/test
python26-tools.x86_64: E: script-without-shebang /usr/lib64/python2.6/Demo/tix/bitmaps/drivea.xbm
python26-tools.x86_64: E: script-without-shebang /usr/lib64/python2.6/Demo/tix/bitmaps/filebox.xpm
tkinter26.x86_64: W: spelling-error %description -l en_US tkinter -> painter, pointer, printer
tkinter26.x86_64: W: no-documentation
tkinter26.x86_64: E: non-standard-executable-perm /usr/lib64/python2.6/lib-dynload/_tkinter.so 0555L

Should be %config(noreplace) ?

python26.x86_64: W: non-conffile-in-etc /etc/rpm/macros.python26

Nothing too outstanding there... might be good to fix some permissions 
though if you have a chance.

(Thanks for the detailed comments, and sorry for the lack of response so far; I'm working on getting the selftest suite working within %check within Koji; hope to post a longer response soon).

(In reply to comment #21)
> 1. It there any value in running some of the tests shipped in python26-test at
> build time in %test? Or are those more standalone testing framework files?
> (They look like they might be unit tests, but not sure how easily they would
> be run)

I've added a %check section which runs the tests (though I run them from the build directory, rather than the buildroot).

I've listed the tests that are known to fail, and the %check ought to fail and halt the build if a test fails in one of the other suites (this is done on a per-file basis rather than a per-case basis, but it seems good for now).


> 2. Looks like there are some files listed twice?

Fixed


> 3. Does the %{?_isa} dep with the devel package work in el5? 
> I think RHEL5 rpm is basically just ignoring this: 

Good catch.  According to http://www.rpm.org/wiki/PackagerDocs/ArchDependencies , _isa was added in rpm 4.6.0, so, yes, this does nothing on a build with RHEL 5's rpm 4.4.2.3

It doesn't hurt though.  Is it OK to keep, for consistency with Fedora, or should I drop it?


> 4. rpmlint says a lot of things. Most of which can be ignored. 

(To be addressed; I wanted to give you an update on progress so far)


New specfile:
http://dmalcolm.fedorapeople.org/epel-packaging/python26.spec

Diff from last SRPM:
http://dmalcolm.fedorapeople.org/epel-packaging/from-python26-2.6.5-1-to-2.6.5-2.diff

New SRPM:
http://dmalcolm.fedorapeople.org/epel-packaging/python26-2.6.5-2.el5.src.rpm

Successful scratch build here:
http://koji.fedoraproject.org/koji/taskinfo?taskID=2092150

Points 1 and 2 look good.

On 3: I think on the isa, it would be ok to leave it, but you should add a comment about it not working in RHEL, so people don't think it does. ;) 

Let me know what you think of the various rpmlint complaints when you get a chance. ;)

(In reply to comment #24)
> Points 1 and 2 look good.
> 
> On 3: I think on the isa, it would be ok to leave it, but you should add a
> comment about it not working in RHEL, so people don't think it does. ;) 

I changed my mind on this, and in the latest version I simply removed it.

Having said that, is it a problem to not have it?
Rereading http://www.rpm.org/wiki/PackagerDocs/ArchDependencies , is there a better way to express python-devel's dependency on python?


> Let me know what you think of the various rpmlint complaints when you get a
> chance. ;)    
I've tried to fix the permissions issues (and others) you identified.

New specfile:
http://dmalcolm.fedorapeople.org/epel-packaging/python26.spec

Diff from last SRPM:
http://dmalcolm.fedorapeople.org/epel-packaging/from-python26-2.6.5-2-to-2.6.5-3.diff

New SRPM:
http://dmalcolm.fedorapeople.org/epel-packaging/python26-2.6.5-3.el5.src.rpm

Scratch build in Koji:
http://koji.fedoraproject.org/koji/taskinfo?taskID=2098596

rpmlint results on the x86_64 build (task 2098598)
$ rpmlint *.rpm|sort
7 packages and 0 specfiles checked; 1 errors, 9 warnings.
python26-test.x86_64: E: zero-length /usr/lib64/python2.6/test/nullcert.pem
python26-test.x86_64: W: no-documentation
python26-test.x86_64: W: uncompressed-zip /usr/lib64/python2.6/test/zipdir.zip
python26-tools.x86_64: W: devel-file-in-non-devel-package /usr/lib64/python2.6/Demo/embed/demo.c
python26-tools.x86_64: W: devel-file-in-non-devel-package /usr/lib64/python2.6/Demo/embed/importexc.c
python26-tools.x86_64: W: devel-file-in-non-devel-package /usr/lib64/python2.6/Demo/embed/loop.c
python26-tools.x86_64: W: devel-file-in-non-devel-package /usr/lib64/python2.6/Demo/pysvr/pysvr.c
python26.x86_64: W: devel-file-in-non-devel-package /usr/include/python2.6/pyconfig-64.h
python26.x86_64: W: incoherent-version-in-changelog 2.6.5-3 2.6.5-3.el5
tkinter26.x86_64: W: no-documentation

$ rpm -q rpmlint
rpmlint-0.85-4.rpmdiff.3.el5

> Having said that, is it a problem to not have it?
> Rereading http://www.rpm.org/wiki/PackagerDocs/ArchDependencies , is there a
> better way to express python-devel's dependency on python?

Not that I know of. Without the isa, someone could have a mismatched i386 and x86_64 python/python-devel, but there's no clever way around that without isa that I know of. ;( 

All the other issues I see are solved, so this package is APPROVED. 

Don't forget to dead.package and get this blocked in devel after import, it should only live in the EL-5 branch.

New Package CVS Request
=======================
Package Name: python26
Short Description: Parallel-installable Python 2.6 for EPEL5
Owners: dmalcolm
Branches: EL5
InitialCC: 

Note: this package is intended purely for EPEL, not for Fedora.

New Package CVS Request
=======================
Package Name: python26
Short Description: Parallel-installable Python 2.6 for EPEL5
Owners: dmalcolm
Branches: EL-5
InitialCC: 

Note: this package is intended purely for EPEL, not for Fedora.   

(gah; sorry; fixing branch name)

CVS done (by process-cvs-requests.py).

Note that there is always a devel branch made, so you will need to mark it 
with a dead.package and get it blocked by rel-eng so it doesn't show up ever
in Fedora.

Thanks

I've added a "dead.package" to the devel branch:
  http://cvs.fedoraproject.org/viewvc/rpms/python26/devel/dead.package?view=markup

I've imported the src.rpm to the EL-5 branch
  http://cvs.fedoraproject.org/viewvc/rpms/python26/EL-5/

Successful Koji build of python26-2.6.5-3.el5 into dist-5E-epel-testing-candidate:
  http://koji.fedoraproject.org/koji/taskinfo?taskID=2105700

I've submitted the build as an update here:
  https://admin.fedoraproject.org/updates/python26-2.6.5-3.el5

The package doesn't seem to appear here yet:
  https://admin.fedoraproject.org/pkgdb/packages/name/python26

Cool. You may also want to file a ticket with rel-eng track to block it in devel/rawhide, just to make sure it never gets built there. 

The pkgdb links have changed in a recent update, it's at: 
https://admin.fedoraproject.org/pkgdb/acls/name/python26

:)

(In reply to comment #31)
> Cool. You may also want to file a ticket with rel-eng track to block it in
> devel/rawhide, just to make sure it never gets built there. 

Filed as https://fedorahosted.org/rel-eng/ticket/3599


> The pkgdb links have changed in a recent update, it's at: 
> https://admin.fedoraproject.org/pkgdb/acls/name/python26

Thanks

python26-2.6.5-3.el5 has been submitted as an update for Fedora EPEL 5.
http://admin.fedoraproject.org/updates/python26-2.6.5-3.el5

python26-2.6.5-3.el5 has been pushed to the Fedora EPEL 5 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update python26'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/python26-2.6.5-3.el5

python26-2.6.5-3.el5 has been pushed to the Fedora EPEL 5 stable repository.  If problems still persist, please make note of it in this bug report.

FWIW, I started gathering some notes on this on this page:
  https://fedoraproject.org/wiki/Python26

Hopefully we can assemble some guidelines on how best to (re)package things for python26.  All just a draft at this stage.