Changes by Nadeem Vawda :
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue5210>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Nadeem Vawda :
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue8536>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Nadeem Vawda :
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue5784>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Nadeem Vawda :
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue5804>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Nadeem Vawda :
http://www.python.org/dev/buildbot/all/builders/AMD64%20debian%20bigmem%203.x/builds/58/steps/test/logs/stdio
--
assignee: nadeem.vawda
messages: 152006
nosy: nadeem.vawda
priority: normal
severity: normal
stage: needs patch
status: open
title: SIGBUS
New submission from Nadeem Vawda :
When running the test suite, I occasionally get the following failure:
ERROR: testRecvmsgEOF (test.test_socket.RecvmsgSCTPStreamTest)
--
Traceback (most recent call last
New submission from Nadeem Vawda :
http://www.python.org/dev/buildbot/all/builders/x86%20XP-5%203.x/builds/4072/steps/test/logs/stdio:
FAIL: test_enter (test.test_sched.TestCase)
--
Traceback (most recent call last
Nadeem Vawda added the comment:
Oops, those links should be:
http://www.python.org/dev/buildbot/all/builders/x86%20XP-5%203.x/builds/4072/steps/test/logs/stdio
and:
http://www.python.org/dev/buildbot/all/builders/x86%20XP-5%203.x/builds/4062/steps/test/logs/stdio
Nadeem Vawda added the comment:
I've also been unable to reproduce it on my own machine (AMD64; 8GB RAM).
I guess I'll have to do some trial-and-error debugging using the custom
builder to figure this out.
--
___
Python trac
New submission from Nadeem Vawda :
I've recently come across a strange failure in the tests for the input()
built-in function:
$ ./python -E -m test -v test_readline test_builtin
[... snip ...]
==
Nadeem Vawda added the comment:
Here's another patch that ensures the test always exercises the GNU
readline code path (rather than the stdio fallback). This will cause the
failure to occur when running just test_builtin (no need to also run
test_readline before it).
Ideally we'd wa
New submission from Nadeem Vawda :
While investigating issue 13886, I found that test_builtin will fail when run
after test_tk:
$ ./python -Wd -E -bb -m test -vuall test_tk test_builtin
== CPython 3.3.0a0 (default:52f68c95e025, Jan 26 2012, 19:05:09) [GCC 4.6.1]
== Linux-3.0.0-15
Nadeem Vawda added the comment:
No, the latest revision of Modules/zlibmodule.c doesn't use any of these
new features.
--
___
Python tracker
<http://bugs.python.org/i
New submission from Nadeem Vawda :
Since changeset b99c54acb22d, the ARM Ubuntu buildbot has been hanging in
test_ssl:
http://www.python.org/dev/buildbot/all/builders/ARM%20Ubuntu%203.x/builds/250/steps/test/logs/stdio
I've been able to reproduce this behaviour on my AMD64 Ubuntu
Nadeem Vawda added the comment:
The ARM Ubuntu 3.2 buildbot is having the same problem:
http://www.python.org/dev/buildbot/all/builders/ARM%20Ubuntu%203.2/builds/158/steps/test/logs/stdio
The 2.7 bot is fine, though.
--
versions: +Python 3.2
Nadeem Vawda added the comment:
With the patch applied on 3.2 (it doesn't apply on default), the test passes,
but it also prints out this exception traceback:
test_protocol_sslv3 (test.test_ssl.ThreadedTests)
Connecting to an SSLv3 server with various client options ...
New submission from Nadeem Vawda :
While running test_ssl in verbose mode, I noticed the following exception:
[...]
test_protocol_sslv3 (test.test_ssl.ThreadedTests)
Connecting to an SSLv3 server with various client options ...
SSLv3->SSLv3 CERT_NONE
SSLv3->
Nadeem Vawda added the comment:
> What is the OpenSSL version?
test_ssl: testing with 'OpenSSL 1.0.0e 6 Sep 2011' (1, 0, 0, 5, 15)
under Linux ('debian', 'wheezy/sid', '')
HAS_SNI = True
--
__
Nadeem Vawda added the comment:
Might it be a distribution-specific issue, then? I'm running Ubuntu and
IIRC you're using Mageia?
--
___
Python tracker
<http://bugs.python.o
Nadeem Vawda added the comment:
I can't see anything in the Ubuntu patches (available from
<https://launchpad.net/ubuntu/+source/openssl/1.0.0e-2ubuntu4>)
that relate to networking or handshakes, so maybe it's not that.
I could be wrong, though - I've neve
Nadeem Vawda added the comment:
> I am just recompressing a 77GB file because of this :-(.
Sorry to hear that :(
> I would consider that a bug, not a feature request.
Semantic issues aside, my concern here is that the patch for 2.7 is considerably
larger than the one for 3.3, and the c
New submission from Nadeem Vawda :
http://www.python.org/dev/buildbot/all/builders/x86%20FreeBSD%206.4%203.x/builds/2206/steps/test/logs/stdio
FAIL: test_6_daemon_threads (test.test_threading.ThreadJoinOnShutdown
Nadeem Vawda added the comment:
> An alternative solution I'd like to pursue is to backport 3.3's BZ2File
> implementation to run on 2.7, and release it on PyPI.
Well, that was easier than I expected. It didn't take much work to get it
working under 2.6, 2.7 and 3.2. I&#x
Changes by Nadeem Vawda :
--
resolution: -> invalid
stage: -> committed/rejected
status: open -> closed
type: enhancement ->
___
Python tracker
<http://bugs.python
Nadeem Vawda added the comment:
> In fact, you can create those files from python, files that python can not
> unpack later.
Really? How so? BZ2File only started accepting the "a" mode in 3.3
(thanks to Nir's patch for this issue, actually).
> If the refusal of bac
Changes by Nadeem Vawda :
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue13963>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nadeem Vawda added the comment:
64-bit Windows (or at least Visual C++) uses the LLP64 model, so a long
is 32 bits wide (the only 64-bit integer type being long long) - see
<http://en.wikipedia.org/wiki/64-bit#64-bit_data_models>
Since Python's int is documented as being implemente
Nadeem Vawda added the comment:
All tests pass with the patch applied, on both Windows 7 and Ubuntu 11.10.
I notice that the patch only changes Lib/packaging/manifest.py; does
Lib/distutils/filelist.py perhaps also need to be updated? Changeset
64485e0700ba modified both of these files
Changes by Nadeem Vawda :
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue5148>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nadeem Vawda added the comment:
The problem here is that gzip.GzipFile does not support text mode, only
binary mode. Unfortunately, its __init__ method doesn't handle unexpected
mode strings sensibly, so you get a confusing error message.
If you need to open a compressed file in text mo
Nadeem Vawda added the comment:
> This not-so-bad patch adds lzma compression support to the shutil functions,
> under the 'xztar' name. Please review.
Functionally, the patch looks good to me. There are some docstrings that
should probably be updated, though:
- _make_tarbal
Nadeem Vawda added the comment:
Patch looks good, but you might want to make this change to test_priority:
l = []
fun = lambda x: l.append(x)
scheduler = sched.scheduler(time.time, time.sleep)
+now = time.time()
for priority in [1
Nadeem Vawda added the comment:
AFAIK, all interested parties are supposed to automatically be sent email
notifications whenever anyone posts an update on the review. However,
I've run into a bug <http://psf.upfronthosting.co.za/roundup/meta/issue402>
that seems to be preventin
Changes by Nadeem Vawda :
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue13997>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nadeem Vawda added the comment:
It appears that while test_process_template() uses "/"-delimited paths
consistently across all OSes, 2.7 also has a test_process_template_line()
that uses os.path.join() to construct its paths. Changing this test to
use hardcoded "/"-delim
Nadeem Vawda added the comment:
Tests are failing on all the Windows buildbots (e.g.
http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/builds/5966/steps/test/logs/stdio
).
The problem seems to be that the test in question is hardwired to expect "/" as
the directory
Changes by Nadeem Vawda :
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue14004>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nadeem Vawda added the comment:
> BTW, any plans on a PyPI backport for fun and profit?
At present, no. I'll look into it later in the year, but at the moment
I don't have the time to work on it - I suspect the parts written in C
will require substantial changes to w
Nadeem Vawda added the comment:
Ah, I suppose that makes sense.
--
___
Python tracker
<http://bugs.python.org/issue13878>
___
___
Python-bugs-list mailin
Nadeem Vawda added the comment:
I've been able to reproduce this on current builds of 2.7, 3.2 and 3.3.
The problem seems to be that distutils.filelist pathnames using the OS
directory separator, but the regexps used for matching paths are written
to always assume "/"-based pa
Nadeem Vawda added the comment:
> The bug is indeed fixed in the latest 2.7 tip:
>
> PS C:\Users\jaraco\projects\public\keyring>
> C:\Users\jaraco\projects\public\cpython\PCbuild\amd64\python.exe setup.py
> sdist 2> NULL | findstr .hg
>(produces no output)
I s
Nadeem Vawda added the comment:
> At first glance, Nadeem’s proposed fix is not right: paths in MANIFEST.in use
> '/', but then filelist produces paths using os.sep, so that the MANIFEST file
> and other operations done by the sdist command use native paths. So even
>
Changes by Nadeem Vawda :
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue14040>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Nadeem Vawda :
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue6884>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nadeem Vawda added the comment:
With the patch applied, the problem from issue 14004 still occurs. There
is also a failure in test_distutils, but I'm not sure whether that's just
the test itself needing to be updated.
Anyway, it's late for me now; I'll give it a more de
Nadeem Vawda added the comment:
Test output:
test test_distutils failed -- Traceback (most recent call last):
File
"C:\Users\Nadeem\Code\python2\python27\lib\distutils\tests\test_filelist.py",
line 230, in test_process_template
self.assertEqual(file_list.files
Nadeem Vawda added the comment:
> It’s strange that glob_to_re needs fixing too; at this point I’m not sure if
> we’re still fixing my commit or if the original code never worked properly on
> Windows. Could you run the same tests with a Python < 2.7?
The original code never wor
Nadeem Vawda added the comment:
This happens because the glob-to-regexp translator assumes that the
directory separator is "/", regardless of platform. Consequently, the
regexp for "include *.py" ends up matching "sandbox\dummy.py" erroneously
on Windows.
Changes by Nadeem Vawda :
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue14053>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nadeem Vawda added the comment:
Thanks for taking this up; it's something that's been bothering me for a
while now.
A couple of comments:
- The mq_changed_files() function will break if the user has specified
git-format diffs in their ~/.hgrc file. In this case, the diff comman
Nadeem Vawda added the comment:
> (2.7.2 doesn’t include neither Antoine’s changeset nor mine, right?)
Correct; it dates back to June last year, before issue 13193 was filed.
> Can you reproduce the “include buildout.cfg” bug too?
Yes, that problem is present in 2.7.2, but not
Nadeem Vawda added the comment:
> Shouldn't be --rev qparent ?
Yes, that's right. I seem to confuse qbase and qparent often...
--
___
Python tracker
<http://bugs.pytho
Nadeem Vawda added the comment:
Hmm... it looks like mq_changed_files() duplicates a chunk of logic from
the existing changed_files() code. You can get rid of this redundancy by
replacing mq_changed_files() with a function that checks for applied MQ
patches; let's call it mq_patches_ap
Nadeem Vawda added the comment:
Patch looks good; I've just got one more small suggestion.
The variable 'some_applied' in mq_patches_applied isn't really necessary
- it would be clearer if you just said:
return st.returncode == 0 and bstdout
after the ca
Changes by Nadeem Vawda :
--
nosy: +bethard
___
Python tracker
<http://bugs.python.org/issue14075>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nadeem Vawda added the comment:
> So, do you agree that “not automated but not ugly” is better than “automated
> with ugly klutches”?
Definitely. If we have to add special cases that are almost as long as
the original code, the "automation" seems pointless.
> Note that th
Nadeem Vawda added the comment:
For the "xztar" format, you should also perhaps recognize the ".txz"
extension - I've seen this used by FreeBSD.
--
___
Python tracker
<http
Nadeem Vawda added the comment:
Committed. Thanks for the patch!
> I haven't added NEWS as I thing is easier for the person that applies the
> patch to simply write the line directly there instead of merging. Is that ok?
Yes, that's fine; usually the NEWS entry is more or
Changes by Nadeem Vawda :
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue13447>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nadeem Vawda added the comment:
This was already reported as issue 13873.
--
nosy: +nadeem.vawda
resolution: -> duplicate
stage: -> committed/rejected
status: open -> closed
superseder: -> SIGBUS in test_zlib on Debian bigmem buildbot
__
Changes by Nadeem Vawda :
--
nosy: +haypo, loewis, pitrou
___
Python tracker
<http://bugs.python.org/issue13873>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nadeem Vawda added the comment:
> The SIGBUS could be due to the buildbot running out of tmpfs.
I haven't been able to reproduce the crash by running the test on a tmpfs
on my own machine (Ubuntu AMD64; 8GB RAM; Linux 3.0.0-15-generic; zlib
1:1.2.3.4.dfsg-3ubuntu3), but maybe it&
Nadeem Vawda added the comment:
> Shall I commit the new file or first add more tests?
Might as well commit now; there's no sense in leaving the code sitting
around just because the file feels a bit short.
A couple of minor nits about your patch, though:
- The docstring for test_to
Nadeem Vawda added the comment:
Well, it turns out that when I tested it on my own machine, I actually
wasn't using a tmpfs - I misread the output of df and used /tmp¹ instead
of /run. Doing the test in /run does in fact give a bus error. Mea culpa.
¹ Apparently on my system /tmp isn'
Nadeem Vawda added the comment:
I don't think there's any harm in testing that the exception message for
a .bz2 file contains the string "unknown archive format". It's unlikely
that we'll want to completely change the error message in future, and if
we do, it will
Nadeem Vawda added the comment:
There were bugs in two of the updated tests:
- test_glob_to_re() was doing two levels of escaping (r'\' -> r'')
for its expected output when it should only do one (r'\' -> r'\\').
- test_process_template() was
New submission from Nadeem Vawda :
As I understand it, a MANIFEST.in directive:
recursive-include foo bar.*
is meant to match files under foo for with names beginning with "bar.".
However, the actual regex that is generated for this line is:
r'^foo/.*bar\.[^/]*\Z(?ms)&
Changes by Nadeem Vawda :
--
dependencies: +Impossible to include file in sdist that starts with 'build' on
Win32
stage: needs patch -> patch review
___
Python tracker
<http://bugs.pytho
Changes by Nadeem Vawda :
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue5438>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Nadeem Vawda :
On the debian bigmem buildbot, test_bigmem hangs until it gets killed
by a timeout:
http://www.python.org/dev/buildbot/all/builders/AMD64%20debian%20bigmem%203.x/builds/134/steps/test/logs/stdio
http://www.python.org/dev/buildbot/all/builders/AMD64
Changes by Nadeem Vawda :
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue14109>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Nadeem Vawda :
Recent failures on one of the Windows XP buildbots:
http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/builds/6049/steps/test/logs/stdio
http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/builds/6051/steps/test/logs/stdio
FAIL
Nadeem Vawda added the comment:
> I ran test_bigmem on my computer. The test pass but it is really slow.
Is this with or without the fix you just pushed? How much RAM does your
system have? I tried running with "-M 4.5G" on my 8GB machine earlier
today, and it ate through all o
Nadeem Vawda added the comment:
> My PC has 12 GB of RAM and no swap. I ran the test after my commit.
That explains. I ran it earlier (obviously), so it included a bunch of
those more-demanding tests, which must be where the OOM killer hit
Nadeem Vawda added the comment:
There are some minor errors in your v3 patch. I've attached a v4 that fixes
them (as usual, tested on Windows and Linux):
- s/special/sep/ in glob_to_re()
- Add missing l(.) to filenames in test_process_template under 'graft d'
>> -
Nadeem Vawda added the comment:
>> - test_glob_to_re() was doing two levels of escaping (r'\' -> r'')
>> for its expected output when it should only do one (r'\' -> r'\\').
> Fix merged. I don’t fully understand why one plac
Nadeem Vawda added the comment:
[Éric]
> New docstring:
>
> Tests for scripts in the Tools directory.
>
> This file contains regression tests for some of the scripts found in the
> Tools directory of a Python checkout or tarball, such as reindent.py.
>
> When I
Nadeem Vawda added the comment:
>>> Fix merged. I don’t fully understand why one place needs two escapes and
>>> the others just one.
>> The places that use one level of escaping are the ones that deal with the
>> regex string directly.
>> In glob_to_re(
New submission from Nadeem Vawda :
The ARM Ubuntu 3.x buildbot often fails test_dbm:
http://www.python.org/dev/buildbot/all/builders/ARM%20Ubuntu%203.x/builds/364/steps/test/logs/stdio
http://www.python.org/dev/buildbot/all/builders/ARM%20Ubuntu%203.x/builds/367/steps/test/logs/stdio
http
Nadeem Vawda added the comment:
Also failing on 3.2:
http://www.python.org/dev/buildbot/all/builders/ARM%20Ubuntu%203.2/builds/227/steps/test/logs/stdio
--
versions: +Python 3.2
___
Python tracker
<http://bugs.python.org/issue14
Nadeem Vawda added the comment:
Also failing on the Windows 7 bot:
http://www.python.org/dev/buildbot/all/builders/x86%20Windows7%203.x/builds/4453/steps/test/logs/stdio
--
___
Python tracker
<http://bugs.python.org/issue14
Changes by Nadeem Vawda :
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue14080>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nadeem Vawda added the comment:
3.2 patch looks good on Windows.
--
___
Python tracker
<http://bugs.python.org/issue6884>
___
___
Python-bugs-list mailin
Nadeem Vawda added the comment:
The buildbot still isn't happy:
http://www.python.org/dev/buildbot/all/builders/AMD64%20debian%20bigmem%203.x/builds/144/steps/test/logs/stdio
Also, I ran the test on my own machine and noticed two tests that are
still exceeding their nominal peak m
Nadeem Vawda added the comment:
> For distutils2 however I have no tester and no bot, so could someone test
> this patch?
I'll take a look at it.
> BTW if someone knows about a continuous integration service which provides
> Windows and Mac OS X VMs I’m all ears.
No
Nadeem Vawda added the comment:
This is rather curious. It looks like the assertion includes a (generous)
fudge factor in case the timing code is inaccurate, but then the actual
time taken is *just* short enough to make it fail.
> (the Win7 buildbot for trunk isn't in a good pla
Nadeem Vawda added the comment:
Well... testing distutils2 on Windows has been quite an adventure. When
I ran the test suite before applying the patch, I got a bunch of failures
on all of the Python versions I tested (except the ones that had issues
preventing me from running the tests at all
Nadeem Vawda added the comment:
> Attached a fix that is tested on Windows.
Patch looks good to me.
> Does test.support track the locale for test mutations?
No, it doesn't.
--
___
Python tracker
<http://bugs.python.
Nadeem Vawda added the comment:
> Python provides locale.getlocale().
That was my initial thought too, but it seems that getlocale() doesn't
accept LC_ALL as its argument:
Traceback (most recent call last):
File "", line 1, in
File "/usr/local/lib/pyt
Changes by Nadeem Vawda :
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue14135>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Nadeem Vawda :
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Nadeem Vawda added the comment:
> Yep, I have one of these and downloaded an ISO, but I haven’t yet managed to
> set it up with qemu.
You might want to give VirtualBox a try - I've found it very easy to set up.
> Please file reports for the bugs you’ve found, on this tra
Changes by Nadeem Vawda :
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue14140>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Nadeem Vawda :
--
components: +Windows
nosy: +brian.curtin, loewis, nadeem.vawda, tim.golden
stage: -> needs patch
type: -> compile error
versions: +Python 2.7
___
Python tracker
<http://bugs.python.org/i
Nadeem Vawda added the comment:
> Perhaps the assertEqual changes should be backported to 3.2 and 2.7
> to keep the files in sync (leaving the issue open for that).
Agreed. I'll also make similar changes to the other test cases; my
initial changes only touched the tests that w
Changes by Nadeem Vawda :
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue14139>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nadeem Vawda added the comment:
A very similar failure in test_thread:
http://www.python.org/dev/buildbot/all/builders/x86%20Windows7%203.x/builds/4469/steps/test/logs/stdio
--
status: pending -> open
___
Python tracker
<http://bugs.pyth
Nadeem Vawda added the comment:
A similar failure to msg136576 has cropped up on the Windows 7 bot:
http://www.python.org/dev/buildbot/all/builders/x86%20Windows7%203.x/builds/4469/steps/test/logs/stdio
--
nosy: +nadeem.vawda
___
Python tracker
New submission from Nadeem Vawda :
http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/builds/6075/steps/test/logs/stdio
FAIL: test_time (test.test_ntpath.NtCommonTest)
--
Traceback (most recent call
Nadeem Vawda added the comment:
> Not making excuses, but this one is rather hard to find, as it's pretty hard
> to reproduce. That's why I haven't made any progress :-(
Yeah, not having a reproducible test case is quite a pain.
(I suppose this should be reopened if
301 - 400 of 535 matches
Mail list logo
