[Bug 504151] Review Request: python-iterthreader - Threaded itertools.imap

bugzilla at redhat.com bugzilla at redhat.com
Tue Jun 9 14:57:17 UTC 2009


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=504151





--- Comment #1 from Stepan Kasal <skasal at redhat.com>  2009-06-09 10:57:15 EDT ---
FAIL source files match upstream
  there seems to be no upstream.
  Source0: is a 70 lines long script; was it published somewhere?
    When adding this to the cvs, please commit Source0 as a text file, do not
    upload using the "sources"mechanism
  The URL: tag points to a list post post from 2006 that contained an almost
  identical script.
  But the Source0: script contains a copyright header; if the origin of that is
  a priv. comm. with the packager, please explain that in a comment in the spec
  file.  Actually, the link to the posting is better suited to be a comment,
  not an URL: tag.

FAIL package meets naming and versioning guidelines.
  version: 20060718
    -- I would use a lower version number, like 0.0.20060718 because I hate
      when one has to use epoch to go to a later version, if this library
      is ever released.
    -- Why the version resembles a date in 2006 (the original post) when the
       copyright mentiones (c) 2005-2008 ?

OK specfile is properly named, is cleanly written and uses macros consistently.
OK dist tag is present.
OK build root is correct.
FAIL license field matches the actual license.
  the licence fields says GPLv2, while the script inmplies it should be "MIT".
OK license is open source-compatible. (both are :-)
OK license text not included upstream.
OK license text not included in package, as it is not included upstream, as
   there is no upstream.
FAIL latest version is being packaged.
   Who knows?  This would also be resolved by the comment about the actual
   origin of the script, for which I asked above.
FAIL BuildRequires are proper.
   http://fedoraproject.org/wiki/Packaging/Python says:
   Python packages should be sure to have: BuildRequires: python-devel
OK %clean is present.
FAIL package builds in mock.
  add the mandatory build require and do s/py$/py*/ in %files to pack pycpyo
  then ok
OK package installs properly.
OK no debuginfo package
FAIL rpmlint is silent.
  -- see below, the warnings should be ignored, but the error should not:
 the module should not have executable bit set
OK final provides and requires are sane
OK %check not present, no test suite available
OK no shared libraries are added to the regular linker search paths.
OK owns the directories it creates.
OK doesn't own any directories it shouldn't.
OK no duplicates in %files.
FAIL file permissions are appropriate.
  clear the exec bit on the module
OK no scriptlets present.
OK code, not content.
OK no docs, headers, .pc files, .la files, desktop files

To sum up:
1)   fix the 8 items marked FAIL
2)   Moreover, I feel uneasy about creating this microscopic package;
I'd like to see a comment from someone who understand what is this module
good for and why is has to be packed as a tiny individual rpm.


Appendix:
$ rpmlint -i  python-iterthreader-20060718-1.fc11.{noarch,src}.rpm 
python-iterthreader.noarch: W: incoherent-version-in-changelog 0-1
['20060718-1.fc11', '20060718-1']
The last entry in %changelog contains a version identifier that is not
coherent with the epoch:version-release tuple of the package.

python-iterthreader.noarch: W: no-documentation
The package contains no documentation (README, doc, etc). You have to include
documentation files.

python-iterthreader.noarch: E: script-without-shebang
/usr/lib/python2.6/site-packages/iterthreader.py
This text file has executable bits set or is located in a path dedicated for
executables, but lacks a shebang and cannot thus be executed.  If the file is
meant to be an executable script, add the shebang, otherwise remove the
executable bits or move the file elsewhere.

1 packages and 0 specfiles checked; 1 errors, 2 warnings.

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




More information about the Fedora-package-review mailing list