Spec URL: http://fedorapeople.org/~johnp/downloads/python3-cairo/python3-cairo.spec SRPM URL: http://fedorapeople.org/~johnp/downloads/python3-cairo/python3-cairo-1.8.10-1.fc13.src.rpm Description: Pycairo has been split into two packages upstream. One compiles for Python 2 (our pycairo package) and one for Python 3 which has yet to be packaged. I have gone ahead and packaged the Python 3 pycairo as the python3-cairo RPM package.
(In reply to comment #0) > Pycairo has been split into two packages upstream. One compiles for Python 2 > (our pycairo package) and one for Python 3 which has yet to be packaged. I > have gone ahead and packaged the Python 3 pycairo as the python3-cairo RPM > package. To clarify, reading the upstream site: http://cairographics.org/pycairo/ upstream are releasing two tarballs: - py2cairo-VERSION.tar.gz for Python 2 - pycairo-VERSION.tar.gz for Python 3 Our existing RPMs are named "pycairo" and are for python 2.
BTW, does this still use the PyCObject API? (see bug 623858) IIRC PyCObject is being removed in python 3.2
Was this based on the existing pycairo.src.rpm? For reference, the merge review seems to have been bug 226329. (I also see a review in bug 167621 that seems to have been superceded, if I'm reading that right.)
grep -r PyCObject * src/py3cairo.h: Pycairo_CAPI = (Pycairo_CAPI_t*) PyCObject_Import("cairo", "CAPI") src/cairomodule.c: PyModule_AddObject(m, "CAPI", PyCObject_FromVoidPtr(&CAPI, NULL)); test/include/pycairo/py3cairo.h: Pycairo_CAPI = (Pycairo_CAPI_t*) PyCObject_Import("cairo", "CAPI") So yes it uses PyCObject right now. I suspect they will fix this in the next version though we should most likely file a bug. And yes this is based off of pycairo.spec
I suspect you can just point to those as reason to pass this but there is the hack I did for supporting lib64 until upstream fixes the bug.
Oh and I am using the waf build system instead of autotools (upstream no longer ships with an autotools build)
Scratch build: $ koji build --scratch dist-f15 python3-cairo-1.8.10-1.fc13.src.rpm http://koji.fedoraproject.org/koji/taskinfo?taskID=2477876
Scratch build succeeded. BTW, I noticed in: http://koji.fedoraproject.org/koji/getfile?taskID=2477877&name=build.log numerous tracebacks of the form: parsing /builddir/build/BUILD/pycairo-1.8.10/src/cairomodule.c failed Traceback (most recent call last): File "/builddir/build/BUILD/pycairo-1.8.10/.waf3-1.5.18-a7b91e2a913ce55fa6ecdf310df95752/wafadmin/Tools/preproc.py", line 475, in addlines lines=filter_comments(filepath) File "/builddir/build/BUILD/pycairo-1.8.10/.waf3-1.5.18-a7b91e2a913ce55fa6ecdf310df95752/wafadmin/Tools/preproc.py", line 47, in filter_comments code=Utils.readf(filename) File "/builddir/build/BUILD/pycairo-1.8.10/.waf3-1.5.18-a7b91e2a913ce55fa6ecdf310df95752/wafadmin/Utils.py", line 411, in readf txt=f.read() File "/usr/lib64/python3.2/encodings/ascii.py", line 26, in decode return codecs.ascii_decode(input, self.errors)[0] UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position 54: ordinal not in range(128) Any idea what's up with that, and if it's serious?
Created attachment 448540 [details] rpmlint output on a local build on an F13 box
Notable rpmlint issues: python3-cairo-debuginfo.x86_64: E: empty-debuginfo-package python3-cairo.x86_64: W: unstripped-binary-or-object /usr/lib64/python3.1/site-packages/cairo/_cairo.so I see this also in the scratch build above: the debuginfo subpackage is empty. Other rpmlint issues: python3-cairo.src:50: E: hardcoded-library-path in $RPM_BUILD_ROOT/usr/lib Looks like a false positive relating to the lib64 fix in the %install The "spurious-executable-perm": these seem to have 755, which doesn't strike me as a problem. Not sure what's up with the "doc-file-dependency"
Uploaded a new SRPM (didn't bump the release, sorry). Added a patch to add --libdir which fixes the hardcoded-library-path issue, removed the executable bit from example files to get rid of the spurious-executable-perm error. Still don't know what to do about the debuginfo and stripping issue. nirik on fedora-devel suggests CFLAGS=%optflags, trying now.
(In reply to comment #11) (snip) > Still don't know what to do about the debuginfo and stripping issue. nirik on > fedora-devel suggests CFLAGS=%optflags, trying now. (In reply to comment #11) > Uploaded a new SRPM (didn't bump the release, sorry). Added a patch to add (Looks like you also uploaded a new .spec file into place) > --libdir which fixes the hardcoded-library-path issue, removed the executable > bit from example files to get rid of the spurious-executable-perm error. Still > don't know what to do about the debuginfo and stripping issue. nirik on > fedora-devel suggests CFLAGS=%optflags, trying now. Did that fix it? (please can you try scratch builds and add the URLs to this bug). If not, this kind of thing can be due to a permissions error on the generated library; iirc if they're not executable, then the post-processing stripping hook in rpm-build doesn't pick up on them. Are they getting built with "-g"? (to actually generate debugging info within GCC)
As far as I can tell -g is getting put in my current iteration but debuginfo is still not being stripped. http://koji.fedoraproject.org/koji/taskinfo?taskID=2481715
Ignore the unapplied patch warning, I forgot to take it out. Also I checked and it looked like the .so is executable. Let me install and check in place.
That is it. It isn't executable (for some reason it is in the buildroot though). http://koji.fedoraproject.org/koji/taskinfo?taskID=2481740 that should fix things
Does http://fedorapeople.org/~johnp/downloads/python3-cairo/python3-cairo.spec have the latest version of the specfile? (the lack of bumping the "release" id makes it harder to review; please bump the release in future!) $ rpmlint python3-cairo* python3-cairo-devel.i686: W: spelling-error %description -l en_US interoperate -> inter operate, inter-operate, interoperable python3-cairo-devel.i686: W: no-documentation python3-cairo-devel.x86_64: W: spelling-error %description -l en_US interoperate -> inter operate, inter-operate, interoperable python3-cairo-devel.x86_64: W: no-documentation 7 packages and 0 specfiles checked; 0 errors, 4 warnings. The word "interoperate" is in common English usage; seems to be missing from the dictionary that rpmlint's using. Are there any developer docs in the package?
Just uploaded the latest version of the spec.
Thanks! Mostly looking good, but there are a few specific things that ought to be fixed. === "MUST" items that need work === (Please do bump the release number when fixing these!) > MUST: 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 must be included in %doc.[4] You've done this for the main package, but I believe you need a duplicate copy of these licenses in the "devel" subpackage as well. > MUST: Packages must NOT bundle copies of system libraries The upstream tarball embeds a copy of "waf" for use during the build, but "waf" is packaged within Fedora. Is it possible to use the system copy of "waf"? Please try removing the embedded copy of "waf" in the %prep and add a: BuildRequires: waf and you'll need to change all the references to "./waf" in the specfile accordingly. There was some discussion of this here: http://lists.fedoraproject.org/pipermail/packaging/2009-February/005722.html has some notes on this. > MUST: A package must own all directories that it creates. If it does not > create a directory that it uses, then it should require a package which does > create that directory. [13] and > MUST: Packages must not own files or directories already owned by other > packages. The rule of thumb here is that the first package to be installed > should own the files or directories that other packages may rely upon. This > means, for example, that no package in Fedora should ever share ownership > with any of the files or directories owned by the filesystem or man package. > If you feel that you have a good reason to own a file or directory that > another package owns, then please present that at package review time. [23] Is this directory also used by the python 2 package? %{_includedir}/pycairo/ Looks like it might be tricky to fix whilst staying close to upstream's intent. > MUST: Each package must consistently use macros. [16] You use %{optflags} in one place, and $RPM_BUILD_ROOT in others. To be nitpicking, this appears to be a violation of: http://fedoraproject.org/wiki/Packaging/Guidelines#macros IMHO of minimal benefit, but please fix it when fixing the other issues. === Other notes === (i) Please can you file a bug usptream about the PyCObject issue mentioned in comment #2 and comment #4 (and add a URL here)? I hope to rebase us to python-3.2 in Fedora 15, and the latest 3.2a2 removes this deprecated API, which would lead to a FTBFS. https://fedoraproject.org/wiki/Features/Python_3.2 (ii) The "doc" directory does contain rst documentation, along with instructions for building it to html. I don't think that doing so is a blocker for review, perhaps an RFE for further work. === "MUST" items that are OK === > MUST: rpmlint must be run on every package. The output should be posted in > the review.[1] OK > MUST: The package must be named according to the Package Naming Guidelines The guidelines say: "So all python3 modules MUST have python3 in their name. Other than that, the module must be in the same format as the python2 package." The python 2 package is currently named "pycairo", but upstream now reserve that name for python 3 (whether or not this was a good idea by upstream is not relevant here). Python 2 guidelines say "When in doubt, use the name of the module that you type to import it in a script.", which in this case is "cairo" Hence I feel that the name "python3-cairo" is acceptable. > MUST: The spec file name must match the base package %{name}, in the format > %{name}.spec unless your package has an exemption. [2] OK > MUST: The package must meet the Packaging Guidelines OK > MUST: The package must be licensed with a Fedora approved license and meet > the Licensing Guidelines . Tarball includes COPYING and COPYING.lesser (GPLv3 and LGPLv3) The README states: > Pycairo is free software and is available to be redistributed and/or modified > under the terms of the GNU Lesser General Public License version 3 (LGPLv3). Copyright headers in the package refer to the LGPLv3 I'm not sure why the COPYING is present; do you know why? > MUST: The License field in the package spec file must match the actual > license. OK > MUST: The spec file must be written in American English. [5] OK > MUST: The spec file for the package MUST be legible. [6] OK > MUST: The sources used to build the package must match the upstream source, > as provided in the spec URL. Reviewers should use md5sum for this task. > If no upstream URL can be specified for this package, please see the > Source URL Guidelines for how to deal with this. OK: $ md5sum pycairo-1.8.10.tar.bz2 python3-cairo-1.8.10-1.fc13.src/pycairo-1.8.10.tar.bz2 ddc544943d791e3c22ca8f019e10e1e3 pycairo-1.8.10.tar.bz2 ddc544943d791e3c22ca8f019e10e1e3 python3-cairo-1.8.10-1.fc13.src/pycairo-1.8.10.tar.bz2 > MUST: The package MUST successfully compile and build into binary rpms on at > least one primary architecture. OK (see scratch builds) > MUST: If the package does not successfully compile, build or work on an... N/A > MUST: All build dependencies must be listed in BuildRequires, except for any > that are listed in the exceptions section of the Packaging Guidelines ; > inclusion of those as BuildRequires is optional. Apply common sense. (assumed correct, given the Koji scratch build; but see the note on "waf" above) > MUST: The spec file MUST handle locales properly. This is done by using > the %find_lang macro. Using %{_datadir}/locale/* is strictly forbidden.[9] N/A > MUST: Every binary RPM package (or subpackage) which stores shared library > files (not just symlinks) in any of the dynamic linker's default paths, must > call ldconfig in %post and %postun. [10] OK; the DSO is a python module > MUST: If the package is designed to be relocatable, the packager must state N/A > MUST: A Fedora package must not list a file more than once in the spec > file's %files listings. (Notable exception: license texts in specific > situations) OK > MUST: Permissions on files must be set properly. Executables should be set > with executable permissions, for example. Every %files section must include > a %defattr(...) line. [15] OK > MUST: The package must contain code, or permissable content. [17] OK > MUST: Large documentation files must go in a -doc subpackage. Should the examples be moved to the -devel subpackage? I'm not sure on this one. > MUST: If a package includes something as %doc, it must not affect the > runtime of the application. To summarize: If it is in %doc, the program > must run properly if it is not present. [18] OK > MUST: Header files must be in a -devel package. [19] OK. > MUST: Static libraries must be in a -static package. [20] N/A > MUST: If a package contains library files with a suffix > (e.g. libfoo.so.1.1)... N/A > MUST: In the vast majority of cases, devel packages must require the base > package using a fully versioned dependency: > Requires: %{name} = %{version}-%{release} [21] OK > MUST: Packages must NOT contain any .la libtool archives, these must be > removed in the spec if they are built.[20] OK > MUST: Packages containing GUI applications must include a %{name}.desktop... N/A > MUST: All filenames in rpm packages must be valid UTF-8. [24] OK
(In reply to comment #18) > Thanks! Mostly looking good, but there are a few specific things that ought to > be fixed. > > === "MUST" items that need work === > (Please do bump the release number when fixing these!) > > > MUST: 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 must be included in %doc.[4] > > You've done this for the main package, but I believe you need a duplicate copy > of these licenses in the "devel" subpackage as well. Really? The devel package requires the main package which will install the license. Can you point to the policy. This is the first I have heard of it. Added the doc line in any case. > > MUST: Packages must NOT bundle copies of system libraries > > The upstream tarball embeds a copy of "waf" for use during the build, but "waf" > is packaged within Fedora. > > Is it possible to use the system copy of "waf"? Please try removing the > embedded copy of "waf" in the %prep and add a: > BuildRequires: waf > and you'll need to change all the references to "./waf" in the specfile > accordingly. > > There was some discussion of this here: > http://lists.fedoraproject.org/pipermail/packaging/2009-February/005722.html > has some notes on this. I was told to use the internal waf, or at least that is what other packages are doing. Actually this needs to be waved. At least on F13 the waf files are not Python3 compliant. I would like to wait for waf to become more mature before depending on the system version. > > > MUST: A package must own all directories that it creates. If it does not > > create a directory that it uses, then it should require a package which does > > create that directory. [13] > > and > > > MUST: Packages must not own files or directories already owned by other > > packages. The rule of thumb here is that the first package to be installed > > should own the files or directories that other packages may rely upon. This > > means, for example, that no package in Fedora should ever share ownership > > with any of the files or directories owned by the filesystem or man package. > > If you feel that you have a good reason to own a file or directory that > > another package owns, then please present that at package review time. [23] > > Is this directory also used by the python 2 package? > %{_includedir}/pycairo/ > > Looks like it might be tricky to fix whilst staying close to upstream's intent. Not an issue. I can have python3-cairo only own the files in that directory. When we switch to python3 as the default we will have pycairo drop ownership and python3-cairo take ownership. > > MUST: Each package must consistently use macros. [16] > You use %{optflags} in one place, and $RPM_BUILD_ROOT in others. To be > nitpicking, this appears to be a violation of: > http://fedoraproject.org/wiki/Packaging/Guidelines#macros > IMHO of minimal benefit, but please fix it when fixing the other issues. Will do. I hate how we don't just pick one :( We allow you to make things look ugly but don't do it - you can choose which one you like and do that. Choice is good. Choice is Mother. Choice is Father. Choose one but just not that one. > === Other notes === > (i) Please can you file a bug usptream about the PyCObject issue mentioned in > comment #2 and comment #4 (and add a URL here)? I hope to rebase us to > python-3.2 in Fedora 15, and the latest 3.2a2 removes this deprecated API, > which would lead to a FTBFS. > https://fedoraproject.org/wiki/Features/Python_3.2 Sorry, already did but didn't tell you - https://bugs.freedesktop.org/show_bug.cgi?id=30289 > (ii) The "doc" directory does contain rst documentation, along with > instructions for building it to html. I don't think that doing so is a blocker > for review, perhaps an RFE for further work. We don't do anything for pycairo so RFE would be right here.
http://koji.fedoraproject.org/koji/taskinfo?taskID=2482285 Spec file update on server: http://fedorapeople.org/~johnp/downloads/python3-cairo/python3-cairo.spec
http://koji.fedoraproject.org/koji/taskinfo?taskID=2482330 use system waf. Spec file has been updated on the server.
Thanks. Looks almost there, but you're missing a: BuildRequires: waf which lead to the build failure of: http://koji.fedoraproject.org/koji/taskinfo?taskID=2482330 with: python3: can't open file '/usr/bin/waf': [Errno 2] No such file or directory in: http://koji.fedoraproject.org/koji/getfile?taskID=2482331&name=build.log
Reverted to using the provided waf script since our system waf does not work under python 3. Filed a bug with system waf: https://bugzilla.redhat.com/show_bug.cgi?id=637935 Build is happening at http://koji.fedoraproject.org/koji/taskinfo?taskID=2492283 new spec file at http://fedorapeople.org/~johnp/downloads/python3-cairo/python3-cairo.spec
Sorry build is at: http://fedorapeople.org/~johnp/downloads/python3-cairo/python3-cairo.spec Forgot to point to the -5 srpm release in the last build
http://koji.fedoraproject.org/koji/taskinfo?taskID=2492290 ^---- copy/paste error
rpmlint report on koji task 2492292: > python3-cairo.src:75: E: files-attr-not-set Please move the: %defattr(-,root,root,-) before the: %doc COPYING* line in the "%files devel" stanza > python3-cairo.x86_64: W: python-bytecode-without-source /usr/lib64/python3.2/site-packages/cairo/__pycache__/__init__.cpython-32.pyo > python3-cairo.x86_64: W: python-bytecode-without-source /usr/lib64/python3.2/site-packages/cairo/__pycache__/__init__.cpython-32.pyc Looks like a false positive: rpmlint needs to be taught about PEP 3147: http://www.python.org/dev/peps/pep-3147/ > python3-cairo-debuginfo.x86_64: E: debuginfo-without-sources I'm not sure what's causing this, but the source file is indeed missing from the debuginfo package. > python3-cairo-devel.x86_64: W: spelling-error %description -l en_US interoperate -> inter operate, inter-operate, interpenetrate False warning, as noted above. > 4 packages and 0 specfiles checked; 2 errors, 3 warnings. Not sure how to fix the debuginfo issue, but I don't feel it should further block getting this into Fedora. APPROVED; please fix the %defattr issue noted above before importing into CVS.
(In reply to comment #26) (snip) > > python3-cairo.x86_64: W: python-bytecode-without-source /usr/lib64/python3.2/site-packages/cairo/__pycache__/__init__.cpython-32.pyo > > python3-cairo.x86_64: W: python-bytecode-without-source /usr/lib64/python3.2/site-packages/cairo/__pycache__/__init__.cpython-32.pyc > Looks like a false positive: rpmlint needs to be taught about PEP 3147: > http://www.python.org/dev/peps/pep-3147/ FWIW, I've filed an rpmlint bug about this as bug 637956 (snip)
New Package SCM Request ======================= Package Name: python3-cairo Short Description: Python 3 bindings for cairo Owners: johnp
Git done (by process-git-requests).
Package Change Request ====================== Package Name: python3-cairo New Branches: F14 It seems that I can not upload sources with fedpkg unless there is a branch other than master. This is due to an annoying bug in fedpkg which expects there to be more than one branch. The work around is to create a branch which just doesn't get built. See https://bugzilla.redhat.com/show_bug.cgi?id=619979 for more info
This is already in Rawhide.
*** Bug 1114702 has been marked as a duplicate of this bug. ***