[Bug 449667] Review Request: python-yenc - yEnc Module for Python

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.

Summary: Review Request: python-yenc - yEnc Module for Python


https://bugzilla.redhat.com/show_bug.cgi?id=449667


tibbs at math.uh.edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|nobody at fedoraproject.org    |tibbs at math.uh.edu
             Status|NEW                         |ASSIGNED
               Flag|                            |fedora-review?




------- Additional Comments From tibbs at math.uh.edu  2008-06-06 19:40 EST -------
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.

-- 
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, or are watching someone who is.