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
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:
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
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:
> 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:
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
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:
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
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
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:
> 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 :
--
resolution: -> invalid
stage: -> committed/rejected
status: open -> closed
type: enhancement ->
___
Python tracker
<http://bugs.python
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
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:
> 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
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:
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:
> 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
--
__
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:
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 ...
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
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:
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 :
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:
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 :
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:
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
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
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
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/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
Changes by Nadeem Vawda :
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue5804>
___
___
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/issue8536>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Nadeem Vawda :
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue5210>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nadeem Vawda added the comment:
Either way, the failure should be fixed now.
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> pending
___
Python tracker
<http://bugs.python.or
Nadeem Vawda added the comment:
Do you have a self-compiled version of zlib (1.2.5) installed on this
system? It looks like this is due to a (benign) version mismatch between
zlib.h and the actual shared lib.
--
___
Python tracker
<h
Changes by Nadeem Vawda :
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Nadeem Vawda :
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue12500>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nadeem Vawda added the comment:
Done.
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
type: -> behavior
___
Python tracker
<http://bugs.python
Nadeem Vawda added the comment:
> As far as fixing this for 2.7 goes, i don't like the _sound_ of it
> because it is gross... But i'm actually okay with having special case
> code in the gzip module that rejects '' as an actual filename
> and uses ''
Nadeem Vawda added the comment:
Fix committed. For the test, it turns out we can get the desired behavior
by telling import_fresh_module to block the threading module directly,
instead of blocking _thread.
--
resolution: -> fixed
stage: patch review -> committed/rejected
status
Nadeem Vawda added the comment:
As Georg suggested, it would be better to use dummy_threading.RLock,
rather than providing our own implementation.
The test in the patch fails when I try to run it on a no-thread build.
support.import_fresh_module seems to treat the absence of the threading
Nadeem Vawda added the comment:
Attached is a fix for 3.x.
--
keywords: +patch
Added file: http://bugs.python.org/file24258/gzip-fdopen.diff
___
Python tracker
<http://bugs.python.org/issue13
Nadeem Vawda added the comment:
For 3.x, I think that ignoring non-string names is a reasonable fix. The docs
for io.FileIO specify that its name attribute can be either a path or an integer
file descriptor, and changing this doesn't seem to serve any purpose.
As for the case of 2.7&#x
Nadeem Vawda added the comment:
Patch looks good to me.
--
___
Python tracker
<http://bugs.python.org/issue5689>
___
___
Python-bugs-list mailing list
Unsub
Nadeem Vawda added the comment:
Yes, that's a good idea. I've been testing a similar change, and it seems
to drop the peak memory usage for test_tarfile from around 810MB down to
under 200MB. It looks like 2GB genuinely isn't enough to reliably use LZMA
compression with prese
Nadeem Vawda added the comment:
Not to worry - as I said in my previous message, I can reproduce the error
on my own XP machine.
I also noticed that running test_tarfile alone doesn't trigger the errors,
which leads me to suspect that the failure is due to some interaction with
another
Nadeem Vawda added the comment:
This failure seems to crop up often, but not on every run:
http://www.python.org/dev/buildbot/all/builders/x86%20XP-5%203.x/builds/3941/steps/test/logs/stdio
http://www.python.org/dev/buildbot/all/builders/x86%20XP-5%203.x/builds/3940/steps/test/logs/stdio
Nadeem Vawda added the comment:
Yes, almost half of the buildbots still don't have the xz-utils headers
installed, and thus are not building/testing the lzma module. I've kept
the issue open as a reminder to myself to follow
Nadeem Vawda added the comment:
Great stuff! I'll close this issue along with issue 6715 once the buildbot
stuff is all sorted out.
--
___
Python tracker
<http://bugs.python.org/i
Nadeem Vawda added the comment:
> Ok, I've e-mailed the owners.
Thanks. I was just thinking I should send a reminder, in case they
missed the note in my announcement on python-dev.
> Will someone write an entry in the "what's new
Nadeem Vawda added the comment:
> I’ll commit my doc patch to all branches later.
OK, great.
> I checked the 4 red 3.3 builbots and they can’t build _lzma.
For the record, the 3.x buildbots that currently aren't able to build the
_lzma module are:
* x86 Ubuntu Shared
* sparc so
Nadeem Vawda added the comment:
> As the docs for zlib, gzip, bz2, lzma, zipfile and tarfile are in the
> archiving subsection, there’s already a link to the subsection index,
> so I just removed the “See also zlib, etc.” lines (except for the link
> from zlib to gzip). I added
Changes by Nadeem Vawda :
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue5411>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nadeem Vawda added the comment:
> Instead of duplicating the list of archiving/compression modules in
> each doc, what about only linking to the shutil doc for archives and
> the archiving.rst file?
Sure, go ahead. I actually hadn't realized that each section of the
library d
Nadeem Vawda added the comment:
>> Not meaning to sound petty, but wouldn't it be common etiquette to
>> retain some original copyright notice from original code intact..?
>
> It seemed to me that Nadeem had rewritten everything from scratch. Is
> there any code of y
Nadeem Vawda added the comment:
The patch has been committed. I'm leaving this issue open for a while
longer, until more of the buildbots are building and testing the module.
--
___
Python tracker
<http://bugs.python.org/i
Nadeem Vawda added the comment:
Victor: Thanks for the review; I've replied to your comments and updated
the patch. Let me know what you think of the changes.
--
___
Python tracker
<http://bugs.python.org/i
Changes by Nadeem Vawda :
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue13453>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Nadeem Vawda :
Removed file: http://bugs.python.org/file23466/371a133b770a.diff
___
Python tracker
<http://bugs.python.org/issue6715>
___
___
Python-bugs-list m
Changes by Nadeem Vawda :
Added file: http://bugs.python.org/file23732/9276fc685c05.diff
___
Python tracker
<http://bugs.python.org/issue6715>
___
___
Python-bugs-list m
Nadeem Vawda added the comment:
I've tested the Windows build, and it works fine. If there are no objections,
I'll commit on Saturday.
Btw, what is the preferred channel for communicating with buildbot owners?
I'll want to send out an email asking that all the *nix bots h
Nadeem Vawda added the comment:
Everything is ready to go, as far as I'm concerned. Once I've tested the
Windows build using the binary from the externals repository, I'll be ready
to commit it to the main repository.
--
___
Python
Changes by Nadeem Vawda :
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue13396>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nadeem Vawda added the comment:
I'm no longer getting the failures on either Ubuntu or Windows (and the
Windows buildbots are now green), so tentatively marking this as fixed.
Feel free to reopen if something is still broken.
--
resolution: -> fixed
stage: needs patch ->
Changes by Nadeem Vawda :
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue13309>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nadeem Vawda added the comment:
How strange. I've had no problem reproducing the failures; they've
occurred every time I've run test_packaging since the bug was opened
(on both Ubuntu and Windows). And the Windows buildbots seem to be
failing consi
Nadeem Vawda added the comment:
> I added the packaging.database.clear_cache() at the end of setUp(); that
> works, too.
That fixes the InstallDataTestCase failure for me as well
(on both Ubuntu 11.10 64-bit and Windows 7 64-bit).
> I get the opposite failure to Nadeem
Nadeem Vawda added the comment:
Issue 6434 was marked as a duplicate of this issue.
--
nosy: +Paul, amaury.forgeotdarc, enlavin, lambacck, nadeem.vawda, segfault42
stage: -> needs patch
versions: +Python 3.3 -Python 3.1
___
Python tracker
&l
Nadeem Vawda added the comment:
Marking as duplicate.
--
resolution: -> duplicate
stage: needs patch -> committed/rejected
status: open -> closed
superseder: -> zipfile writes incorrect local file header for large files in
zip64
type: crash
Nadeem Vawda added the comment:
> New changeset 3c225f938dae by Barry Warsaw in branch '2.7':
> - Issue #13218: Fix test_ssl failures on Debian/Ubuntu.
> http://hg.python.org/cpython/rev/3c225f938dae
This changeset appears to have broken a number of the 2.7 Linux bu
Nadeem Vawda added the comment:
I've been able to consistently reproduce the test_resources failure on Ubuntu
11.10 64-bit, FWIW.
--
___
Python tracker
<http://bugs.python.org/is
Nadeem Vawda added the comment:
> Spamlib-0.1.dist-info is in a directory on sys.path, so the error makes no
> sense to me. Can you inspect the content of that directory? (i.e os.listdir
> and file contents) Also, if you can interrupt the test to get a Python or
> pdb shell, c
Nadeem Vawda added the comment:
> none of the buildbots are having this problem.
Actually, it turns out the Ubuntu ARM builder is hitting the same failures.
First failure for each branch was on 14 October (the day after 11.10 came out):
http://www.python.org/dev/buildbot/all/builders/
Changes by Nadeem Vawda :
--
title: test_packaging and test_distutils failures under Windows ->
test_packaging and test_distutils failures
___
Python tracker
<http://bugs.python.org/issu
Nadeem Vawda added the comment:
Issue 13230 (closed as duplicate) reports another Linux failure in
test_resources.
Changing the title, since it isn't Windows-specific.
--
nosy: +anikom15
stage: -> needs patch
___
Python tracke
Nadeem Vawda added the comment:
This seems to be a duplicate of issue 13193.
--
nosy: +nadeem.vawda
resolution: -> duplicate
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Nadeem Vawda :
Added file: http://bugs.python.org/file23466/371a133b770a.diff
___
Python tracker
<http://bugs.python.org/issue6715>
___
___
Python-bugs-list m
Changes by Nadeem Vawda :
Removed file: http://bugs.python.org/file23393/bdf0afbbbd80.diff
___
Python tracker
<http://bugs.python.org/issue6715>
___
___
Python-bugs-list m
Nadeem Vawda added the comment:
Sorry, please disregard my last message - I confused the commit times for
8bbfb24d4824 and f6b8e4226260. There haven't been any further lockups
since f6b8e4226260 was committed.
--
___
Python tracker
Nadeem Vawda added the comment:
The AMD64 FreeBSD 8.2 3.x buildbot has been experiencing sporadic
lockups since changeset 8bbfb24d4824 was committed:
http://www.python.org/dev/buildbot/all/builders/AMD64%20FreeBSD%208.2%203.x/builds/1174/steps/test/logs/stdio
http://www.python.org
Nadeem Vawda added the comment:
> The test creates a temporary directory which is inserted at the head of
> sys.path.
> packaging.database.get_distribution should thus find Spamlib-0.1.dist-info.
> Can someone with a Windows install help me with this? Printing sys.path and
Nadeem Vawda added the comment:
> Hmm... I guess Ubuntu may have aliased SSLv23 to SSLv3. Can someone take
> a look at Ubuntu patches to OpenSSL?
I don't know enough about OpenSSL to make sense of the actual headers on my
system without spending more time on it, but it seems like
Nadeem Vawda added the comment:
Sorry, that wasn't very coherent. What I meant to say is that I tried this:
if ((ssl.OPENSSL_VERSION_INFO, platform.linux_distribution()) in
[((0, 9, 8, 15, 15), ('debian', 'squeeze/sid', '')),
((1, 0,
Nadeem Vawda added the comment:
I get (1, 0, 0, 5, 15) for ssl.OPENSSL_VERSION_INFO. A trivial modification
of Victor's patch doesn't seem to fix the failures for me, though :/
--
___
Python tracker
<http://bugs.python.o
Nadeem Vawda added the comment:
> Also, how about the system Python? Does it show the same test failures?
Unfortunately, it seems that the system Python package doesn't install the
test suite; if you try to run "python -m test.regrtest", it complains that
it can'
New submission from Nadeem Vawda :
Since upgrading to Ubuntu 11.10, I've been getting the following failures in
test_ssl:
==
FAIL: test_protocol_sslv3 (test.test_ssl.ThreadedTests)
Connecting to an SSLv3 s
Nadeem Vawda added the comment:
Fixed for 2.7, 3.2 and 3.3. Thanks for the bug report!
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Nadeem Vawda added the comment:
After disabling a bunch of services and skipping the tests that are
failing on the Windows buildbots, it seems that the failures I was
getting last week have disappeared. It looks like they were due to the
Windows search indexer preventing temp directories from
Nadeem Vawda added the comment:
Confirmed for 3.3. I should be able to post a patch tomorrow.
--
assignee: -> nadeem.vawda
___
Python tracker
<http://bugs.python.org/issu
Nadeem Vawda added the comment:
No problem :)
--
assignee: -> nadeem.vawda
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python
Nadeem Vawda added the comment:
Patch update time! Noteworthy changes:
* Windows build support, thanks to Amaury
* Thread safety for LZMACompressor and LZMADecompressor, by means of
per-instance locks
* O(n) buffer growth strategy
I've tried running the tests on Windows, but I've be
Changes by Nadeem Vawda :
Removed file: http://bugs.python.org/file23168/591277fe6b4a.diff
___
Python tracker
<http://bugs.python.org/issue6715>
___
___
Python-bugs-list m
Changes by Nadeem Vawda :
Added file: http://bugs.python.org/file23393/bdf0afbbbd80.diff
___
Python tracker
<http://bugs.python.org/issue6715>
___
___
Python-bugs-list m
Changes by Nadeem Vawda :
--
stage: needs patch -> patch review
___
Python tracker
<http://bugs.python.org/issue13159>
___
___
Python-bugs-list mailing list
Un
Nadeem Vawda added the comment:
I've attached a patch that makes the suggested change to FileIO, and also
to _bz2.BZ2Compressor/Decompressor (which currently have the same issue).
--
keywords: +patch
Added file: http://bugs.python.org/file23389/buffer-growth
Nadeem Vawda added the comment:
> To elaborate on the policy: giving bogus data in cases of race
> conditions is ok; crashing the interpreter or corrupting memory
> is not. If bogus data is given, it would be useful if the bogosity
> can be specified (e.g. when multiple threads r
New submission from Nadeem Vawda :
As mentioned in issue 6715, the buffer growth strategy used by _io.FileIO
has quadratic running time if each reallocation is O(n). The code in
question is new_buffersize() from Modules/_io/fileio.c:
if (currentsize > SMALLCHUNK) {
/* Keep doubl
Nadeem Vawda added the comment:
Awesome stuff! I'll post an updated patch during the course of the day.
Martin: I've been having problems with Rietveld lately, so I'm posting
my replies to your comments here instead.
>> Modules/_lzmamodule.c:115: return _PyBytes_Resize
201 - 300 of 535 matches
Mail list logo
