Jason Vas Dias added the comment:
Hmm.. investigating that "syscall_293..." stuff - I did
$ cd /usr/src/linux; make headers_install
and then built glibc-2.13 with the new header OK, but
strace is rather old . I'll rebuild strace ...
--
___
Jason Vas Dias added the comment:
$ python
Python 2.7 (r27:82500, Jul 4 2010, 23:30:10)
[GCC 4.4.2 20090927 (prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> import re
>&
Jason Vas Dias added the comment:
new strace 4.6 of newly built python 2.7.1 failing test_commands.py
$ LD_LIBRARY_PATH=`pwd` LD_PRELINK=`pwd`/libpython2.7.so.1.0 strace -s8192 -f
-e trace=execve ./python /usr/src/Python-2.7.1/Lib/test/test_commands.py
execve("./python", ["./
Jason Vas Dias added the comment:
Newly built python 2.7.1 commands.getstatus succeeds :
$ LD_LIBRARY_PATH=`pwd` LD_PRELINK=`pwd`/libpython2.7.so.1.0 ./python
Python 2.7.1 (r271:86832, Apr 28 2011, 15:53:47)
[GCC 4.6.0] on linux2
Type "help", "copyright", "credi
Jason Vas Dias added the comment:
Aha ! Fixed ! : patch :
[ root@jvdspc:/mnt/sda3/Python-2.7 18:02:22 1685:1178 ]
$ LD_LIBRARY_PATH=`pwd` LD_PRELINK=`pwd`/libpython2.7.so.1.0 ./python
/tmp/test_commands.py
test_getoutput (__main__.CommandTests) ... ok
test_getstatus (__main__.CommandTests
Jason Vas Dias added the comment:
oops, over-eager bash again -
I've certainly had one too many bash s today :-)
Here's the patch against 2.7.1's test_commands.py, not 2.7's :
[ root@jvdspc:/mnt/sda3/Python-2.7 18:04:15 1687:1180 ]
$ diff -U0 /usr/src/Python-2.7.1/Lib/t
Jason Vas Dias added the comment:
Not sure if relevant, but ls is appending a ' ' (0x20 == space) after
the filename :
$ ls -ld -d /. | od -x
000 7264 7877 2d72 7278 782d 202e 3532 7220
020 6f6f 2074 6f72 746f 3420 3930 2036 7041
040 2072 3032 3120 3a35 3832 2f20 0a2e
00
Changes by Jason Vas Dias :
--
keywords: +patch
Added file: http://bugs.python.org/file21827/bug_11946.patch
___
Python tracker
<http://bugs.python.org/issue11
Jason Vas Dias added the comment:
Wow, GNU have respun two major releases of coreutils since I built
coreutils-2.10 two weeks ago !
Now moving to latest version of coreutils : 8.12 and retesting .
--
___
Python tracker
<http://bugs.python.
Jason Vas Dias added the comment:
$ ls -dl /. | od -x
000 7264 7877 2d72 7278 782d 202e 3532 7220
020 6f6f 2074 6f72 746f 3420 3930 2036 7041
040 2072 3032 3120 3a35 3832 2f20 0a2e
056
[ root@jvdspc:/tmp 19:15:01 1730:1223 ]
$ ls --version
ls (GNU coreutils) 8.12
Either GNU
Jason Vas Dias added the comment:
Oops, Paul is right here - I asked [email protected], and Paul
responds:
Re: bug#8578: 8.12 and 8.10 'ls -dl' appends ' ' (0x20: space) to file output
lines
From: Paul Eggert (UCLA Computer Science Department)
To: jason.vas.d.
Jason Vas Dias added the comment:
I imagine lots of other python REs fail if this one is failing ? :
$ cat test.py
import os
import sys
import re
pat = r'''d. # It is a directory.
\+? # It may have ACLs.
\s+\d+ # It has some
Jason Vas Dias added the comment:
When I see messages like this in the "make test" log it makes me
want to remove python and all python using software from my system :
test_dl
test test_dl crashed -- : module dl requires
sizeof(int) == sizeof(long) == sizeof(char*)
NO, GEE, TH
Jason Vas Dias added the comment:
RE: msg134737 :
> indeed this test bug was only recently (April 4th!) fixed.
Please can you let me know how to get the patch / source / that fixes this ?
The bug # of the original bug ? Should I be building from GIT ? Which GIT tag ?
I'll try t
Jason Vas Dias added the comment:
Aha ! Yes, I see, it is the extra '.' - this test now works :
$ cat test.py
import os
import sys
import re
pat = r'''d. # It is a directory.
[+.@]?
\s+\d+ # It has some number of links.
Jason Vas Dias added the comment:
In case you don't believe me, believe a "C" compiler :
$ echo -e '#include \nint main(){ printf("%u
%u\\n",sizeof(int),sizeof(void*));}' > si.c
$ gcc -o si si.c
$ ./si
4 8
Any code that assumes that "sizeof(int) ==
Jason Vas Dias added the comment:
Furthermore, look at your configure script output :
checking for int32_t... yes
checking for int64_t... yes
Jason Vas Dias added the comment:
OK, the test failures reported for this bug now succeed with Python-3.3
from latest HG head .
But Python-3.3 now has its own new test failures :
[149/354] test_import
New submission from Jason Vas Dias :
I do :
$ hg clone http://hg.python.org/cpython
( my existing Python-2.7, following upgrade to glibc-2.13, started
producing erroneous results - see gnome.org glib bug :
https://bugzilla.gnome.org/show_bug.cgi?id=648863
So I tried downloading and
Changes by Jason Vas Dias :
--
components: +Build
versions: +Python 3.4
___
Python tracker
<http://bugs.python.org/issue11954>
___
___
Python-bugs-list mailin
Changes by Jason Vas Dias :
--
type: -> crash
___
Python tracker
<http://bugs.python.org/issue11954>
___
___
Python-bugs-list mailing list
Unsubscri
Jason Vas Dias added the comment:
my expat was just built a few weeks ago from expat-2.0.1.tar.gz:
$ ls -l /usr/lib64/libexpat*
-rw-r--r-- 1 root root 577052 Apr 8 21:52 /usr/lib64/libexpat.a
lrwxrwxrwx 1 root root 17 Apr 8 21:52 /usr/lib64/libexpat.so ->
libexpat.so.1.5.2
lrwxrwxrw
Jason Vas Dias added the comment:
suspect cause #1 - bad system libffi ? I just built it, but :
$ ls -l /usr/lib64/libffi*
-rwxr-xr-x 1 root root 36839 May 25 2008 /usr/lib64/libffi-2.00-beta.so
-rw-r--r-- 1 root root 201320 Apr 8 03:46 /usr/lib64/libffi.a
lrwxrwxrwx 1 root root 15 Apr
Jason Vas Dias added the comment:
$ ls -l /usr/lib64/libffi*
-rwxr-xr-x 1 root root 36839 May 25 2008 /usr/lib64/libffi-2.00-beta.so
-rw-r--r-- 1 root root 193480 Apr 29 13:22 /usr/lib64/libffi.a
-rwxr-xr-x 1 root root904 Apr 29 13:22 /usr/lib64/libffi.la
lrwxrwxrwx 1 root root 15 Apr
Jason Vas Dias added the comment:
no, 'make test V=1' still fails with 'run in verbose mode for details' .
does it mean 'make test verbose=1' ? 'make test mode=verbose' ?
--
___
Python tra
Jason Vas Dias added the comment:
OK, so getting out strace shows I need to do :
$ LD_LIBRARY_PATH=`pwd` LD_PRELINK=`pwd`/libpython3.3.so.1.0 ./python -Wd -E
-bb /usr/src/cpython/Lib/test/regrtest.py -l -v 2>&1 | tee
make.test.verbose.log
I'll show the failures from the above
Jason Vas Dias added the comment:
[ 16/354] test_argparse
... # all ok up to:
test_wb_1 (test.test_argparse.TestFileTypeRepr) ... ok
test_failures_many_groups_listargs (test.test_argparse.TestFileTypeW) ... FAIL
test_failures_many_groups_sysargs (test.test_argparse.TestFileTypeW) ... FAIL
Jason Vas Dias added the comment:
test_successes_one_group_sysargs (test.test_argparse.TestTypeUserDefined) ...
test test_argparse failed -- multiple errors occurred
ok
==
FAIL: test_failures_many_groups_listargs
Jason Vas Dias added the comment:
test_start_with_double_slash
(test.test_httpservers.SimpleHTTPRequestHandlerTestCase) ...
/usr/src/cpython/Lib/unittest/case.py:799: BytesWarning: str() on a bytes
instance
(i, item1, item2))
test test_httpservers failed -- multiple errors occurred
ok
Jason Vas Dias added the comment:
test_too_high_from_package (test.test_import.RelativeImportFromImportlibTests)
... test test_import failed -- Traceback (most recent call last):
File "/usr/src/cpython/Lib/test/test_import.py", line 545, in
test_unwritable_directory
&#
Jason Vas Dias added the comment:
[237/354] test_pyexpat
test_ordered_attributes (test.test_pyexpat.SetAttributeTest) ... ok
test_specified_attributes (test.test_pyexpat.SetAttributeTest) ... ok
test_parse_file (test.test_pyexpat.ParseTest) ... ok
test_unicode (test.test_pyexpat.ParseTest
Jason Vas Dias added the comment:
In reply to last comment :
RE: > a single, focused bug
What is this bug if not single and focused ?
The "SINGLE FOCUS" of this bug, in case you missed it , is that
there appears to be no source release of python that can build
and pass its mak
Jason Vas Dias added the comment:
OK, so the ' vanilla configure ' build succeeds too - using DB module
only gdbm , and with internal libffi:
$ make clean
$/usr/src/cpython/configure --prefix=/usr --libdir=/usr/lib64 --enable-shared
...
$ echo $?
0
$ make -j2
...
$ echo $?
0
But e
Jason Vas Dias added the comment:
'make test' failures after
$ /usr/src/cypython/configure --prefix=/usr --libdir=/usr/lib64 --enable-shared
$ make -j2 && make test
(make test fails)
So, to run in "verbose mode", I do :
$ LD_LIBRARY_PATH=`pwd` LD_PRELOAD=`pwd`/lib
New submission from Jason Vas Dias :
Hi - I've been experiencing many errors trying to build any version
of Python that will pass its test suite - see issues : #11946 , #11954 -
and now I've been advised to raise bugs about each test failure -
hence this bug. For details of my config
New submission from Jason Vas Dias :
Hi - I've been experiencing many errors trying to build any version
of Python that will pass its test suite - see issues : #11946 , #11954 -
and now I've been advised to raise bugs about each test failure -
hence this bug. For details of my config
Changes by Jason Vas Dias :
--
components: +Build
type: -> crash
versions: +Python 3.3
___
Python tracker
<http://bugs.python.org/issue11956>
___
___
Python-
Jason Vas Dias added the comment:
So, in the statement that fails :
self.assertFalse(os.path.exists(os.path.join(...))) .
either self.assertFalse is failing or os.path.exists is failing
or os.path.join is failing.
The fact that the error message is 'AssertionError: True is not
Jason Vas Dias added the comment:
oops, no sorry it was this bit from the strace log :
umask(0222) = 022
stat("./@test_9634_tmp", 0x7fff7ef64130) = -1 ENOENT (No such file or directory)
open("./@test_9634_tmp.cpython-33m.so", O_RDONLY) = -1 ENO
Jason Vas Dias added the comment:
Aha ! Yes, the test DOES succeed as a non-root user , and yes,
if you are super user you can override any write bits in
directory permissions if you own the directory.
So the fix ? : skip 'unwritable_directory' test if you are root -
here&#
Jason Vas Dias added the comment:
Aha ! the test succeeds as a non root (super-) user .
This is because as a root user I can override w bit
settings on directories I own: see issue #11956
for fix I applied to test_import.py to fix same
issue. Thanks
Jason Vas Dias added the comment:
OK, so those test_argparse.py and test_import.py tests succeed if run
as a non-root user , because as the super-user one is allowed to
override mode 0300 ( lack of 'w' bit for owner ) on a directory ,
so some tests that check if they are unable to cr
Jason Vas Dias added the comment:
argparse.py needs a similar fix, but I'm not sure where - I raised
issue #11955 on this .
--
___
Python tracker
<http://bugs.python.org/is
Jason Vas Dias added the comment:
hmm... not sure if "make test" completely succeeds as non-root user yet:
"test_subprocess" has been sitting in this state for @ 30mins :
[282/354] test_subprocess
.
this bit of output is from a test of stdout in a different process
Jason Vas Dias added the comment:
Nope, all tests except rpm dependant test_distutils OK as non-root
with the patch I submitted for #11956 - so I guess that's good
enough .
Please fix the python 'make test' to work when run as root u
Jason Vas Dias added the comment:
One last niggle : when I do
$ DESTDIR=`pwd`/inst make install
The configure '--libdir=/usr/lib64' setting I specified is ignored
and python installs itself under /usr/lib . I guess I need to raise
a different b
Jason Vas Dias added the comment:
RE: msg134751 - Thanks for responding, George -
This bug is still an issue for me, as even though I now have Python-3.3
having passed its test suite, installed and running OK, and even
went so far as to 'cd /usr/bin; rm -f python; ln -s python3.3 p
Jason Vas Dias added the comment:
Now I'm really confused.
After linked /usr/bin/python to python3.3 :
$ cd /usr/bin; rm -f python; ln -s python3.3 python;
the 2.7.1 build now succeeds !
(with the patched Lib/test/test_commands.py and the 'make test'
run as non-root ).
Th
Jason Vas Dias added the comment:
BTW, while I'm here :
Any advice on how to setup a truly multi-architecture python installation?
I'm considering doing something like :
1. build same python source for both 32-bit and 64-bit, with
64-bit installing /usr/lib/python-$V as /usr/li
Jason Vas Dias added the comment:
Aha ! Is the above multi-arch config what would result if I did :
--with-universal-archs=ARCH
select architectures for universal build
("32-bit",
"64-bit",
Jason Vas Dias added the comment:
So to get python multi-arch working as I expect I'd have to wrap the C header:
/usr/include/python-2.7/pyconfig.h
with something like:
#ifdef __i386__
#include
#else
#include
#endif
and that's it ! After building i686-Python-2.7.1, I
Jason Vas Dias added the comment:
OK, the last two comment contained complete instructions for setting
up a working dual 64-bit + 32-bit python installation.
Final, working /usr/bin/python :
$ cat /usr/bin/python
#!/bin/sh
ME=$0
ME=${ME##*/}
VERSION=${ME#python}
VERSION=${VERSION:-2.7}
ARCH
Jason Vas Dias added the comment:
Oops, thought there may be gotchas to that multi-arch python wrapper -
it wasn't quoting its arguments properly - here is now what I have as
/usr/bin/python :
$ cat python
#!/bin/bash
ME=$0
ME=${ME##*/}
VERSION=${ME#python}
VERSION=${VERSION:-2.7}
ARCH=`
Jason Vas Dias added the comment:
final python wrapper script :
$ cat python
#!/bin/bash
ME=$0
ME=${ME##*/}
VERSION=${ME#python}
VERSION=${VERSION:-2.7.1}
ARCH=`uname -m`
CMD=''
case $ARCH in
i686)
CMD="/usr/bin/32/${ME}"
;;
*)
CMD="/usr
Jason R. Coombs added the comment:
That's interesting. You're saying that you've been using symlinked packages for
some time and that it works for you. I filed this bug because it's never worked
for me. Can you describe a little bit about the environment in which you&
Jason R. Coombs added the comment:
And since you seem to have some systems that honor symlinked packages, can you
run the attached test_import_symlink_package.py and report the results?
--
___
Python tracker
<http://bugs.python.org/issue6
Jason R. Coombs added the comment:
Thanks for that. The output is very telling.
First, it shows there's a bug in the test script where an exception occurs when
it succeeds because a .pyc file is created and not properly cleaned up.
Second, it demonstrates that the bug as I reported it i
Changes by Jason R. Coombs :
Removed file: http://bugs.python.org/file14741/test_import_symlink_package.py
___
Python tracker
<http://bugs.python.org/issue6727>
___
___
Jason R. Coombs added the comment:
I updated the test script to avoid the error when the .pyc (or __pycache__) is
created.
--
Added file: http://bugs.python.org/file21959/test_import_symlink_package.py
___
Python tracker
<http://bugs.python.
Jason R. Coombs added the comment:
Confirmed the issue exists on Python 2.7 and 3.2
--
versions: +Python 2.7, Python 3.2
___
Python tracker
<http://bugs.python.org/issue6
Changes by Jason R. Coombs :
Removed file: http://bugs.python.org/file21959/test_import_symlink_package.py
___
Python tracker
<http://bugs.python.org/issue6727>
___
___
Jason R. Coombs added the comment:
Updated script to run under Python 3.2 as well.
--
Added file: http://bugs.python.org/file21962/test_import_symlink_package.py
___
Python tracker
<http://bugs.python.org/issue6
Jason R. Coombs added the comment:
Re msg125818, I agree that the mixed EOLs is also a potential problem, though
the proposed solution behaves better than the status quo, where the EOLs get
converted without warning.
It would be desirable for the patch to be more robust in that situation
Jason R. Coombs added the comment:
I've made some progress on this issue. Thanks to Waldemar's findings, I'm able
to selectively reproduce the issue by installing/uninstalling the Visual C++
redistributable that includes KB2467174 on a Windows 7 RTM installation.
So I a
Jason R. Coombs added the comment:
I decided to investigate further. I created another script to test the call to
_wstat to try to recreate the -1 return code, but I was unable to do so. I'm
attaching the script, which creates the same 'sample' package, but instead of
callin
Jason R. Coombs added the comment:
Digging deeper with the Visual Studio debugger, I discovered the following
interesting outcome (run with cmd.exe):
@echo off
mklink /d sample sample-target
mkdir sample-target
echo "" > sample-target\__init__.py
:: Bef
Jason R. Coombs added the comment:
Indeed, this appears to be a bug in stat64.c, specifically a regression in
KB2467174. If I look at the code for _wstat64i32, it doesn't have the code that
calls into _wsopen_s for symlinked files/dirs, so uses the legacy behavior to
stat the targ
Jason R. Coombs added the comment:
Brian, I'm available to help with this tomorrow evening; let me know if you
want to team up on it then.
--
___
Python tracker
<http://bugs.python.org/is
Jason R. Coombs added the comment:
MS Connect is apparently only for projects under active development, not
mature, released products. I've posted to the MSDN forums, where with my MSDN
account, I can expect priority support from MS personnel.
http://social.msdn.microsoft.com/Forums/
Jason R. Coombs added the comment:
Per the suggestion in the Visual Studio forums, I posted a report against
Visual Studio here:
https://connect.microsoft.com/VisualStudio/feedback/details/669601/regression-calling-wstat64i32-on-symlink-directory-with-kb2467174-installed#details
Jason R. Coombs added the comment:
Thanks and good work, Brian.
I think ,though, I'm leaning toward agreeing with Amaury on the presence of the
symlink attribute in os.
I can easily see the justification for hiding it in legacy environments
(Windows XP & Server 2003), where the
New submission from Jason R. Coombs :
When reindent.py runs, it will convert the line endings for each file it
converts to the default line ending for the platform on which reindent.py runs.
It would be better if reindent.py would retain line endings of the source file.
Attached is a patch
Changes by Jason R. Coombs :
Removed file: http://bugs.python.org/file19955/reindent-autonewline.patch
___
Python tracker
<http://bugs.python.org/issue10639>
___
___
Pytho
Jason R. Coombs added the comment:
Merged the patch with the latest trunk.
--
Added file: http://bugs.python.org/file19956/reindent-autonewline.patch
___
Python tracker
<http://bugs.python.org/issue10
Jason R. Coombs added the comment:
Good work Eric.
When I first heard of new string formatting, I was a little wary. The syntax to
supply a dictionary of keyword replacements seemed awkward. It took me a while
before I realized why it really bothered me. There's string formatting you ca
Jason R. Coombs added the comment:
That's great that reindent works in your environment, but that's no help in my
environment.
Here's the use case: We have a software package developed in Unix and with Unix
LF line endings. The code base may also contain files with CRLF
Jason R. Coombs <[EMAIL PROTECTED]> added the comment:
+1 on using "Program Files" by default.
In addition to the points mentioned above, there are other considerations.
In 64-bit platforms (Windows XP x64 and Vista 64-bit), programs are
segmented by their binary compatibi
Jason R. Coombs added the comment:
I haven't seen this error. My first guess is its a regression due to
win 7 or updates to the python code. I'll look into it.
Sent from my comm
On Jan 16, 2010, at 17:47, "Eric Smith" wrote:
>
> Eric Smith added the comment:
Jason R. Coombs added the comment:
Eric: I'm guessing the error you're seeing might be due to a UAC issue
(http://en.wikipedia.org/wiki/User_Account_Control). I've been developing with
UAC disabled (because working with the command-line in a UAC environment is a
bit**).
Can y
Jason R. Coombs added the comment:
Brian: That's interesting. Many of those failures look very much like failures
I've encountered and fixed, though I have been developing in a 32-bit
environment. I'll run the tests on my 64-bit system and see if
Jason R. Coombs added the comment:
Brian: I applied the draft 18 patch to the latest version of /branches/py3k
(77592). I compiled the release x64 build and ran a few tests using the
following syntax:
PS C:\Users\jaraco\projects\public\python-core-py3k> .\pcbuild\amd64\python
.\lib\t
Changes by Jason R. Coombs :
Removed file: http://bugs.python.org/file15616/windows symlink draft 17.patch
___
Python tracker
<http://bugs.python.org/issue1578
Jason R. Coombs added the comment:
Eric: The failures I'm seeing in test_posixpath indicate that realpath isn't
working properly. Are you getting the same results?
As for the buildbot issue - I'm unfamiliar with the buildbot configuration. I
think it would be worth creating
Jason R. Coombs added the comment:
This new patch (draft 19) addresses the outstanding test failures in
test_posixpath.py and test_platform.py (by essentially disabling tests that
were previously-disabled but became enabled on Windows by adding symlink
support).
--
Added file: http
Jason R. Coombs added the comment:
I've confirmed that in fact a security policy permission is required to create
a symbolic link, and that by default, that permission is only granted to
administrators (see
http://en.wikipedia.org/wiki/Symbolic_link#Windows_Vista_symbolic_link). Given
Jason R. Coombs added the comment:
When I consider that the buildslaves are probably donated and not designated
exclusively for Python testing, it makes good sense that they typically run
under a restricted account.
Given that there is a specific permission that can be assigned to the
Jason R. Coombs added the comment:
Great suggestion. I'll do that.
--
title: Add os.link() and os.symlink() and os.path.islink() support for Windows
-> Add os.link() and os.symlink() and os.path.islink() support for Windows
___
Python
Jason R. Coombs added the comment:
If you want support for symlinks in Python 2.6, see
http://pypi.python.org/pypi/jaraco.windows . It even has a method to monkey
patch the os module to provide forward compatibility to the 3.2 functionality.
--
Added file: http://bugs.python.org
Jason R. Coombs added the comment:
Eric: I concur. The function to skip tests will test for the presence of the
particular permission.
--
Added file: http://bugs.python.org/file15939/smime.p7s
___
Python tracker
<http://bugs.python.
Changes by Jason R. Coombs :
Removed file: http://bugs.python.org/file15938/smime.p7s
___
Python tracker
<http://bugs.python.org/issue1578269>
___
___
Python-bugs-list m
Changes by Jason R. Coombs :
Removed file: http://bugs.python.org/file15939/smime.p7s
___
Python tracker
<http://bugs.python.org/issue1578269>
___
___
Python-bugs-list m
Jason R. Coombs added the comment:
I'm currently struggling with determining if the host process has the
appropriate privileges. I'm stuck in that I've enumerated the privileges for an
admin account, but the SeCreateSymbolicLink privilege is not present. I guess
it's in
New submission from Jason R. Coombs :
Under Python 2.6.4 64-bit on Windows 7 64-bit, I found that when launching a
script under the debugger, if backslashes were in the script pathname, they
were not interpreted correctly by the interpreter.
For example, create a simple test script, &q
Changes by Jason R. Coombs :
--
title: IOError when launching script under pdb with backslash in script path ->
IOError in execfile with backslash in path
___
Python tracker
<http://bugs.python.org/iss
Jason R. Coombs added the comment:
I'm changing the title back to the original title. I don't believe the problem
is reproducible using execfile. That is, if a properly-escaped path is passed
to execfile, it works fine.
So I believe the problem lies between when pdb takes control
Jason R. Coombs added the comment:
I suspect this patch may fix the problem. I haven't yet had time to test it.
Index: Lib/pdb.py
===
--- Lib/pdb.py (revision 77683)
+++ Lib/pdb.py (working copy)
@@ -1200,7 +1
Jason R. Coombs added the comment:
The attached test-case identifies the failure mode (and verifies that the
proposed fix corrects the issue).
--
Added file: http://bugs.python.org/file15968/test_pdb.py
___
Python tracker
<http://bugs.python.
Jason R. Coombs added the comment:
Here's a new patch against the trunk that addresses Brian's concerns.
--
keywords: +patch
versions: +Python 2.7
Added file: http://bugs.python.org/file15970/fix with test.patch
___
Python trac
Jason R. Coombs added the comment:
For completeness, I've back-ported the patch to the release26-maint branch.
--
Added file: http://bugs.python.org/file15971/fix with test
(releas26-maint).patch
___
Python tracker
<http://bugs.py
Changes by Jason R. Coombs :
Removed file: http://bugs.python.org/file15968/test_pdb.py
___
Python tracker
<http://bugs.python.org/issue7750>
___
___
Python-bugs-list m
501 - 600 of 1863 matches
Mail list logo
