Hi,
I noticed that gconf-schemas was hung (even overnight) until ctrl-c is
pressed. This prevented correct installation (and disinstallation) of
xchat-common deb binary package.
I'm using Debian gnu/hurd K14.
When using ctrl-c python gives the following traceback, showing the
instruction where it hangs:
Traceback (most recent call last):
File "/usr/lib/python2.4/tempfile.py", line 33, in ?
from random import Random as _Random
File "/usr/lib/python2.4/random.py", line 834, in ?
inst = Random()
File "/usr/lib/python2.4/random.py", line 94, in __init__
self.seed(x)
File "/usr/lib/python2.4/random.py", line 108, in seed
a = long(_hexlify(_urandom(16)), 16)
File "/usr/lib/python2.4/os.py", line 723, in urandom
bytes += read(_urandomfd, n - len(bytes))
KeyboardInterrupt
The bug can be simply reproduced by launching python and issuing the
following two commands:
>>> import os
>>> os.urandom(16) #this may be any number
At first I tried showtrans on the /dev/random, /dev/urandom devices and
I found they were attached to the unofficial translator
(http://hurd.gnufans.org/bin/view/Hurd/RandomDevice).
Resetting /dev/random, /dev/urandom by detaching (settrans -fg
/dev/urandom) and then reattaching the translator fixed the bug. If I
release the translator the bug comes out again.
Judging from the behaviour traceback, I think that when the translator
is not attached, os.urandom() tries to read a random stream that doesn't
exist, so it hangs until the right number of bytes arrives... that is,
never. However the translator *was* attached before; so maybe it's
(also) a translator bug. I was root when testing, so I doubt a
permission issue.
I have some Python knowledge so I can try to patch os.urandom() to
behave correctly (or at least throw an exception noticing that there is
no translator bound to the device/he can't have the stream). The bug is
of some importance because at least gconf-schemas depends on it, and it
prevents installation of some packages. To my knowledge (Googling
"os.urandom + hurd" :) ) the bug is unknown.
What should I do? Contact the upstream os module developers? or do we
need to "unofficially" patch it for the gnu Hurd?
massimo
_______________________________________________
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
