Bug 727541 - Review Request: comoonics-base-py - base libs for comoonics-cdsl-py and comoonics-cluster-py
Summary: Review Request: comoonics-base-py - base libs for comoonics-cdsl-py and comoo...
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Nils Philippsen
QA Contact: Fedora Extras Quality Assurance
: 749562 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2011-08-02 12:16 UTC by Marc Grimme
Modified: 2016-04-08 10:07 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2016-04-08 10:07:22 UTC
Type: ---
tcallawa: fedora-review+
gwync: fedora-cvs+

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 511276 0 low CLOSED Review Request: comoonics-base-py - Comoonics minimum baselibraries written in Python 2021-02-22 00:41:40 UTC

Internal Links: 511276

Description Marc Grimme 2011-08-02 12:16:01 UTC
Spec URL: http://www.open-sharedroot.org/development/comoonics-base-py/comoonics-base-py.spec
SRPM URL: http://www.open-sharedroot.org/development/comoonics-base-py/comoonics-base-py-0.1.tar.gz
I just wanted to reenable (right now it is orphaned for Fedora 16) the package comoonics-base-py. It is dep for the packages comoonics-cdsl-py and comoonics-cluster-py.
In the last days they failed to build for rawhide because of the missing dep.

This package has been orphaned for Fedora 16. I took ownership of the older rpms but would need it also for Fedora 16 because of the dependencies so I would also like to take the ownership there too.

This package has been part of the Open-Sharedroot feature see http://fedoraproject.org/wiki/Features/Opensharedroot.

I reuploaded the sources/specs so they should build.

Let me know what I can do.


Comment 1 Nils Philippsen 2011-08-09 10:15:33 UTC
One issue up front: You didn't upload a source package built from the spec file (release -6), so besides the tarball you uploaded, I downloaded the latest one beside it (-3) and the latest one I found on a Fedora mirror (-5). After unpacking I ended up with three tarballs of the same name, but different contents and I found yet another different one in my rpmbuild directory (probably from the old review). As I mentioned in the original review of this package (cf. comment 9 in bug #511276) you must bump the version of the tarball if you change the contents. This is especially important to not make tools checking tarballs used to build packages against what is available upstream (i.e. at your site) warn unnecessarily.

Items marked "GOOD" or "PASS" fulfil the guidelines or they don't apply to this package.
Items marked "CHECK" aren't covered by the guidelines but you should check and fix them anyway in my opinion.
Items marked "BAD" violate the guidelines in some point and need to be fixed.

- BAD: rpmlint run on comoonics-base-py-0.1-5.src.rpm flags issues:

    nils@gibraltar:~/devel/reviews/fedora/comoonics-base-py> rpmlint comoonics-base-py-0.1-5.src.rpm
    comoonics-base-py.src: W: spelling-error Summary(en_US) baselibraries -> base libraries, base-libraries, libraries
    comoonics-base-py.src: W: spelling-error %description -l en_US baselibraries -> base libraries, base-libraries, libraries

  -> correct spelling

    comoonics-base-py.src: W: file-size-mismatch comoonics-base-py-0.1.tar.gz = 40620, http://www.open-sharedroot.org/development/comoonics-base-py/comoonics-base-py-0.1.tar.gz = 39598
    1 packages and 0 specfiles checked; 0 errors, 3 warnings.

  -> bump tarball version each time you change contents, see above

- GOOD/CHECK: named according to naming guidelines, but doesn't have a dist tag (cf. http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Using_the_.25.7B.3Fdist.7D_Tag). I found that you have many RPM packages for different distributions on your site, all of which only have a number as the release field. Adding a dist tag to the release could help distinguishing the packages for different distributions from each other.
- GOOD: spec file name matches package name
- BAD/CHECK: doesn't match python packaging guidelines (cf. http://fedoraproject.org/wiki/Packaging:Python):
  - BAD: as your package is for python 2.x, it needs to require python2-devel for building
  - CHECK: Fedora >= 13 (and EL >= 6) sets %python_sitelib, you could set it only for older releases like this:

    %if ! (0%{?fedora} > 12 || 0%{?rhel} > 5)
    %{!?python_sitelib: %global python_sitelib %(%{__python} -c "from distutils.sysconfig import get_python_lib; print(get_python_lib())")}
    %{!?python_sitearch: %global python_sitearch %(%{__python} -c "from distutils.sysconfig import get_python_lib; print(get_python_lib(1))")}

  - GOOD: includes source and byte-compiled python files properly

  I think you don't target python 3.x just yet, so we can dispense with the guidelines related to that. Mind that sometime in the future, 3.x might become the default and you would need to adapt your package in that case.

- GOOD: licensed well (GPLv3+)
- BAD: license field (GPLv2+) doesn't match actual license
- GOOD: package ships license text as %doc
- BAD: package is written in American English, but has spelling errors (see rpmlint output above)
- GOOD: spec file is legible
- BAD: sources used to build the package must match the upstream source, see above ;-)
- GOOD: package successfully builds into noarch package in mock for Fedora 15
- GOOD: Lists all build requirements
- PASS: no locale specific files
- PASS: no shared library files included
- GOOD: doesn't bundle system libraries
- PASS: package not marked as relocatable
- GOOD: package owns all directories that it creates
- GOOD: doesn't list files more than once
- GOOD: permissions on files set properly
- GOOD/CHECK: The package uses macros consistently. The python interpreter is referenced directly though, this might require fixing if python 3.x should become the default in the future.
- GOOD: package contains code
- PASS: no large documentation
- GOOD: %doc doesn't affect runtime
- PASS: no header files
- PASS: no static libraries
- PASS: doesn't contains libraries with suffix
- PASS: no -devel subpackage
- PASS: no libtool archive files on account of no libraries 
- PASS: no GUI app
- GOOD: doesn't own files or directories owned by other packages
- GOOD: all file names are valid UTF-8

Comment 2 Marc Grimme 2011-08-09 12:35:00 UTC
All negative passes should now be fixed.

I've also taken the last sources from comoonics-base-py-0.1-5 from fc15 and updated the uploaded one.

Comment 3 Nils Philippsen 2011-08-09 13:01:59 UTC
- GOOD: rpmlint run on current spec file/SRPM built from it doesn't flag any issues.
- GOOD: dist tag added
- GOOD: matches python packaging guidelines:
  - GOOD: requires python2-devel for building
  - GOOD: uses supplied %python_sitelib macro on Fedora >= 13
- GOOD: license field matches actual license
- GOOD: package is written in American English (spelling errors corrected)
- GOOD: sources used to build the package match the upstream source

This package is APPROVED.

Please continue with your part of the package review process -- cf. http://fedoraproject.org/wiki/Package_Review_Process#Contributor -- your next step (#8) is to make the SCM admin request to get the package out of retirement/undeprecated for Rawhide/devel and the branch created for Fedora 16. And take care of that if you roll new tarballs that they get new versions. Thanks!

Comment 4 Marc Grimme 2011-08-09 13:20:27 UTC
Package Change Request
Package Name: comoonics-base-py
New Branches: rawhide
Owners: elcody02

This package has been orphaned but is still needed for the packages comoonics-cdsl-py and comoonics-cluster-py as requirement.
I've taken ownership of this package and would like to request a retirement of this package for rawhide fc16.

Thanks Marc.

Comment 5 Nils Philippsen 2011-08-09 13:30:03 UTC
This ticket should remain on the "Package Review" component. Mind that you don't need a new branch for "devel" (Rawhide), but for Fedora 16 -- note the pkgdb entry: https://admin.fedoraproject.org/pkgdb/acls/name/comoonics-base-py

Comment 6 Gwyn Ciesla 2011-08-09 14:10:01 UTC
Unretired rawhide, please take ownership in pkgdb.

Comment 7 Nils Philippsen 2011-08-10 12:16:01 UTC
Marc, as Fedora 16 is already branched away from Rawhide -- http://fedoraproject.org/wiki/Releases/Branched -- you need to request an F-16 branch for this package, then build and issue an update (of type "newpackage") to get the package back in for all Fedora versions.

Comment 8 Marc Grimme 2011-08-12 05:57:41 UTC
New Package SCM Request
Package Name: comoonics-base-py
Short Description: base libs for comoonics-cdsl-py and comoonics-cluster-py
Owners: elcody02
Branches: f16

This package has been orphaned but is still needed for the packages
comoonics-cdsl-py and comoonics-cluster-py as requirement.
I've taken ownership of this package and would like to request a retirement/rebranch of
this package for fc16.

Thanks Marc.

Comment 9 Tom "spot" Callaway 2012-02-23 17:49:15 UTC
*** Bug 749562 has been marked as a duplicate of this bug. ***

Comment 10 Tom "spot" Callaway 2012-02-23 17:50:59 UTC
New Package SCM Request
Package Name: comoonics-base-py
Short Description: base libs for comoonics-cdsl-py and comoonics-cluster-py
Owners: elcody02
Branches: f16 f17

Comment 11 Gwyn Ciesla 2012-02-23 17:58:28 UTC
Reveiw flag should be set to + if approved, and the reviewer should take

Comment 12 Gwyn Ciesla 2012-02-23 19:50:39 UTC
Sorry, I should have read the whole BZ.  This already exists and is owned
for devel and f15, please file a Package Change request to get f16 and f17

Comment 13 Tom "spot" Callaway 2012-02-23 19:53:54 UTC
Package Change Request
Package Name: comoonics-base-py
New Branches: f16 f17
Owners: elcody02

Comment 14 Gwyn Ciesla 2012-02-23 19:58:54 UTC
Git done (by process-git-requests).

Comment 15 Marc Grimme 2012-02-24 08:12:00 UTC
I've had a look into the git repo. Still only the dead.package file. Do I have to  do something? Or just be patient?

Comment 16 Tom "spot" Callaway 2012-02-24 13:53:00 UTC
Marc, you should have commit access to the git repo. Just git rm dead.package and treat it as if it were a new package from that point onward, following these steps (start at step 9):


Comment 17 Marc Grimme 2012-02-24 14:00:44 UTC
Ok, no problem. I'll follow the instructions.


Comment 18 Nils Philippsen 2016-04-08 10:07:22 UTC
Assuming this is fixed (no activity in 4 years), closing.

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