11:53 a.m.
https://bugzilla.redhat.com/show_bug.cgi?id=1369067
--- Comment #1 from Debarshi Ray <debarshir(a)redhat.com> ---
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