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(a)redhat.com> 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.