Spec URL: http://salimma.fedorapeople.org/specs/gnome/gtksourcecompletion.spec SRPM URL: http://salimma.fedorapeople.org/specs/gnome/gtksourcecompletion-0.5.2-1.fc11.src.rpm Description: GtkSourceCompletion is a code completion library for GtkSourceView. (needed as a dependency for vtg, Vala Tools for gedit)
Some general comments first ... > find $RPM_BUILD_ROOT -name '*.la' -exec rm -f {} ';' can be replaced by: > find $RPM_BUILD_ROOT -name '*.la' -delete The license file issue should be raised upstream. Just adding a link to a mailing list message into the spec file should be sufficient. More comments follow ...
rpmlint output: gtksourcecompletion-devel.x86_64: W: no-documentation gtksourcecompletion-doc.x86_64: E: description-line-too-long The gtksourcecompletion-doc package contains documentation for gtksourcecompletion. 5 packages and 0 specfiles checked; 1 errors, 1 warnings. The no-documentation warning is OK temporarily until we resolve the license issue. description-line-too-long should be corrected.
- rpmlint output See comment 2. + package name satisfies the packaging naming guidelines Yes, but the very loose standards of Fedora. cf. "gtksourceview" + specfile name matches the package base name + package should satisfy packaging guidelines + license meets guidelines and is acceptable to Fedora Real license is LGPLv2+. COPYING file needs updating as mentioned in comment 1. + license matches the actual package license - %doc includes license file See comment 1. + spec file written in American English + spec file is legible + upstream sources match sources in the srpm b031896ce03bef4ca711f9b1e0a34544 / 431699 + package successfully builds on at least one architecture x86_64 n/a ExcludeArch bugs filed + BuildRequires list all build dependencies http://koji.fedoraproject.org/koji/taskinfo?taskID=1115220 + %find_lang instead of %{_datadir}/locale/* + binary RPM with shared library files must call ldconfig in %post and %postun + does not use Prefix: /usr + package owns all directories it creates + no duplicate files in %files + %defattr line + %clean contains rm -rf $RPM_BUILD_ROOT + consistent use of macros + package must contain code or permissible content + large documentation files should go in -doc subpackage + files marked %doc should not affect package + header files should be in -devel n/a static libraries should be in -static + packages containing pkgconfig (.pc) files need 'Requires: pkgconfig' + libfoo.so must go in -devel + -devel must require the fully versioned base + packages should not contain libtool .la files n/a packages containing GUI apps must include %{name}.desktop file + packages must not own files or directories owned by other packages + %install must start with rm -rf %{buildroot} etc. + filenames must be valid UTF-8 Optional: ? if there is no license file, packager should query upstream see comment 1 n/a translations of description and summary for non-English languages, if available + reviewer should build the package in mock + the package should build into binary RPMs on all supported architectures - review should test the package functions as described + scriptlets should be sane + pkgconfig files should go in -devel + shouldn't have file dependencies outside /etc /bin /sbin /usr/bin or /usr/sbin
To clarify, these are the remaining issues: - wrong copying file included in tarball: is this a blocker, and could I just bundle the correct COPYING and COPYING.LIB files from the FSF? - package naming: should this ideally be gtksourceview2-completion, GtkSourceCompletion, or something else? - functionality review: the vtg demo should allow this to be tested: http://vtg.googlecode.com/svn/wiki/screencasts/vtg-demo-1.ogg
(In reply to comment #4) > To clarify, these are the remaining issues: > - wrong copying file included in tarball: is this a blocker, and could I just > bundle the correct COPYING and COPYING.LIB files from the FSF? This is not a blocker. Just post about it on an upstream mailing list, and then add the URL of that posting as a comment eg in the spec file, just so we know what is happening. > - package naming: should this ideally be gtksourceview2-completion, > GtkSourceCompletion, or something else? Package name is OK according to the guidelines, it's just that I personally think the guidelines are rather weak. Again, this is not a blocker. > - functionality review: the vtg demo should allow this to be tested: > http://vtg.googlecode.com/svn/wiki/screencasts/vtg-demo-1.ogg I can't build vtg yet unfortunately, but I will try this when it builds.
OK, so once we can resolve the vtg build issue, both reviews should be in good shape. I'm contacting upstream about the licensing text.
Just put that link into the spec file when you check it in. Package is APPROVED by rjones.
New Package CVS Request ======================= Package Name: gtksourcecompletion Short Description: Completion support for GtkSourceView Owners: salimma Branches: F-9 F-10 EL-5 InitialCC:
cvs done.
This is in Fedora now, so closing.