Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=731891
Haïkel Guémar karlthered@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |karlthered@gmail.com AssignedTo|nobody@fedoraproject.org |karlthered@gmail.com
--- Comment #1 from Haïkel Guémar karlthered@gmail.com 2012-02-08 16:36:51 EST --- 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.