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=225808 --- Comment #2 from Debarshi Ray <debarshi.ray@xxxxxxxxx> 2008-12-31 08:57:26 EDT --- MUST Items: xx - rpmlint is unclean on RPM + [rishi@ginger ~]$ rpmlint gmime gmime.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libgmime-2.0.so.2.2.21 /lib64/libgmodule-2.0.so.0 gmime.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libgmime-2.0.so.2.2.21 /lib64/libdl.so.2 gmime.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libgmime-2.0.so.2.2.21 /lib64/libgthread-2.0.so.0 gmime.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libgmime-2.0.so.2.2.21 /lib64/librt.so.1 gmime.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libgmime-2.0.so.2.2.21 /lib64/libnsl.so.1 1 packages and 0 specfiles checked; 0 errors, 5 warnings. [rishi@ginger ~]$ rpmlint gmime-sharp gmime-sharp.x86_64: W: no-documentation gmime-sharp.x86_64: W: devel-file-in-non-devel-package /usr/lib64/pkgconfig/gmime-sharp-2.4.pc gmime-sharp.x86_64: W: summary-not-capitalized mono bindings for gmime gmime-sharp.x86_64: E: only-non-binary-in-usr-lib 1 packages and 0 specfiles checked; 1 errors, 3 warnings. [rishi@ginger ~]$ OK - follows Naming Guidelines OK - spec file is named as %{name}.spec xx - package does not meet Packaging Guidelines + The '%ifarch s390 s390x ppc64' condition looks wrong because devel/mono.spec has 'ExclusiveArch: %ix86 x86_64 ia64 armv4l sparc alpha s390 s390x ppc'. Since Mono is unavailable in ppc64 causing gmime-sharp to be excluded for that architecture, a bug should be filed blocking the ExcludeArch tracker for PPC64 (https://bugzilla.redhat.com/238953). The bug number should be documented in the Spec file as a comment. + The -sharp sub-package's summary should start with a capital letter. + Invoking autoreconf and friends from the Spec file has evoked strong reactions in the past. In this case it would be easy to rework Patch2 to apply against mono/Makefile.in instead of mono/Makefile.am and then use chrpath to remove the rpaths. Remember to replace 'BuildRequires: automake libtool' with 'BuildRequires: chrpath'. See: https://fedoraproject.org/wiki/Packaging/Guidelines#Removing_Rpath It looks like the --disable-rpath switch does not work, neither could I manage to get rid of the rpaths by modifying libtool. But chrpath is better than using autoreconf. + Here is how the unused-direct-shlib-dependency can be removed: https://fedoraproject.org/wiki/PackageMaintainers/Common_Rpmlint_Issues#unused-direct-shlib-dependency + Instead of using mv to rename the files in the %install stanza, would it not be better to pass '--program-prefix=%{name}-' to %configure? It is there for this purpose only. If you choose to use this switch, please don't pass transform='s,x,x' to 'make install' in the %install stanza. + gmime-sharp-2.4.pc should be packaged in a separate -sharp-devel sub-package. See: https://fedoraproject.org/wiki/Packaging/Mono#-devel_packages + Can gmime-2.2.3-use-pkg-config.patch be removed from CVS? OK - license meets Licensing Guidelines xx - License field does not meet actual license + While most of the source code is under LGPLv2+, the gmime-uudecode and gmime-uuencode binaries are obtained from GPLv2+ sources -- src/*.[ch]. This is a multiple licensing scenario. See: https://fedoraproject.org/wiki/Packaging/LicensingGuidelines#Multiple_Licensing_Scenarios Please change the value of the License field to "GPLv2+ and LGPLv2+" and document it in the Spec or the package. + examples/*-example.c are under GPLv2+. It appears to be a simple mistake and would be good to request upstream to put them at par with the rest of the files. + util/md5-utils.[ch] are in the public domain. xx - upstream license file not included in %doc + Please include src/COPYING, containing the GPLv2 text, also. OK - spec file uses American English OK - spec file is legible OK - sources match upstream sources OK - package builds successfully OK - ExcludeArch not needed OK - build dependencies correctly listed OK - no locales OK - %post and %postun invoke ldconfig OK - package is not relocatable xx - file and directory ownership + The -devel sub-package should have 'Requires: gtk-doc' because it installs files in /usr/share/gtk-doc. + Although 'Requires: gtk-sharp2' will pull in mono-core, it is better to have an explicit 'Requires: mono-core' since the -sharp sub-package installs files in /usr/lib/mono. OK - no duplicates in %file OK - file permissions set properly OK - %clean present OK - macros used consistently OK - contains code and permissable content OK - -doc is not needed OK - contents of %doc does not affect the runtime OK - header files in -devel OK - no static libraries OK - -devel has *.pc file and requires pkgconfig + Although 'Requires: glib2-devel' will pull in pkgconfig, it is better to have an explicit 'Requires: pkgconfig' for the sake of readability. OK - library files without suffix in -devel OK - -devel requires base package OK - no libtool archives OK - %{name}.desktop file not needed OK - does not own files or directories owned by other packages OK - buildroot correctly prepped OK - all file names valid UTF-8 SHOULD Items: OK - upstream provides license text xx - no translations for description and summary OK - package builds in mock successfully OK - package builds on all supported architectures OK - package functions as expected OK - scriptlets are sane OK - subpackages other than -devel requires base package xx - pkgconfig files in -devel + gmime-sharp-2.4.pc should be packaged in a separate -sharp-devel sub-package. See: https://fedoraproject.org/wiki/Packaging/Mono#-devel_packages OK - no file dependencies -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review