So GLSAMaker comes with this obviously wrong idea of appending slots to version as plaintext: glsa-201010-01.xml: <unaffected range="ge">1.2.46:1.2</unaffected> glsa-201206-15.xml: <unaffected range="ge">1.2.49:1.2</unaffected> glsa-201502-10.xml: <unaffected range="ge">1.5.21:1.5</unaffected> glsa-201502-10.xml: <unaffected range="ge">1.2.52:1.2</unaffected> glsa-201611-08.xml: <unaffected range="ge">1.2.56:1.2</unaffected> glsa-201611-08.xml: <unaffected range="ge">1.5.26:1.5</unaffected> glsa-201701-33.xml: <unaffected range="ge">9.5.4:9.5</unaffected> glsa-201701-33.xml: <unaffected range="ge">9.4.9:9.4</unaffected> glsa-201701-33.xml: <unaffected range="ge">9.3.14:9.3</unaffected> glsa-201701-33.xml: <unaffected range="ge">9.2.18:9.2</unaffected> glsa-201701-33.xml: <unaffected range="ge">9.1.23:9.1</unaffected> Which is really fugly, considering that operator is already split out to attribute. It would therefore be only reasonable to move the slot as attribute as well. Funny enough, this is exactly what Portage expects: try: slot = versionNode.getAttribute("slot").strip() except KeyError: pass
Not a bug, follows currently available spec which is up for discussion/change in the future.
glsa-check has supported slot attribute since September 2008. It is now used in the glsa repo because all this range="rge" business breaks each time an older SLOT receives a bump. But this needs to be done manually in the XML, because there is no SLOT field alongside the version field in glsamaker to generate it. rbu seems to have done both portage and DTD patches, but for some reason the DTD change was never deployed. That DTD change might also have made slot attribute a required one with default to "*", but I think it's better to have it as an optional attribute, with which the glsa-check code works fine.
I don't know where mgorny got the XML snippet, as the glsa repo has never used that syntax (except for a couple minutes for 201701-33 only where it was tried to get some slot information to the GLSA HTMLs, but glsa-check would throw an exception then)
Ok, I see, they were changed after I knew we had settled on using the slot attribute. They used to completely break glsa-check in one try, but seems it doesn't anymore (though glsa-check is now broken due to revised count="3" in newest GLSA)
(In reply to Alex Legler from comment #1) > Not a bug, follows currently available spec which is up for > discussion/change in the future. Where is that spec? SLOTs in this way were never used, and a spec of sorts does exist for the slot attribute, unlike these freeform things you decided to go for, so that GLSAmaker doesn't need any changes or something. Any claims of it being more backwards compatible seem dubious as well. Even glsa-check works by happy accident of the version being passed verbatim to portage and it just accidentally works. How about any of the other external things that parse our GLSAs? They might just as well not know anything about our SLOTs and their markup with a colon, then pass that to some generic version comparison method without Gentoo knowledge, and... A specification was done for the slots attribute in 2008. Yes, 8.5 years ago. A DTD patch was also provided, but probably due to the mess of our DTDs back then and people not knowing how to get em updated, it never was. There is explicit code for handling slot attribute, while freeform text slot works by accident really. If you want to be pedantic about specifications, GLSA XML versions and whatever else, then neither of these should get used, which would be a whole lot of "progress" after it was made to work where it matters 9 years ago... And a whole lot of breakage with false positives each time some old slot gets a new version.
So now pkgcore is crashing and all pull request checks fail. I've disabled them completely until the situation is resolved.
Reverted all slots to use the attribute.
