Bug 903732

Summary: Review Request: python-collada - A python module for creating, editing and loading COLLADA
Product: [Fedora] Fedora Reporter: Richard Shaw <hobbes1069>
Component: Package ReviewAssignee: John Morris <john>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: fedyapupkin, john, notting, package-review, przemek
Target Milestone: ---Flags: hobbes1069: fedora-review+
gwync: fedora-cvs+
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: python-collada-0.4-3.fc19 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-03-19 19:59:54 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Richard Shaw 2013-01-24 17:01:35 UTC
Spec URL: https://dl.dropbox.com/u/34775202/python-collada/python-collada.spec
SRPM URL: https://dl.dropbox.com/u/34775202/python-collada/python-collada-0.4-1.fc18.src.rpm
Description: 
pycollada is a python module for creating, editing and loading COLLADA, which
is a COLLAborative Design Activity for establishing an interchange file format
for interactive 3D applications.

The library allows you to load a COLLADA file and interact with it as a python
object. In addition, it supports creating a collada python object from scratch,
as well as in-place editing.

Fedora Account System Username: hobbes1069

rpmlint output:
$ rpmlint python-collada
python-collada.noarch: W: spelling-error %description -l en_US pycollada -> colloidal
1 packages and 0 specfiles checked; 0 errors, 1 warnings.

$ rpmlint rpmbuild/python-collada/SPECS/python-collada.spec
rpmbuild/python-collada/SPECS/python-collada.spec: W: invalid-url Source0: pycollada-0.4.tar.gz
0 packages and 1 specfiles checked; 0 errors, 1 warnings.

Github source URL. Actual URL put in a comment.

Comment 1 John Morris 2013-01-25 09:46:02 UTC
Hi Richard, I'll take this one.

Real quick off the bat, are you planning to build this for EL5?  If not, I think the python_site* macros are already provided by EL6 and Fedora.

How did you find the v0.4 tarball archive?  I guess that's the most recent release?  I've got a specfile for master if it looks interesting; it's more complicated, with arch-specific binary RPMs linking numpy, and more BRs and Rs.  Might not be stable yet.

I can add a %check script in there, but if it's like 0.5, it'll need a small patch to disable downloading dependencies.

Looks good, pretty cookie-cutter.  I'll take a closer look in a day or two.

Comment 2 Richard Shaw 2013-01-25 14:07:57 UTC
(In reply to comment #1)
> Hi Richard, I'll take this one.

Thanks!

 
> Real quick off the bat, are you planning to build this for EL5?  If not, I
> think the python_site* macros are already provided by EL6 and Fedora.

Yeah, those can go. I used rpmdev-newspec for the template which still has the macros so I didn't bother to remove them.

 
> How did you find the v0.4 tarball archive?  I guess that's the most recent
> release?  I've got a specfile for master if it looks interesting; it's more
> complicated, with arch-specific binary RPMs linking numpy, and more BRs and
> Rs.  Might not be stable yet.

I just went to the github page and downloaded the latest tag there. If it's sufficient for FreeCAD I'm not too worried about packaging master.

 
> I can add a %check script in there, but if it's like 0.5, it'll need a small
> patch to disable downloading dependencies.

0.4 doesn't download anything currently using the standard python setup.py method.


> Looks good, pretty cookie-cutter.  I'll take a closer look in a day or two.

Thanks!

Comment 3 John Morris 2013-01-25 21:45:18 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > How did you find the v0.4 tarball archive?  I guess that's the most recent
> > release?  I've got a specfile for master if it looks interesting; it's more
> > complicated, with arch-specific binary RPMs linking numpy, and more BRs and
> > Rs.  Might not be stable yet.
> 
> I just went to the github page and downloaded the latest tag there. If it's
> sufficient for FreeCAD I'm not too worried about packaging master.

Ah, they put the 'Tags' tab over on the right away from everything else.  Made it practically invisible to a half-blind person like me.

You're right, 0.4 will be fine.

> > I can add a %check script in there, but if it's like 0.5, it'll need a small
> > patch to disable downloading dependencies.
> 
> 0.4 doesn't download anything currently using the standard python setup.py
> method.

I recommend adding a %check script.  It takes a patch to comment out the install_requires line in setup.py; otherwise easy_install will download them from pypi.  (Maybe this won't be an issue once the BRs are properly put in place, but it also safeguards against future changes.)

Running %checks reveals that numpy and python-dateutil are both Requires: (and BRs, along with python-unittest2, for the checks themselves).


Also need a BR for python-setuptools or the mock build will fail.


Are group tags needed for EPEL compatibility [1]?  If so, here's a candidate used by several python-* packages:
Group:          Development/Languages


I'm putting all these changes on github [2], so feel free to pull/cherry-pick/copy-and-paste from there.


Once these are taken care of, I'll write the formal review.


[1] https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelines#Group_tag

[2] https://github.com/zultron/python-collada-rpm

Comment 4 Richard Shaw 2013-02-26 14:17:03 UTC
I guess we need to finish this review since I already did builds for RPM Fusion :)

I complete forgot since I was running a local build of python-collada...

All the changes look good to me!

Spec URL: https://dl.dropbox.com/u/34775202/python-collada/python-collada.spec
SRPM URL: https://dl.dropbox.com/u/34775202/python-collada/python-collada-0.4-2.fc18.src.rpm

Comment 5 John Morris 2013-03-07 06:14:43 UTC
Hi Richard, apologies for not getting to this sooner.

Results of fedora-review, with 'Manual review needed' keys filled out, and comments at bottom:

Package Review
==============

Key:
[x] = Pass
[!] = Fail
[-] = Not applicable
[?] = Not evaluated
[ ] = Manual review needed



===== MUST items =====

Generic:
[x]: Package is licensed with an open-source compatible license and meets
     other legal requirements as defined in the legal section of Packaging
     Guidelines.
[x]: Package successfully compiles and builds into binary rpms on at least one
     supported primary architecture.
[x]: %build honors applicable compiler flags or justifies otherwise.
[x]: All build dependencies are listed in BuildRequires, except for any that
     are listed in the exceptions section of Packaging Guidelines.
[x]: Package contains no bundled libraries.
[X]: Changelog in prescribed format.
[x]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the
     beginning of %install.
[x]: Sources contain only permissible code or content.
[x]: Each %files section contains %defattr if rpm < 4.4
[x]: Macros in Summary, %description expandable at SRPM build time.
[-]: Package contains desktop file if it is a GUI application.
[-]: Development files must be in a -devel package
[x]: Package requires other packages for directories it uses.
[x]: Package uses nothing in %doc for runtime.
[x]: Package is not known to require ExcludeArch.
[x]: Package does not contain duplicates in %files.
[x]: Permissions on files are set properly.
[x]: Package complies to the Packaging Guidelines
[x]: Spec file lacks Packager, Vendor, PreReq tags.
[x]: If (and only if) the source package includes the text of the license(s)
     in its own file, then that file, containing the text of the license(s)
     for the package is included in %doc.
[x]: License field in the package spec file matches the actual license.
     Note: Checking patched sources after %prep for licenses. Licenses found:
     "Unknown or generated". 1 files have unknown license. Detailed output of
     licensecheck in /home/jman/tmp/review-python-collada/licensecheck.txt
[x]: Package consistently uses macro is (instead of hard-coded directory
     names).
[x]: Package is named using only allowed ASCII characters.
[x]: Package is named according to the Package Naming Guidelines.
[x]: Package does not generate any conflict.
     Note: Package contains no Conflicts: tag(s)
[x]: Package do not use a name that already exist
[x]: Package obeys FHS, except libexecdir and /usr/target.
[-]: If the package is a rename of another package, proper Obsoletes and
     Provides are present.
[x]: Package must own all directories that it creates.
[x]: Package does not own files or directories owned by other packages.
[x]: Package installs properly.
[x]: Package is not relocatable.
[x]: Requires correct, justified where necessary.
[x]: CheckResultdir
[x]: Rpmlint is run on all rpms the build produces.
     Note: There are rpmlint messages (see attachment).
[x]: Sources used to build the package match the upstream source, as provided
     in the spec URL.
[x]: Spec file is legible and written in American English.
[x]: Spec file name must match the spec package %{name}, in the format
     %{name}.spec.
[-]: Package contains systemd file(s) if in need.
[x]: File names are valid UTF-8.
[-]: Large documentation must go in a -doc subpackage.
     Note: Documentation size is 20480 bytes in 4 files.
[x]: Packages must not store files under /srv, /opt or /usr/local

Python:
[x]: Package contains BR: python2-devel or python3-devel
[-]: Binary eggs must be removed in %prep
     Note: Cannot find sources under BUILD (using prebuilt sources?)
[x]: Python eggs must not download any dependencies during the build process.
[x]: A package which is used by another package via an egg interface should
     provide egg info.
[x]: Package meets the Packaging Guidelines::Python

===== SHOULD items =====

Generic:
[x]: Reviewer should test that the package builds in mock.
[x]: Buildroot is not present
[x]: Package has no %clean section with rm -rf %{buildroot} (or
     $RPM_BUILD_ROOT)
[-]: If the source package does not include license text(s) as a separate file
     from upstream, the packager SHOULD query upstream to include it.
[x]: Dist tag is present.
[x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin.
[x]: Final provides and requires are sane (rpm -q --provides and rpm -q
     --requires).
[x]: Package functions as described.
[x]: Latest version is packaged.
[x]: Package does not include license text files separate from upstream.
[!]: Patches link to upstream bugs/comments/lists or are otherwise justified.
[x]: The placement of pkgconfig(.pc) files are correct.
[x]: SourceX tarball generation or download is documented.
     Note: Package contains tarball without URL, check comments
[!]: SourceX / PatchY prefixed with %{name}.
     Note: Patch0 (pycollada-0.4-disable_unittest_downloads.patch) Source0
     (pycollada-0.4.tar.gz)
[x]: SourceX is a working URL.
[-]: Description and summary sections in the package spec file contains
     translations for supported Non-English languages, if available.
[x]: Package should compile and build into binary rpms on all supported
     architectures.
[x]: %check is present and all tests pass.
[-]: Packages should try to preserve timestamps of original installed files.
[x]: Spec use %global instead of %define.

===== EXTRA items =====

Generic:
[x]: Rpmlint is run on all installed packages.
     Note: There are rpmlint messages (see attachment).
[x]: Large data in /usr/share should live in a noarch subpackage if package is
     arched.


Rpmlint
-------
Checking: python-collada-0.4-2.fc19.noarch.rpm
          python-collada-0.4-2.fc19.src.rpm
python-collada.noarch: I: enchant-dictionary-not-found en_US
python-collada.src:56: E: files-attr-not-set
python-collada.src:57: E: files-attr-not-set
python-collada.src: W: no-cleaning-of-buildroot %install
python-collada.src: W: no-cleaning-of-buildroot %clean
python-collada.src: W: no-buildroot-tag
python-collada.src: W: no-%clean-section
python-collada.src: W: invalid-url Source0: pycollada-0.4.tar.gz
2 packages and 0 specfiles checked; 2 errors, 5 warnings.




Rpmlint (installed packages)
----------------------------
# rpmlint python-collada
python-collada.noarch: W: spelling-error %description -l en_US pycollada -> colloidal
1 packages and 0 specfiles checked; 0 errors, 1 warnings.
# echo 'rpmlint-done:'


Requires
--------
python-collada-0.4-2.fc19.noarch.rpm (rpmlib, GLIBC filtered):
    
    numpy  
    python(abi) = 2.7
    python-dateutil  



Provides
--------
python-collada-0.4-2.fc19.noarch.rpm:
    
    python-collada = 0.4-2.fc19



MD5-sum check
-------------


Generated by fedora-review 0.3.1 (b71abc1) last change: 2012-10-16
Buildroot used: fedora-rawhide-x86_64
Command line :/usr/bin/fedora-review --rpm-spec -n python-collada-0.4-2.fc18.src.rpm -m fedora-rawhide-x86_64


-------------------------------
Nitpicks:

[!]: Patches link to upstream bugs/comments/lists or are otherwise justified.
(This is my own patch, and absence of a comment in the specfile is my fault)
The patch itself contains comments about its purpose.  A one-liner version should be in the specfile comments above the Patch0: line, perhaps:
# Disable pypi downloads in setup.py to guarantee use of only system libs

[!]: SourceX / PatchY prefixed with %{name}.
     Note: Patch0 (pycollada-0.4-disable_unittest_downloads.patch) Source0
     (pycollada-0.4.tar.gz)
(This is also mine; my original RPM was called 'pycollada')
pycollada-0.4-disable_unittest_downloads.patch should be renamed to python-collada-0.4-disable_unittest_downloads.patch


Non-errors:

python-collada.src: W: invalid-url Source0: pycollada-0.4.tar.gz
- There is no official tarball distribution whose filename is at all related to the project name, so there is therefore no direct URL for Source0.  The correct URL is cited in the comments.


APPROVED.

Comment 6 John Morris 2013-03-08 01:03:44 UTC
New Package SCM Request
======================
Package Name: python-collada
Short Description: A python module for creating, editing and loading COLLADA
Branches: el6 f17 f18 f19
Owners: hobbes1069 zultron
InitialCC:

Comment 7 Gwyn Ciesla 2013-03-08 13:13:28 UTC
John, please set the review flag.

Comment 8 Richard Shaw 2013-03-08 13:33:52 UTC
I hope it's ok if I set it.

Comment 9 Gwyn Ciesla 2013-03-08 13:53:25 UTC
Git done (by process-git-requests).

Not ideal, no, but oh well.

Comment 10 John Morris 2013-03-08 19:52:45 UTC
Sorry, I forgot about the flag.  Pretend I set it.  :)  Thanks!

Comment 11 Fedora Update System 2013-03-09 07:37:55 UTC
python-collada-0.4-3.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/python-collada-0.4-3.fc18

Comment 12 Fedora Update System 2013-03-09 07:38:07 UTC
python-collada-0.4-3.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/python-collada-0.4-3.fc17

Comment 13 Fedora Update System 2013-03-09 07:38:16 UTC
python-collada-0.4-3.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/python-collada-0.4-3.el6

Comment 14 Fedora Update System 2013-03-09 19:20:30 UTC
python-collada-0.4-3.el6 has been pushed to the Fedora EPEL 6 testing repository.

Comment 15 Przemek Klosowski 2013-03-15 17:34:54 UTC
This package is a requirement in other packages that are already included in e.g. rpmfusion and therefore blocks updates on Fedora (requiring --skip-broken)

Is it being considered for push to Fedora or rpmfusion?

Comment 16 Przemek Klosowski 2013-03-15 18:26:29 UTC
FWIW, if it's still in testing because it needs karma, I successfully installed FreeCAD by 'yum --enablerepo updates-testing update freecad'.

The python-collada tests in /usr/lib/python2.7/site-packages/collada/tests run fine, except for those requiring data files /usr/lib/python2.7/site-packages/collada/tests/data

The package should probably include those files because otherwise included test scripts are useless.

Comment 17 John Morris 2013-03-16 06:37:54 UTC
Hi Przemek,

This package is still in testing because it needs karma, yes.  If you want to give it karma, it may speed things up; otherwise, expect it to hit stable in a week or so.

As for the tests, I'm tempted to simply remove them from the package.  Opinions from anyone on this ticket?

Comment 18 Fedora Update System 2013-03-19 19:59:56 UTC
python-collada-0.4-3.fc17 has been pushed to the Fedora 17 stable repository.

Comment 19 Fedora Update System 2013-03-19 20:09:29 UTC
python-collada-0.4-3.fc18 has been pushed to the Fedora 18 stable repository.

Comment 20 Fedora Update System 2013-03-24 18:00:58 UTC
python-collada-0.4-3.el6 has been pushed to the Fedora EPEL 6 stable repository.

Comment 21 Fedora Update System 2013-05-08 02:58:06 UTC
python-collada-0.4-3.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/python-collada-0.4-3.fc19

Comment 22 Fedora Update System 2013-05-14 04:37:17 UTC
python-collada-0.4-3.fc19 has been pushed to the Fedora 19 stable repository.