[Python-bugs-list] [ python-Bugs-712322 ] test_zipimport failing on ia64 (at least)
SourceForge.net
noreply@sourceforge.net
Mon, 07 Apr 2003 08:06:27 -0700
Bugs item #712322, was opened at 2003-03-30 15:32
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=712322&group_id=5470
Category: Extension Modules
Group: Python 2.3
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
>Assigned to: Just van Rossum (jvr)
Summary: test_zipimport failing on ia64 (at least)
Initial Comment:
test_zipimport is failing on the snake-farm. I'm
pretty sure this test worked before. The only
difference is the file ends in .py vs. .pyc. I don't
know what changed recently which would have cause this.
http://www.lysator.liu.se/xenofarm/python/files/454_3/python-testlog.txt
test test_zipimport failed -- Traceback (most recent
call last):
File
"/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/Lib/test/test_zipimport.py",
line 108, in testBoth
self.doTest(pyc_ext, files, TESTMOD)
File
"/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/Lib/test/test_zipimport.py",
line 66, in doTest
self.assertEquals(file, os.path.join(TEMP_ZIP,
File
"/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/Lib/unittest.py",
line 292, in failUnlessEqual
raise self.failureException, \
AssertionError:
'/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/junk95142.zip/ziptestmodule.py'
!=
'/usr/local/xenofarm/python/soyokaze.roxen.com/buildtmp/dist/python/dist/src/junk95142.zip/ziptestmodule.pyc'
----------------------------------------------------------------------
>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-07 11:06
Message:
Logged In: YES
user_id=33168
I agree, let's do the -1 now. I'll check in later, unless
Just beats me to it.
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2003-04-07 10:36
Message:
Logged In: YES
user_id=31435
Setting tm_isdst to -1 does fix the test on Windows, now that
it's DST here. I can't say whether it would also have left the
test working before DST kicked in yesterday, but am happy
to assume that it would: with any luck, I'll die before October,
and then fixing it on Windows will be somebody else's
headache <wink>.
----------------------------------------------------------------------
Comment By: Just van Rossum (jvr)
Date: 2003-04-07 02:07
Message:
Logged In: YES
user_id=92689
Glad we didn't fix it sooner, then ;-)
Can you verify whether changing
tm_isdst = 0;
to
tm_isdst = -1;
(somewhere in zipimport.c)
Helps on Windows, too?
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2003-04-06 20:01
Message:
Logged In: YES
user_id=31435
Noting that DST began in the USA this morning, and
test_zipimport started failing on Windows immediately
after. I don't know what will work across all platforms, but
you've got ample evidence that what's there now will
eventually fail on all platforms <wink>.
----------------------------------------------------------------------
Comment By: Just van Rossum (jvr)
Date: 2003-04-06 06:54
Message:
Logged In: YES
user_id=92689
How do we proceed on this one? Shall I just check this change in, and we'll see what happens on other platforms?
----------------------------------------------------------------------
Comment By: Just van Rossum (jvr)
Date: 2003-04-02 03:26
Message:
Logged In: YES
user_id=92689
It sure works for OSX!
----------------------------------------------------------------------
Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-01 15:34
Message:
Logged In: YES
user_id=33168
Changing the tm_isdst to -1 fixed the problem on HPUX. I'm
not sure if this will work on all platforms. -1 means
mktime should guess whether DST is in effect or not. 0
means it's never DST. I can see problems with any value.
Perhaps there's some zip documentation which describes what
should be done? Or perhaps the time (dostime, dosdate) are
encoded incorrectly?
----------------------------------------------------------------------
Comment By: Just van Rossum (jvr)
Date: 2003-04-01 14:28
Message:
Logged In: YES
user_id=92689
Found the cause: daylight saving. I think it's a mismatch between zipfile.py's handling of time and zipimport.c's.
I just tested with a manually created zip file and the same problem occurs, so I'm fairly sure the problem is with zipimport's parse_dostime(). The effbot wrote that one for me, but perhaps someone else with the necessary time.h expertise can advise what's wrong?
----------------------------------------------------------------------
Comment By: Just van Rossum (jvr)
Date: 2003-04-01 13:23
Message:
Logged In: YES
user_id=92689
Ah, duh, it even fails on OSX, so I can do some research myself.
Wild guess: are the other failing boxes also big endian machines?
----------------------------------------------------------------------
Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-01 11:05
Message:
Logged In: YES
user_id=33168
This test is now failing on most unixes. AIX, HPUX and
others I think. I tried building some older versions from
3/1, 2/20, etc. but the problem persists. Even though I
thought those versions worked at the time. This will take
some time to look into further. Assigning to me, but
hopefully someone else who also sees this problem can help.
----------------------------------------------------------------------
Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-31 09:32
Message:
Logged In: YES
user_id=33168
Yes, I believe it worked more recently, but I could be
wrong... I checked out source from 3/20 and that still
fails, so I have to keep going back until I find exactly
where it failed. I'll keep trying too.
----------------------------------------------------------------------
Comment By: Just van Rossum (jvr)
Date: 2003-03-31 09:22
Message:
Logged In: YES
user_id=92689
dict order should not have relevance to the test. I currently have no idea what could have caused it, and zipimport.c itself hasn't been changed significantly in a while. I see in the logs that in february you fixed some 64-bit issues, but I guess that by "it worked before" you mean something much more recent than that. I'll continue trying to figure out potential causes.
----------------------------------------------------------------------
Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-31 08:33
Message:
Logged In: YES
user_id=33168
It is also broken on AIX which I do have access to. I'm
trying to determine what broke it. One guess is dictionary
order. I'm not sure if the test relies on .pyc being
written before .py as a result of file.items(). It is
broken on 3/26. Unfortunately it takes a very long time to
build on these boxes (hours). Let me know if you have any
idea of what might have recently changed to break zipimports.
----------------------------------------------------------------------
Comment By: Just van Rossum (jvr)
Date: 2003-03-31 02:40
Message:
Logged In: YES
user_id=92689
Then how are we/am I supposed to fix this? Assigning to None.
----------------------------------------------------------------------
Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-30 17:32
Message:
Logged In: YES
user_id=33168
Unfortunately, I don't have access to the boxes where this
is failling. The only possibility would be in the compaq
(hp) test drive machines.
----------------------------------------------------------------------
Comment By: Just van Rossum (jvr)
Date: 2003-03-30 16:03
Message:
Logged In: YES
user_id=92689
Hm, apparently loading from pyc fails. Perhaps a bug with zipimport's pyc magic or mod date checking code?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=712322&group_id=5470