Spec URL: http://people.redhat.com/roland/tmp/trac-monotone-plugin.spec SRPM URL: http://people.redhat.com/roland/tmp/trac-monotone-plugin-0.0.11-1.20080112mtn.fc9.src.rpm Description: This Trac plugin provides support for the Monotone SCM.
New SRPM URL: http://people.redhat.com/roland/tmp/trac-monotone-plugin-0.0.12-1.fc9.src.rpm
This is my first review attempt so I'm probably going to miss something but I'm trying to get some experience with the fedora procedures. ok MUST: rpmlint output trac-monotone-plugin.noarch: E: non-executable-script /usr/lib/python2.5/site- packages/tracmtn/basic_io.py 0644 trac-monotone-plugin.noarch: E: non-executable-script /usr/lib/python2.5/site- packages/tracmtn/automate.py 0644 trac-monotone-plugin.noarch: E: non-executable-script /usr/lib/python2.5/site- packages/tracmtn/cache.py 0644 trac-monotone-plugin.noarch: E: non-executable-script /usr/lib/python2.5/site- packages/tracmtn/backend.py 0644 trac-monotone-plugin.noarch: E: non-executable-script /usr/lib/python2.5/site- packages/tracmtn/util.py 0644 trac-monotone-plugin.noarch: E: non-executable-script /usr/lib/python2.5/site- packages/tracmtn/__init__.py 0644 Seems silly to patch these out, I would consider asking upstream to remove the shebangs since it doesn't look like these are inteded to be executed. ok MUST: name follows naming guidelines ok MUST: spec file matches package name ok MUST: The package must meet the Packaging Guidelines. ok MUST: license is acceptable ok MUST: license is correct ok MUST: license file included in doc ok MUST: The spec file must be written in American English. ok MUST: spec file is readable NO MUST: source matches upstream The instructions for retrieving the source from the upstream vcs does not specify a specific tag or revision. This makes it impossible to verify the source. ok MUST: package builds successfully NO MUST: BuildRequires is complete trac is required at build because it is imported (indirectly) from setup.py ok MUST: owns created directories ok MUST: A package must not contain any duplicate files in the %files listing. ok MUST: permssions are correct ok MUST: clean removes buildroot ok MUST: macros used consistently ok MUST: package contains code or permissable content ok MUST: package does not depend on %doc files ok MUST: doesn't own other package's files ok MUST: install preps buildroot ok MUST: All filenames in rpm packages must be valid UTF-8. SHOULD Items: NO SHOULD: builds in mock See above regarding buildrequires ok SHOULD: package works properly
Interesting that this build for Geoff, because it doesn't build for me. Geoff, did you do a mock build? Against which version of Fedora did you build? In mock, building against current rawhide repositories, I get: + /usr/bin/python setup.py build Traceback (most recent call last): File "setup.py", line 28, in <module> from tracmtn import __version__ as VERSION File "/builddir/build/BUILD/TracMonotone-0.0.12/tracmtn/__init__.py", line 6, in <module> import backend File "/builddir/build/BUILD/TracMonotone-0.0.12/tracmtn/backend.py", line 28, in <module> from trac.versioncontrol.api import Repository, Node, Changeset, \ ImportError: No module named trac.versioncontrol.api error: Bad exit status from /var/tmp/rpm-tmp.54163 (%build) I added a build-time depenency on trac and the package builds. I'll concurr with Geoff about the non-executable-script rpmlint complaints. Python programmers do this for some unknown reason and I'm long past blocking packages because of it. Wow, this is significantly broken; you can't even use setup.py to create the tarball without having trac installed. Really suboptimal. I did the checkout as instructed in the spec and the content I get differs. I think it's important to specify a date or a tag or whatever monotone supports to ensure that we can get a consistent checkout in the absense of an actual release tarball. On the plus side, it looks like many of the shebang lines are gone in the checkout I made.
(In reply to comment #3) > Interesting that this build for Geoff, because it doesn't build for me. Geoff, > did you do a mock build? Against which version of Fedora did you build? I thought it was clear from my comment but I guess not. It did not build for me in mock, but it did build outside of mock since I already had trac installed. I probably should have pasted the failure from mock. All part of the learning experience. > Wow, this is significantly broken; you can't even use setup.py to create the > tarball without having trac installed. Really suboptimal. It seems that they import the main module in setup.py so they only have to specify the version number in one place. I can see why this is attractive but I would think there is a less irritating way to do it. > I did the checkout as instructed in the spec and the content I get differs. I > think it's important to specify a date or a tag or whatever monotone supports to > ensure that we can get a consistent checkout in the absense of an actual release > tarball. I really don't understand why upstream doesn't seem to have tagged any revisions, bizarre. > On the plus side, it looks like many of the shebang lines are gone in the > checkout I made. Well that's one good thing I suppose.
(In reply to comment #4) > > Wow, this is significantly broken; you can't even use setup.py to the > > create tarball without having trac installed. Really suboptimal. > It seems that they import the main module in setup.py so they only have to > specify the version number in one place. Exactly, but fixed in 3907adc701ba257b87c83ce64cc06a86443ae47b. You should now (from upstreams pov) be able to build without having trac installed. > I really don't understand why upstream doesn't seem to have tagged any > revisions, bizarre. Upstream (that's me) doesn't tag revisions, because there are no recent, publicly announced releases. Nevertheless I'm increasing the version number even for small changes, in order to ease deployment using eggs. When there is a release, I will of course tag the corresponding revision within monotone. So, Roland is doing a snapshot release package, and I already suggested to him using the naming scheme outlined in http://fedoraproject.org/wiki/Packaging/NamingGuidelines#head-cfd71146dbb6f00cec9fe3623ea619f843394837 e.g. trac-monotone-0.0.12-1.20080116mtn3907adc701ba2. The combination of date and part of the revision id uniquely identifies a revision.
New spec and srpm uploaded.
I poked around and found the srpm at: http://people.redhat.com/roland/tmp/trac-monotone-plugin-0.0.12-1.20080116mtn3907adc7.fc9.src.rpm
Builds fine; rpmlint says: trac-monotone-plugin.noarch: W: no-version-in-last-changelog and indeed, the changelog entry doesn't have a version. http://fedoraproject.org/wiki/Packaging/Guidelines#Changelogs has info on changelog entry formats. Since that's the only issue I can find with this package, I'll go ahead and approve it and you can fix it when you check in. Checklist: * source files match upstream (I followed the instructions in the spec and diffed against the contents of the tarball.) * package meets naming and versioning guidelines. * specfile is properly named, is cleanly written and uses macros consistently. * summary is OK. * description is OK. * 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. * %clean is present. * package builds in mock (rawhide, x86_64). * package installs properly X rpmlint has one valid complaint. * final provides and requires are sane: trac-monotone-plugin = 0.0.12-1.20080116mtn3907adc7.fc9 = monotone >= 0.31 python(abi) = 2.5 python-setuptools trac * %check is not present; no test suite upstream. I don't have a trac instance I can use to test this. * owns the directories it creates. * doesn't own any directories it shouldn't. * no duplicates in %files. * file permissions are appropriate. * no scriptlets present. * code, not content. * documentation is small, so no -docs subpackage is necessary. * %docs are not necessary for the proper functioning of the package. APPROVED; please fix the changelog entry when checking in.
New Package CVS Request ======================= Package Name: trac-monotone-plugin Short Description: Monotone version control plugin for Trac Owners: roland Branches: F-7 F-8 EL-5 InitialCC: Cvsextras Commits: yes
cvs done.
Any reason not to close this ticket?
Package is approved and in Fedora. Is the packager supposed to close the bug or the reviewer?
Generally the packager closes things once they're satisfied that everything's progressing, or the packager requests that bodhi close the bug once the update is pushed.