Spec URL: http://johnp.fedorapeople.org/downloads/python-cairo/python-cairo.spec SRPM URL: http://johnp.fedorapeople.org/downloads/python-cairo/python-cairo-1.10.0-1.fc15.src.rpm Description: The pycairo package changed its name internally to python-cairo to be consistent with python3-cairo. This unfortunately causes issues with uploading new sources. Since upstream has changed the build procedure and we need to get the new package name approved and listed as a existing package, it makes sense to put the package through another review.
Few remarks * For arch-dependent package, *-devel should have a fully versionned requirement Requires: %{name}%{?_isa} = %{version}-%{release} This is now a MUST for new packages review. * i suggest you do the same for other arch-dependent requires (python-devel, cairo-devel) * unless you plan to support EPEL5, drop the requirements on pkgconfig, the buildroot and defattr stuff * though it's optional, i suggest that you drop shell style macro $RPM_BUILD_ROOT and use %{buildroot} instead. *let's check rpmlint output: rpmlint python-cairo-devel-1.10.0-1.fc17.i686.rpm python-cairo-devel.i686: W: spelling-error %description -l en_US interoperate -> inter operate, inter-operate, interpenetrate python-cairo-devel.i686: W: no-documentation python-cairo-devel.i686: E: incorrect-fsf-address /usr/include/pycairo/pycairo.h 1 packages and 0 specfiles checked; 1 errors, 2 warnings. rpmlint python-cairo-1.10.0-1.fc17.i686.rpm python-cairo.i686: W: self-obsoletion pycairo < 1.10.1 obsoletes pycairo = 1.10.0 python-cairo.i686: W: private-shared-object-provides /usr/lib/python2.7/site-packages/cairo/_cairo.so _cairo.so python-cairo.i686: E: incorrect-fsf-address /usr/share/doc/python-cairo-1.10.0/COPYING-LGPL-2.1 python-cairo.i686: W: install-file-in-docs /usr/share/doc/python-cairo-1.10.0/INSTALL 1 packages and 0 specfiles checked; 1 errors, 3 warnings. rpmlint python-cairo-1.10.0-1.fc17.src.rpm python-cairo.src:54: W: macro-in-comment %{_bindir} 1 packages and 0 specfiles checked; 0 errors, 1 warnings. ==> FSF address issue, according Fedora Legal, maintainers are entitled to report this issue upstream, you are welcome to patch this but it's not mandatory. ==> "private-shared-object-provides" should be fixed, that can be done using the following snippet that filters python arch-dependent module before processing provides %{?filter_setup: %filter_provides_in %{python_sitearch}.*\.so$ %filter_setup } => the rest can be safely ignored As soon as the previous raised issues will be fixed, i'll formally review this package.
Last time, i checked on #fedora-devel, J5 changed work assignment so someone else from RedHat Desktop Team was supposed to take over, anyone can help on that ?
Can't believe this package is not in Fedora...
Hmm..Because Fedora uses a different name. *** This bug has been marked as a duplicate of bug 770828 ***
*** Bug 770828 has been marked as a duplicate of this bug. ***
Hi J5, can you finish this review quickly? Thanks.
You should ping mclasen since J5 is no more working in the desktop team. I can finish and approve the review if needed.
(In reply to Haïkel Guémar from comment #8) > You should ping mclasen since J5 is no more working in the desktop team. > I can finish and approve the review if needed. I hope you can lift needinfo to him next time since you know more than me and ask J5 if he can release his ownership to others, it's just a waste of time. Anyway thanks.
*** Bug 636041 has been marked as a duplicate of this bug. ***
John: why don't you use the package rename process, tends to be much quicker than a new review and keeps package history
@peter: John doesn't work anymore in the RH Desktop team, i reported that issue on irc, and mclasen told me that he would reassign that ticket to someone else. I'm stepping down for that review, feel free to close it. I'm currently in deep shit, and i'm not able to help here, sorry guys :'(
I think we should not close this bug anymore cuz this one has obsoleted another ancient bug already. I want to get the latest version of it also. This is the best time to approach.
Still no action on this ticket.
This package is already packaged as pycairo, it really should just be a package rename process if people care about the name, it's stalled so closing.