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=731966 --- Comment #5 from Mark McLoughlin <markmc@xxxxxxxxxx> 2011-08-22 10:54:42 EDT --- Thanks for the review Steven! (In reply to comment #2) > [root@beast noarch]# rpmlint openstack-glance-2011.3-0.1.987bzr.fc15.noarch.rpm > openstack-glance.noarch: W: non-standard-uid /var/log/glance glance > openstack-glance.noarch: W: non-standard-uid /var/run/glance glance > openstack-glance.noarch: W: non-standard-uid /var/lib/glance glance Okay, this just means that these dirs are (a) owned by the glance user and (b) the glance user is dynamically allocated I've just followed the guidelines here: http://fedoraproject.org/wiki/Packaging:UsersAndGroups Which suggest allocating the uids and gids dynamically, but I've just now filed a static uidgid allocation request which would shut the warning up: https://bugzilla.redhat.com/732442 > openstack-glance.noarch: W: log-files-without-logrotate /var/log/glance I'll add a bugzilla to track this once. It's just a warning and the logs aren't huge > openstack-glance.noarch: W: no-manual-page-for-binary glance-scrubber > ... Will file a bugzilla for these too > openstack-glance.noarch: W: missing-lsb-keyword Provides in /etc/rc.d/init.d/openstack-glance-registry See: http://fedoraproject.org/wiki/Packaging:SysVInitScript In Fedora, a # Provides: line listing the name of the service that the initscript starts is not needed as the name of the service is implicitly Provided. I've add an empty Provides: line to work around the warning, though. > openstack-glance.noarch: W: incoherent-subsys /etc/rc.d/init.d/openstack-glance-registry $prog This turns out to be rpmlint getting confused by: suffix="registry" prog="openstack-glance-$suffix" instead of: suffix=registry prog=openstack-glance-$suffix I've changed it to the latter > (BLOCKER) Steve Traylen recommends that the package be ported to systemd. This > is not currently required by Fedora or reviewers to enforce this activity. Right. I'd prefer to defer switching to systemd until after the package has been included. I'll file a bugzilla to remind us to do this though > NEEDSWORK -> After fedora-review-+, please file a bug with upstream requesting > the upstream to release a license file in the software distribution Will do > NEEDSWORK -> I'd recommend removing the %{shortname} macro Yeah, I'm not a big fan of the macro either - done now. > NEEDSWORK -> Generally nightly builds should not be used for releasing Fedora > software. Many upstream projects remove upstream nightly build files in short > periods of time, making it impossible to validate the upstream sources. Is it > possible to use a stable or unstable release version? Fair point. The idea is to switch to the official Diablo release tarballs once it comes out in September. See: http://wiki.openstack.org/DiabloReleaseSchedule I'll also plan on switching to the diablo-4 milestone release when that comes out later this week, and stick with that until we get the official release (or, indeed, a release candidate). I'm not too worried about the logevity of the nightly snapshots; they have them archived since November 2010 currently. > The source1 and Source2 init script definitions use %{name} which is confusing > - a maintainer has to figure out what name means. Better not to use a macro > for this case. Okay, done. (In reply to comment #4) > Python package review: > > Please see: > http://fedoraproject.org/wiki/Packaging:Python > > To build a package containing python2 files, you need to have > > BuildRequires: python2-devel This came up in bug #731980 too. The question there is why we need the -devel package at all? BR: python2-devel vs BR: python-devel isn't such a big deal, except for future-proofing. Currently, python-devel Provides: python2-devel. I've just sent a mail to the python SIG asking for their clarification. Will update based on that. -- 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