Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ecryptfs-utils - Linux eCryptfs utilities https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=218556 notting@xxxxxxxxxx changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |notting@xxxxxxxxxx ------- Additional Comments From notting@xxxxxxxxxx 2007-06-07 02:49 EST ------- MUST items: - Package meets naming and packaging guidelines - OK - Spec file matches base package name. - OK - Spec has consistant macro usage. - OK - Meets Packaging Guidelines. - OK - License - OK - License field in spec matches - OK - License file included in package - OK - Spec in American English - OK - Spec is legible. - OK - Sources match upstream md5sum: - OK - Package needs ExcludeArch - OK - BuildRequires correct - OK - Spec handles locales/find_lang - N/A - Package is relocatable and has a reason to be. - N/A - Package has %defattr and permissions on files is good. - OK - Package has a correct %clean section. - OK - Package has correct buildroot - OK %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) - Package is code or permissible content. - OK - Doc subpackage needed/used. - N/A - Packages %doc files don't affect runtime. - OK - Headers/static libs in -devel subpackage. - OK - Spec has needed ldconfig in post and postun - OK - .pc files in -devel subpackage/requires pkgconfig - N/A - .so files in -devel subpackage. - OK - -devel package Requires: %{name} = %{version}-%{release} - OK - .la files are removed. - OK - Package is a GUI app and has a .desktop file - N/A - Package compiles and builds on at least one arch. - OK - Package has no duplicate files in %files. - OK - Package doesn't own any directories other packages own. - OK - Package owns all the directories it creates. - OK - No rpmlint output. *** E: ecryptfs-utils binary-or-shlib-defines-rpath /sbin/mount.ecryptfs ['/usr/lib64'] E: ecryptfs-utils binary-or-shlib-defines-rpath /lib64/security/pam_ecryptfs.so ['/usr/lib64'] E: ecryptfs-utils binary-or-shlib-defines-rpath /usr/bin/ecryptfsd ['/usr/lib64'] E: ecryptfs-utils binary-or-shlib-defines-rpath /usr/bin/ecryptfs-manager ['/usr/lib64'] - final provides and requires are sane: *** Main package has: Requires: keyutils openssl pam kernel >= 2.6.19 1) keyutils, openssl, pam requirements should be superfluous - library dependencies take care of this 2) kernel requires are tricky. Generally, we do Conflicts: kernel < 2.6.19 as there's no reason, for example, to pull a kernel into a buildroot. SHOULD Items: - Should build in mock. - OK (tried x86_64) - Should build on all supported archs - build i386 non-mock - Should function as described. - mounted FS successfully - Should have sane scriptlets. - OK - Should have subpackages require base package with fully versioned depend. - OK - Should have dist tag - OK - Should package latest version - build checks were done with 16, even though 15 was here :) MISC item: So, general sanity checking: /lib/security/pam_ecryptfs.so: linux-gate.so.1 => (0x00e9e000) ... libdl.so.2 => /lib/libdl.so.2 (0x006a6000) libecryptfs.so.0 => /usr/lib/libecryptfs.so.0 (0x00b11000) libgcrypt.so.11 => /usr/lib/libgcrypt.so.11 (0x007c4000) ... libgpg-error.so.0 => /usr/lib/libgpg-error.so.0 (0x0056f000) /sbin/mount.ecryptfs: linux-gate.so.1 => (0x00397000) libgpg-error.so.0 => /usr/lib/libgpg-error.so.0 (0x038a8000) libecryptfs.so.0 => /usr/lib/libecryptfs.so.0 (0x008eb000) ... libgcrypt.so.11 => /usr/lib/libgcrypt.so.11 (0x03e3a000) That's bad; these shouldn't be linked against things in /usr/lib. (Yes, some people still run /usr separate.) Moreover, I suspect that both of these will also dlopen the plugins in $(libdir)/ecryptfs? -devel: what, if anything, will ever build against this? If there's nothing, it may not be worth shipping. (Also,does this package maintain a stable ABI?) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review