Traceback (most recent call last): File "/usr/lib/python-exec/python3.4/glsa-check", line 181, in <module> myglsa = Glsa(x, glsaconfig) File "/usr/lib64/python3.4/site-packages/gentoolkit/glsa/__init__.py", line 509, in __init__ self.read() File "/usr/lib64/python3.4/site-packages/gentoolkit/glsa/__init__.py", line 527, in read self.parse(urlopen(myurl)) File "/usr/lib64/python3.4/site-packages/gentoolkit/glsa/__init__.py", line 574, in parse self.count = int(count) TypeError: int() argument must be a string, a bytes-like object or a number, not 'Attr' Due to count="3" attribute in <revised count="3">2017-01-13</revised> in portage calling int(count) on the ETree attribute, instead of int(count.text) or so. As such, this count attribute shouldn't be used until it has been fixed in stable portage for a sufficient time, imho.
and stable gentoolkit. Both contain such code that seems to throw this exception
So this particular one got hand fixed now. Future new and revision GLSAs from glsamaker are probably using the count thing then still, which would have to be handtweaked until something changes. I would personally do: 1) Change GLSAmaker to keep the revision after the date with a colon, instead of count attribute until things are fixed up. The date format itself can stay ISO as was changed to. 2) Make glsa-check in gentoolkit not have an old glsa/__init__.py that got copied into portage, but import it from portage instead, with whatever other changes needed to keep it working. 3) Fix portages glsa.py to not throw this error due to wrong int() casting. I'm blindly guessing an int(count) -> int(count.text) change would work as a minimal change, but this could use some other safeties and refactoring. 4) After the fixed things have been available for long enough in stable tree, flip things back to using the revised count attribute in glsamaker. If you agree, please create new bugs or assign/CC as needed.
Apparently this is actually using minidom, not ElementTree, so the quick fix would be adding an else case for the "if count is None" check: else: count = count.value Or if an empty count attribute like <revised count=""> should fallback to looking for it in the text, then replacing count = revisedEl.attributes.get("count") with count = revisedEl.getAttribute("count") and if count is None: with if not count: should also work, as getAttribute will already set it to an empty string if the attribute isn't found, and then "if not count" will be true for an empty string (but it won't be None, hence the check change). But all that code might use some refactoring. Like not use minidom, but ElementTree or lxml, etc... (no, minidom is not faster than ETree.) And this all is really step 3), we need to do 1 and 2 first or in parallel really.
Patch emailed to the Portage tools team with the proposed changes. These have been tested on both styles (and a mixed style repo) and proper processing ensured with 'glsa-check --dump'. Thanks to Mart for the work and additional testing.
The patch looks good, go ahead and push it to the gentoolkit repo. All developers have access and are authorized to make changes. Once it is pushed, I'll do a gentoolkit-0.3.3-r1 release containing the patch.
The same code has to be patched in portage's glsa.py module as well, for @security set and more, as long as there are two copies of it (portage's is copy-paste more or less, with some VDB and other related tweaks it seems)
Fix has been pushed to gentoolkit [1]. We will track the code merge in bug 463952. [1]: https://gitweb.gentoo.org/proj/gentoolkit.git/commit/?id=8aed03d3c4170943568ff1446574f21e0c7396d7
