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 Review | Assignee: | John Morris <john> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | 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
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. (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! (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 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 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. 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: John, please set the review flag. I hope it's ok if I set it. Git done (by process-git-requests). Not ideal, no, but oh well. Sorry, I forgot about the flag. Pretend I set it. :) Thanks! 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 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 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 python-collada-0.4-3.el6 has been pushed to the Fedora EPEL 6 testing repository. 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? 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. 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? python-collada-0.4-3.fc17 has been pushed to the Fedora 17 stable repository. python-collada-0.4-3.fc18 has been pushed to the Fedora 18 stable repository. python-collada-0.4-3.el6 has been pushed to the Fedora EPEL 6 stable repository. 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 python-collada-0.4-3.fc19 has been pushed to the Fedora 19 stable repository. |