Spec URL: http://kzak.fedorapeople.org/review/util-linux.spec SRPM URL: http://kzak.fedorapeople.org/review/util-linux-2.19-0.1.fc15.src.rpm Spec file diff (upgrade from v2.18 to v2.19 and rename): http://kzak.fedorapeople.org/review/2.18-to-2.19-spec.diff Description: the upstream project has been renamed back to util-linux. Please, review changes in the spec file (especially proper Provides: and Obsoletes: setting). Thanks.
formal review is here, see the notes explaining OK* and BAD statuses below: OK source files match upstream: 5dcb211602b1639a6cda5055f02245b8f94d0559 util-linux-2.19-rc1.tar.bz2 OK package meets naming and versioning guidelines. OK specfile is properly named, is cleanly written and uses macros consistently. OK dist tag is present. OK license field matches the actual license. BAD license is open source-compatible. License text included in package. OK latest version is being packaged. OK BuildRequires are proper. OK compiler flags are appropriate. OK package builds in mock (Rawhide/x86_64). OK debuginfo package looks complete. BAD rpmlint is silent. BAD final provides and requires look sane. N/A %check is present and all tests pass. OK shared libraries are added to the regular linker search paths with proper scriptlets OK owns the directories it creates. OK doesn't own any directories it shouldn't. OK no duplicates in %files. OK file permissions are appropriate. OK correct scriptlets present. OK code, not content. OK documentation is small, so no -docs subpackage is necessary. OK %docs are not necessary for the proper functioning of the package. OK headers in -devel OK pkgconfig files in -devel OK no libtool .la droppings. OK not a GUI app. - the uuidd, libmount, libblkid, libuuid subpackages must include their license text as %doc - rpmlint throws a lot of warnings/errors, mostly can be ignored I think, but they deserve a review - the compatibility Provides/Obsoletes should be cleaned up for the update path I suggest to use "Obsoletes: util-linux-ng < 2.19" (instead of < 2.18.1) - you can drop the Buildroot tag and the clean section, they are not needed in recent Fedoras (and next RHEL)
(In reply to comment #1) > - the uuidd, libmount, libblkid, libuuid subpackages must include their license > text as %doc Fixed. > - rpmlint throws a lot of warnings/errors, mostly can be ignored I think, but > they deserve a review I fixed some warnings. > - the compatibility Provides/Obsoletes should be cleaned up > for the update path I suggest to use "Obsoletes: util-linux-ng < 2.19" > (instead of < 2.18.1) Fixed. > - you can drop the Buildroot tag and the clean section, they are not needed in > recent Fedoras (and next RHEL) Fixed. The rpm and spec at fedorapeople.org has been update. I have also added a new code for mtab to specfile. Please, review.
there are few issues remaining - dracut contains "Requires: mount" and new util-linux doesn't provide that, will be fixed in dracut package - the architecture list "sparc sparcv9 sparc64" should be replaced with %{sparc} - the architecture list in "cytune_arch" should contain %{arm} instead of armv4l
Fixed and srpm and spec at fedorapeople.org updated.
All issues are fixed now, new dracut package is also built. This package rename is APPROVED.
New Package SCM Request ======================= Package Name: util-linux Short Description: A collection of basic system utilities Owners: kzak Branches: InitialCC:
For a retired/orphaned package you should use "Package SCM Request". I untired the package, so you should be able to take ownership at https://admin.fedoraproject.org/pkgdb/acls/name/util-linux . If not please make a new SCM request, thanks.
> For a retired/orphaned package you should use "Package SCM Request". Sorry "Package Change Request".
Package Change Request ====================== Package Name: util-linux New Branches: Owners: kzak InitialCC: [rename util-linux-ng back to util-linux]
I'm not sure what you're asking for here. We do not rename packages; we just create a new package under the new name and let the package owner retire the old package. However, util-linux already exists in pkgdb, so we can't just create it, and it's not even retired. So I'm really not sure what you're asking us to do here. Please describe in detail what operations you need an SCM admin to take for you and re-raise the fedora-cvs flag.
Sorry Jason, you're right. The git repository works as expected, so SCM request is unnecessary. Thanks.