Bug 449667

Hi,

I just had a quick look, it looks _ok_ but I think it needs some extra work
before it can be approved etc etc etc

The method you have used is acceptable for Fedora 8 but the powers that be
changed the SOP/best practice for handling eggs & setuptools, check out
http://fedoraproject.org/wiki/Packaging/Python/Eggs#Providing_Eggs_using_Setuptools
for an example, or have a look at python-dictclient's SPEC file -
http://cvs.fedoraproject.org/viewcvs/rpms/python-dictclient/F-8/python-dictclient.spec?rev=1.1&view=markup
- which was recently accepted into Fedora for a practical example.

I'm not sure if I'd be able to do a full review, it depends how much time I
have/if anyone else jumps in ahead.

Alright, sorry if it's not quite kosher yet. I was working off of the rpmdev-
the references you cited.

Apparently lost a line somewhere. "I was working off of the rpmdev-newspec
python- template and Packaging/Python and I'm going to take a look at the
references you cited."

OK, I'm having it build an egg now. New URLs:
Spec URL: http://konradm.fedorapeople.org/fedora/SPECS/python-yenc.spec
SRPM URL: http://konradm.fedorapeople.org/fedora/SRPMS/python-SRPM URL: http://konradm.fedorapeople.org/fedora/SRPMS/python-yenc-0.3-2.fc9.src.rpm

Ugh, Konqueror in kde4 seems a bit fragile. Actual URLs:
Spec URL: http://konradm.fedorapeople.org/fedora/SPECS/python-yenc.spec
SRPM URL: http://konradm.fedorapeople.org/fedora/SRPMS/python-SRPM URL: http://konradm.fedorapeople.org/fedora/SRPMS/python-yenc-0.3-2.fc9.src.rpm

Ugh, this is very frustrating. I'm sorry for so many comments (and incorrect
links) but my browser seems pretty broken. Please try and click the correct ones
:).

Looks mostly OK.  rpmlint says:
  E: non-standard-executable-perm /usr/lib64/python2.5/site-packages/_yenc.so 
   0775
which seems a bit odd; on my system all such python loadable modules are mode
755, mode 655, or mode 555.  It's probably best to clean this up; we don't know
how people might use group root.

  W: summary-not-capitalized yEnc Module for Python
This is OK; yEnc is the appropriate spelling.

Normally I'd suggest that you refer to the actual upstream for this module
(http://golug.cc.uniud.it/yenc.html) instead of another project which merely
keeps a copy, but I can't get to the actual upstream at the moment so perhaps
it's gone away.

I don't see the point of indicating in the %description that the module is used
by "hellanzb"; it's somewhat of a non sequitur since there's nothing to indicate
what hellanzb is, there's no guarantee that nothing else will use it, and if
someone wants to see what uses this module, they need only use the package's
dependency information.

It might be nice to define yEnc in the %description, though.  This, from
wikipedia, seems appropriate:
  yEnc is a binary-to-text encoding scheme for transferring binary files in 
  messages on Usenet or via e-mail.

For some reason all of the compiler flags appear either twice or three times
when gcc is called.  I have no idea why this is.  The tripled flags come from
extra_compile_args in setup.py, I think, but I don't know where the others come
from.  Anyway, it doesn't seem to cause any problems, and almost certainly isn't
a bug in this package anyway.

There's some kind of test suite present; can you see if it's runnable?  I think
it should be if you set PYTHONPATH properly.

* source files match upstream:
   fb04fea7c5821345608fa01728ce5356b6dfb2d3e469e59e3fd31b88f45fb313  
   yenc-0.3.tar.gz
* package meets naming and versioning guidelines.
* specfile is properly named, is cleanly written and uses macros consistently.
* summary is OK.
X description could use a couple of tweaks.
* dist tag is present.
* build root is OK.
* license field matches the actual license.
* license is open source-compatible.
* license text included in package.
* latest version is being packaged.
* BuildRequires are proper.
* compiler flags are appropriate.
* %clean is present.
* package builds in mock (rawhide, x86_64).
* package installs properly.
* debuginfo package looks complete.
X rpmlint has a valid complaint.
* final provides and requires are sane:
   _yenc.so()(64bit)
   python-yenc = 0.3-2.fc10
  =
   libpython2.5.so.1.0()(64bit)
   python(abi) = 2.5

? %check is not present but there seems to be a test suite present.
* no shared libraries are added to the regular linker search paths.
* owns the directories it creates.
* doesn't own any directories it shouldn't.
* no duplicates in %files.
X file permissions on _yenc.so are odd.
* no scriptlets present.
* code, not content.
* documentation is small, so no -doc subpackage is necessary.
* %docs are not necessary for the proper functioning of the package.
* no headers.
* no pkgconfig files.
* no static libraries.
* no libtool .la files.

Thanks for the quick response! New URLs:
Spec: http://konradm.fedorapeople.org/fedora/SPECS/python-yenc.spec
SRPM: http://konradm.fedorapeople.org/fedora/SRPMS/python-yenc-0.3-3.fc9.src.rpm

Unfortunately the new ones don't build.  The tests fail because they can't
import the yenc module directly, since it's not installed.  That's why I
mentioned messing with PYTHONPATH.

Are you testing builds in mock or koji?

Ah, my mistake. I didn't try it in mock or koji, oops. New SRPM (spec hasn't
moved):
http://konradm.fedorapeople.org/fedora/SRPMS/python-yenc-0.3-4.fc9.src.rpm

Builds on koji:
http://koji.fedoraproject.org/koji/taskinfo?taskID=651477

Actually that chmod should be "g-w" if you want to fix up the "strange
permission" complaint, but it's not a really big deal.  Everything else looks
good to me; the tests seem to run fine.

APPROVED; you can fix up the permission bit, if you want to, when you check in.

New Package CVS Request
=======================
Package Name: python-yenc
Short Description: yEnc Module for Python
Owners: konradm
Branches: F-8 F-9
InitialCC:
Cvsextras Commits: yes

cvs done.

Built in rawhide (http://koji.fedoraproject.org/koji/taskinfo?taskID=657964).

Package Change Request
======================
Package Name: python-yenc
New Branches: EL-5

cvs done.