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
mbanck@debian.org
http://www.advogato.org/person/mbanck/diary.html