Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=922438 --- Comment #2 from Patrick Uiterwijk <puiterwijk@xxxxxxxxx> --- OK - Package meets naming and packaging guidelines OK - Spec file matches base package name. NO, See below - Spec has consistant macro usage. OK - Meets Packaging Guidelines. OK - License GPLv2 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: e00f5b5672a74f93ca6e5667254de5be libreswan-3.1.tar.gz e00f5b5672a74f93ca6e5667254de5be libreswan-3.1.tar.gz OK - BuildRequires correct OK, See below - Package has %defattr and permissions on files is good. OK - Package is code or permissible content. OK - Packages %doc files don't affect runtime. OK - Package compiles and builds on at least one arch. OK - Package has no duplicate files in %files. NO, See below - Package doesn't own any directories other packages own. OK - Package owns all the directories it creates. OK - Package obey's FHS standard (except for 2 exceptions) See below - No rpmlint output. OK - final provides and requires are sane. SHOULD Items: OK - Should build in mock. OK - Should build on all supported archs OK - Should function as described. OK - Should have dist tag OK - Should package latest version OK - Should not use file requires outside of /etc, /bin, /sbin, /usr/bin, or /usr/sbin Issues: 1. Macro usage Both $RPM_BUILD_ROOT and %{buildroot} styles are used 2. Directory owner It owns some packages also owned by openswan, but it contains an Obsoletes/Provides for this. I just wonder if this complies to the notes in the packaging guidelines "If a package is being renamed without any functional changes, or is a compatible enough replacement to an existing package (where "enough" means that it includes only changes of magnitude that are commonly found in version upgrade changes)". So: are the changes of magnitude of version upgrade changes, or have there been major changes as openswan-2.6.38-12? 3. rpmlint says: Checking: libreswan-3.1-1.fc18.x86_64.rpm libreswan.x86_64: W: spelling-error Summary(en_US) IPsec -> Eclipse libreswan.x86_64: W: spelling-error %description -l en_US IPsec -> Eclipse libreswan.x86_64: W: spelling-error %description -l en_US untrusted -> entrusted, trusted, encrusted libreswan.x86_64: W: spelling-error %description -l en_US decrypted -> encrypted libreswan.x86_64: W: spelling-error %description -l en_US userland -> user land, user-land, slanderous libreswan.x86_64: W: spelling-error %description -l en_US kmod -> mod, k mod, mood libreswan.x86_64: W: only-non-binary-in-usr-lib libreswan.x86_64: E: non-standard-dir-perm /etc/ipsec.d/policies 0700L libreswan.x86_64: E: non-standard-dir-perm /etc/ipsec.d/crls 0700L libreswan.x86_64: E: non-standard-dir-perm /var/run/pluto 0700L libreswan.x86_64: E: non-readable /etc/ipsec.secrets 0600L libreswan.x86_64: E: non-standard-dir-perm /etc/ipsec.d 0700L libreswan.x86_64: E: non-standard-dir-perm /etc/ipsec.d/cacerts 0700L libreswan.x86_64: E: non-standard-dir-perm /var/log/pluto/peer 0700L 1 packages and 0 specfiles checked; 7 errors, 7 warnings. You can safely ignore the spelling-errors, and the non-standard-dir-perms seem logical in this case. Please fix the macro usage as per 1 and answer the question in issue 2. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=RCVTlDDgBF&a=cc_unsubscribe _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review