# glsa-check error [solved]

## huuan

This morning I noticed that glsa-check has developed an issue on our server (2.6.18 hardened):

When 

glsa-check -t all

 is run it does this 

 *Quote:*   

> Traceback (most recent call last):
> 
>   File "/usr/bin/glsa-check", line 257, in ?
> 
>     myglsa = Glsa(myid, glsaconfig)
> ...

 

Has something broken the Unicode encoder? Is that what that says?

Tried re-emergeing gentools but same result.

I suspect it has to do with the shibboleth daemon I installed yesterday but stopping that doesn't fix it so I am at a loss.

Now that I think about it in the process of installing shibboleth  I also just installed and  updated a bunch of other stuff such as:

dev-java/java-config-1.3.7

dev-java/sun-jdk-1.4.2.15

dev-java/sun-jdk-1.5.0.12

net-misc/curl-7.16.4 which lead to revdep-rebuild --library libcurl.so.3

- dev-lang/php-5.2.2-r1

- dev-lang/php-4.4.7

but as I recall after that glsa-check was working OK

It was next day things went awry after shibboleth-sp install using a prototype ebuild that added:

DEPEND=">=dev-libs/openssl-0.9.7

        =dev-libs/log4cpp-0.3.5_rc1

        >=dev-libs/xerces-c-2.6.1

        =dev-libs/xml-security-c-1.3.0

        =dev-cpp/opensaml-1.1b"

as well as shibboleth itself.

Hoping you can give a few pointers about where to start...Last edited by huuan on Tue Oct 02, 2007 2:17 am; edited 1 time in total

----------

## Abraxas

Are you using glsa-check by itself or in a script?  I just tried it out on my box and glsa-check will work fine by itself but when I try to redirect the output to a file I get basically the same error that you do.

----------

## huuan

The error came initially from using it via a daily cron but gives the same error when run from shell.

[edit] Looking back at the error it last worked fine yesterday at 8am but I think since then I have fixed 3 vulnerabilities 200705-23,200702-07 and 200701-15 all to do with java sdk. No clue if that last  is relevant.

[edit some more] I just noticed some new info: the time line goes more like:

sun 8am glsa-check -t all  OK

sun sometime fix java sdk glsa's

mon 3:30am emerge --sync

mon 5:30am test -x /usr/sbin/run-crons && /usr/sbin/run-crons

  gave error:

 *Quote:*   

> curl: (7) couldn't connect to host
> 
> update-pciids: download failed

 

mon 8am glsa-check goes awry

so maybe it has to do with the curl update from the other day messing with something.

[edit yet again] i checked the firewall logs and found that curl had been trying to talk to 66.35.250.209 projects.sourceforge.net and been blocked by the output policy.

after opening a hole for that IP in the firewall I ran 

test -x /usr/sbin/run-crons && /usr/sbin/run-crons

both from shell and from cron but it didn't seem to do anything, no errors no messages. I read the man page on test and I'm not sure still what that call actually does...in the past the output was of the form "/usr/lib/openldap/openldap/.keep_net-nds_openldap-0 /usr/lib/locale/.keep_sys-libs_glibc-2.2..." but many more lines. Clear as mud to me.

----------

## Khabi

I'm seeing the same problem on two of my boxes today after doing an emerge --sync

Maybe there is something wacky going on in the portage tree right now?

----------

## AlanR

This has happened a couple of times before with different GLSAs, to fix this one open /usr/portage/metadata/glsa/glsa-200709-18.xml, go to line 40 and replace the é's in Frédéric with e's (Frederic).

If you want more info see the bug.

-Alan

----------

## huuan

 *Quote:*   

> If you want more info see the bug. 

 

Thanks. That fixed it.   :Very Happy:   I'm marking this solved thanks to your input.

for those intersted the bug is https://bugs.gentoo.org/show_bug.cgi?id=162493

----------

## mikegpitt

I can't stand this bug... it seems to creep up about every 2 months or so.  Usually there is a fix in portage within the same day, but this is the 2nd day with the issue for me.

----------

