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=225865 --- Comment #1 from Debarshi Ray <debarshi.ray@xxxxxxxxx> 2009-01-04 11:06:24 EDT --- MUST Items: xx - rpmlint is unclean on RPM and SRPM + See: http://rishi.fedorapeople.org/gstreamer-plugins-base.rpmlint OK - follows Naming Guidelines + Although the upstream tarball is named gst-plugins-base, the project is named gstreamer, which is the prefix used by Debian also. OK - spec file is named as %{name}.spec xx - package does not meet Packaging Guidelines + Please try not to mix spaces and tabs as field separators. + You could consider passing --disable-gnome_vfs to %configure, because a simple non-Mock or non-Koji rpmbuild will fail if gnome-vfs is present due to PolicyKit-gnome, abiword, brasero, evolution, yelp, etc.. + According to https://fedoraproject.org/wiki/Packaging/Guidelines#Beware_of_Rpath we should avoid rpaths, especially for standard locations like %{_libdir}. Here is a possible solution: BuildRequires: libtool [...] %build %configure \ [...] rm -f ./libtool cp %{_bindir}/libtool . [...] + Here is how the unused-direct-shlib-dependency can be removed: https://fedoraproject.org/wiki/PackageMaintainers/Common_Rpmlint_Issues#unused-direct-shlib-dependency + According to https://fedoraproject.org/wiki/Packaging/Guidelines#Why_the_.25makeinstall_macro_should_not_be_used %makeinstall macro should not be used. To also preserve timestamps you could consider using: make install INSTALL="%{__install} -p" DESTDIR=$RPM_BUILD_ROOT + Why not include ChangeLog, NEWS and RELEASE in %doc? + According to https://fedoraproject.org/wiki/Packaging/Guidelines#Documentation the REQUIREMENTS file should not be distributed. + The most recent entry in the %changelog has a typo. The %{version}-%{release} should be 0.10.21-3. + In the %changelog %files should be replaced by %%files in this entry: * Wed Jan 18 2006 John (J5) Palmieri <johnp@xxxxxxxxxx> - 0.10.2-1 + The following lines in gst-libs/gst/fft, are responsible for libgstfft-0.10.so.0.15.0 calling exit: kiss_fftr_f32.c:81: exit (1); kiss_fftr_f32.c:138: exit (1); kiss_fftr_f64.c:81: exit (1); kiss_fftr_f64.c:138: exit (1); kiss_fftr_s16.c:81: exit (1); kiss_fftr_s16.c:138: exit (1); kiss_fftr_s32.c:81: exit (1); kiss_fftr_s32.c:138: exit (1); I do not know what we can do about this, but nowadays rpmlint marks this as a warning. OK - license meets Licensing Guidelines OK - License field meets actual license xx - upstream license file included in %doc + COPYING contains the GPLv2, while the actual license of this package is LGPLv2+. Please include COPYING.LIB instead. OK - spec file uses American English OK - spec file is legible OK - sources match upstream sources xx - package does not build successfully + Libtheora has a broken version numbering in its *.pc file. See: https://bugzilla.redhat.com/478651 Since the version of libtheora in Fedora 8 and above is recent enough, we can disable the version check in the configure script. OK - ExcludeArch not needed OK - build dependencies correctly listed + Pedantically speaking 'BuildRequires: libtheora >= 1.0' is wrong, but libtheora has a broken NEVRA (https://bugzilla.redhat.com/478651) so we have to live with it. OK - locales handled properly xx - %post and %postun do not invoke ldconfig + Since shared libraries are being installed in the dynamic linker's default path, ldconfig should be invoked in the %post and %postun scriptlets. See: https://fedoraproject.org/wiki/Packaging/ScriptletSnippets#Shared_libraries OK - package is not relocatable xx - file and directory ownership + The -devel sub-package should have 'Requires: gtk-doc' as it installs files under /usr/share/gtk-doc. + The -devel sub-package should have 'Requires: pkgconfig' as it installs files under /usr/lib/pkgconfig. Or has the new autogenerated pkgconfig dependencies feature removed this requirement? OK - no duplicates in %file OK - file permissions set properly + The preferred attribute definition is: %defattr(-,root,root,-) 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 xx - -devel has *.pc file and does not require pkgconfig + The -devel sub-package should have 'Requires: pkgconfig' as it installs a *.pc file under /usr/lib/pkgconfig. Or has the new autogenerated pkgconfig dependencies feature removed this requirement? OK - library files without suffix in -devel + Some plugins, which are shared libraries without a suffix, are in the main package. This is fine. xx - -devel does not require base package using fully versioned dependency + The -devel subpackage should have 'Requires: %{name} = %{version}-%{release}' instead of just 'Requires: %{name} = %{version}'. Is there any reason for this to be otherwise? 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 xx - package does not build in mock successfully + Libtheora has a broken version numbering in its *.pc file. See: https://bugzilla.redhat.com/478651 Since the version of libtheora in Fedora 8 and above is recent enough, we can disable the version check in the configure script. OK - package builds on all supported architectures OK - package functions as expected xx - scriptlets are not sane + Since shared libraries are being installed in the dynamic linker's default path, ldconfig should be invoked in the %post and %postun scriptlets. See: https://fedoraproject.org/wiki/Packaging/ScriptletSnippets#Shared_libraries OK - subpackages other than -devel are not needed OK - pkgconfig files in -devel 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