Spec URL: http://kalev.fedorapeople.org/pyside-tools.spec SRPM URL: http://kalev.fedorapeople.org/pyside-tools-0.2.2-1.fc15.src.rpm Description: PySide provides Python bindings for the Qt cross-platform application and UI framework. This package ships the following accompanying tools: * pyside-rcc - PySide resource compiler * pyside-uic - Python User Interface Compiler for PySide * pyside-lupdate - update Qt Linguist translation files for PySide
Scratch build for rawhide: http://koji.fedoraproject.org/koji/taskinfo?taskID=2614146
rpmlint output. pyside-tools.x86_64: W: spelling-error %description -l en_US rcc -> cc, rec, acc pyside-tools.x86_64: W: spelling-error %description -l en_US uic -> uric, sic, tic pyside-tools.x86_64: W: spelling-error %description -l en_US lupdate -> update, l update, lapidate pyside-tools.x86_64: W: no-manual-page-for-binary pyside-uic pyside-tools.x86_64: W: no-manual-page-for-binary pyside-rcc pyside-tools.x86_64: W: no-manual-page-for-binary pyside-lupdate pyside-tools.src: W: spelling-error %description -l en_US rcc -> cc, rec, acc pyside-tools.src: W: spelling-error %description -l en_US uic -> uric, sic, tic pyside-tools.src: W: spelling-error %description -l en_US lupdate -> update, l update, lapidate 3 packages and 1 specfiles checked; 0 errors, 9 warnings. which is all fine. - Package meets naming and packaging guidelines Yes tar ball called pyside-tools - Spec file matches base package name. It does. - Spec has consistant macro usage. It does. - Meets Packaging Guidelines. No, in particular private ElementTree. - License GPLv2 and MIT and there is a comment about this duality. - License field in spec matches it's GPL3 except element tree, see below. Also pysideuic appears to be dual GPL and BSD. - License file included in package Yes. - Spec in American English - Spec is legible. - Sources match upstream md5sum: $ curl -q http://www.pyside.org/files/pyside-tools-0.2.2.tar.bz2 | md5sum - ../SOURCES/pyside-tools-0.2.2.tar.bz2 5fe207cd8cd16ddbb033533fe7528011 - 5fe207cd8cd16ddbb033533fe7528011 ../SOURCES/pyside-tools-0.2.2.tar.bz2 - Package needs ExcludeArch Builds okay in mock so no. - BuildRequires correct Builds in mock and nothing excessive. - Spec handles locales/find_lang Nothing to localed - Package is relocatable and has a reason to be. Not relocatable. - Package has %defattr and permissions on files is good. They are indeed. - Package has a correct %clean section. It does. - Package has correct buildroot %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) Yep. - Package is code or permissible content. Yes. - Doc subpackage needed/used. Not needed. - Packages %doc files don't affect runtime. They don't - Headers/static libs in -devel subpackage. Not relavent. - Spec has needed ldconfig in post and postun Not relavent. - .pc files in -devel subpackage/requires pkgconfig Not relavent. - .so files in -devel subpackage. Not relavent. - -devel package Requires: %{name} = %{version}-%{release} Not relavent. - .la files are removed. Not relavent. - Package is a GUI app and has a .desktop file Not relavent. - Package compiles and builds on at least one arch. Koji build. - Package has no duplicate files in %files. Nope. - Package doesn't own any directories other packages own. Nope. - Package owns all the directories it creates. /usr/lib64/python2.6/site-packages/pysideuic is owned. - final provides and requires are sane: rpm -qp --provides pyside-tools-0.2.2-1.fc13.x86_64.rpm pyside-tools = 0.2.2-1.fc13 pyside-tools(x86-64) = 0.2.2-1.fc13 requires are qt libs, and python-abi = 2.6 so fine. SHOULD Items: - Should build in mock. Koji build - Should build on all supported archs Koji build - Should function as described. - Should have sane scriptlets. - Should have subpackages require base package with fully versioned depend. - Should have dist tag - Should package latest version - check for outstanding bugs on package. (For core merge reviews) Issues: 1. pysideuic/elementtree/ElementTree.py at a quick look to looks to be a copy of $ rpm -qf /usr/lib64/python2.6/xml/etree/ElementTree.py python-2.6.4-27.fc13.x86_64 Can the private copy be removed and this also would allow you to drop a license maybe. 2. It seems the pysideuic is BSD as well. Can this be reflected in the License tag. I might worth a comment stating which part of the code is LICENSE-rcc and which is LICENSE-uic. Of course this could be split into subpackages with different licenses which I believe is the recommended way in the guidelines.
Thanks for your quick review, Steve! (In reply to comment #2) > Issues: > > 1. pysideuic/elementtree/ElementTree.py at a quick look to looks to be a copy > of > $ rpm -qf /usr/lib64/python2.6/xml/etree/ElementTree.py > python-2.6.4-27.fc13.x86_64 > > Can the private copy be removed and this also would allow you to drop a > license maybe. Good idea. uiparser.py first tries to load Python's copy of ElementTree and only if that fails it tries the bundled copy, so it's safe to remove the bundled copy as the version of Python we have in Fedora is recent enough. Updated %prep section to remove the bundled copy of ElementTree. > 2. It seems the pysideuic is BSD as well. Can this be reflected in the License > tag. > > I might worth a comment stating which part of the code is LICENSE-rcc and > which > is LICENSE-uic. Looks like uic was dual-licensed at some point in the past and LICENSE-uic includes the historical license text. In this source tarball, however, all the source files in pysideuic/ directory (except for ElementTree) have been re-licensed as GPLv2-only, so it's really no longer BSD. Added a comment in the spec file explaining the situation. > Of course this could be split into subpackages with different licenses > which I believe > is the recommended way in the guidelines. It's all GPLv2 now that we got rid of bundled ElementTree. * Tue Nov 23 2010 Kalev Lember <kalev> - 0.2.2-2 - Remove bundled ElementTree library in prep (#655527) - Updated License tag to reflect bundled ElementTree removal Spec URL: http://kalev.fedorapeople.org/pyside-tools.spec SRPM URL: http://kalev.fedorapeople.org/pyside-tools-0.2.2-2.fc14.src.rpm
Just one question , what's the reason for all the mkdir -p %{_target_platform} pushd %{_target_platform} and similar building in a fresh directory? Steve.
CMake upstream strongly suggests to use a separate build directory if possible. However our CMake packaging guidelines aren't particulary up to date, so I'm following KDE packaging guidelines where it makes sense. The directory name %{_target_platform} comes from the example spec file: https://fedoraproject.org/wiki/SIGs/KDE/Packaging/Guidelines#Spec_file The rationale for using platform name for generated files (as opposed to simply calling the directory 'build') is to avoid conflicts between multilib debuginfo subpackages.
All seems in order: APPROVED. If you have the time: https://bugzilla.redhat.com/show_bug.cgi?id=631964
Thanks Steve, I'll take a look at your review request tomorrow.
New Package SCM Request ======================= Package Name: pyside-tools Short Description: Development tools for PySide Owners: kalev rdieter kkofler than ltinkl Branches: f13 f14 InitialCC:
Git done (by process-git-requests).
Package imported and built; closing the ticket.