Nadeem Vawda nadeem.va...@gmail.com added the comment:
There is already such a function, gzip.decompress() - it was added in 3.2.
--
nosy: +nadeem.vawda
resolution: - invalid
stage: - committed/rejected
status: open - pending
___
Python tracker rep
Nadeem Vawda nadeem.va...@gmail.com added the comment:
The code should be changed to use the buffer API (instead of accepting
only bytes objects). Other than that, I think it's ready for integration.
--
___
Python tracker rep...@bugs.python.org
http
Nadeem Vawda nadeem.va...@gmail.com added the comment:
popitem()
Remove and return an arbitrary (key, value) pair from the dictionary. Raises
KeyError if the dict is empty. Use next(iter(d)) to return an arbitrary pair
without removing it.
Actually, next(iter(d)) on a dict returns
Nadeem Vawda nadeem.va...@gmail.com added the comment:
The functionality looks a bit cryptic to me. What is the use case?
Serializing filter specifiers for custom file formats. The particular
case that prompted adding the code is zipfile (issue 14366).
I've added a note to the docs
Changes by Nadeem Vawda nadeem.va...@gmail.com:
--
nosy: +nadeem.vawda
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14583
___
___
Python-bugs
Nadeem Vawda nadeem.va...@gmail.com added the comment:
Committed as changeset 9118ef2b651a.
--
resolution: - fixed
stage: patch review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Nadeem Vawda nadeem.va...@gmail.com added the comment:
I've committed my patch as changeset 9118ef2b651a, adding functions
encode_filter_properties and decode_filter_properties to the lzma module.
--
___
Python tracker rep...@bugs.python.org
http
Nadeem Vawda nadeem.va...@gmail.com added the comment:
Changeset 9118ef2b651a was broken, but the bug should have been fixed by
changeset 10ccbb90a8e9. Which revision have you been using?
But there are no tests for these functions.
There *are* tests for these functions, and they were failing
Changes by Nadeem Vawda nadeem.va...@gmail.com:
--
nosy: +nadeem.vawda
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14684
___
___
Python-bugs
Nadeem Vawda nadeem.va...@gmail.com added the comment:
I've posted a review on Rietveld.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14684
New submission from Nadeem Vawda nadeem.va...@gmail.com:
Patch attached. Reviews welcome.
--
components: Extension Modules
files: lzma-properties.diff
keywords: patch
messages: 160051
nosy: nadeem.vawda
priority: normal
severity: normal
stage: patch review
status: open
title: Add
Nadeem Vawda nadeem.va...@gmail.com added the comment:
I've put together a patch for the lzma module adding functions for
encoding and decoding filter properties (see issue 14736). It's a bit
bulky, though, so I'd like to get a review before committing
Changes by Nadeem Vawda nadeem.va...@gmail.com:
--
nosy: +nadeem.vawda
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14548
___
___
Python-bugs
Nadeem Vawda nadeem.va...@gmail.com added the comment:
Patch looks good to me.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13902
Nadeem Vawda nadeem.va...@gmail.com added the comment:
I have been able to reproduce it; see attached script. It happens for
inputs of 2GB (decompressed), but not for ones of 1GB.
It seems that bz2module.c doesn't guard against 32-bit overflows when
handling the size of the decompressed data
Nadeem Vawda nadeem.va...@gmail.com added the comment:
(the contents of the input file don't matter; I just pulled out a
bunch of zeros from /dev/zero and compressed them with bzip2.)
--
___
Python tracker rep...@bugs.python.org
http
Changes by Nadeem Vawda nadeem.va...@gmail.com:
--
versions: +Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14398
___
___
Python-bugs
Nadeem Vawda nadeem.va...@gmail.com added the comment:
This should be fixed for 2.7.3. I'll have a patch ready in the next day
or two.
--
nosy: +benjamin.peterson, georg.brandl
priority: normal - release blocker
___
Python tracker rep
Nadeem Vawda nadeem.va...@gmail.com added the comment:
No, it's been around since at least 2.6. I wasn't really sure what the
protocol was for bugs found during the RC process. It'd be nice to get
a fix for this into 2.7.3 (and 3.2.3), but it's not urgent.
--
priority: release blocker
Nadeem Vawda nadeem.va...@gmail.com added the comment:
That's fine by me, then. Sorry for the confusion.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14398
Nadeem Vawda nadeem.va...@gmail.com added the comment:
[Adding Alan McIntyre, who is listed as zipfile's maintainer.]
I haven't yet had a chance to properly familiarize myself with the
zipfile module, but I did notice an issue in the changes to ZipExtFile's
read() method. The existing code
Nadeem Vawda nadeem.va...@gmail.com added the comment:
I plan on doing a review of the patch, but it might be a week or two
before I have time to do it.
Regarding changes to lzma; exactly what is being proposed? If it's just
additional functions for encoding and decoding of filter specs
Nadeem Vawda nadeem.va...@gmail.com added the comment:
You made a mess. The existing code uses ``buf += data``, but I allowed myself
to replace it with the ``b.join()`` idiom. The bzip2 codec has to deal with
large pieces of data, now this may be important. In read1 still used ``buf
Changes by Nadeem Vawda nadeem.va...@gmail.com:
--
nosy: +alanmcintyre, nadeem.vawda
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14366
Nadeem Vawda nadeem.va...@gmail.com added the comment:
Jesús, did you have any particular idea about exactly where these new
features would be useful? Or was your idea that someone needs to read
through the code and check whether the features can be used at all?
Also, it should be noted
Nadeem Vawda nadeem.va...@gmail.com added the comment:
This looks similar to a sporadic failure on the debian bigmem buildbot:
http://www.python.org/dev/buildbot/all/builders/AMD64%20debian%20bigmem%203.x/builds/168/steps/test/logs/stdio
ERROR: test_expanduser
Changes by Nadeem Vawda nadeem.va...@gmail.com:
--
nosy: +nadeem.vawda
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14229
___
___
Python-bugs
Nadeem Vawda nadeem.va...@gmail.com added the comment:
Is this a single failure that you encountered, or have you been able to
reproduce it on subsequent runs? I haven't seen a failure in
test_concurrent_futures in 10-15 runs of make test (also on Ubuntu
11.10 64-bit).
--
nosy
Nadeem Vawda nadeem.va...@gmail.com added the comment:
I happended several times.
Hmm. If you hit another failure, can you post the random seed and any
other interesting info that might help figure this out?
The test_dbm failures look like issue 14120. You might want to follow up
Nadeem Vawda nadeem.va...@gmail.com added the comment:
I had intended to wait until the code had been tested on all of the
buildbots before closing it. However, it's taking a while to get xz-utils
installed on the last few bots, so it doesn't make sense to keep the
issue open
Changes by Nadeem Vawda nadeem.va...@gmail.com:
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5689
___
___
Python-bugs
Changes by Nadeem Vawda nadeem.va...@gmail.com:
--
nosy: +eric.araujo, nadeem.vawda
stage: - patch review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14183
Nadeem Vawda nadeem.va...@gmail.com added the comment:
-install.install_dists = lambda x, y=None: None
+install.install_dists = lambda x, y = None: None
PEP 8: Never put spaces in a function (or lambda) signature.
I cannot find that exactly in pep8.
From the section
Nadeem Vawda nadeem.va...@gmail.com added the comment:
The same failure has appeared on the Debian bigmem buildbot:
http://www.python.org/dev/buildbot/all/builders/AMD64%20debian%20bigmem%203.x/builds/152/steps/test/logs/stdio
--
versions: +Python 3.3
Changes by Nadeem Vawda nadeem.va...@gmail.com:
--
nosy: +nadeem.vawda
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14154
___
___
Python-bugs
Changes by Nadeem Vawda nadeem.va...@gmail.com:
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14113
___
___
Python-bugs
Changes by Nadeem Vawda nadeem.va...@gmail.com:
--
resolution: - fixed
stage: needs patch - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13873
Nadeem Vawda nadeem.va...@gmail.com 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
Changes by Nadeem Vawda nadeem.va...@gmail.com:
--
nosy: +nadeem.vawda
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14140
___
___
Python-bugs
Changes by Nadeem Vawda nadeem.va...@gmail.com:
--
components: +Windows
nosy: +brian.curtin, loewis, nadeem.vawda, tim.golden
stage: - needs patch
type: - compile error
versions: +Python 2.7
___
Python tracker rep...@bugs.python.org
http
Nadeem Vawda nadeem.va...@gmail.com 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
Changes by Nadeem Vawda nadeem.va...@gmail.com:
--
nosy: +nadeem.vawda
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14139
___
___
Python-bugs
Nadeem Vawda nadeem.va...@gmail.com 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 rep
Nadeem Vawda nadeem.va...@gmail.com 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
New submission from Nadeem Vawda nadeem.va...@gmail.com:
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
Nadeem Vawda nadeem.va...@gmail.com 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
Nadeem Vawda nadeem.va...@gmail.com 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
Nadeem Vawda nadeem.va...@gmail.com 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
Nadeem Vawda nadeem.va...@gmail.com 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
Nadeem Vawda nadeem.va...@gmail.com 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 rep...@bugs.python.org
http
Nadeem Vawda nadeem.va...@gmail.com 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 stdin, line 1, in module
File /usr/local/lib
Changes by Nadeem Vawda nadeem.va...@gmail.com:
--
nosy: +nadeem.vawda
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14135
___
___
Python-bugs
Nadeem Vawda nadeem.va...@gmail.com 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 nadeem.va...@gmail.com 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 place needs two escapes and the
others just one.
I
Nadeem Vawda nadeem.va...@gmail.com 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 commit I’ll
Nadeem Vawda nadeem.va...@gmail.com 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() itself, the string you're
New submission from Nadeem Vawda nadeem.va...@gmail.com:
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
Nadeem Vawda nadeem.va...@gmail.com 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 rep...@bugs.python.org
http
Nadeem Vawda nadeem.va...@gmail.com 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 rep...@bugs.python.org
http
Changes by Nadeem Vawda nadeem.va...@gmail.com:
--
nosy: +nadeem.vawda
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14080
___
___
Python-bugs
Nadeem Vawda nadeem.va...@gmail.com added the comment:
3.2 patch looks good on Windows.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6884
Nadeem Vawda nadeem.va...@gmail.com 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
Nadeem Vawda nadeem.va...@gmail.com 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 be pretty
Nadeem Vawda nadeem.va...@gmail.com 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 not converting some
New submission from Nadeem Vawda nadeem.va...@gmail.com:
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
Changes by Nadeem Vawda nadeem.va...@gmail.com:
--
dependencies: +Impossible to include file in sdist that starts with 'build' on
Win32
stage: needs patch - patch review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14106
Changes by Nadeem Vawda nadeem.va...@gmail.com:
--
nosy: +nadeem.vawda
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5438
___
___
Python-bugs-list
New submission from Nadeem Vawda nadeem.va...@gmail.com:
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
Changes by Nadeem Vawda nadeem.va...@gmail.com:
--
nosy: +nadeem.vawda
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14109
___
___
Python-bugs
New submission from Nadeem Vawda nadeem.va...@gmail.com:
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
Nadeem Vawda nadeem.va...@gmail.com 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
Nadeem Vawda nadeem.va...@gmail.com 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 nadeem.va...@gmail.com 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
Nadeem Vawda nadeem.va...@gmail.com 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
Nadeem Vawda nadeem.va...@gmail.com 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
Nadeem Vawda nadeem.va...@gmail.com 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
Nadeem Vawda nadeem.va...@gmail.com added the comment:
For the xztar format, you should also perhaps recognize the .txz
extension - I've seen this used by FreeBSD.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5411
Nadeem Vawda nadeem.va...@gmail.com 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
Changes by Nadeem Vawda nadeem.va...@gmail.com:
--
nosy: +nadeem.vawda
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13447
___
___
Python-bugs
Nadeem Vawda nadeem.va...@gmail.com 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 nadeem.va...@gmail.com:
--
nosy: +haypo, loewis, pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13873
___
___
Python
Nadeem Vawda nadeem.va...@gmail.com 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 call
Changes by Nadeem Vawda nadeem.va...@gmail.com:
--
nosy: +bethard
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14075
___
___
Python-bugs-list
Nadeem Vawda nadeem.va...@gmail.com 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
Nadeem Vawda nadeem.va...@gmail.com added the comment:
Shouldn't be --rev qparent ?
Yes, that's right. I seem to confuse qbase and qparent often...
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14053
Nadeem Vawda nadeem.va...@gmail.com 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
Nadeem Vawda nadeem.va...@gmail.com 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
Nadeem Vawda nadeem.va...@gmail.com 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.
The problem
Changes by Nadeem Vawda nadeem.va...@gmail.com:
--
nosy: +nadeem.vawda
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14053
___
___
Python-bugs
Nadeem Vawda nadeem.va...@gmail.com 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
Nadeem Vawda nadeem.va...@gmail.com 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
Changes by Nadeem Vawda nadeem.va...@gmail.com:
--
nosy: +nadeem.vawda
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14040
___
___
Python-bugs
Changes by Nadeem Vawda nadeem.va...@gmail.com:
--
nosy: +nadeem.vawda
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6884
___
___
Python-bugs-list
Nadeem Vawda nadeem.va...@gmail.com 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
Nadeem Vawda nadeem.va...@gmail.com 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
Nadeem Vawda nadeem.va...@gmail.com 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 work
Nadeem Vawda nadeem.va...@gmail.com added the comment:
Ah, I suppose that makes sense.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13878
Nadeem Vawda nadeem.va...@gmail.com 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
Nadeem Vawda nadeem.va...@gmail.com 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 suspect you
Nadeem Vawda nadeem.va...@gmail.com 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
101 - 200 of 536 matches
Mail list logo
