Martin v. Löwis wrote:

"Brett C." writes:

...

And after I updated my copy of CVS and tried out the patch for tzset detection as mentioned above I got a failure in test_pep277.py (only difference between CVS and my checkout is configure.in and only in the tzset code and regrtest.py):

That would be most likely due to Just's activating supports_unicode_filenames in posixpath.py.

That seems to be correct. Unfortuanately I have no time to look into this, as I'm leaving tomorrow for a trip. Jack is also away (until the 22nd). Is anyone left on python-dev with an OSX box? Just

Skip Montanaro writes:

Yeah, me. I can't do anything this evening, but can look at it tomorrow. What's the bug id?

No bug id: test_pep277 fails. Regards, Martin

[Skip, test_pep277.py]

... This seems better:

Not with hard tab characters it ain't <wink>.

def test_listdir(self): import sys f1 = os.listdir(test_support.TESTFN) f1.sort() f2 = os.listdir(unicode(test_support.TESTFN, sys.getfilesystemencoding())) f2.sort() print f1 print f2

If someone with ready access to a Windows machine can try that change tonight I'll check it in, otherwise it will have to wait until I'm at work tomorrow morning.

Caution: if someone does this, say which version of Windows you used. This entire test file is skipped on Win95/98/ME, so a report of "no problem" from one of those won't help. I'll try it on Win2K tomorrow (I won't have access to Win2K until then).

Skip Montanaro writes:

I suspect details.filename needs to be set to a unicode object, but I don't know where or how.

I see. You should revert Just's checkin of setting supports_unicode_filenames in posixpath.py. OSX doesn't. On Windows, posixmodule.c uses posix_error_with_unicode_filename, which recreates a Unicode object, whereas on Unix (including OSX) posix_error_with_filename is used, which puts the converted byte string into the exception. This is clearly brain-dead: AFAICT, in all cases, we are putting a basestring object into the exception essentially denoting a file name which we already have a Python object for. So this entire error handling should be changed to a new posix_error_with_basestring_filename, which would pass the original Python object that the user was providing, instead of creating new strings for the exception. However, this would be a significant rewrite of the entire error handling, which we can't do before 2.3. Regards, Martin

On Tue, 2003-07-22 at 15:20, Brett C. wrote:

This bug is still open. Skip and I have verified it works on OS X, but it *really* needs to be tested on a Red Hat 6.2 box.

We may just be SOL here. No one at Pylabs has an installed copy of RH that old, and if no one here on python-dev steps up, there's not much we can do. This late in the game I'm inclined to postpone the patch unless we can find someone to test it. Even a patch that does no harm on existing systems isn't of much use if we can't verify that it fixes the bug. there's-always-2.3.1-ly y'rs, -Barry

On Tue, 22 Jul 2003 12:41:34 -0700, Jordan Krushen wrote:

I'm currently bored at work, so I'm downloading a 6.2 ISO to run in VMware, if that's acceptable for testing purposes. Just let me know exactly what to test, and I should be able to do that today.

On a freshly-installed RedHat 6.2 VMware box (./configure, make, make test) : test_time test test_time failed -- Traceback (most recent call last): File "/var/src/Python-2.3c1/Lib/test/test_time.py", line 107, in test_tzset self.failUnless(time.tzname[1] == 'AEDT', str(time.tzname[1])) File "/var/src/Python-2.3c1/Lib/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: AEST 1 test failed: test_time 29 tests skipped: test_aepack test_al test_bsddb test_bsddb185 test_bsddb3 test_cd test_cl test_curses test_email_codecs test_gl test_imgfile test_largefile test_linuxaudiodev test_macfs test_macostools test_mpz test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sunaudiodev test_timeout test_urllibnet test_winreg test_winsound 2 skips unexpected on linux2: test_bsddb test_mpz J.

Jordan Krushen wrote:

On Tue, 22 Jul 2003 13:50:39 -0700, Jordan Krushen wrote:

...

On a freshly-installed RedHat 6.2 VMware box (./configure, make, make test) :

1 test failed: test_time

After patching with tzset4.diff and running autoreconf (after installing autoconf 2.57):

1 test failed: test_time

After patching with tzset_AEST.diff and running autoreconf:

1 test failed: test_time

No luck.

Thanks for the help, Jordan. Looks like the patch doesn't do the trick. -Brett

Brett> This bug is still open. Skip and I have verified it works on OS Brett> X, but it *really* needs to be tested on a Red Hat 6.2 box. The thought occurred to me the other day that we ought to have a table on the website (probably on the Wiki) where people can list the kind of systems they have ready access to if they are willing to help with some tests. It would make it easier to locate people who can "configure ; make ; make test" on more obscure platforms. I'll set something up and let people know where it is. If folks on this list think it's a bad idea, I can easily dump the page. Skip

[Skip]

...

The thought occurred to me the other day that we ought to have a table on the website (probably on the Wiki) where people can list the kind of systems they have ready access to if they are willing to help with some tests. It would make it easier to locate people who can "configure ; make ; make test" on more obscure platforms.

Hm, what happened to the snake-farm at Lysator? Aren't they supposed to do exactly this? Is Neal around? I think he's our official rep there. --Guido van Rossum (home page: http://www.python.org/~guido/)

On Tue, Jul 22, 2003 at 04:04:24PM -0400, Neal Norwitz wrote:

RedHat 6.2 isn't in the snake farm. Right now, things are in pretty good shape on the snake farm builds (I watch them on a regular basis).

Whoops, I lied. The snake-farm does have RedHat 6.2 that runs on an Alpha. test_time fails on it, as does test_grp, test_pwd, and test_struct in my builds. In the automated builds, only test_grp and test_time fail. I'll see what I can do about these, but I'm leaving for vacation tomorrow. Be back Sunday. Neal

Neal Norwitz wrote:

The patch below fixes test_time on RedHat 6.2/Alpha. Since I don't understand the code, I haven't the slighest clue if the patch is correct or not. But I do know what (365 * 24 * 3600) is. :-) I don't know what ((365 * 24 + 6) * 3600) is supposed to represent. 1 year + 6 hours in seconds. What's that?

And why does ``t = (time((time_t *)0) / YEAR) * YEAR;`` on line 608 have to divide by YEAR and then multiply by YEAR? Shouldn't those cancel out? The idea seeems reasonable if you stare at the code since the division might be causing the time_t to wrap around the year when it divides by 2 and thus get the wrong part of the year. But as Neal said I would defer to Stuart for saying whether this is a good fix or not. -Brett

Guido van Rossum wrote:

...

And why does ``t = (time((time_t *)0) / YEAR) * YEAR;`` on line 608 have to divide by YEAR and then multiply by YEAR? Shouldn't those cancel out?

I guess it should have used // instead of /. (X//Y)*Y is a standard way to round X down to a whole multiple of Y, and I presume that's what the code here does.

Didn't know C had a flooring divide operator. Good to know. -Brett

Tim Peters wrote:

[Brett]

...

...

...

And why does ``t = (time((time_t *)0) / YEAR) * YEAR;`` on line 608 have to divide by YEAR and then multiply by YEAR? Shouldn't those cancel out?

[Guido]

...

...

I guess it should have used // instead of /. (X//Y)*Y is a standard way to round X down to a whole multiple of Y, and I presume that's what the code here does.

[Brett]

...

Didn't know C had a flooring divide operator. Good to know.

It doesn't. If Guido were still my boss, I'd say he was pulling your leg. But since he left us, I'll just diplomatically say he's an idiot <wink>.

=) But he is still your BDFL so be careful how to tread, Tim. =)

If dividend and divisor are both positive and integer, C's / is flooring division.

That's what I figured. Although isn't that assuming time_t is an int or long or something? But the entire chunk of code seems to assuming that so what is one more spot of code. =) -brett

Quothe Neal Norwitz , on Tue, Jul 22, 2003:

I don't know what ((365 * 24 + 6) * 3600) is supposed to represent. 1 year + 6 hours in seconds. What's that?

I know nothing about this code, but it would make sense to assume that the extra + 6 hours was intended to account for leap years, 6 * 4 == 24 hours, or 1 extra day every 4 years. Dave -- 454e4420434f4d4d554e49434154494f4e <a href="http://sco.iwethey.org">SCO</a>

On Wednesday, July 23, 2003, at 08:42 AM, Neal Norwitz wrote:

The patch below fixes test_time on RedHat 6.2/Alpha. Since I don't understand the code, I haven't the slighest clue if the patch is correct or not. But I do know what (365 * 24 * 3600) is. :-) I don't know what ((365 * 24 + 6) * 3600) is supposed to represent. 1 year + 6 hours in seconds. What's that?

I've copied Stuart Bishop on this message as I believe he wrote all this code. The patches in http://python.org/sf/762934 haven't made the tests pass.

I'm following this thread (from an out of sync timezone). I didn't change much in timemodule.c - I just shuffled some things around a bit and added the tzset function (see the comment at the start of inittimezone()). I don't know why YEAR is defined as 365 days + 6 hours either. I think it is there to account for leap years as others have mentioned. It would be interesting to see what happens if a Redhat6.2 user runs test_time.py with 'xmas2002 = 1040774400.0' changed to 'xmas2002 = 914508000.0' in case it is a Y2K bug we only just noticed :-) I can't see why removing the '+6' would make any difference at all, unless your OS doesn't understand leap years and your DST changeovers are ±8 days of 1st Jan or 1 Jul (which is not the case for the AEST/AEDT timezone being tested). I think the existing algorithm is broken, as it assumes that midnight Jan 1st UTC is always non-DST, and 'around July 1st UTC' always DST in the northern hemisphere (reversing this in the southern hemisphere). I'm sure there is at least one country where this isn't true :-) bcannon's tzset_AEST.diff patch can be improved (it doesn't check if the system believes the whole year is entirely in DST). It also needs to do the following: time_t midyear = xmas - (365 * 24 * 3600 / 2); if (strcmp(localtime(&midyear)->tm_zone, "AEST")) exit(1); I'll make a patch when anon-cvs gets back up, unless someone beats me to it.

I'm not real comfortable including this in 2.3. Although the worst that should happen is that it gives incorrect results (which may very well be happening now).

-- Stuart Bishop http://shangri-la.dropbear.id.au/

Stuart Bishop writes:

On Wednesday, July 23, 2003, at 08:42 AM, Neal Norwitz wrote:

...

The patch below fixes test_time on RedHat 6.2/Alpha. Since I don't understand the code, I haven't the slighest clue if the patch is correct or not. But I do know what (365 * 24 * 3600) is. :-) I don't know what ((365 * 24 + 6) * 3600) is supposed to represent. 1 year + 6 hours in seconds. What's that?

I've copied Stuart Bishop on this message as I believe he wrote all this code. The patches in http://python.org/sf/762934 haven't made the tests pass.

I'm following this thread (from an out of sync timezone).

[...]

bcannon's tzset_AEST.diff patch can be improved (it doesn't check if the system believes the whole year is entirely in DST). It also needs to do the following:

time_t midyear = xmas - (365 * 24 * 3600 / 2);

if (strcmp(localtime(&midyear)->tm_zone, "AEST")) exit(1);

I'll make a patch when anon-cvs gets back up, unless someone beats me to it.

Further testing on RH Linux 6.2 and a revised patch: [kbk@float ~/PYSRC]$ ./python Python 2.3c2 (#15, Jul 24 2003, 11:17:16) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 Type "help", "copyright", "credits" or "license" for more information.

...

...

import time from os import environ victoria = 'AEST-10AEDT-11,M10.5.0,M3.5.0' environ['TZ'] = victoria time.tzset() time.tzname ('AEST', 'AEST')

=========================================================== Hm!! Try a couple of things to try to see what's going on: ===========================================================

...

victoria2 = 'AEST-10AEDT-11' environ['TZ'] = victoria2 time.tzset() time.tzname ('AEST', 'AEDT')

# try reversing the changeover ... victoria3 = 'AEST-10AEDT-11,M3.5.0,M10.5.0' environ['TZ'] = victoria3 time.tzset() time.tzname ('AEST', 'AEDT')

=================================== ok, debug inittimezone: =================================== Breakpoint 1, inittimezone (m=0x4014053c) at /home/kbk/PYTHON/python/dist/src/Modules/timemodule.c:608 608 t = (time((time_t *)0) / YEAR) * YEAR; (gdb) n 609 p = localtime(&t); (gdb) p asctime(localtime(&t)) $14 = 0x4013be00 "Wed Jan 1 16:00:00 2003\n" (gdb) p localtime(&t)->tm_zone $19 = 0x8162b78 "AEST" [std time on Jan 1!! ...back up a day or so....] (gdb) p t = t - 84000 $20 = 1041316800 (gdb) p localtime(&t)->tm_zone $21 = 0x8162b90 "AEDT" (gdb) p asctime(localtime(&t)) $22 = 0x4013be00 "Tue Dec 31 17:40:00 2002\n" (gdb) ============================================================= so Linux6.2 thinks AEDT switches to AEST in Jan, and six months forward is still AEST. xmas2002 is AEDT so config test passes but timemodule uses Jan 1 and flubs when setting tzname. Need to do the config test later than xmas. ============================================================== ****** Apply Patch SF 762934 configure.in.patch.kbk ******* ============================================= autoreconf && ./configure && make clean && make OPT=-g ============================================== extract from configure log: .... checking for broken nice()... yes checking for working tzset()... no checking for tv_nsec in struct stat... no checking whether mvwdelch is an expression... yes .... ============================================= [kbk@float ~/PYSRC]$ ./python Python 2.3c2 (#18, Jul 24 2003, 22:40:09) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 Type "help", "copyright", "credits" or "license" for more information.

...

...

from test import test_time test_time.test_main() test_asctime (test.test_time.TimeTestCase) ... ok test_clock (test.test_time.TimeTestCase) ... ok test_conversions (test.test_time.TimeTestCase) ... ok test_data_attributes (test.test_time.TimeTestCase) ... ok test_sleep (test.test_time.TimeTestCase) ... ok test_strftime (test.test_time.TimeTestCase) ... ok test_strptime (test.test_time.TimeTestCase) ... ok test_tzset (test.test_time.TimeTestCase) ... ok

---------------------------------------------------------------------- Ran 8 tests in 2.523s OK

...

...

================================================ make test: ================================================ .... .... test_zlib 227 tests OK. 28 tests skipped: test_aepack test_al test_bsddb185 test_bsddb3 test_cd test_cl test_curses test_email_codecs test_gl test_imgfile test_largefile test_linuxaudiodev test_macfs test_macostools test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sunaudiodev test_timeout test_unicode_file test_urllibnet test_winreg test_winsound Those skips are all expected on linux2. [kbk@float ~/PYSRC]$ -- KBK

On Tue, Jul 22, 2003 at 04:04:24PM -0400, Neal Norwitz wrote:

On Tue, Jul 22, 2003 at 03:45:20PM -0400, Guido van Rossum wrote:

...

[Skip]

...

...

The thought occurred to me the other day that we ought to have a table on the website (probably on the Wiki) where people can list the kind of systems they have ready access to if they are willing to help with some tests. It would make it easier to locate people who can "configure ; make ; make test" on more obscure platforms.

Hm, what happened to the snake-farm at Lysator? Aren't they supposed to do exactly this? Is Neal around? I think he's our official rep there.

Here. I was thinking Skip's idea would be bad since I'll be listed for a bunch of platforms. :-)

RedHat 6.2 isn't in the snake farm. Right now, things are in pretty good shape on the snake farm builds (I watch them on a regular basis).

Unfortunately, some of the problems deal with minor OS variations (like a specific patching being applied or not), so even having the "same" version of th OS isn't always enough.

I have access to the following systems: RedHat: 8, 9 Solaris: 8 AIX: 4.2.1.0, 4.3.1.0, 4.3.3.0 HPUX: 11.00 A IRIX: 6.5 DecUNIX, OSF/1, Tru64: 5.0, 5.1

Neal- I have an old SGI Indigo box that's running an ancient version of IRIX (I know it is 5.x, but it *may* be 4.x). Would you like to have it to look over? ;-) Jokingly (I think it only has a 800Mb disk!), -c -- 18:10:00 up 67 days, 7:45, 8 users, load average: 0.18, 0.24, 0.20

Brett> This bug is still open. Skip and I have verified it works on OS Brett> X, but it *really* needs to be tested on a Red Hat 6.2 box. Skip> The thought occurred to me the other day that we ought to have a Skip> table on the website (probably on the Wiki) where people can list Skip> the kind of systems they have ready access to if they are willing Skip> to help with some tests. Barry> +1. It also tells us which systems people care about <wink>. Okay, the minimal beginning is at http://www.python.org/cgi-bin/moinmoin/PythonTesters Feel free to add rows to the table. Skip

>> I'll set something up and let people know where it is. If folks on >> this list think it's a bad idea, I can easily dump the page. Fred> I think this is a good idea. Please put it in the dev/ area on Fred> the site; it should probably just be a .ht file in the pydotorg Fred> CVS. Well, my intent was to put it in the Wiki. I certainly don't want to be the rate-limiting factor in getting peoples' info in the table. Fred> Any chance you're going to move your 404 report to dev/pydotorg/? Fred> ;-) Sure. Skip

"Brett C." writes:

Brett C. wrote:

...

Just a quick reminder, I am going off for a vacation and my brother's wedding tomorrow (July 13) and won't have a definite Net connection until July 22.

OK, I am back with vacation having gained a sister-in-law and possible housing in San Luis Obispo.

...

The bug #762934 (patch for configure.in to detect time.tzset better) is still open. I uploaded my own version of the patch that is more explicit in detecting whether the function works properly. It works for me, but tzset has always worked properly for me. If someone with Red Hat 6.2 can test it that would be great (that will close bug #763153).

This bug is still open. Skip and I have verified it works on OS X, but it *really* needs to be tested on a Red Hat 6.2 box.

Hang on... I think the starship is RH 6.2... yep. I'll build and see what happens (tho' it's possible glibc or whatever has been upgraded). Cheers, M. -- Unfortunately, nigh the whole world is now duped into thinking that silly fill-in forms on web pages is the way to do user interfaces. -- Erik Naggum, comp.lang.lisp

"Phillip J. Eby" writes:

IIRC, it might be me who opened this bug in the first place, so of course I have a machine suitable for the test. :)

Doesn't look like it.

In any case, my 'make test' of 2.3c1 fails with the test_time AEST thingy. If someone will once again give me step-by-step instructions for what they want done, I'll test it again.

Well, test_time fails for me on the starship seeminly no matter waht I do (i.e. just check out from CVS or apply either of the patches mentioned in the report). This may be pilot error. Home time here. Various other locals have starship accounts, though (note you'll need to install autoconf 2.53 in ~/bin). Cheers, mwh -- Java sucks. [...] Java on TV set top boxes will suck so hard it might well inhale people from off their sofa until their heads get wedged in the card slots. --- Jon Rabone, ucam.chat

Kurt B. Kaiser wrote:

Michael Hudson writes:

...

Well, test_time fails for me on the starship seeminly no matter waht I do (i.e. just check out from CVS or apply either of the patches mentioned in the report). This may be pilot error.

Redhat 6.0 + libc.so.6 2.1.3 autoconf 2.53

Using 2.3c1, no patch:

test_time test test_time failed -- Traceback (most recent call last): File "/home/kbk/PYTHON/python/dist/src/Lib/test/test_time.py", line 107, in test_tzset self.failUnless(time.tzname[1] == 'AEDT', str(time.tzname[1])) File "/home/kbk/PYTHON/python/dist/src/Lib/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: AEST

====================== Apply patch 55665: tzset_AEST.diff 2003-7-12 18:01 bcannon:

=========================== What have I done??

Did you run autoreconf? That is an important step since it regenerates configure from the patch file. -Brett

"Brett C." writes:

Did you run autoreconf? That is an important step since it regenerates configure from the patch file.

==================== autoreconf ./configure make make install ==================== [kbk@float ~/PYSRC]$ lsl config* -rw-r--r-- 1 kbk users 105368 Jul 22 17:55 config.log -rwxr-xr-x 1 kbk users 52705 Jul 22 17:55 config.status* -rw-r--r-- 1 kbk users 13585 Jul 22 17:12 config22Jul03.log -rw-r--r-- 1 kbk users 13546 Jul 22 17:55 config22Jul03b.log -rwxr-xr-x 1 kbk users 502876 Jul 22 17:52 configure* -rw-r--r-- 1 kbk users 82844 Jul 22 17:07 configure.in [kbk@float ~/PYSRC]$ python2.3 -c "from test import test_time;

test_time.test_main()" test_asctime (test.test_time.TimeTestCase) ... ok test_clock (test.test_time.TimeTestCase) ... ok test_conversions (test.test_time.TimeTestCase) ... ok test_data_attributes (test.test_time.TimeTestCase) ... ok test_sleep (test.test_time.TimeTestCase) ... ok test_strftime (test.test_time.TimeTestCase) ... ok test_strptime (test.test_time.TimeTestCase) ... ok test_tzset (test.test_time.TimeTestCase) ... FAIL

====================================================================== FAIL: test_tzset (test.test_time.TimeTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib/python2.3/test/test_time.py", line 107, in test_tzset self.failUnless(time.tzname[1] == 'AEDT', str(time.tzname[1])) File "/usr/local/lib/python2.3/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: AEST ---------------------------------------------------------------------- Ran 8 tests in 2.094s FAILED (failures=1) Traceback (most recent call last): File "<string>", line 2, in ? File "/usr/local/lib/python2.3/test/test_time.py", line 125, in test_main test_support.run_unittest(TimeTestCase) File "/usr/local/lib/python2.3/test/test_support.py", line 262, in run_unittest run_suite(suite, testclass) File "/usr/local/lib/python2.3/test/test_support.py", line 247, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "/usr/local/lib/python2.3/test/test_time.py", line 107, in test_tzset self.failUnless(time.tzname[1] == 'AEDT', str(time.tzname[1])) File "/usr/local/lib/python2.3/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: AEST [kbk@float ~/PYSRC]$ lsl `which python2.3` -rwxr-xr-x 2 root root 2506493 Jul 22 18:03 /usr/local/bin/ python2.3* [kbk@float ~/PYSRC]$ lsl /usr/local/lib/python2.3/test/test_time.p* -rw-r--r-- 1 root root 4651 Jul 22 18:03 /usr/local/lib/pyth on2.3/test/test_time.py -rw-r--r-- 1 root root 5216 Jul 22 18:05 /usr/local/lib/python2 .3/test/test_time.pyc -rw-r--r-- 1 root root 5216 Jul 22 18:06 /usr/local/lib/python2 .3/test/test_time.pyo -- KBK

"Brett C." writes:

Nuts. Well, then I am stumped on how to fix this tzset problem. The damn autoconf code should have failed and thus time.tzset should not have been compiled.

Any suggestions?

Not worrying about it too much? Cheers, mwh -- All parts should go together without forcing. You must remember that the parts you are reassembling were disassembled by you. Therefore, if you can't get them together again, there must be a reason. By all means, do not use a hammer. -- IBM maintenance manual, 1925

On Wed, 2003-07-23 at 14:58, Brett C. wrote:

Yeah, I am there in terms of getting this done in time for 2.3 . If it takes this much effort for people to dig up a RH 6.2 system I suspect most people have upgraded by now. I don't think we are going to get a thorough enough of a testing of this patch so I am going to stop worrying about this and redirect it to worrying about moving in a month.

+1, or really +0.0.1 :) there's-always-2.3.1-ly y'rs, -Barry

Michael Hudson writes:

This may be pilot error.

And after I woke up and ran make install I got what appears to be the same thing, though I got it a little faster :-) [kbk@float ~/PYSRC]$ python2.3 -c "from test import test_time;

test_time.test_main() " test_asctime (test.test_time.TimeTestCase) ... ok test_clock (test.test_time.TimeTestCase) ... ok test_conversions (test.test_time.TimeTestCase) ... ok test_data_attributes (test.test_time.TimeTestCase) ... ok test_sleep (test.test_time.TimeTestCase) ... ok test_strftime (test.test_time.TimeTestCase) ... ok test_strptime (test.test_time.TimeTestCase) ... ok test_tzset (test.test_time.TimeTestCase) ... FAIL

====================================================================== FAIL: test_tzset (test.test_time.TimeTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib/python2.3/test/test_time.py", line 107, in test_tzset self.failUnless(time.tzname[1] == 'AEDT', str(time.tzname[1])) File "/usr/local/lib/python2.3/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: AEST ---------------------------------------------------------------------- Ran 8 tests in 2.206s FAILED (failures=1) Traceback (most recent call last): File "<string>", line 2, in ? File "/usr/local/lib/python2.3/test/test_time.py", line 125, in test_main test_support.run_unittest(TimeTestCase) File "/usr/local/lib/python2.3/test/test_support.py", line 262, in run_unittest run_suite(suite, testclass) File "/usr/local/lib/python2.3/test/test_support.py", line 247, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "/usr/local/lib/python2.3/test/test_time.py", line 107, in test_tzset self.failUnless(time.tzname[1] == 'AEDT', str(time.tzname[1])) File "/usr/local/lib/python2.3/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: AEST -- KBK

Jack> It turns out Brett was using an ucs4 build of Python, and the bug Jack> is related to that.... Dumb-ass question: What's a "ucs4 build of Python" and how does one create such a thing? I see no mention of ucs4 in the output from configure --help. Thx, Skip

On Tue, Jul 22, 2003 at 04:17:09PM -0500, Skip Montanaro wrote:

Jack> It turns out Brett was using an ucs4 build of Python, and the bug Jack> is related to that....

Dumb-ass question: What's a "ucs4 build of Python" and how does one create such a thing? I see no mention of ucs4 in the output from configure --help.

./configure --enable-unicode=ucs4 (Necessary for Tkinter on RH 9)

On Tue, 2003-07-22 at 17:25, Brett C. wrote:

Picked this up from Barry in an email to the list once and figured it sounded like a good idea.

Heh, I only need to do this so tkinter works on RH9. ;) -Barry