classification
Title: test_cmd_line fails on MacOS X
Type: behavior Stage: needs patch
Components: Tests, Unicode Versions: Python 3.1, Python 3.2
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: MrJean1, amaury.forgeotdarc, ixokai, loewis, mark.dickinson, michael.foord, piro, pitrou, ronaldoussoren, rpetrov, skip.montanaro, slmnhq, vstinner
Priority: normal Keywords: patch

Created on 2008-11-22 04:54 by MrJean1, last changed 2010-10-20 23:08 by vstinner. This issue is now closed.

Files
File name Uploaded Description Edit
issue4388.patch mark.dickinson, 2008-11-29 22:22
osx_utf8_cmdline.patch vstinner, 2010-10-13 23:39
osx_utf8_cmdline-3.patch vstinner, 2010-10-20 16:38
Messages (35)
msg76232 - (view) Author: Jean Brouwers (MrJean1) Date: 2008-11-22 04:54
There is one test failure with Python 3.0rc3 built on MacOS X 10.4.11 
(Intel).  Test  test_cmd_line fails in the very last test as follows:

% python.exe Lib/test/test_cmd_line.py
test_directories (__main__.CmdLineTest) ... ok
test_optimize (__main__.CmdLineTest) ... ok
test_q (__main__.CmdLineTest) ... ok
test_run_code (__main__.CmdLineTest) ... FAIL
test_run_module (__main__.CmdLineTest) ... ok
test_run_module_bug1764407 (__main__.CmdLineTest) ... ok
test_site_flag (__main__.CmdLineTest) ... ok
test_usage (__main__.CmdLineTest) ... ok
test_verbose (__main__.CmdLineTest) ... ok
test_version (__main__.CmdLineTest) ... ok

======================================================================
FAIL: test_run_code (__main__.CmdLineTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_cmd_line.py", line 143, in test_run_code
    0)
AssertionError: 1 != 0

----------------------------------------------------------------------
Ran 10 tests in 2.074s

FAILED (failures=1)
Traceback (most recent call last):
  File "Lib/test/test_cmd_line.py", line 151, in <module>
    test_main()
  File "Lib/test/test_cmd_line.py", line 147, in test_main
    test.support.run_unittest(CmdLineTest)
  File ".../Python-3.0rc3/Lib/test/support.py", line 698, in 
run_unittest
    _run_suite(suite)
  File ".../Python-3.0rc3/Lib/test/support.py", line 681, in _run_suite
    raise TestFailed(err)
test.support.TestFailed: Traceback (most recent call last):
  File "Lib/test/test_cmd_line.py", line 143, in test_run_code
    0)
AssertionError: 1 != 0


The results for this code snippet:

        # Test handling of non-ascii data
        if sys.getfilesystemencoding() != 'ascii':
            command = "assert(ord('\xe9') == 0xe9)"
            self.assertEqual(
                self.exit_code('-c', command),
                0)

are:

% python.exe 
Python 3.0rc3 (r30rc3:67312, Nov 21 2008, 14:20:38) 
[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.getfilesystemencoding()
'utf-8'
>>> ord('\xe9') == 0xe9
True
msg76241 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2008-11-22 11:14
This seems to have something to do with the current locale.
On OS X 10.4.11/PPC I have:

$ echo $LANG
C

and the test fails.  On OS X 10.5.5:

$ echo $LANG
en_GB.UTF-8

and test_cmd_line.py passes.  Moreover, after doing:

$ export LANG=C

test_cmd_line.py fails on OS X 10.5 too in the same way.
msg76242 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2008-11-22 12:37
Here's a minimal failing example, which I believe captures the cause of 
the test_cmd_line failure.  After "export LANG=C", on OS X 10.5, I get:

Python 3.0rc3+ (py3k:67335, Nov 22 2008, 09:11:58) 
[GCC 4.0.1 (Apple Inc. build 5488)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys, posix
>>> sys.getfilesystemencoding()
'utf-8'
>>> posix.execv(sys.executable, [sys.executable, '-c', "ord('\xe9')"])
Traceback (most recent call last):
  File "<string>", line 1, in <module>
TypeError: ord() expected a character, but string of length 2 found

Clearly the single '\xe9' character is being encoded in utf8 as
b'\xc3\xa9', and the python interpreter invoked by the execv ends up 
receiving two characters here instead of one.

The encoding happens at around line 2988 of posixmodule.c, in posix_execv.
msg76243 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2008-11-22 12:45
I'm not competent enough in this area to judge how serious this bug is, or 
determine what to do about it, but it seems as though it might potentially 
be a release blocker.

Martin, would you be able to take a look?
msg76244 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2008-11-22 12:51
There is some inconsistency in the conversions with the "command line":
- on input, sys.argv decodes with mbstowcs
- on output, os.system uses utf-8, os.execv uses the 
FileSystemDefaultEncoding.
msg76253 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2008-11-22 17:01
The locale machinery on OSX is flaky. The question is what people really
pass for command line arguments. It would be useful to find out what
happens in these two cases:

1. Somebody runs "a.py ภาษาไทย" in a Terminal.app window. Most likely,
the terminal encoding is applied, which we should assume to be UTF-8
(although it might be different on some systems).

2. Somebody creates a file japanese_コンテンツ in the finder, then uses
shell completion to pass this to a Python script. Here I expect that
UTF-8 is used even if the terminal's encoding is not UTF-8.

I don't know whether it's possible to launch Python scripts from Finder,
for given files, if so, it would also be interesting to find out what
encoding will be used there.

Without actual testing, I would assume that command line arguments are
typically encoded in UTF-8 on OSX. We should use that for argument
processing, regardless of mbstowcs.
msg76255 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2008-11-22 18:41
It looks like your conjectures are right in both cases.

I tried adding a few lines to Modules/python.c to print out the argv 
entries as byte strings, before they're passed to mbstowcs.  Results
on OS X 10.5:

> 1. Somebody runs "a.py ภาษาไทย" in a Terminal.app window. Most likely,
> the terminal encoding is applied, which we should assume to be UTF-8
> (although it might be different on some systems).

Yes, it appears that the terminal encoding is applied, if I'm reading 
the results right.  Trying

./python.exe a.py é

with the terminal character encoding set to "Unicode (UTF-8)", Python 
receives the third argument as bytes([195, 169]).  With the terminal 
encoding set to "Western (ISO Latin 1)" instead, Python receives
bytes([233]).

> 2. Somebody creates a file japanese_コンテンツ in the finder, then uses
> shell completion to pass this to a Python script. Here I expect that
> UTF-8 is used even if the terminal's encoding is not UTF-8.

Yes.  Python seems to receive the same string regardless of terminal 
encoding.  (With the terminal encoding set to latin1, the tab-completed 
filename looks like garbage within Terminal, of course.)
msg76263 - (view) Author: Jean Brouwers (MrJean1) Date: 2008-11-22 22:46
The test was originally run with

% echo $LANG
tcsh: LANG: Undefined variable.

The same failure occurs with LANG set to C 

% env LANG=C ../Python-3.0rc3/python.exe Lib/test/test_cmd_line.py
test_directories (__main__.CmdLineTest) ... ok
....
FAILED (failures=1)
Traceback (most recent call last):
  File "Lib/test/test_cmd_line.py", line 151, in <module>
    test_main()
  File "Lib/test/test_cmd_line.py", line 147, in test_main
    test.support.run_unittest(CmdLineTest)
  File "/Users/jean/Desktop/Python-3.0rc3/Lib/test/support.py", line 
698, in run_unittest
    _run_suite(suite)
  File "/Users/jean/Desktop/Python-3.0rc3/Lib/test/support.py", line 
681, in _run_suite
    raise TestFailed(err)
test.support.TestFailed: Traceback (most recent call last):
  File "Lib/test/test_cmd_line.py", line 143, in test_run_code
    0)
AssertionError: 1 != 0


But the test passes in both these cases:

% env LANG=en_US.UTF-8 ../Python-3.0rc3/python.exe 
Lib/test/test_cmd_line.py
Lib/test/test_cmd_line.py
....
test_run_code (__main__.CmdLineTest) ... ok
....
OK


% env LANG=en_GB.UTF-8 ../Python-3.0rc3/python.exe 
Lib/test/test_cmd_line.py
....
test_run_code (__main__.CmdLineTest) ... ok
....
OK
msg76264 - (view) Author: Jean Brouwers (MrJean1) Date: 2008-11-22 23:21
The results from this script

  import os, sys
  print('Python %s' % sys.version.split()[0])
  print('env[LANG]: %s' % os.environ.get('LANG', '<not set>'))
  print('default encoding: %s' % sys.getdefaultencoding())
  print('filesystem encoding: %s' % sys.getfilesystemencoding())

are with Python 3.0:

Python 3.0rc3
env[LANG]: <not set>
default encoding: utf-8
filesystem encoding: utf-8

but for Python 2.3 thru 2.6:

Python 2.6
env[LANG]: <not set>
default encoding: ascii
filesystem encoding: utf-8

All with Python built from source on MacOS X 10.4.11 (Intel).
msg76626 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2008-11-29 22:22
So the obvious quick fix is, on OS X only, to set the locale to e.g. 
"en_US.UTF-8" instead of "" just before the mbstowcs call.

Here's a patch that does this.

I don't like this much, though.  For one thing, I don't have any reason 
to believe that the particular locale "en_US.UTF-8" will be supported on 
any given installation of OS X.

Anyone have any better suggestions?
msg76632 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2008-11-29 23:18
> I don't like this much, though.  For one thing, I don't have any reason 
> to believe that the particular locale "en_US.UTF-8" will be supported on 
> any given installation of OS X.

I'm opposed to this patch for the same reason.

> Anyone have any better suggestions?

We should manually decode the command line arguments with UTF-8 on OSX;
this will require yet another UTF-8 implementation (this time to
wchar_t).

Regards,
Martin
msg76646 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2008-11-30 17:32
I'm now very confused.

In trying to follow things of type wchar_t* around the Python source, I 
discovered PyUnicode_FromWideChar in unicodebject.c.  For OS X, the 
conversion lands in the following code, where w is the incoming WideChar 
array, declared as wchar_t *.

	register Py_UNICODE *u;
	register Py_ssize_t i;
	u = PyUnicode_AS_UNICODE(unicode);
	for (i = size; i > 0; i--)
	    *u++ = *w++;

But this looks wrong:  on OS X, sizeof(wchar_t) is 4 and I think w is 
encoded in UTF-32.  So I was expecting to see some kind of explicit 
conversion from UTF-32 to UCS-2 here.  Instead, it looks as though the 
incoming values are implicitly truncated from 32 bits to 16.  Doesn't this 
do the wrong thing for characters outside the BMP?

Should I open an issue for this, or am I simply misunderstanding?
msg76648 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2008-11-30 18:05
> conversion from UTF-32 to UCS-2 here

That 'UCS-2' should be 'UTF-16', of course.
msg76649 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2008-11-30 18:22
> Should I open an issue for this, or am I simply misunderstanding?

I think you are right. However, conversion to/from wchar_t is/was
rarely used, and so are non-BMP characters; it's very likely that
the problem hasn't occurred in practice (and I doubt it would occur
in 3.0 if not fixed - there are more severe problems around).
msg76652 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2008-11-30 18:59
> it's very likely that
> the problem hasn't occurred in practice (and I doubt it would occur
> in 3.0 if not fixed - there are more severe problems around).

Okay. So it's an issue, but not a blocker. Opened issue 4474 for this.

Thanks, Martin.
msg76667 - (view) Author: Roumen Petrov (rpetrov) * Date: 2008-11-30 21:42
"C locale (alias POSIX, ANSI_X3.4-1968) define is 7-bit char-set.
It is expected mbstowcs to return error is a byte sequence contain a
byte > 128. 

After quick check into code
(http://svn.python.org/view/python/branches/py3k/Lib/test/test_cmd_line.py?rev=67193&view=auto)
I guess that failure is from command "assert(ord('\xe9') == 0xe9)" (test
is run only on mac os platforms). For the "C" program run is ascii(C,..)
locale is expected conversion of byte \xe9 to wchar_t to return error.
msg89362 - (view) Author: Jean Brouwers (MrJean1) Date: 2009-06-14 18:37
This test still fails and is the only failure with Python 3.1rc2 on MacOS 
X 10.4.11 Tiger (Intel).
msg96865 - (view) Author: Salman Haq (slmnhq) Date: 2009-12-24 17:05
Confirming that the test fails on r77044. 

Tested on Mac OS X 10.4.11 (Intel).

running build_scripts
test_cmd_line
test_directories (test.test_cmd_line.CmdLineTest) ... ok
test_large_PYTHONPATH (test.test_cmd_line.CmdLineTest) ... ok
test_optimize (test.test_cmd_line.CmdLineTest) ... ok
test_q (test.test_cmd_line.CmdLineTest) ... ok
test_run_code (test.test_cmd_line.CmdLineTest) ... FAIL
test_run_module (test.test_cmd_line.CmdLineTest) ... ok
test_run_module_bug1764407 (test.test_cmd_line.CmdLineTest) ... ok
test_site_flag (test.test_cmd_line.CmdLineTest) ... ok
test_unbuffered_input (test.test_cmd_line.CmdLineTest) ... ok
test_unbuffered_output (test.test_cmd_line.CmdLineTest) ... ok
test_usage (test.test_cmd_line.CmdLineTest) ... ok
test_verbose (test.test_cmd_line.CmdLineTest) ... ok
test_version (test.test_cmd_line.CmdLineTest) ... ok

======================================================================
FAIL: test_run_code (test.test_cmd_line.CmdLineTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File 
"/Users/salman/svn/python/branches/py3k/Lib/test/test_cmd_line.py", line 
132, in test_run_code
    0)
AssertionError: 1 != 0

----------------------------------------------------------------------
Ran 13 tests in 2.235s

FAILED (failures=1)
test test_cmd_line failed -- Traceback (most recent call last):
  File 
"/Users/salman/svn/python/branches/py3k/Lib/test/test_cmd_line.py", line 
132, in test_run_code
    0)
AssertionError: 1 != 0

1 test failed:
    test_cmd_line
msg104700 - (view) Author: Michael Foord (michael.foord) * (Python committer) Date: 2010-05-01 10:01
I still see this failure on Python 3 trunk with Mac OS X 10.6.
msg104713 - (view) Author: Michael Foord (michael.foord) * (Python committer) Date: 2010-05-01 11:54
This passes for me in Mac OS X Terminal (a UTF8 terminal) but fails in iTerm (an ascii terminal) on both 31-maint and py3k.
msg106105 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2010-05-19 21:33
This issue is specific to Mac OS X because the file system encoding is hardcoded to UTF-8 on this OS. As written in msg76244, the problem is that the encoding is different for input (sys.argv) and output arguments (arguments of child processes). As written in msg76255, program arguments are encoded to the locale (terminal) encoding.

Finally, the problem is that subprocess, os.exec*(), etc. encode command line arguments with the file system encoding instead of the locale encoding.

On Linux, it just work because the file system encoding is the locale encoding.
msg106144 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2010-05-20 12:40
I created to related issues:
 - #8775: Use locale encoding to decode sys.argv, not the file system encoding
 - #8776: Bytes version of sys.argv

If #8775 is fixed, it should fix this issue too.
msg106149 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2010-05-20 12:57
What if os.system(), os.execvp() and friends used "wcstombs" (or locale.preferredencoding) to convert arguments from unicode to bytes? this would at least guarantee round-trip when spawning another python interpreter.

An interesting test is to compare the effects of os.unlink(filename) and os.system('rm "%s"' % filename), where filename is non-ascii. Does it work today?
msg115674 - (view) Author: Skip Montanaro (skip.montanaro) * (Python triager) Date: 2010-09-05 22:11
Any progress on this?  Is the best thing to just set LANG?
msg118220 - (view) Author: Stephen Hansen (ixokai) (Python triager) Date: 2010-10-08 19:24
FWIW, this still happens on the latest of /branches/py3k, when LANG does not match up to the enforced fs encoding-- which for me happened when I ran the buildslave under launchd.

I was finally able to reproduce it, and after doing so, verified that cmdline_encoding-2.patch on issue9992 fixed it.
msg118223 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2010-10-08 19:59
> FWIW, this still happens on the latest of /branches/py3k, 
> when LANG does not match up to the enforced fs encoding
 
ixokai has the bug on Snow Leopard x86.
msg118226 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2010-10-08 20:36
For the record, this can be now reproduced under Linux by forcing different locale and filesystem encodings:

$ PYTHONFSENCODING=utf8 LANG=ISO-8859-1 ./python -m test.regrtest test_cmd_line

[1/1] test_cmd_line
test test_cmd_line failed -- Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/test_cmd_line.py", line 109, in test_run_code
    assert_python_ok('-c', command)
  File "/home/antoine/py3k/__svn__/Lib/test/script_helper.py", line 35, in assert_python_ok
    return _assert_python(True, *args)
  File "/home/antoine/py3k/__svn__/Lib/test/script_helper.py", line 31, in _assert_python
    "stderr follows:\n%s" % (rc, err.decode('ascii', 'ignore')))
AssertionError: Process return code is 1, stderr follows:
Traceback (most recent call last):
  File "<string>", line 1, in <module>
TypeError: ord() expected a character, but string of length 2 found
msg118254 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2010-10-09 08:25
> For the record, this can be now reproduced under Linux by forcing different
> locale and filesystem encodings:
> 
> $ PYTHONFSENCODING=utf8 LANG=ISO-8859-1 ./python -m test.regrtest
> test_cmd_line

I opened a separated issue for Linux, #9992, because some Mac OS X users say 
that this issue looks like a Mac OS X bug and the fix may be different.

Extract of msg111432 (#8775): "To be honest, I'd say the behavior of OSX 10.4 
is a bug and we might add a workaround on that platform that uses 
CFStringGetSystemEncoding() to fetch the actual system encoding when LANG=C."
msg118597 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2010-10-13 22:23
This issue should be fixed by r85435 (OSX: decode command line arguments from utf-8), see #9992.

I will watch for the OSX buildbots.
msg118601 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2010-10-13 23:31
> This issue should be fixed by r85435 ... 
> I will watch for the OSX buildbots.

I don't know if it fixes the issue, but it introduces a regression. r85442 reverts it.

---

Revert r85435 (and r85440): decode command line arguments from utf-8

Python exits with a fatal error if the command line contains an undecodable argument. PyUnicode_FromString() fails at the first undecodable byte because it calls the error handler, but error handlers are not ready before Python initialization.

---

The problem is to get a function to decode a bytes string from utf-8 in main() (before Python initialization). Possibilities:
 - Use PyUnicode_DecodeUTF8Stateful() and tell it to not call the error handler but exit immediatly (return NULL). Eg. check a flag (function argument or global variable?) to check if we should call the error handler or not
 - Use _Py_char2wchar() and set temporary the locale to an utf-8 locale. The problem is to get an utf-8 locale. Is there an utf-8 locale which is always available?
 - Another solution?

I prefer the _Py_char2wchar() solution because I'm sure that it works before Python initialization.
msg118603 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2010-10-13 23:39
osx_utf8_cmdline.patch: copy of r85435.
msg118619 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2010-10-14 06:27
One solution would be to duplicate the UTF-8 decoder for OSX, incorporating surrogate escape. This should be much shorter than the full UTF-8 codec, and perhaps at least utf8_code_length could be shared.
msg119223 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2010-10-20 16:38
> One solution would be to duplicate the UTF-8 decoder for OSX,
> incorporating surrogate escape. This should be much shorter 
> than the full UTF-8 codec, and perhaps at least utf8_code_length 
> could be shared.

Good idea, implemented in the attached patch [osx_utf8_cmdline-3.patch]. I tested the patch on x86 Snow Leopard 3.x and it looks like it fixes the test_cmd_line failure (I modified some tests to remove manually LC_ALL, LC_CTYPE and LANG environment variables).
msg119224 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2010-10-20 16:56
_Py_DecodeUTF8_surrogateescape() is a simplified version of 
PyUnicode_DecodeUTF8Stateful():
 - no "consumed" argument
 - only support surrogateescape error handler
 - no optimization
 - don't resize the buffer at exit

Hum, resize the buffer is maybe a good idea to not waste memory.
msg119242 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2010-10-20 23:08
I commited my patch to Python 3.2 (r85765), with a specific test in test_cmd_line. Reopen the issue if the bug is not fixed.
History
Date User Action Args
2010-10-20 23:08:57vstinnersetstatus: open -> closed
resolution: fixed
messages: + msg119242
2010-10-20 16:56:00vstinnersetmessages: + msg119224
2010-10-20 16:39:01vstinnersetfiles: + osx_utf8_cmdline-3.patch

messages: + msg119223
2010-10-14 06:27:44loewissetmessages: + msg118619
2010-10-13 23:39:00vstinnersetfiles: + osx_utf8_cmdline.patch

messages: + msg118603
2010-10-13 23:31:42vstinnersetmessages: + msg118601
2010-10-13 22:23:54vstinnersetmessages: + msg118597
2010-10-09 08:25:07vstinnersetmessages: + msg118254
2010-10-08 20:36:51pitrousetnosy: + pitrou
messages: + msg118226
2010-10-08 19:59:34vstinnersetmessages: + msg118223
2010-10-08 19:24:56ixokaisetnosy: + ixokai
messages: + msg118220
2010-09-05 22:11:40skip.montanarosetnosy: + skip.montanaro
messages: + msg115674
2010-07-07 02:01:45pirosetnosy: + piro
2010-05-20 12:57:31amaury.forgeotdarcsetmessages: + msg106149
2010-05-20 12:40:51vstinnersetmessages: + msg106144
2010-05-19 21:33:32vstinnersetmessages: + msg106105
2010-05-19 21:16:00vstinnersetnosy: + vstinner
components: + Unicode
2010-05-01 11:54:43michael.foordsetmessages: + msg104713
2010-05-01 10:01:46michael.foordsetnosy: + michael.foord
messages: + msg104700
2010-01-07 19:49:52brian.curtinsetpriority: normal
stage: needs patch
versions: + Python 3.1, Python 3.2, - Python 3.0
2009-12-24 17:05:57slmnhqsetnosy: + slmnhq
messages: + msg96865
2009-06-25 06:26:10ned.deilysetnosy: + ronaldoussoren
2009-06-14 18:37:15MrJean1setmessages: + msg89362
2008-11-30 21:42:56rpetrovsetnosy: + rpetrov
messages: + msg76667
2008-11-30 18:59:12mark.dickinsonsetmessages: + msg76652
2008-11-30 18:22:39loewissetmessages: + msg76649
2008-11-30 18:05:27mark.dickinsonsetmessages: + msg76648
2008-11-30 17:32:51mark.dickinsonsetmessages: + msg76646
2008-11-29 23:18:43loewissetmessages: + msg76632
2008-11-29 22:22:57mark.dickinsonsetfiles: + issue4388.patch
keywords: + patch
messages: + msg76626
2008-11-22 23:21:52MrJean1setmessages: + msg76264
2008-11-22 22:46:56MrJean1setmessages: + msg76263
2008-11-22 18:41:20mark.dickinsonsetmessages: + msg76255
2008-11-22 17:01:28loewissetassignee: loewis ->
2008-11-22 17:01:02loewissetmessages: + msg76253
2008-11-22 12:51:17amaury.forgeotdarcsetnosy: + amaury.forgeotdarc
messages: + msg76244
2008-11-22 12:45:44mark.dickinsonsetassignee: loewis
messages: + msg76243
nosy: + loewis
2008-11-22 12:37:17mark.dickinsonsetmessages: + msg76242
2008-11-22 11:14:08mark.dickinsonsetnosy: + mark.dickinson
messages: + msg76241
2008-11-22 04:54:40MrJean1create