Bug 428549 - Review Request: trac-monotone-plugin - Monotone version control plugin for Trac
Review Request: trac-monotone-plugin - Monotone version control plugin for Trac
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Tibbitts
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-12 23:09 EST by Roland McGrath
Modified: 2008-03-03 23:19 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-03-03 22:35:03 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
tibbs: fedora‑review+
kevin: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Description Roland McGrath 2008-01-12 23:09:03 EST
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.
Comment 2 Geoff Reedy 2008-01-13 21:58:21 EST
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

Comment 3 Jason Tibbitts 2008-01-15 20:32:49 EST
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.
Comment 4 Geoff Reedy 2008-01-15 22:49:36 EST
(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.
Comment 5 Thomas Moschny 2008-01-16 05:40:43 EST
(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.
Comment 6 Roland McGrath 2008-01-16 16:19:25 EST
New spec and srpm uploaded.
Comment 7 Jason Tibbitts 2008-01-16 18:26:42 EST
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
Comment 8 Jason Tibbitts 2008-01-16 22:03:56 EST
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.
Comment 9 Roland McGrath 2008-01-18 20:22:33 EST
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
Comment 10 Kevin Fenzi 2008-01-19 13:30:24 EST
cvs done.
Comment 11 Jason Tibbitts 2008-03-03 22:14:55 EST
Any reason not to close this ticket?
Comment 12 Roland McGrath 2008-03-03 22:35:03 EST
Package is approved and in Fedora.
Is the packager supposed to close the bug or the reviewer?
Comment 13 Jason Tibbitts 2008-03-03 23:19:15 EST
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.

Note You need to log in before you can comment on or make changes to this bug.