On Sun, Apr 25, 2004 at 05:05:32PM +0200, Matthias Klose wrote: > Michael Banck writes: > > > It seems that the pthread init hook is not being run by libc during > > > start up. Try adding -lpthread and see if that makes a difference. > > > > That indeed helps. On the other hand, generally adding -lpthread to > > $LDFLAGS makes linking libpython fail. I've built _tkinter.so manually > > and assembled a hacked python2.3 package which I've uploaded to > > ftp.gnuab.org: > > > > http://ftp.gnuab.org/debian/pool/main/p/python2.3/python2.3_2.3.3-6.0.1.changes > > In setup.y, add after "# Add the Tcl/Tk libraries" > > if platform == '<hurd platform name>': > libs.append('pthread')
Ah, great. I only looked at the Makefiles and forgot about setup.py. I'll report back whether that works when I've got the time to test this (probably later today). > what does sys.platform print? Ah, that's one thing I forgot to report. The platform string seems broken: Python 2.3.3 (#2, Apr 24 2004, 24:05:06) [GCC 3.3.3 (Debian 20040321)] on gnu0 [...] >>> import sys >>> sys.platform 'gnu0' >>> I't probably supposed to be 'gnu0.3', perhaps the dot confuses python? Or is 'gnu0' really the right platform string? Hmm, looking at 'linux2' on GNU/Linux, 'gnu0' does not look so far off anymore :) > > I've CC'ed the python maintainers, perhaps they have an idea how to > > handle this. Would be nice if people interested in python would test the > > packages, they seem to work fine for me but I did not have the time to > > install any other python packages/modules yet. > > > > A couple of tests failed (namely, 'cpickle', 'parser', 'poll', 're' and > > 'socket'. 'class' did fail, too, but changing recursion_limit in > > Python/ceval.c from 1000 to 930 made that pass on my machine at least) > > that could be hacked with an architecture specific patch. Is this new > for python2.3? No idea. We did not have python2.3 (or any other python packages, for that matter) in a looong time. 2.2.92-1exp1 is the version on ftp.debian.org, I don't know whether the test suite was even run back then, there's no test-suite output in /usr/share/doc/python2.3 at least. So it could be nobody tried to run the test-suite before, dunno :-/ > > As the tests get removed in the package building later on anyway, > > perhaps it can be avoided to byte-compile them at all? > > byte-compiling at this time should be done for qa during package build > time. I'll skip this for the test directories in the next build. Great, thanks. Alternatively, I could provide a patch to just remove those tests after the check target and before installation on hurd-i386. But then, these failures should be investigated anyway. I just don't know whether I'll have the time in the near future. Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html
