http://kojipkgs.fedoraproject.org/packages/pam_shield/0.9.5/2.fc16/data/logs/x86_64/build.log See the gcc invocations (Fedora optflags are not present there), and blocker bug for more info. (Cc'ing reviewer.)
I am repackaging with an updated spec file to include the %{optflags}
pam_shield-0.9.5-4.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/pam_shield-0.9.5-4.fc14
pam_shield-0.9.5-4.el5 has been submitted as an update for Fedora EPEL 5. https://admin.fedoraproject.org/updates/pam_shield-0.9.5-4.el5
pam_shield-0.9.5-4.fc13 has been submitted as an update for Fedora 13. https://admin.fedoraproject.org/updates/pam_shield-0.9.5-4.fc13
pam_shield-0.9.5-4.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/pam_shield-0.9.5-4.fc15
pam_shield-0.9.5-4.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/pam_shield-0.9.5-4.el6
Not fixed in 0.9.5-4: http://kojipkgs.fedoraproject.org/packages/pam_shield/0.9.5/4.fc16/data/logs/x86_64/build.log | gcc -Wall -Wstrict-prototypes -fPIC -c shield_purge.c ^- no optflags there ...and -debuginfo is still empty. Also, you seem to also have included the %build and %{optflags} strings as is in %changelog. Don't do that, write them as %%build and %%{optflags} there, see for example the Changelog section at http://koji.fedoraproject.org/koji/buildinfo?buildID=238141 for what results otherwise. (rpmlint would have caught this bug, BTW)
Package pam_shield-0.9.5-4.el5: * should fix your issue, * was pushed to the Fedora EPEL 5 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=epel-testing pam_shield-0.9.5-4.el5' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/pam_shield-0.9.5-4.el5 then log in and leave karma (feedback).
I have rebuilt it again fixing my goofs. Please double check it http://red-dragon.com/pam_shield-0.9.5-5.fc13.src.rpm I got no rpmlint errors from spec, srpm, or binary rpms. The %optflags are in place and the debug package isn't empty. Soon as you say okay then I'll push the new release.
CFLAGS and %changelog look ok now, but there's still a debuginfo related issue with pam_shield.so: it's stripped before rpmbuild has had a chance to extract debuginfo from it, and not installed with executable permissions so rpmbuild would not extract debuginfo from it anyway. Fix: --- pam_shield.spec~ 2011-04-09 01:15:28.000000000 +0300 +++ pam_shield.spec 2011-04-09 11:44:09.882259898 +0300 @@ -50 +50 @@ -install -s -m 644 pam_shield.so %{buildroot}/%{_lib}/security/ +install -m 755 pam_shield.so %{buildroot}/%{_lib}/security/ I would also suggest this change: --- pam_shield.spec~ 2011-04-09 01:15:28.000000000 +0300 +++ pam_shield.spec 2011-04-09 11:52:27.796033394 +0300 @@ -70,3 +70,3 @@ %files -%defattr(644,root,root) +%defattr(-,root,root) /%{_lib}/security/pam_shield.so @@ -81,3 +81,2 @@ %config(noreplace) %{_sysconfdir}/security/shield.conf -%defattr(755,root,root) %dir /var/lib/pam_shield This way you're setting permissions only in one place (%install) instead of two. It also fixes (?) the permissions of /var/lib/pam_shield - %install indicates the intent is to have perms 700 for it, but your latter %defattr overrides that and it ends up packaged with 755 perms. ...and one more thing you might be interested in: remove all lines containing _defaultdocdir from %install and %files and add this to %files instead: %doc Changelog CREDITS GPL INSTALL README
I changed the %defattr information as your correct, its set in install so no need to duplicate effort and specify it again in the %files section. I can't do the shorthand for %doc because I'm renaming the file GPL to LICENSE to meet packaging standards and shorthand doesn't work when you rename a file on anything in %doc. If I remove the -s from the install line on pam_shield.so I get the following warning from rpmlint on the binary: pam_shield.x86_64: W: unstripped-binary-or-object /lib64/security/pam_shield.so Also is the the following error passable? pam_shield.x86_64: E: non-standard-dir-perm /var/lib/pam_shield 0700L For security the permissions on the library are set to 700 but rpmlint doesn't like it. Considering the format of the file I don't find it a security risk, it was just how the original author installs that directory.
Okay the issue I had with stripping was the so was not installed executable - fixed I changed permissions on /var/lib/pam_shield to 755 as I seen no security risk to it being 755 Check out http://red-dragon.com/pam_shield-0.9.5-6.fc13.src.rpm
(In reply to comment #11) > I can't do the shorthand for %doc because I'm renaming the file GPL to LICENSE > to meet packaging standards What packaging standards require you to do that? (In reply to comment #12) > Okay the issue I had with stripping was the so was not installed executable - > fixed Yes, that was suggested in comment 10. > I changed permissions on /var/lib/pam_shield to 755 as I seen no security risk > to it being 755 I suggest asking upstream before doing this. rpmlint can't know if 700 is intentional - it's just unusual and that's why it emits a warning so packagers can double check it. > Check out http://red-dragon.com/pam_shield-0.9.5-6.fc13.src.rpm Diff against -5 looks otherwise ok, but I'd think twice and ask upstream before doing the 700 -> 755 perms change for /var/lib/pam_shield. (I don't even know what this package is for nor do I plan to use it, so it's unlikely I'll have further comments.)
Permissions changed back to 700 on /var/lib/pam_shield The packaging standards say that a LICENSE file is required so I make sure its named LICENSE when distributed in the name of the license. Thanks again for all your assistance.
pam_shield-0.9.5-7.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/pam_shield-0.9.5-7.fc14
pam_shield-0.9.5-7.el5 has been submitted as an update for Fedora EPEL 5. https://admin.fedoraproject.org/updates/pam_shield-0.9.5-7.el5
pam_shield-0.9.5-7.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/pam_shield-0.9.5-7.el6
pam_shield-0.9.5-7.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/pam_shield-0.9.5-7.fc15
pam_shield-0.9.5-7.fc13 has been submitted as an update for Fedora 13. https://admin.fedoraproject.org/updates/pam_shield-0.9.5-7.fc13
(In reply to comment #14) > The packaging standards say that a LICENSE file is required so I make sure its > named LICENSE when distributed in the name of the license. Could you post a link to a document that requires that the name of the file containing the license must be LICENSE? I'm fairly certain that either you're misinterpreting the document, or the document needs to be fixed not to require that. I believe this is the first package I've seen where the license files is renamed, and there are thousands of packages in Fedora in which it isn't.
Package pam_shield-0.9.5-7.el6: * should fix your issue, * was pushed to the Fedora EPEL 6 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=epel-testing pam_shield-0.9.5-7.el6' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/pam_shield-0.9.5-7.el6 then log in and leave karma (feedback).
pam_shield-0.9.5-7.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.
pam_shield-0.9.5-7.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
pam_shield-0.9.5-7.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
pam_shield-0.9.5-7.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report.
pam_shield-0.9.5-7.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report.