Bug 209889

*** Bug 209869 has been marked as a duplicate of this bug. ***

Created attachment 138057 [details]
Fix false assumptions about some tags' existence

This happens because rpmlint incorrectly assumes that everything has a source
rpm - gpg-pubkeys obviously don't - and proceeds to blindly try to access the
SRPM name as a string.	Fixing this uncovers other similar incorrect
assumptions, but I think the attached patch (upstream site is inaccessible so
I'll attach it here) catches them.

Another thing that should probably be done would be to filter everything about
gpg-pubkeys, by adding 'addFilter("gpg-pubkey")' to /usr/share/rpmlint/config. 
Opinions?

(In reply to comment #1)
> *** Bug 209869 has been marked as a duplicate of this bug. ***

Why? 209869 was meant to be about the traceback, while this one was meant to be
on the "meaningfulness" of these warnings:

W: gpg-pubkey summary-not-capitalized gpg(Livna.org rpms <rpm-key>)
W: gpg-pubkey non-standard-group Public Keys
E: gpg-pubkey no-changelogname-tag
W: gpg-pubkey invalid-license pubkey
W: gpg-pubkey no-url-tag

None of them is useful nor valid.

(In reply to comment #3)
This, to me is PR 209869

Both the meaninglessness and the backtrace were reported in this bug.  Bug 
209869 contains only the backtrace, but no reproducer.  Therefore I prefer to 
track both issues here.

The patch in comment 2 is a proposed fix/workaround for the backtrace, and the 
second paragraph of comment 2 contains a suggested solution for the bogosity 
of the gpg-pubkey related messages.

(In reply to comment #4)
> Both the meaninglessness and the backtrace were reported in this bug.  Bug 
> 209869 contains only the backtrace, but no reproducer.
Well, providing a reproducer would have required to have one - When I filed
209869, all I saw was "rpmlint -a" crashing at what had seemed to be random spots.

> The patch in comment 2 is a proposed fix/workaround for the backtrace,
AFAICT so far from testing your patch, it seems to fix the backtrace for 
"rpmlint gpg-pubkey", but for "rpmlint -a", a different traceback now occurs
(Cf. attachment).

BTW: Unsurprisingly, "rpmlint -a" now takes MUCH longer (hours!) than before,
before it bombs out ;)

> and the 
> second paragraph of comment 2 contains a suggested solution for the bogosity 
> of the gpg-pubkey related messages.
I am not sufficiently familiar with rpmlint to be able to comment on this.
Generally speaking, I'd say "filtering packages by name" should be the last resort.

Created attachment 138111 [details]
traceback at the end of "rpmlint -a"

This traceback is from the end of running "rpmlint -a" using rpmlint-0.78-1.fc5

w/ rpmlint-nosrcrpm.patch applied on FC5/i386.
The full log is > 7MB  and > 60000 lines ;)

rpmlint iptables(In reply to comment #6)
> Created an attachment (id=138111) [edit]
> traceback at the end of "rpmlint -a"

FYI: I can deterministically reproduce the same traceback running
"rpmlint iptables"
using rpmlint-0.78-1.fc5 w/ and w/o your patch.

=> Yet another bug, unrelated to the previous ones.

(In reply to comment #5)
> > The patch in comment 2 is a proposed fix/workaround for the backtrace,
> AFAICT so far from testing your patch, it seems to fix the backtrace for 
> "rpmlint gpg-pubkey"

Applied upstream as http://rpmlint.zarb.org/cgi-bin/trac.cgi/changeset/1284

> Generally speaking, I'd say "filtering packages by name" should be the last
> resort.

Ditto, but I can't come up with anything better at the moment for the 
gpg-pubkey case.

(In reply to comment #7)
> 
> FYI: I can deterministically reproduce the same traceback running
> "rpmlint iptables"
> using rpmlint-0.78-1.fc5 w/ and w/o your patch.

Reproduced, I'm looking into it.

> => Yet another bug, unrelated to the previous ones.

If you happen to come across even more, could you file separate bug reports 
about them and not add new unrelated ones here?  TIA.

Filtering by name is okay, its highly unlikely that "gpg-pubkey" will ever change.

Otherwise, "gpg-pubkeys" do not have RPMTAG_ARCH, and are unlikely to ever acquire that tag,
arch is meaningless for RFC-2240 public keys.

RFC-2440, typo.

Better still would be to teach rpmlint to actually verify the
header of gpg-pubkey packages.

Version: is the fingerprint
Release: is the creation time
Group: is "Public Keys"
%description is the ascii armor'ed pubkey

Verifying the fingerprint is most important, as rpm prior to 4.4.2 did not
calculate the fingerprint directly, but rather used a field from the certification signature.

All the above is just random rpmlint RFE ideas, skipping makes perfect sense as well.

Fixed in 0.78-2.fc*