https://bugzilla.redhat.com/show_bug.cgi?id=1369067 --- Comment #1 from Debarshi Ray <debarshir@xxxxxxxxxx> --- MUST items ---------- rpmlint output: $ rpmlint /home/rishi/devel/rpmbuild/SRPMS/libgepub-0.3-0.1.git395779e.fc23.src.rpm libgepub.src: W: spelling-error Summary(en_US) epub -> pub, e pub libgepub.src: W: spelling-error %description -l en_US epub -> pub, e pub libgepub.src: W: invalid-url Source0: libgepub-0.3-395779e.tar.bz2 1 packages and 0 specfiles checked; 0 errors, 3 warnings. $ rpmlint /home/rishi/devel/rpmbuild/RPMS/x86_64/libgepub-0.3-0.1.git395779e.fc23.x86_64.rpm libgepub.x86_64: W: spelling-error Summary(en_US) epub -> pub, e pub libgepub.x86_64: W: spelling-error %description -l en_US epub -> pub, e pub libgepub.x86_64: W: no-documentation libgepub.x86_64: E: incorrect-fsf-address /usr/share/licenses/libgepub/COPYING 1 packages and 0 specfiles checked; 1 errors, 3 warnings. $ rpmlint /home/rishi/devel/rpmbuild/RPMS/x86_64/libgepub-devel-0.3-0.1.git395779e.fc23.x86_64.rpm libgepub-devel.x86_64: W: only-non-binary-in-usr-lib libgepub-devel.x86_64: W: no-documentation 1 packages and 0 specfiles checked; 0 errors, 2 warnings. $ rpmlint /home/rishi/devel/rpmbuild/RPMS/x86_64/libgepub-debuginfo-0.3-0.1.git395779e.fc23.x86_64.rpm 1 packages and 0 specfiles checked; 0 errors, 0 warnings. All those are harmless. It prefers 'e-pub' instead of 'epub', but that's really trivial. We should probably tell upstream to update their COPYING file. YES - package follows Naming Guidelines YES - spec file name matches base package %{name} NO - package follows Packaging Guidelines It is not obvious whether libgepub has had a release or not. I don't see anything in https://download.gnome.org/sources/, but https://github.com/GNOME/libgepub/releases suggests that there was a 0.3 release from the 0.3 git tag. Therefore, I think it will be better to use a post-release versioning scheme, instead of a pre-release scheme. The current scheme (0.3-0.1.git<shortcommit>, 0.3-0.2.git<shortcommit>, etc..) expects that there will be a 0.3 release at some point in the future. Instead, I think we should do something like: 0.3-2.git<shortcommit>, 0.3-3.git<shortcommit>, etc.. I skipped 0.3-1 because we have moved ahead of the 0.3 tag. YES - package is under a Fedora approved license YES - license field matches actual license YES - source package includes license text, which is included in %license YES - spec file written in American English YES - spec file is legible YES - sources match upstream source Since this is a Git snapshot, the checksum of the tarball depends on the exact versions of Autotools. Quite surprisingly, libgepub-0.3/aclocal.m4 was the only difference between Kalev's tarball and mine. YES - package compiles on all primary architectures YES - there is no need for ExcludeArch YES - all build dependencies in BuildRequires YES - doesn't have any locale files YES - calls ldconfig in %post and %postun YES - doesn't bundle system libraries YES - package is not relocatable YES - package owns all directories that it creates YES - files are listed only once in %files YES - file permissions are set properly YES - consistent use of macros YES - package contains code or permissible content YES - no need for doc subpackage YES - no chance of items marked as %doc affecting runtime YES - no static libraries YES - development files in devel subpackage YES - devel subpackage requires base package YES - package removes all libtool archives YES - package doesn't need a .desktop file YES - doesn't own files or directories owned by other packages It owns %{_libdir}/girepository-1.0 and %{_datadir}/gir-1.0, which are owned by gobject-introspection and gobject-introspection-devel respectively. However, these are not in libgepub's "natural dependency chain" - a C program can use libgepub without gobject-introspection. Therefore, I think this is fine. YES - all filenames are valid UTF-8 SHOULD items ------------ YES - package includes license text from upstream NO - description and summary doesn't have translations YES - package builds in Koji YES - builds on all primary architectures YES - package functions as described YES - package doesn't use scriptlets YES - no subpackages other than devel YES - pkgconfig files are part of devel subpackage YES - no dependencies outside of /etc/, /bin/, /sbin, etc. YES - no need for man pages -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/package-review@xxxxxxxxxxxxxxxxxxxxxxx