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=531544 --- Comment #9 from Toshio Ernie Kuratomi <a.badger@xxxxxxxxx> 2010-11-07 16:54:11 EST --- Please up the Release number whenever you make a new spec file. Good: * Package named appropriately * License file is included * specfile is readable * tarball matches what's on satchmo but see the information in the Notes section. * Builds in koji * No locales to handle * No shared libraries * No bundled libraries * Not relocatable * Package owns all directories it creates * No files listed multiple times * Permissions set properly * Packages used consistently * Code not content * Nothing in %doc is used at runtime * No GUI * All filenames are valid UTF-8 Needswork: * License is LGPLv2+. Please update the spec file to reflect that. Note: * Removing the python_sitelib definition is fine as long as you are not planning on building on older releases. If you do want to build this on F13 or less or EL-4 or EL-5 you will need to add it back in. * Upstream seems dead as you note but there's several projects that have copies: - satchmo (where you got the tarball from) http://www.satchmoproject.com/snapshots/ - kraft: http://sourceforge.net/projects/kraft/files/ - template2pdf: http://code.google.com/p/template2pdf/ It would be very nice if you could contact these groups and get them to revive the project in some shape or form. For instance, everyone could contirbute to the template2pdf project and make that module the new upstream Currently the tarballs for these projects do not match but the differences are minor and not in the code. satchmo has a setup.py file, kraft is saved as tar.bz2, template2pdf has bundled the module in their code. * Realize that currently, as there is no upstream for this package, you are putting yourself on the hook for fixing anything wrong in the code, bugs, security issues, etc. This can be alleviated if you get those other projects to help out in creating a new canonical upstream. rpmlint: python-trml2pdf.src: W: no-cleaning-of-buildroot %clean python-trml2pdf.src: W: no-%clean-section Both of these are something that's needed in EPEL builds but not F-14. If you're not planning to build on EPEL-5 then you don't need to worry about this. python-trml2pdf.noarch: W: no-manual-page-for-binary trml2pdf This is not a requirement but if you want to write a man page for the script, it would be helpful for people looking to run it. It doesn't look like Debian has one so we'd have to write one rather than copy it. This is not a blocker. 3 packages and 0 specfiles checked; 0 errors, 5 warnings. Summary: So fixing the licensing issue is the only blocker to the package. Do take the things in the Note section under consideration. I also don't see any reviews from you. There's quite a few python-* reviews listed here: http://fedoraproject.org/PackageReviewStatus/NEW.html I know that the maintainer of the python-zope-* packages is quite active if you want a relatively quick turnaround time. If you'll just choose one review and let me know what you're doing, I'll check your review and then sponsor you so you can officially complete it. -- 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. _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review