Dave Malcolm dmalc...@redhat.com added the comment:
I slightly messed up the test_hash.py changes.
Revised patch attached:
optin-hash-randomization-for-3.1-dmalcolm-2012-01-30-002.patch
--
Added file:
http://bugs.python.org/file24371/optin-hash-randomization-for-3.1-dmalcolm-2012-01
Dave Malcolm dmalc...@redhat.com added the comment:
Am attaching a backport of
optin-hash-randomization-for-3.1-dmalcolm-2012-01-30-002.patch to 2.6
Randomization covers the str, unicode and buffer types; equality of hashes is
preserved for these types.
--
Added file:
http
Dave Malcolm dmalc...@redhat.com added the comment:
On Sun, 2012-01-29 at 00:06 +, Dave Malcolm wrote:
I went ahead and added the flag to sys.flags, so now
$ make test TESTPYTHONOPTS=-R
shows:
Testing with flags: sys.flags(debug=0, division_warning=0, inspect=0,
interactive=0, optimize=0
Dave Malcolm dmalc...@redhat.com added the comment:
On Sat, 2012-01-28 at 23:56 +, Terry J. Reedy wrote:
Terry J. Reedy tjre...@udel.edu added the comment:
I think you should check with randomization enabled, if only to see the
nature of the failures and if they are expected
Dave Malcolm dmalc...@redhat.com added the comment:
This turns out to pass without PYTHONHASHRANDOMIZATION in the
environment, and fail intermittently with it.
Note that make test invokes the built python with -E, so that it
ignores the setting of PYTHONHASHRANDOMIZATION in the environment
Dave Malcolm dmalc...@redhat.com added the comment:
On Sat, 2012-01-28 at 20:05 +, Benjamin Peterson wrote:
Benjamin Peterson benja...@python.org added the comment:
I think we don't need to mess with tests in 2.6/3.1, but everything should
pass under 2.7 and 3.2.
New version
Dave Malcolm dmalc...@redhat.com added the comment:
On Sat, 2012-01-28 at 23:56 +, Terry J. Reedy wrote:
Terry J. Reedy tjre...@udel.edu added the comment:
I think you should check with randomization enabled, if only to see the
nature of the failures and if they are expected
Dave Malcolm dmalc...@redhat.com added the comment:
On Fri, 2012-01-27 at 21:02 +, Martin v. Löwis wrote:
Martin v. Löwis mar...@v.loewis.de added the comment:
But then isn't it vulnerable to Frank's first attack as exposed in
http://mail.python.org/pipermail/python-dev/2012-January
Dave Malcolm dmalc...@redhat.com added the comment:
On Sat, 2012-01-28 at 03:03 +, Benjamin Peterson wrote:
Benjamin Peterson benja...@python.org added the comment:
For the record, Barry and I agreed on what we'll be doing for stable releases
[1]. David says he should have a patch soon
Dave Malcolm dmalc...@redhat.com added the comment:
On Thu, 2012-01-26 at 21:04 +, Alex Gaynor wrote:
Alex Gaynor alex.gay...@gmail.com added the comment:
On Thu, Jan 26, 2012 at 4:00 PM, Martin v. Löwis
rep...@bugs.python.orgwrote:
Martin v. Löwis mar...@v.loewis.de added
Dave Malcolm dmalc...@redhat.com added the comment:
I'm attaching a patch which implements a hybrid approach:
hybrid-approach-dmalcolm-2012-01-25-001.patch
This is a blend of various approaches from the discussion, taking aspects of
both hash randomization *and* collision-counting
Dave Malcolm dmalc...@redhat.com added the comment:
I've found a bug in my patch; insertdict writes the old non-randomized
hash value into me_hash at:
ep-me_hash = hash;
rather than using the randomized hash, leading to issues when tested
against a real attack.
I'm looking into fixing
Dave Malcolm dmalc...@redhat.com added the comment:
On Wed, 2012-01-25 at 18:05 +, Antoine Pitrou wrote:
Antoine Pitrou pit...@free.fr added the comment:
I'm attaching a revised version of the patch that should fix the above
issue:
hybrid-approach-dmalcolm-2012-01-25-002.patch
Dave Malcolm dmalc...@redhat.com added the comment:
I think you're right: it will stop matching it during lookup within such
a dict, since the dict will be using the secondary hash for abc, but
hash() for the C instance.
It will still match outside of the dict, and within other dicts.
So yes
Dave Malcolm dmalc...@redhat.com added the comment:
Hi Vikash - thanks for working on this.
It's normal when packaging code downstream for Fedora to file a package
review request at bugzilla.redhat.com, following the process here:
http://fedoraproject.org/wiki/Package_Review_Process
(sorry
Dave Malcolm dmalc...@redhat.com added the comment:
I'm attaching an attempt at backporting haypo's random-8.patch to 2.7
Changes relative to random-8.patch:
* The randomization is off by default, and must be enabled by setting
a new environment variable PYTHONHASHRANDOMIZATION
Dave Malcolm dmalc...@redhat.com added the comment:
On Sat, 2012-01-21 at 23:47 +, Alex Gaynor wrote:
Alex Gaynor alex.gay...@gmail.com added the comment:
On Sat, Jan 21, 2012 at 5:42 PM, Gregory P. Smith
rep...@bugs.python.orgwrote:
Gregory P. Smith g...@krypto.org added
Dave Malcolm dmalc...@redhat.com added the comment:
I arbitrarily started with 50, and then decided a power of two would be
quicker when multiplying. There wasn't any rigorous analysis behind the
choice of factor.
Though, as noted in msg151796, I've gone off this idea, since I think
Dave Malcolm dmalc...@redhat.com added the comment:
On Sat, 2012-01-21 at 14:27 +, Antoine Pitrou wrote:
Antoine Pitrou pit...@free.fr added the comment:
Thoughts? (apart from ugh! it's ugly! yes I know - it's late here)
Is it guaranteed that no usage pattern can render
Dave Malcolm dmalc...@redhat.com added the comment:
(or combination of fixes, of course)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13703
Dave Malcolm dmalc...@redhat.com added the comment:
Well, the old attempt was hardly robust :)
Can anyone see any vulnerabilities in this approach?
Yeah; I was mostly trying to add raw data (to help me debug the
implementation).
I wonder if the dict statistics should be exposed with extra
Dave Malcolm dmalc...@redhat.com added the comment:
On Sat, 2012-01-21 at 22:20 +, Antoine Pitrou wrote:
Sounds a bit overkill, and it shouldn't be a public API (which
__methods__ are). Even a private API on dicts would quickly become
visible, since dicts are so pervasive.
Fair enough
Dave Malcolm dmalc...@redhat.com added the comment:
5 more characters:
PYTHONHASHTABLEPROTECTION
or
PYHASHTABLEPROTECTION
maybe?
I'm in *both* camps: I like hash seed randomization fwiw. I'm nervous
about enabling either of the approaches by default, but I can see myself
backporting both
Dave Malcolm dmalc...@redhat.com added the comment:
On Fri, 2012-01-06 at 12:52 +, Marc-Andre Lemburg wrote:
Marc-Andre Lemburg m...@egenix.com added the comment:
Demo patch implementing the collision limit idea for Python 2.7.
--
Added file: http://bugs.python.org/file24151
Dave Malcolm dmalc...@redhat.com added the comment:
On Fri, 2012-01-20 at 22:55 +, Dave Malcolm wrote:
Dave Malcolm dmalc...@redhat.com added the comment:
On Fri, 2012-01-06 at 12:52 +, Marc-Andre Lemburg wrote:
Marc-Andre Lemburg m...@egenix.com added the comment:
Demo patch
Dave Malcolm dmalc...@redhat.com added the comment:
On Fri, 2012-01-20 at 04:46 +, Benjamin Peterson wrote:
Benjamin Peterson benja...@python.org added the comment:
As great as a tool it maybe, it's still only available on a minority
platform. So I couldn't really try it.
FWIW
Changes by Dave Malcolm dmalc...@redhat.com:
--
nosy: +dmalcolm
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13704
___
___
Python-bugs-list
Changes by Dave Malcolm dmalc...@redhat.com:
--
nosy: +dmalcolm
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13703
___
___
Python-bugs-list
Dave Malcolm dmalc...@redhat.com added the comment:
I agree. I filed this here in case anyone else ran into it, but given that
this is really a glibc bug (now fixed), I'm closing this out as won't fix.
--
resolution: - wont fix
status: open - closed
Dave Malcolm dmalc...@redhat.com added the comment:
The glibc bug has been fixed in that project's git repo:
http://repo.or.cz/w/glibc.git/commit/850fb039cec802072f70ed9763927881bbbf639c
--
title: test_cmath fails on ppc with glibc-2.14.90 due to optimized
architecture-specific hypot
New submission from Dave Malcolm dmalc...@redhat.com:
On ppc64, on this box, with glibc-2.14.90-19.ppc64, test_cmath fails with:
==
FAIL: test_specific_values (test.test_cmath.CMathTests
Dave Malcolm dmalc...@redhat.com added the comment:
Reported in glibc's bug tracker as:
http://sourceware.org/bugzilla/show_bug.cgi?id=13472
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13534
Changes by Dave Malcolm dmalc...@redhat.com:
--
nosy: +dmalcolm
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13390
___
___
Python-bugs-list
Dave Malcolm dmalc...@redhat.com added the comment:
- running Python in gdb
This is somewhat orthogonal, but the devguide/gdb page doesn't say how to
start running Python
in gdb (it might be obvious to people used to use gdb, but it should still
be mentioned).
If the devguide
Dave Malcolm dmalc...@redhat.com added the comment:
I've refreshed this patch against the latest version of the code in hg.
In an attempt to make it easier to review, I've split it up into four (so far)
thematic patches, which apply in sequence.
--
Added file:
http://bugs.python.org
Changes by Dave Malcolm dmalc...@redhat.com:
Added file:
http://bugs.python.org/file23173/0002-Add-error-handling-to-initialization-of-_hashlib.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9216
Changes by Dave Malcolm dmalc...@redhat.com:
Added file:
http://bugs.python.org/file23174/0003-Add-optional-usedforsecurity-argument-in-various-pla.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9216
Changes by Dave Malcolm dmalc...@redhat.com:
Added file:
http://bugs.python.org/file23175/0004-_hashlib-Add-selftest-for-FIPS-mode-and-usedforsecur.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9216
Dave Malcolm dmalc...@redhat.com added the comment:
[and yes, I used git to generate the 4 patches; sorry ]
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9216
Dave Malcolm dmalc...@redhat.com added the comment:
The cumulative effect of the above patches (to _hashlib) are equivalent to what
I've applied downstream to python 2 in RHEL 6.0 and Fedora 17 onwards, and
python 3 in Fedora 17 onwards.
In those environments I've additionally patched hashlib
New submission from Dave Malcolm dmalc...@redhat.com:
On 64-bit PPC builds configured --with-tsc, Python segfaults within the first
function call in the bytecode interpreter.
Upon investigation this is due to this code in Python/ceval.c:
32 typedef unsigned long long uint64;
33
Dave Malcolm dmalc...@redhat.com added the comment:
Note that PyPy is also affected by this issue; see
https://bugs.pypy.org/issue832
For CPython, I'm of the opinion that:
- the final digit of sys.platform as-is for linux* is effectively
meaningless
- that no code should be relying
Dave Malcolm dmalc...@redhat.com added the comment:
Another datapoint:
For Fedora 16, I haven't done any downstream patching (so far), because we
hadn't run into any downstream problems.
I did some digging into why we're _not_ experiencing issues.
Currently for Fedora 16, we're shipping
New submission from Dave Malcolm dmalc...@redhat.com:
I'm attaching patches to handle some more events in the gdb7 debugging hooks
for CPython (aka Tools/gdb/libpython.py).
Currently, the hooks only care about C frames that are the bytecode interpreter
(i.e. PyEval_EvalFrameEx)
This patch
Changes by Dave Malcolm dmalc...@redhat.com:
--
keywords: +patch
Added file: http://bugs.python.org/file22712/more-frames-in-gdb-hooks-py3k.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12605
Dave Malcolm dmalc...@redhat.com added the comment:
(On 2.7, I needed import_site=True to get the new tests to work from a fresh
build: import time wasn't being found otherwise)
--
Added file: http://bugs.python.org/file22713/more-frames-in-gdb-hooks-2.7.patch
Dave Malcolm dmalc...@redhat.com added the comment:
FWIW, I've filed a bug about this issue for Fedora 15's python3 package here:
https://bugzilla.redhat.com/show_bug.cgi?id=722578
Looks like this has led to an extra .pyc in the old location for every Python 3
.py file in Fedora 15's various
New submission from Dave Malcolm dmalc...@redhat.com:
test_gdb.py fails when builddir != srcdir: the regex tries to match lines like
this:
#0 builtin_id (self=module at remote 0x720d3240, v=()) at
../Python/bltinmodule.c:919
but isn't expecting the ../ before the Python/bltinmodule.c
Dave Malcolm dmalc...@redhat.com added the comment:
[for reference: issue 11743 covered Antoine's rewrite of the connection class
to be pure python, for 3.3 (re msg138310)]
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Changes by Dave Malcolm dmalc...@redhat.com:
--
nosy: +dmalcolm
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10527
___
___
Python-bugs-list
Dave Malcolm dmalc...@redhat.com added the comment:
The analogous code within Modules/selectmodule.c uses
#ifdef HAVE_POLL
to guard the poll-using code, to support non-Windows platforms that don't have
poll.
Presumably a patch for this should do the same
Dave Malcolm dmalc...@redhat.com added the comment:
Also, I see that Modules/selectmodule.c has some painful-looking workarounds
involving HAVE_BROKEN_POLL, which presumably would also be applicable here.
--
___
Python tracker rep...@bugs.python.org
Changes by Dave Malcolm dmalc...@redhat.com:
--
nosy: +dmalcolm
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11849
___
___
Python-bugs-list
Changes by Dave Malcolm dmalc...@redhat.com:
--
nosy: +dmalcolm
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11845
___
___
Python-bugs-list
Dave Malcolm dmalc...@redhat.com added the comment:
From IRC discussion, how about something like:
The current implementation consolidates integers in the range -5 to 256
(inclusive) into singleton PyIntObject instances, whereas other integer values
have unique PyIntObject instances created
Dave Malcolm dmalc...@redhat.com added the comment:
Perhaps should also note that this is done for the purposes of optimization
(both speed and memory).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11846
Dave Malcolm dmalc...@redhat.com added the comment:
Interpreter idea: int is int could trigger a compatibility warning,
perhaps, to help people avoid relying on CPython quirks
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
New submission from Dave Malcolm dmalc...@redhat.com:
For Python 2 (here with 2.7.1):
$ python -c 'import locale; locale.setlocale(locale.LC_ALL, tr_TR.UTF-8);
import decimal'
Traceback (most recent call last):
File string, line 1, in module
File /usr/lib64/python2.7/decimal.py, line 3715
Dave Malcolm dmalc...@redhat.com added the comment:
jcea: I notice that on 2011-02-22 you made these changes:
assignee: dmalcolm - dino.viehland
nosy: +dino.viehland
versions: +Python 3.3 -Python 3.2
Did you mean to change the assignee, or was this an accident
Dave Malcolm dmalc...@redhat.com added the comment:
This is indeed looking like it's RHEL-specific.
I was about to close it out as a duplicate of issue 10517, but I'm wondering
why Brian chose to open it as a separate bug.
--
___
Python tracker rep
New submission from Dave Malcolm dmalc...@redhat.com:
With hg/mercurial 0.9.3, the build of CPython fails with this error:
gcc -pthread -c -fno-strict-aliasing -g -O0 -Wall -Wstrict-prototypes-I.
-IInclude -I./Include-DPy_BUILD_CORE \
-DHGVERSION=\`LC_ALL=C hg id -i
Dave Malcolm dmalc...@redhat.com added the comment:
Works OK with mercurial 1.3.1
(specifically, this is on a RHEL5 box, using mercurial-1.3.1-3.el5.i386.rpm
from EPEL5)
Closing this out, and changing title to help people searching for this. Not
sure of the exact version of mercurial that's
Dave Malcolm dmalc...@redhat.com added the comment:
I tried again, and I'm still able to reproduce this bug on a RHEL5 box with
cpython --with-pydebug as of a recent checkout (69030:00217100b9e7 as it
happens):
$ ./python -c import multiprocessing.managers ; mpp = multiprocessing.Pool(4);
sm
Dave Malcolm dmalc...@redhat.com added the comment:
Various thoughts/nitpicking:
- is it possible to indicate with a coding convention (e.g. comments) which
parts of the code are intended to be called from a signal handler? It seems
worth making this explicit. Or perhaps put it all in one
Changes by Dave Malcolm dmalc...@redhat.com:
--
nosy: +loewis
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9263
___
___
Python-bugs-list mailing
Changes by Dave Malcolm dmalc...@redhat.com:
--
resolution: - accepted
stage: patch review - committed/rejected
status: open - closed
versions: -Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10288
Changes by Dave Malcolm dmalc...@redhat.com:
--
nosy: +loewis
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9635
___
___
Python-bugs-list mailing
Changes by Dave Malcolm dmalc...@redhat.com:
--
nosy: +dmalcolm
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11410
___
___
Python-bugs-list
Changes by Dave Malcolm dmalc...@redhat.com:
--
nosy: +dmalcolm
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10924
___
___
Python-bugs-list
Dave Malcolm dmalc...@redhat.com added the comment:
FWIW, this regressed in 2.6.6 relative to 2.6.5, due to r79646 adding the
T_STRING_INPLACE test code to the 2.6 branch.
Note to self: https://bugzilla.redhat.com/show_bug.cgi?id=677392
Dave Malcolm dmalc...@redhat.com added the comment:
CVE-2011-0705
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11197
___
___
Python-bugs-list
Dave Malcolm dmalc...@redhat.com added the comment:
I spent some time bisecting the SVN history in the py3k branch, and believe
that r84914 is the commit that introduced this issue.
Details:
Trying on 4-core i386 RHEL 5 box
$ svn up -r REV
$ make clean ; make
(configured
Changes by Dave Malcolm dmalc...@redhat.com:
--
nosy: +krisvale
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10517
___
___
Python-bugs-list
Dave Malcolm dmalc...@redhat.com added the comment:
r84914 was the implementation of issue 9786 (Native TLS support for pthreads)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10517
Dave Malcolm dmalc...@redhat.com added the comment:
This appears to be happening in a child process when the parent process is
running:
Lib/multiprocessing/util.py, line 255, in _exit_function ()
Liberally adding printf() and getpid() calls in various places, seems to always
happen when
Dave Malcolm dmalc...@redhat.com added the comment:
On Wed, 2011-02-09 at 16:41 +, Barry A. Warsaw wrote:
IIRC we thought about something like this during the PEP discussions and
Guido nixed it.
FWIW, the closest I could find was this mail:
http://www.mail-archive.com/python-dev
Changes by Dave Malcolm dmalc...@redhat.com:
--
title: test_concurrent_futures crashes with Fatal Python error: Invalid thread
state for this thread - test_concurrent_futures crashes with --with-pydebug
on RHEL5 with Fatal Python error: Invalid thread state for this thread
New submission from Dave Malcolm dmalc...@redhat.com:
If we start a short-lived process which finishes before we begin communicating
with it (e.g. by crashing), we can receive a SIGPIPE due to the receiving
process no longer existing. This becomes an EPIPE, which becomes an:
OSError: [Errno
Dave Malcolm dmalc...@redhat.com added the comment:
Attaching updated version of the patch.
I've added a selftest which (in a sacrificial subprocess) abuses ctypes to
break an ob_refcnt, and then triggers a garbage collection.
I also changed the printing to stderr to directly use fprintf
Dave Malcolm dmalc...@redhat.com added the comment:
As above, but I added an extra call to fflush in case the call to
_PyObject_Dump leads to a segfault.
--
Added file:
http://bugs.python.org/file20344/py3k-objdump-on-gcmodule-assertions-2011-01-10-002.patch
Dave Malcolm dmalc...@redhat.com added the comment:
Adrian verified in the downstream bug tracker that this fixed the build for him
(and the logs show it successfully ran the test suite), so I committed my patch
to py3k as r87796.
--
___
Python
Dave Malcolm dmalc...@redhat.com added the comment:
Merged back to 3.1 as r87800 and to 2.7-maint as r87801
--
resolution: - fixed
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Dave Malcolm dmalc...@redhat.com added the comment:
FWIW, I just added this patch downstream to Fedora's python 3 builds:
http://pkgs.fedoraproject.org/gitweb/?p=python3.git;a=blob_plain;f=python-3.2b2-fix-ppc-debug-build.patch;hb=5659c63442be2e91eb42e60284d7a9a9ab0b80dd
Dave Malcolm dmalc...@redhat.com added the comment:
Note that for that test case to be run, it must be on an installed python:
@unittest.skipIf(sysconfig.is_python_build(),
need an installed Python. See #7774)
Am testing the 2.7 branch now on an x86_64 Fedora 13 box
Dave Malcolm dmalc...@redhat.com added the comment:
That test works for me on this x86_64 Fedora 13 box (using latest 2.7 code from
SVN, built and installed to a test prefix):
[da...@surprise bin]$ ./python -m test.regrtest -v test_subprocess
== CPython 2.7.1+ (release27-maint:87724, Jan 3
Dave Malcolm dmalc...@redhat.com added the comment:
I should note that Fedora Core 4 reached its End of Life at August 2006:
http://fedoraproject.org/wiki/End_of_life
Do you see this with a more up-to-date version of Fedora?
--
___
Python tracker
Dave Malcolm dmalc...@redhat.com added the comment:
For reference, this seems to affect SWIG, specifically, I'm seeing build
failures using:
/usr/share/swig/2.0.1/python/pycontainer.swg
from swig-2.0.1
See downstream build failure report for znc, which uses swig to generate python
3
Dave Malcolm dmalc...@redhat.com added the comment:
This is very interesting work - thank you!
Sorry for not commenting earlier (very busy), so here are my thoughts so far.
The baseline for the diff appears to be against the py3k branch, in that it
adds back in classes from 2.*: PyIntObject
Changes by Dave Malcolm dmalc...@redhat.com:
--
nosy: +dmalcolm
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1705520
___
___
Python-bugs-list
Dave Malcolm dmalc...@redhat.com added the comment:
A (probably crazy) idea that just occurred to me:
typedef char utf8_bytes;
typedef char iso8859_1_bytes;
typedef char fsenc_bytes;
then specify the encoding in the type signature of the API e.g.:
- int PyRun_SimpleFile(FILE *fp, const
Dave Malcolm dmalc...@redhat.com added the comment:
What version of the compiler was this with?
(For reference, I see that you also filed this downstream in Fedora's bug
tracker as:
https://bugzilla.redhat.com/show_bug.cgi?id=661510 )
--
nosy: +dmalcolm
Dave Malcolm dmalc...@redhat.com added the comment:
Forgot to close this one out
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9518
Changes by Dave Malcolm dmalc...@redhat.com:
--
stage: patch review - committed/rejected
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9518
Changes by Dave Malcolm dmalc...@redhat.com:
--
assignee: - dmalcolm
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10399
___
___
Python-bugs-list
Dave Malcolm dmalc...@redhat.com added the comment:
One of RH's gcc gurus told me in IRC that:
__ppc__ is not a standard powerpc*-linux macro
__PPC__ or __powerpc__ is
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10655
New submission from Dave Malcolm dmalc...@redhat.com:
(was misspelled when issue 5650 was fixed, FWIW)
--
assignee: orsenthil
components: Library (Lib)
files: py3k-fix-jwz-surname.patch
keywords: patch
messages: 123079
nosy: dmalcolm, orsenthil
priority: low
severity: normal
status
Dave Malcolm dmalc...@redhat.com added the comment:
Fixed in py3k in r86932
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10606
New submission from Dave Malcolm dmalc...@redhat.com:
2.6.6 has an erronenous use of a unittest method that was added in 2.7, but
it's only seen when running as root. More specificially, with this guard:
if posix.getuid() == 0 and hasattr(posix, 'getgroups') and sys.platform !=
'darwin
Changes by Dave Malcolm dmalc...@redhat.com:
--
nosy: +dmalcolm
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10517
___
___
Python-bugs-list
Dave Malcolm dmalc...@redhat.com added the comment:
I'm able to reliably reproduce this on a RHEL 5 box (i386 in this case).
All of the ProcessPool* unittest subclasses within
Lib/test/test_concurrent_futures.py exhibit this hang, each printing out just
the name of the first test (so
101 - 200 of 412 matches
Mail list logo
