Some test fail on my new Python 2.6

Wed Apr 8 13:15:26 EDT 2009

Sorin Schwimmer <sxn02 at yahoo.com> wrote:
> 
> Thanks for the pointers.
> 
> Here are some answers:
> 
> > Ok, so DBM wasn't built because it couldn't find the external symbol
> > 'dbm_firstkey'.  I have no idea off the top of my head why that would
> > happen, but I don't think you really care at the moment since you are
> > trying to get tkinter working.  If you do care we can come back to that.
>
> Although I can live without it, I do use sometime dbm. And then, again,
> there are other ways to accomplish the same, so it's not critical.

OK, so we'll come back to it later.

> >> *** WARNING: renaming "_tkinter" since importing it failed: libtk8.5.so: cannot open shared object file: No such file or directory
>
> > Now, this one is clear.  It couldn't find libtk8.5.so when it tried to
> > use _tkinter.so.  So either that symlink doesn't exist, or points to a
> > nonexistent library, or there's something wrong with your load library
> > path, so that python isn't finding it when it tries to do the load.
> > If you don't know what that last one means, check out 'man ldconfig'.
> 
> # pwd
> /usr/local/lib
> # ls
> libpq.so.4    libtcl8.4.so  libtclstub8.4.a  libtk8.4.so  libtkstub8.4.a  python2.4  tcl8.4  tclConfig.sh  tk8.5
> libpq.so.4.0  libtcl8.5.so  libtclstub8.5.a  libtk8.5.so  libtkstub8.5.a  tcl8       tcl8.5  tk8.4         tkConfig.sh
> 
> It's there!

Well, there is _something_ there.  Maybe it's a symbolic link that
doesn't point anywhere?  Do ls -l, and/or 'file' on it just to check.
The above message is what you would get if it were a symbolic link
that didn't point anywhere valid.

Oh, and make sure /usr/local/lib is in your /etc/ld.so.conf file.  If
it isn't, then that's your problem.  If you need to update that
file I'm pretty sure you need to run ldconfig afterwards.

> >> test_multiprocessing
> >> test_multiprocessing skipped -- OSError raises on RLock creation, see issue 3111!
> > According to the referenced bug, this may be a result of your not having
> > /dev/shm mounted, but in any case it is more a bug in the tests than a
> > bug in your system or setup.
> 
> # mount
> /dev/hda3 on / type reiserfs (rw,noatime)
> proc on /proc type proc (rw)
> sysfs on /sys type sysfs (rw)
> udev on /dev type tmpfs (rw,nosuid)
> devpts on /dev/pts type devpts (rw)
> shm on /dev/shm type tmpfs (rw,noexec,nosuid,nodev)
> usbfs on /proc/bus/usb type usbfs (rw,devmode=0664,devgid=85)
> 
> It's there, but if it is about a known bug in the test, maybe we should just ignore it?

Yeah.  Or download 2.6.2c1 and see if that has the same problem.  The bug
doesn't say that it was fixed in 2.6.2, and the conditional skip is
still there in the test, but I know Jesse was doing work in that area,
so it might get past it on 2.6.2.

On the other hand, if you aren't using multiprocessing you don't need
to worry about it.

> >> test_socket
> >> test test_socket failed -- Traceback (most recent call last):
> >>   File "/install/Python-2.6.1/Lib/test/test_socket.py", line 474, in testSockName
> >>     my_ip_addr = socket.gethostbyname(socket.gethostname())
> >> gaierror: [Errno -2] Name or service not known
> > This probably means that you haven't properly defined 'localhost'
> > in your /etc/hosts file.
> 
> # cat /etc/hosts
> # /etc/hosts
> #
> # This file describes a number of hostname-to-address
> # mappings for the TCP/IP subsystem.  It is mostly
> # used at boot time, when no name servers are running.
> # On small systems, this file can be used instead of a
> # "named" name server.  Just add the names, addresses
> # and any aliases to this file...
> #
> 
> 127.0.0.1       localhost
> # IPV6 versions of localhost and co
> ::1 ip6-localhost ip6-loopback
> fe00::0 ip6-localnet
> ff00::0 ip6-mcastprefix
> ff02::1 ip6-allnodes
> ff02::2 ip6-allrouters
> ff02::3 ip6-allhosts
> 
> 
> There is a localhost definition. Is it not correct?

Yes, but...I just did the functions on my own machine and got this:

    Python 2.6.1 (r261:67515, Mar 26 2009, 08:03:17) 
    [GCC 4.1.2 (Gentoo 4.1.2)] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import socket
    >>> socket.gethostname()
    'partner'
    >>> socket.gethostbyname('partner')
    '127.0.0.1'

So I suspect that you need to add your hostname to the 'localhost' line in
order to get that test to pass.  Mine looks like this:

    127.0.0.1       partner.bitdance.com partner localhost

I'm inclined to call that a bug in the tests.  You could file a bug
report if you feel so moved :)

> >> test_sys
> >> test test_sys failed -- Traceback (most recent call last):
> >>   File "/install/Python-2.6.1/Lib/test/test_sys.py", line 354, in test_43581
> >>     self.assert_(sys.__stdout__.encoding == sys.__stderr__.encoding)
> >> AssertionError
> > This one is puzzling.  Did you modify 'site.py'?  Or perhaps you
> > redirected stdout and stderr to different places and they
> > wound up with different encodings for some reason.  In which
> > case that one would be a bug in the tests as well.
> 
> No, I didn't, nor have I done anything with stdout, stderror. When I ran the test, I did a make test | tee test.rez, which in my mind should have been harmless.

Ah, but that does redirect stdout and not stderr.  stdout goes into the
pipe, and thence to 'tee', which writes one copy of the input lines to
stdout and one to the file.  Not sure what python would see as stdout
at that point, but I wouldn't be surprised if that was the source of
the problem (and that means that the test is a little fragile).  If you
rerun that test in verbose mode without the pipe into tee, does it pass?

> The output for individual test_httpservers was posted here:
> http://mail.python.org/pipermail/python-list/2009-April/708041.html

Hmm.  These puzzle me.

The first one is failing because for some reason the code is able to
read a file that has been chmoded to have no access.  Did you run the
tests as root, by any chance?

The rest of them might be failing because 'sys.executable' isn't
pointing at the actual instance of the python command for some reason.
If you do 'import sys; print sys.executable' what does it say?

But I'd think you'd see other failures in that case, so it might be
something else.  The bottom line is that the little script files that the
test writes are not returning anything for some reason.

If you want to debug this one further we may have to start sticking
prints into the tests and things like that.

--
R. David Murray             http://www.bitdance.com

PS: 'issue 3111' means issue number 3111 on the Python bug
tracker at http://bugs.python.org.