[ python-Bugs-1077302 ] test_macostools failure on OS X

[SourceForge.net]

Bugs item #1077302, was opened at 2004-12-02 15:24
Message generated for change (Comment added) made by webperf
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077302&group_id=5470

Category: Macintosh
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Ian Holsman (webperf)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_macostools failure on OS X

Initial Comment:
hi.. I'm a newbie on this stuff.. just trying to
install the latest & greatest and have come up with
this issue

$ uname -a
Darwin dyn-130-194-244-92.its.monash.edu.au 7.6.0
Darwin Kernel Version 7.6.0: Sun Oct 10 12:05:27 PDT
2004; root:xnu/xnu-517.9.4.obj~1/RELEASE_PPC  Power
Macintosh powerpc

^^10.3.6 Powerbook G4 1.5ghz box

  $ ./configure --prefix=/ex --enable-toolbox-glue
--enable-framework
$ make 
...
$ make test
...
test test__locale failed -- Traceback (most recent call
last):
  File "/python/Python-2.4/Lib/test/test__locale.py",
line 43, in test_lc_numeric
"%s != %s (%s); "
AssertionError: , != . (decimal_point); supposed to be
fr_FR, set to fr_FR

test_aepack
...
test_locale
test_locale skipped -- Locale support on MacOSX is
minimal and cannot be tested
test_logging
test_long
test_long_future
test_longexp
test_macfs
test_macostools
test test_macostools failed -- Traceback (most recent
call last):
  File
"/python/Python-2.4/Lib/test/test_macostools.py", line
78, in test_mkalias_relative
macostools.mkalias(test_support.TESTFN, TESTFN2,
sys.prefix)
  File "/python/Python-2.4/Lib/plat-mac/macostools.py",
line 39, in mkalias
relativefsr = File.FSRef(relative)
Error: (-43, 'File not found')

test_macpath


--

>Comment By: Ian Holsman (webperf)
Date: 2004-12-05 21:05

Message:
Logged In: YES 
user_id=5209

your patch did the trick
Thanks Brett!

--

Comment By: Brett Cannon (bcannon)
Date: 2004-12-05 07:04

Message:
Logged In: YES 
user_id=357491

Aha!  That missing directory is the problem.  If you read the docs on 
what macostools.mkalias does is it creates a Finder shortcut for a 
location.  Well, it fails because it can't make a shortcut to a non-existent 
location.

OK, I have uploaded a patch that basically just checks for sys.prefix's 
existence; if it is missing the test just returns without running.  I figured 
creating the directory would be the improper thing to do since ``make 
install`` will handle that and use specific permissions I didn't want to 
override by having the test create it.

If you can, Ian, apply the patch and let me know if it fixes the issue.

--

Comment By: Ian Holsman (webperf)
Date: 2004-12-04 20:37

Message:
Logged In: YES 
user_id=5209

Python 2.4 (#1, Dec  2 2004, 11:53:05) 
[GCC 3.3 20030304 (Apple Computer, Inc. build 1671)] on darwin
Type "help", "copyright", "credits" or "license" for more
information.

>>> import sys
>>> print sys.prefix 
/Library/Frameworks/Python.framework/Versions/2.4

This directory doesn't exist. the make test uses
DYLD_FRAMEWORK_PATH 

--

Comment By: Brett Cannon (bcannon)
Date: 2004-12-04 09:23

Message:
Logged In: YES 
user_id=357491

The test_shutil failure has already been reported; bug #1076467 and it 
seems to have to do with running as root.

As for the test_macostools failure, lets take this one step at a time.  
What is the value for sys.prefix?  Does that directory exist on your 
machine when you run the test?

--

Comment By: Ian Holsman (webperf)
Date: 2004-12-03 21:46

Message:
Logged In: YES 
user_id=5209

when running the tests as root it fails 3 tests ;(

3 tests failed:
test__locale test_macostools test_shutil
32 tests skipped:
test_al test_bsddb test_bsddb3 test_cd test_cl
test_codecmaps_cn
test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr
test_codecmaps_tw test_curses test_dl test_gdbm test_gl
test_imgfile test_largefile test_linuxaudiodev test_locale
test_nis test_normalization test_ossaudiodev test_pep277
test_poll
test_socket_ssl test_socketserver test_sunaudiodev test_tcl
test_timeout test_urllib2net test_urllibnet test_winreg
test_winsound
1 skip unexpected on darwin:
test_tcl

test_shutil
test test_shutil failed -- Traceback (most recent call last):
  File "/python/Python-2.4/Lib/test/test_shutil.py", line
34, in test_on_error
self.assertEqual(self.errorState, 2)
AssertionError: 0 != 2

test_signal

--

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-12-03 21:30

Message:
Logged In: YES 
user_id=38388

Jurjen, can you put some more context with that ?

What does test_locale have to do with Unicode ?

[ python-Bugs-1077106 ] Negative numbers to os.read() cause segfault

[SourceForge.net]

Bugs item #1077106, was opened at 2004-12-01 21:40
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077106&group_id=5470

Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Jp Calderone (kuran)
Assigned to: Michael Hudson (mwh)
Summary: Negative numbers to os.read() cause segfault

Initial Comment:
Python 2.3.4 (#2, Sep 24 2004, 08:39:09)
[GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import sys, os
>>> stdin = sys.stdin.fileno()
>>> os.read(stdin, 0)
''
>>> os.read(stdin, 0)
''
>>> os.read(stdin, -1)
asdkljasd
'asdk\x01\x00\x00\x00\x00\x00'
>>> os.read(stdin, 100)
Segmentation fault
[EMAIL PROTECTED]:~$

This problem persists in Python 2.4, although the
resulting incorrect behavior differs slightly (at least
on my build), as is to be expected of a memory
corrupting bug.

Note that the value returned from os.read(stdin, -1) is
incorrect in addition to the subsequent read segfaulting.


--

>Comment By: Michael Hudson (mwh)
Date: 2004-12-05 10:30

Message:
Logged In: YES 
user_id=6656

I'm waiting until I'm not behind a modem at my parents' house :)

Tomorrow.

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-12-05 00:39

Message:
Logged In: YES 
user_id=80475

No, I simply tried the OP's example and reported its
behavior on my system.

If you don't want to create a new test file, try adding this
on to test_subprocess.

Yes, I read the patch.  Yes, I forgot you added the
assertion already.

So are you going commit or wait for an engraved invitation?
 

--

Comment By: Michael Hudson (mwh)
Date: 2004-12-04 21:11

Message:
Logged In: YES 
user_id=6656

Hmm.  Did you try a debug build and/or a range of arguments?

Is os.read actually tested anywhere?  I can't find any...

> Also, you could prevent/detect future errors by adding an
> assertion (checking for negative arguments) to
> PyString_FromStringAndSize().

Did you read the patch? 

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-12-04 20:58

Message:
Logged In: YES 
user_id=80475

No doubt it is a clear bug.  My note was just a data point.
 Had I been able to reproduce the error on my machine, I
would have been able to make a test_case and checkin a fix.

So, please, if you can demonstrate the error, go ahead and
check-in a fix with a testcase.

The OSError is probably fine though there is an alternative
of having a ValueError raised immediately after the args are
parsed in the read() method.

Also, you could prevent/detect future errors by adding an
assertion (checking for negative arguments) to
PyString_FromStringAndSize().

--

Comment By: Michael Hudson (mwh)
Date: 2004-12-04 20:38

Message:
Logged In: YES 
user_id=6656

I'm surprised at all this discussion.  It's a clear bug.  The only question is 
what the error message should be.  The attached makes it 

OSError: [Errno 22] Invalid argument

which seems most faithful to what the read() syscall does.

--

Comment By: Gerrit Holl (gerrit)
Date: 2004-12-04 20:13

Message:
Logged In: YES 
user_id=13298

FWIW, another data point, Python 2.4., Linux 2.6.9, Fedora
Core 3:

$ python2.4 t.py < /usr/src/linux/README
Traceback (most recent call last):
  File "t.py", line 3, in ?
os.read(0, -1)
OSError: [Errno 22] Invalid argument
$ python2.4 t.py < /dev/zero
Traceback (most recent call last):
  File "t.py", line 3, in ?
os.read(0, -1)
OSError: [Errno 14] Bad address
$ python2.4 t.py < /dev/urandom
Segmentation fault

Interesting.

--

Comment By: George Yoshida (quiver)
Date: 2004-12-04 11:43

Message:
Logged In: YES 
user_id=671362

On Win2k(Python 2.3.4 & 2.4), I get:
>>> os.read(si, -1)
Traceback (most recent call last):
  File "", line 1, in ?
OSError: [Errno 12] Not enough space

On Linux(SUSE 9.2 & kernel 2.6.5-7.108-smp & gcc 3.3.3) 
in Python 2.4 debug built, I get:

>>>os.read(si, -1)
asd
Debug memory block at address p=0x4024d6b8:
31 bytes originally requested
The 4 pad bytes at p-4 are FORBIDDENBYTE, as expected.
The 4 pad bytes at tail=0x4024d6d7 are not all 
FORBIDDENBYTE
(0xfb):
at tail+0: 0x0a *** OUCH
at tail+1: 0xfb
at tail+2: 0xfb
at tail+3: 0xfb
The block was made by call #10310 to debug 
malloc/realloc.
Data at p: 00 00 00 00 00 00 00 00 ... ff 00 00 00 00 61 
73 64
Fatal Python error: bad trailing pad byte
Aborted

In

[ python-Bugs-1075703 ] PyGILState_Ensure() deadlocks (ver 2.4)

[SourceForge.net]

Bugs item #1075703, was opened at 2004-11-30 01:54
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075703&group_id=5470

Category: Threads
Group: Python 2.4
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Andi Vajda (andivajda)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyGILState_Ensure() deadlocks (ver 2.4)

Initial Comment:
PyLucene (http://pylucene.osafoundation.org) wraps
libgcj with python. Python objects are also wrapped by
java objects. The ref count of the python is
incremented in the wrapping java object constructor and
is decremented in the wrapping java object's finalize()
method. Yes, finalize() is not a reliable means of
cleaning memory up but, so far, I wasn't able to figure
out a better way to do this. The finalize() method runs
in its own libgcj finalizer thread.
It has to acquire the GIL before it can call
Py_DECREF() is my understanding. The java finalize()
calls this code in PyLucene:

void finalizeObject(PyObject *object)
{
#if PY_VERSION_HEX >= 0x0204
PyGILState_STATE state = PyGILState_Ensure();

Py_DECREF(object);
PyGILState_Release(state);
#endif
}

When compiled with python 2.4c1, this mostly works.
Except that it deadlocks, every now and then. If I
comment this code out, no deadlock. I also verified
that the finalizer is called at most once per such
object. I realize that reproducing this bug maybe hard,
building PyLucene is not particularly easy, unless you
have gcj ready.
If you contact me, I'm more than willing to help in
providing all that's needed to reproduce this. I've
seen the deadlock on Mac OS X 10.3.6, my main
development OS.
For what it's worth, I also tried this with python
2.3.4 (including threadmodule.c patch made in
September, related to GIL function usage).

--

>Comment By: Michael Hudson (mwh)
Date: 2004-12-05 10:35

Message:
Logged In: YES 
user_id=6656

Speaking as a Python developer, phew :)

--

Comment By: Andi Vajda (andivajda)
Date: 2004-12-05 04:15

Message:
Logged In: YES 
user_id=1139346

I finally tracked down this bug to gcj bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16478";>16478
which is fixed in gcj version >= 3.4.2.
I am hence closing this python bug as invalid.

--

Comment By: Andi Vajda (andivajda)
Date: 2004-12-04 03:42

Message:
Logged In: YES 
user_id=1139346

I've been running the same test loop on Gentoo/2.6/python
2.4 and was not able to get it to deadlock so far. This bug
could be limited to Mac OS X.

--

Comment By: Andi Vajda (andivajda)
Date: 2004-12-04 03:10

Message:
Logged In: YES 
user_id=1139346

I verified this now with python 2.4 final. It still happens
as tested on Mac OS X.
I was also able to narrow it down to a unit test, that when
run repeatedly will eventually lock up. It is attached.
If you need assistance building PyLucene from sources, or
want me to provide a binary, let me know. At the moment, to
reproduce this bug, it is best to build PyLucene from
subversion.
See http://pylucene.osafoundation.org for more information.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075703&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1071516 ] test_subprocess fails on cygwin

[SourceForge.net]

Bugs item #1071516, was opened at 2004-11-23 09:34
Message generated for change (Comment added) made by astrand
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071516&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Miki Tebeka (tebeka)
Assigned to: Peter Åstrand (astrand)
Summary: test_subprocess fails on cygwin

Initial Comment:
[10:29] $python -V
Python 2.4c1
[10:30] $
[10:31] $
[10:31] $python -c 'from test.test_subprocess import
test_main; test_main()' -v
test_args_string (test.test_subprocess.ProcessTestCase)
... ok
test_call_kwargs (test.test_subprocess.ProcessTestCase)
... ok
test_call_seq (test.test_subprocess.ProcessTestCase) ... ok
test_call_string (test.test_subprocess.ProcessTestCase)
... ok
test_communicate (test.test_subprocess.ProcessTestCase)
... ok
test_communicate_pipe_buf
(test.test_subprocess.ProcessTestCase) ... ok
test_communicate_returns
(test.test_subprocess.ProcessTestCase) ... ok
test_cwd (test.test_subprocess.ProcessTestCase) ... ok
test_env (test.test_subprocess.ProcessTestCase) ... ok
test_exceptions (test.test_subprocess.ProcessTestCase)
... ok
test_executable (test.test_subprocess.ProcessTestCase)
... ok
test_invalid_args
(test.test_subprocess.ProcessTestCase) ... ok
test_list2cmdline
(test.test_subprocess.ProcessTestCase) ... ok
test_no_leaking (test.test_subprocess.ProcessTestCase)
... ok
test_poll (test.test_subprocess.ProcessTestCase) ... ok
test_preexec (test.test_subprocess.ProcessTestCase) ... ok
test_run_abort (test.test_subprocess.ProcessTestCase)
... ok
test_shell_sequence
(test.test_subprocess.ProcessTestCase) ... ok
test_shell_string
(test.test_subprocess.ProcessTestCase) ... ok
test_stderr_filedes
(test.test_subprocess.ProcessTestCase) ... ok
test_stderr_fileobj
(test.test_subprocess.ProcessTestCase) ... ok
test_stderr_none (test.test_subprocess.ProcessTestCase)
... ok
test_stderr_pipe (test.test_subprocess.ProcessTestCase)
... ok
test_stdin_filedes
(test.test_subprocess.ProcessTestCase) ... ok
test_stdin_fileobj
(test.test_subprocess.ProcessTestCase) ... ok
test_stdin_none (test.test_subprocess.ProcessTestCase)
... ok
test_stdin_pipe (test.test_subprocess.ProcessTestCase)
... ok
test_stdout_filedes
(test.test_subprocess.ProcessTestCase) ... ok
test_stdout_fileobj
(test.test_subprocess.ProcessTestCase) ... ok
test_stdout_none (test.test_subprocess.ProcessTestCase)
... this bit of output is from a test of stdout in
a different process ...
ok
test_stdout_pipe (test.test_subprocess.ProcessTestCase)
... ok
test_stdout_stderr_file
(test.test_subprocess.ProcessTestCase) ... ok
test_stdout_stderr_pipe
(test.test_subprocess.ProcessTestCase) ... FAIL
test_universal_newlines
(test.test_subprocess.ProcessTestCase) ... FAIL
test_universal_newlines_communicate
(test.test_subprocess.ProcessTestCase) ... ok
test_wait (test.test_subprocess.ProcessTestCase) ... ok
test_writes_before_communicate
(test.test_subprocess.ProcessTestCase) ... ok

==
FAIL: test_stdout_stderr_pipe
(test.test_subprocess.ProcessTestCase)
--
Traceback (most recent call last):
  File "/usr/lib/python2.4/test/test_subprocess.py",
line 191, in test_stdout_stderr_pipe
self.assertEqual(stripped, "appleorange")
AssertionError: 'apple' != 'appleorange'

==
FAIL: test_universal_newlines
(test.test_subprocess.ProcessTestCase)
--
Traceback (most recent call last):
  File "/usr/lib/python2.4/test/test_subprocess.py",
line 312, in test_universal_newlines
"line1\nline2\nline3\nline4\nline5\nline6")
AssertionError: 'line1\n' !=
'line1\nline2\nline3\nline4\nline5\nline6'

--
Ran 37 tests in 109.478s

FAILED (failures=2)
Traceback (most recent call last):
  File "", line 1, in ?
  File "/usr/lib/python2.4/test/test_subprocess.py",
line 548, in test_main
test_support.run_unittest(ProcessTestCase)
  File "/usr/lib/python2.4/test/test_support.py", line
290, in run_unittest
run_suite(suite, testclass)
  File "/usr/lib/python2.4/test/test_support.py", line
274, in run_suite
raise TestFailed(msg)
test.test_support.TestFailed: errors occurred in
test.test_subprocess.ProcessTestCase


--

>Comment By: Peter Åstrand (astrand)
Date: 2004-12-05 15:43

Message:
Logged In: YES 
user_id=344921

This seems to be a Cygwin bug: p.stdout.read() only returns
a partial result. Another p.stdout.read() is necessary to
retrieve all data. fileobject.read should return all data,
though. It doesn't, because fread() is behaving strange: It
returns a short read, but neither feof() nor ferror() is
set. This is wrong:

"Upon  successful

[ python-Bugs-1078919 ] Email.Header encodes non-ASCII content incorrectly

[SourceForge.net]

Bugs item #1078919, was opened at 2004-12-04 16:47
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1078919&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tessa Lau (tlau)
Assigned to: Nobody/Anonymous (nobody)
Summary: Email.Header encodes non-ASCII content incorrectly

Initial Comment:
I'm generating a MIME message with an attachment whose
filename includes non-ASCII characters.  I create the
MIME header as follows:

msg.add_header('Content-Disposition', 'attachment',
filename=u'Fu\xdfballer_sind_klug.ppt')

The Python-generated header looks like this:

Content-disposition:
=?utf-8?b?YXR0YWNobWVudDsgZmlsZW5hbWU9IkZ1w59iYWxsZXJf?=
=?utf-8?q?sind=5Fklug=2Eppt=22?=

I sent messages with this header to Gmail, evolution,
and thunderbird, and none of them correctly decode that
header to suggest the correct default filename. 
However, I've found that those three mailers do behave
correctly when the header looks like this instead:

Content-disposition: attachment;
filename="=?iso-8859-1?q?Fu=DFballer=5Fsind=5Fklug=2Eppt?="

Is there a way to make Python's email module generate a
Content-disposition header that works with common MUAs?
 I know I can manually encode the filename before
passing it to add_header(), but it seems that Python
should be doing this for me.

--

>Comment By: Martin v. Löwis (loewis)
Date: 2004-12-05 20:42

Message:
Logged In: YES 
user_id=21627

The fact that neither Gmail, evolution, or thunderbird can
decode this string properly does not mean that Python
encodes it incorrectly. I cannot see an error in this header
- although I can sympathize with the developers of the MUAs
that this is a non-obvious usage of the standards.

So I recommend you report this as a bug to the authors of
the MUAs.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1078919&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1074873 ] Windows 2.4c1 installer default location issues

[SourceForge.net]

Bugs item #1074873, was opened at 2004-11-28 23:34
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074873&group_id=5470

Category: Installation
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: dmerrill (davemerrill)
Assigned to: Nobody/Anonymous (nobody)
Summary: Windows 2.4c1 installer default location issues

Initial Comment:
On win2k sp4, python-2.4c1.msi defaults to installing
in c:\Python24\, rather than the more usual c:\Program
Files\Python24\ like 2.3.3 did.

When I pointed it to c:\Program Files\Python24\, it
installed there, but I couldn't get IDLE to run; silent
failure. Not sure if there were other similar issues.
Uninstalled, and reinstalled to the default location,
all is (apparently, so far) well.

--

>Comment By: Martin v. Löwis (loewis)
Date: 2004-12-05 20:45

Message:
Logged In: YES 
user_id=21627

Not sure what the bug is that you are reporting here. It is
intentional that Python installs into c:\python24, not into
Program Files.

The IDLE problem indicates a bug, of course.

--

Comment By: Jean M. Brouwers (jbrouwers)
Date: 2004-12-01 17:30

Message:
Logged In: YES 
user_id=832557

More details on the IDLE issue in bug report 1076861, here



--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074873&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1076861 ] Bad IDLE shortcut by 2.4 installer on XP

[SourceForge.net]

Bugs item #1076861, was opened at 2004-12-01 17:28
Message generated for change (Settings changed) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076861&group_id=5470

Category: Installation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jean M. Brouwers (jbrouwers)
>Assigned to: Martin v. Löwis (loewis)
Summary: Bad IDLE shortcut by 2.4 installer on XP

Initial Comment:
There is a problem with the Python 2.4 installer on
Windows XP.

The IDLE shortcut set up by the installer in the
StartUp folder does not work.  If the shortcut is
removed and recreated manually, it works fine.

That was *after* a complete reinstall of Python 2.4 and
after removing the previous version of Python 2.3 on
the machine.  With Python 2.3 present, the IDLE
shortcut installed by Python 2.4 runs the 2.3 version.

See also



and




--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076861&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1076500 ] python24.msi install error

[SourceForge.net]

Bugs item #1076500, was opened at 2004-12-01 05:47
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076500&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: guan zi jing (guanzijing)
>Assigned to: Martin v. Löwis (loewis)
Summary: python24.msi  install error

Initial Comment:
I can't install the python24.msi on my notebook
( windows (english version with chinese support) xp with 
sp2 )

the install programe display an error after chose the 
install path. 

btw: I installed the office 2003 and norton system works 
and norton firewall 2003. and the python2.3.4 install is 
ok.

--

>Comment By: Martin v. Löwis (loewis)
Date: 2004-12-05 20:49

Message:
Logged In: YES 
user_id=21627

To produce a log file, please run

msiexec /i python-2.4.msi /l*v python.log

and attach the resulting python.log to this report.

--

Comment By: guan zi jing (guanzijing)
Date: 2004-12-04 03:45

Message:
Logged In: YES 
user_id=923521

Yes, I did. 
And I have checked the msi version: 3.0.3790.2180. 
Where can I get the additional information about the install 
error. (eg. log file )

--

Comment By: Facundo Batista (facundobatista)
Date: 2004-12-03 13:31

Message:
Logged In: YES 
user_id=752496

Did you verify your downloaded file with md5sum?

What error the installer gives you?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076500&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1074873 ] Windows 2.4c1 installer default location issues

[SourceForge.net]

Bugs item #1074873, was opened at 2004-11-28 23:34
Message generated for change (Settings changed) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074873&group_id=5470

Category: Installation
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: dmerrill (davemerrill)
>Assigned to: Martin v. Löwis (loewis)
Summary: Windows 2.4c1 installer default location issues

Initial Comment:
On win2k sp4, python-2.4c1.msi defaults to installing
in c:\Python24\, rather than the more usual c:\Program
Files\Python24\ like 2.3.3 did.

When I pointed it to c:\Program Files\Python24\, it
installed there, but I couldn't get IDLE to run; silent
failure. Not sure if there were other similar issues.
Uninstalled, and reinstalled to the default location,
all is (apparently, so far) well.

--

Comment By: Martin v. Löwis (loewis)
Date: 2004-12-05 20:45

Message:
Logged In: YES 
user_id=21627

Not sure what the bug is that you are reporting here. It is
intentional that Python installs into c:\python24, not into
Program Files.

The IDLE problem indicates a bug, of course.

--

Comment By: Jean M. Brouwers (jbrouwers)
Date: 2004-12-01 17:30

Message:
Logged In: YES 
user_id=832557

More details on the IDLE issue in bug report 1076861, here



--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074873&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1071594 ] Windows msi doesn't install site-packages directory

[SourceForge.net]

Bugs item #1071594, was opened at 2004-11-23 11:25
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071594&group_id=5470

Category: Installation
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Anna Ravenscroft (annarave)
Assigned to: Nobody/Anonymous (nobody)
Summary: Windows msi doesn't install site-packages directory

Initial Comment:
On Windows XP, I downloaded and installed 
python-2.4c1.msi, both the "single user" and the "all
users" versions. 

It did not create a site-packages directory in Lib (or
in libs - I checked). I found this surprising behavior.



--

>Comment By: Martin v. Löwis (loewis)
Date: 2004-12-05 20:50

Message:
Logged In: YES 
user_id=21627

This was fixed in the final 2.4 msi.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071594&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1067732 ] wininst --install-script leaves residual files on C:Mime-Version: 1.0

[SourceForge.net]

Bugs item #1067732, was opened at 2004-11-17 01:14
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1067732&group_id=5470

Category: Distutils
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: J Livingston (jlivingston)
>Assigned to: Thomas Heller (theller)
Summary: wininst --install-script leaves residual files on C:
Initial Comment:
I'm running Python 2.3.4 and using distutils ( 
__revision__ of 1.58 2003/02/19) on WinXP SP2 to 
create a windows .exe installer. Both installation and 
removal of the package result in a residual file on the 
root of C: drive. This seems to be directly related to the 
use of the windows install-script which is provided with 
the --install-script switch.
 
The residual file has a naming convention of sxxx 
where 'xxx' is any alphanumeric combination. There is 
never an extension on the file name. On installation, the 
residual file contains the same text the install-script 
prints in the install screen window. On removal, the 
residual file is empty (the install-script does not print 
anything when removing.)

Users attempting to execute the installer from a 
network drive experience installer crash as they do not 
have file system permission to generate the residual 
file..

--

>Comment By: Martin v. Löwis (loewis)
Date: 2004-12-05 20:51

Message:
Logged In: YES 
user_id=21627

Thomas, can you take a look? If not, please unassign.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1067732&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1067153 ] win32con missing codes VK_VOLUME_MUTE, VK_BROWSER_BACK, ...

[SourceForge.net]

Bugs item #1067153, was opened at 2004-11-16 07:15
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1067153&group_id=5470

Category: Windows
>Group: 3rd Party
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Jeff Connelly aka shellreef (jeffconnelly)
Assigned to: Nobody/Anonymous (nobody)
Summary: win32con missing codes VK_VOLUME_MUTE, VK_BROWSER_BACK, ...

Initial Comment:
win32con is missing many virtual keycode constants:

# from WinUser.h
win32con.MOUSEEVENTF_XDOWN = 0x0080
win32con.MOUSEEVENTF_XUP = 0x0100
win32con.MOUSEEVENTF_WHEEL = 0x0800
win32con.VK_XBUTTON1 = 0x05
win32con.VK_XBUTTON2 = 0x06
win32con.VK_VOLUME_MUTE = 0xAD
win32con.VK_VOLUME_DOWN = 0xAE
win32con.VK_VOLUME_UP = 0xAF
win32con.VK_MEDIA_NEXT_TRACK = 0xB0
win32con.VK_MEDIA_PREV_TRACK = 0xB1
win32con.VK_MEDIA_PLAY_PAUSE = 0xB3
win32con.VK_BROWSER_BACK = 0xA6
win32con.VK_BROWSER_FORWARD = 0xA7



--

>Comment By: Martin v. Löwis (loewis)
Date: 2004-12-05 20:53

Message:
Logged In: YES 
user_id=21627

win32con is not supported in the Python project. Please
report this to

https://sourceforge.net/projects/pywin32/

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1067153&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1079545 ] python-2.4.msi install error

[SourceForge.net]

Bugs item #1079545, was opened at 2004-12-05 20:02
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1079545&group_id=5470

Category: Installation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: maharal (maharal)
Assigned to: Nobody/Anonymous (nobody)
Summary: python-2.4.msi install error

Initial Comment:
when I try to install python2.4. using the python-
2.4.msi-file, it stopps with the error message: 
"The installer has encountered an unexpected error 
installing this package. This may inidicate a problem with 
this package. The error code is 2738"



--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1079545&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1078919 ] Email.Header encodes non-ASCII content incorrectly

[SourceForge.net]

Bugs item #1078919, was opened at 2004-12-04 10:47
Message generated for change (Settings changed) made by bwarsaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1078919&group_id=5470

Category: Python Library
>Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Tessa Lau (tlau)
>Assigned to: Barry A. Warsaw (bwarsaw)
Summary: Email.Header encodes non-ASCII content incorrectly

Initial Comment:
I'm generating a MIME message with an attachment whose
filename includes non-ASCII characters.  I create the
MIME header as follows:

msg.add_header('Content-Disposition', 'attachment',
filename=u'Fu\xdfballer_sind_klug.ppt')

The Python-generated header looks like this:

Content-disposition:
=?utf-8?b?YXR0YWNobWVudDsgZmlsZW5hbWU9IkZ1w59iYWxsZXJf?=
=?utf-8?q?sind=5Fklug=2Eppt=22?=

I sent messages with this header to Gmail, evolution,
and thunderbird, and none of them correctly decode that
header to suggest the correct default filename. 
However, I've found that those three mailers do behave
correctly when the header looks like this instead:

Content-disposition: attachment;
filename="=?iso-8859-1?q?Fu=DFballer=5Fsind=5Fklug=2Eppt?="

Is there a way to make Python's email module generate a
Content-disposition header that works with common MUAs?
 I know I can manually encode the filename before
passing it to add_header(), but it seems that Python
should be doing this for me.

--

Comment By: Martin v. Löwis (loewis)
Date: 2004-12-05 14:42

Message:
Logged In: YES 
user_id=21627

The fact that neither Gmail, evolution, or thunderbird can
decode this string properly does not mean that Python
encodes it incorrectly. I cannot see an error in this header
- although I can sympathize with the developers of the MUAs
that this is a non-obvious usage of the standards.

So I recommend you report this as a bug to the authors of
the MUAs.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1078919&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1077302 ] test_macostools failure on OS X

[SourceForge.net]

Bugs item #1077302, was opened at 2004-12-01 20:24
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077302&group_id=5470

Category: Macintosh
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Ian Holsman (webperf)
>Assigned to: Brett Cannon (bcannon)
Summary: test_macostools failure on OS X

Initial Comment:
hi.. I'm a newbie on this stuff.. just trying to
install the latest & greatest and have come up with
this issue

$ uname -a
Darwin dyn-130-194-244-92.its.monash.edu.au 7.6.0
Darwin Kernel Version 7.6.0: Sun Oct 10 12:05:27 PDT
2004; root:xnu/xnu-517.9.4.obj~1/RELEASE_PPC  Power
Macintosh powerpc

^^10.3.6 Powerbook G4 1.5ghz box

  $ ./configure --prefix=/ex --enable-toolbox-glue
--enable-framework
$ make 
...
$ make test
...
test test__locale failed -- Traceback (most recent call
last):
  File "/python/Python-2.4/Lib/test/test__locale.py",
line 43, in test_lc_numeric
"%s != %s (%s); "
AssertionError: , != . (decimal_point); supposed to be
fr_FR, set to fr_FR

test_aepack
...
test_locale
test_locale skipped -- Locale support on MacOSX is
minimal and cannot be tested
test_logging
test_long
test_long_future
test_longexp
test_macfs
test_macostools
test test_macostools failed -- Traceback (most recent
call last):
  File
"/python/Python-2.4/Lib/test/test_macostools.py", line
78, in test_mkalias_relative
macostools.mkalias(test_support.TESTFN, TESTFN2,
sys.prefix)
  File "/python/Python-2.4/Lib/plat-mac/macostools.py",
line 39, in mkalias
relativefsr = File.FSRef(relative)
Error: (-43, 'File not found')

test_macpath


--

>Comment By: Brett Cannon (bcannon)
Date: 2004-12-05 22:28

Message:
Logged In: YES 
user_id=357491

OK, fixed in HEAD as rev. 1.6, 2.4 as rev. 1.5.18.1, and 2.3
as rev. 1.5.14.1 (damn that is a lot of branches).

Thanks for helping out with this, Ian.

--

Comment By: Ian Holsman (webperf)
Date: 2004-12-05 02:05

Message:
Logged In: YES 
user_id=5209

your patch did the trick
Thanks Brett!

--

Comment By: Brett Cannon (bcannon)
Date: 2004-12-04 12:04

Message:
Logged In: YES 
user_id=357491

Aha!  That missing directory is the problem.  If you read the docs on 
what macostools.mkalias does is it creates a Finder shortcut for a 
location.  Well, it fails because it can't make a shortcut to a non-existent 
location.

OK, I have uploaded a patch that basically just checks for sys.prefix's 
existence; if it is missing the test just returns without running.  I figured 
creating the directory would be the improper thing to do since ``make 
install`` will handle that and use specific permissions I didn't want to 
override by having the test create it.

If you can, Ian, apply the patch and let me know if it fixes the issue.

--

Comment By: Ian Holsman (webperf)
Date: 2004-12-04 01:37

Message:
Logged In: YES 
user_id=5209

Python 2.4 (#1, Dec  2 2004, 11:53:05) 
[GCC 3.3 20030304 (Apple Computer, Inc. build 1671)] on darwin
Type "help", "copyright", "credits" or "license" for more
information.

>>> import sys
>>> print sys.prefix 
/Library/Frameworks/Python.framework/Versions/2.4

This directory doesn't exist. the make test uses
DYLD_FRAMEWORK_PATH 

--

Comment By: Brett Cannon (bcannon)
Date: 2004-12-03 14:23

Message:
Logged In: YES 
user_id=357491

The test_shutil failure has already been reported; bug #1076467 and it 
seems to have to do with running as root.

As for the test_macostools failure, lets take this one step at a time.  
What is the value for sys.prefix?  Does that directory exist on your 
machine when you run the test?

--

Comment By: Ian Holsman (webperf)
Date: 2004-12-03 02:46

Message:
Logged In: YES 
user_id=5209

when running the tests as root it fails 3 tests ;(

3 tests failed:
test__locale test_macostools test_shutil
32 tests skipped:
test_al test_bsddb test_bsddb3 test_cd test_cl
test_codecmaps_cn
test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr
test_codecmaps_tw test_curses test_dl test_gdbm test_gl
test_imgfile test_largefile test_linuxaudiodev test_locale
test_nis test_normalization test_ossaudiodev test_pep277
test_poll
test_socket_ssl test_socketserver test_sunaudiodev test_tcl
test_timeout test_urllib2net test_urllibnet test_winreg
test_winsound
1 skip unexpected on darwin:
test_tcl

test_shutil
test test_shutil failed -- Traceback (most recent call last):
  File "/python/Python-2.4/Lib/test/test_shutil.py", line
34, in test_on_error
self.assertEqual(self.errorState, 2)
A

[ python-Bugs-1003935 ] xrange overflows

[SourceForge.net]

Bugs item #1003935, was opened at 2004-08-05 13:16
Message generated for change (Comment added) made by connelly
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003935&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Hallvard B Furuseth (hfuru)
Assigned to: Tim Peters (tim_one)
Summary: xrange overflows

Initial Comment:
These restrictions are undocumented both in the
xrange doc string and in the reference manual
(Info node 'XRange Type'):

  >>> xrange(maxint, maxint + 10)
  Traceback (most recent call last):
File "", line 1, in ?
  OverflowError: long int too large to convert to int

  >>> xrange(-100, maxint)
  Traceback (most recent call last):
File "", line 1, in ?
  OverflowError: xrange() result has too many items

I hope the overflows below are bugs and not
features.  It works if 3/-3 is replaced with 1/-1:

  >>> xrange(0, maxint, 3)
  Traceback (most recent call last):
File "", line 1, in ?
  OverflowError: integer addition

  >>> xrange(0, -maxint, -3)
  Traceback (most recent call last):
File "", line 1, in ?
  OverflowError: integer addition

Python installation:

  Python 2.3.3 (#1, May 25 2004, 20:22:36) 
  [GCC 3.2.3] on sunos5
  Type "help", "copyright", "credits" or "license"
formore information.
  >>> from sys import maxint
  >>> "%x" % maxint
  '7fff'


--

Comment By: Connelly (connelly)
Date: 2004-12-06 07:04

Message:
Logged In: YES 
user_id=1039782


Yes, I run into this bug all the time.  For example, I may 
want to generate all strings of length n:

BINARY_CHARSET = ''.join([chr(i) for i in range(256)])

def all_strs(n, charset=BINARY_CHARSET):
  m = len(charset)
  for i in xrange(m**n):
yield ''.join([charset[i//m**j%m] for j in range(n)])

This is correct algorithmically, but fails due to the buggy 
Python xrange() function.  So I end up writing my own irange
() function.

Other cases where I've run into this problem: Sieving for 
primes starting at a given large prime, checking for integer 
solutions to an equation starting with a large integer, and 
searching very large integer sets.

itertools.count and itertools.repeat are similarly annoying.  
Often I want to search the list of all positive integers starting 
with 1, and have to use an awkward while loop to do this, or 
write my own replacement for itertools.count.

There should be little performance hit for apps which use 
xrange(n), where n fits in the system's integer size.  xrange
() can just return an iterator which returns system ints, and 
the only performance penalty is an extra if statement in the 
call to xrange (and there is no performance penalty in the 
iterator's next() method).

Finally, this move appears consistent with Python's values, ie 
simplicity, long ints supported with no extra effort, avoid 
gotchas for newbies, no special cases, etc.


--

Comment By: Hallvard B Furuseth (hfuru)
Date: 2004-08-08 18:09

Message:
Logged In: YES 
user_id=726647

Here is why repr() is relevant - though the error message
was certainly weird.  With the latest CVS version:

  >>> xrange(maxint-1, maxint, 2)
  xrange(2147483646, -2147483648, 2)

Which is why I suggested to return last+step/abs(step)
as the 2nd argument.

--

Comment By: Tim Peters (tim_one)
Date: 2004-08-08 07:20

Message:
Logged In: YES 
user_id=31435

Changed range_new() to stop using PyRange_New().  This 
fixes a variety of bogus errors.

Documented that xrange() is intended to be simple and fast, 
and that CPython restricts its arguments, and length of its 
result sequence, to native C longs.

Added some tests that failed before the patch, and repaired 
a test that relied on a bogus OverflowError getting raised.

Doc/lib/libfuncs.tex; new revision: 1.171
Lib/test/test_xrange.py; new revision: 1.2
Objects/rangeobject.c; new revision: 2.53

--

Comment By: Tim Peters (tim_one)
Date: 2004-08-06 05:10

Message:
Logged In: YES 
user_id=31435

It looks like there are two bugs here.  One is that the "integer 
addition" detail doesn't make sense, since the user isn't doing 
any integer addition here (sorry, no, repr() is irrelevant to 
this).

Second, it shouldn't be complaining in the last two cases at 
alll.  If the numbers truly were out of range, then 
rangeobject.c's range_new() would have raised a "too many 
items" exception.  Note:

>>> from sys import maxint as m
>>> xrange(0, m, 2)
Traceback (most recent call last):
  File "", line 1, in ?
OverflowError: integer addition
>>> xrange(-m, m, 2)
xrange(-2147483647, 2147483647, 2)
>>>

The second xrange() there contains twice as many items as 
the first one, but doesn't complain.  It's code in Py