After the 'emerge --sync' on Thu Jul 26 06:49:05 UTC 2007, I ran # glsa-check --fix affected which failed with a UNICODE conversion error message. Reproducible: Always Steps to Reproduce: 1.glsa-check --fix affected 2. 3. Actual Results: Traceback (most recent call last): File "/usr/bin/glsa-check", line 148, in ? myglsa = Glsa(x, glsaconfig) File "/usr/lib/gentoolkit/pym/glsa.py", line 414, in __init__ self.read() File "/usr/lib/gentoolkit/pym/glsa.py", line 432, in read self.parse(urllib.urlopen(myurl)) File "/usr/lib/gentoolkit/pym/glsa.py", line 470, in parse self.description = getText(myroot.getElementsByTagName("description")[0], format="xml") File "/usr/lib/gentoolkit/pym/glsa.py", line 233, in getText return str(rValue) UnicodeEncodeError: 'ascii' codec can't encode character u'\xf6' in position 34: ordinal not in range(128) Expected Results: (Not an error message) As glsa-check itself has not updated recently, it seems this is either a GLSA database issue, or glsa-check has a bug which makes it fail on certain conditions. Both is dangerous, because without glsa-check working, important security fixes might not be applied to systems which run "glsa-check --fix affected" as cron jobs.
In order to make sure my Portage overlays cannot interfere with this problem, I disabled them totally in /etc/make.conf. But the problem did not go away; seems it is really a problem of the main portage tree or its glsa-files.
It is not even necessary to run "--fix affected" - even a simple # glsa-check --list will do. The error is triggered after the following line of output: 200707-06 [U] XnView: Stack-based buffer overflow ( x11-misc/xnview )
I have identified the failing GLSA-database entry: If the file /usr/portage/metadata/glsa/glsa-200707-07.xml is deleted, glsa-check works fine again.
I have examined the failing database entry and have not seen anything terribly incorrect. However, there is an UTF-8 encoded Umlaut in line 31. Since I don't know the character set encoding conventions for GLSA-files I do not know whether this might actually be a problem. But I suspect it.
Yes! It has been the umlaut! When I replaced it by ö everything works fine again.
If there are there any QA-checking scripts involved when releasing new GLSAs, a "glsa-check --list > /dev/null || exit 1" or something should really be added in order to make such trivial problems impossible in the future.
*** This bug has been marked as a duplicate of bug 186549 ***
