I don't know, if this is the same known problem as with slots but glsa-check has problems with some revision-declarations: # glsa-check -t 200502-08 This system is affected by the following GLSA: 200502-08 # glsa-check -p 200502-08 Checking GLSA 200502-08 The following updates will be performed for this GLSA: dev-db/postgresql-8.0.1-r3 (7.4.8) The GLSA looks like this: <affected> <package name="dev-db/postgresql" auto="yes" arch="*"> <unaffected range="rge">7.4.7</unaffected> <unaffected range="ge">8.0.1</unaffected> <vulnerable range="lt">8.0.1</vulnerable> </package> </affected> From the DTD it seems, as if glsa-check thinks that the last number is the revision instead of the first. So it thinks that the following are vulnerable: 7.4.6, 7.4.6-r1 and so on and unaffected would be: 7.4.7, 7.4.7-r1 but affected is everything <8.0.1, so even: 7.4.8, as its not the same revision as 7.4.7, but below 8.0.1 Where from does glsa-check know, which number is in the same revision, and which not? Example: Kernel revisions are: 2.2.x, 2.4.x, 2.6.x, but Postgresql, php and apache have revisions like: 1.3.x, 2.0.x or 7.x.x,8.0.x or 4.7.x,5.0.x and so on... I think, the r* parameters in the glsa needs to define how revisions look like.
I commited changed GLSAs, hopefully this fixes the problem.
*** Bug 118891 has been marked as a duplicate of this bug. ***
