Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=225856 --- Comment #13 from Zdenek Prikryl <zprikryl@xxxxxxxxxx> 2009-02-05 04:14:30 EDT --- (In reply to comment #12) > Thank you for going on, rpmlint against latest CVS build (from http:// > cvs.fedoraproject.org/viewvc/devel/gpm/gpm.spec?revision=1.69) > > > gpm.x86_64: W: shared-lib-calls-exit /usr/lib64/libgpm.so.2.1.0 exit@xxxxxxxxxxx > > Any ideas for this? That really looks strange to me - and I do not really > have a clue what causes this. See also below at the bottom of this comment. This is caused by exit() function. If something goes wrong, libgpm calls exit(). This isn't standard library behaviour. Even in the source code there is a comment that mentions this fact. But anyway, right now there isn't a easy way how to get rid of exit() calls. I mean, if we want to remove calls, we'll have to change an architecture of library's reporting stuff. So, IMO we can ignore this warning. > > > %__cc %{?_smp_mflags} -o inputattach %{SOURCE2} > > Well, we've lost $RPM_OPT_FLAGS. See build logs: %{?_smp_mflags} only causes > -jX, not the rest of the flags $RPM_OPT_FLAGS would bring. So please re-add. Right, re-added. > Could you perform real integer comparisons rather half string comparisions? > > -if [ "$1" = "0" ]; then > +if [ $1 -eq 0 ]; then > > -if [ "$1" -ge "1" ]; then > +if [ $1 -ne 0 ]; then I had a conversation about this and string comparison is safer than integer comparison. So that's why I prefer this. > > Following is suggested to not break rpm transaction if something goes wrong: > > -/sbin/install-info %{_infodir}/gpm.info.gz --delete %{_infodir}/dir > +/sbin/install-info %{_infodir}/gpm.info.gz --delete %{_infodir}/dir || : IMO, if something goes wrong, user has to be notified. I committed spec with corrections. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review