Spec URL: http://www.benhur.prf.cuni.cz/medved-7/wydobitki/fedora/python-iterthreader/python-iterthreader.spec SRPM URL: http://www.benhur.prf.cuni.cz/medved-7/wydobitki/fedora/python-iterthreader/python-iterthreader-20060718-1.fc11.src.rpm Description: It is similar to itertools.imap, but it calls each function in its own thread and uses Queues for moving the data around.
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.
(In reply to comment #1) > 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. Just my comment ... this is not C, so even in 70 lines of code it is possible to make useful library, which this seems to be.
Setting the fedora-review flag since that seems to have been forgotten.
Closing per #4 and #5