> Transmitting file data .........subversion/libsvn_client/commit.c:832: (apr_err=165001)
> svn: Commit failed (details follow):
> /build/buildd/subversion-1.4.2dfsg1/subversion/libsvn_repos/hooks.c:135: (apr_err=165001)
> svn: 'pre-commit' hook failed with error output:
> file /python/trunk/Lib/ssl.py is not whitespace-normalized
So, the pre-commit hook is blocking me; how do I trouble-shoot this?
What's the client-side way to run this scan? Can I add it to the
On 8/29/07, Bill Janssen <janssen(a)parc.com> wrote:
> > Transmitting file data .........subversion/libsvn_client/commit.c:832:
> > svn: Commit failed (details follow):
> > /build/buildd/subversion-1.4.2dfsg1/subversion/libsvn_repos/hooks.c:135:
> > svn: 'pre-commit' hook failed with error output:
> > file /python/trunk/Lib/ssl.py is not whitespace-normalized
> So, the pre-commit hook is blocking me; how do I trouble-shoot this?
> What's the client-side way to run this scan? Can I add it to the
> regression-test harness?
It basically calls Tools/scripts/reindent.py with --dry-run (although I
notice the version we call from SVN is more forgiving towards tokenizer
errors. I'm not sure we need that here.) Incorporating it in the normal test
suit would be good, as I've been caught by the same problem several times
Thomas Wouters <thomas(a)python.org>
Hi! I'm a .signature virus! copy me into your .signature file to help me
apt-get install openssl will fix that on those systems. on windows you're
unlikely to ever have an openssl binary present and available to execute.
On 8/26/07, Bill Janssen <janssen(a)parc.com> wrote:
> Now it looks as if both the Debian and Ubuntu failures are failing
> because they can't create a certificate, just like the Windows test.
> I'll go out on a limb here and guess that it's because "openssl" isn't
> on the path of the user running the tests.
> That would also account for the other stack traces, if the keyfile
> or certfile didn't actually contain a key or a cert.
> Python-Dev mailing list
First, some background.
I've recently tried to port a certain library that manipulates dates
from C. Some of the core functions contain heavy integer math (very long
formulae), and after implementing them I tested them to see the give the
I got very odd results, which surprised me since I copied the formula
letter to letter.
I decided to investigate further, and after trying to evaluate several
expressions in the python console, I realized it was the integer
For some reason, the integer division behaves unexpectedly for negative
Looking deeper in the python PEPs, I saw that division on integers is
defined as: idiv(a, b) = floor(fdiv(a, b)).
This non-quotient division leads to some odd results, e.g. Python seems
to think -3/2+3/2 = -1. This is clearly, and correct me if I'm mistaken
Now, seeing as Python 3000 is getting closer, and backwards
compatibility isn't an issue, I believe it would be a good idea to
change the // operator (which will be used for integer division) to
behave as quotient, i.e.: a // b = trunc(a / b)
I've taken the week off and I'm trying to do something useful for Python in
some of my time. I've basically been looking through the entries sorted by
priority and least recent activity.
Some items I've been able to do something with (like the "immediate"
priority %formatting bug #1467929, and the "high" priority bz2 module bug
#1597011). Others I've been just kind of prodding people to take some
action on, just kind of getting them in front of people again. Keeping
them "fresh" instead of just letting them stagnate...
I kind of figure that something that's in "high" priority, that has been
sitting there for 46 months, either needs to have some activity on it
or should be pushed to a lower priority.
I've also been tempted to try to triage some of the bugs without assigned
priorities, guessing a priority, that sort of thing.
Is doing this sort of triage or administration work useful? Any
recommendations on what you'd like to have happen in this sort of task?
Obtuse: Not pointed or acute. Exceeding 90 degrees but less than 180 degrees.
OOOooh! Rounded at the free end. Dull... Hey! That's an insult! -- WKRP
Sean Reifschneider, Member of Technical Staff <jafo(a)tummy.com>
tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability
I think it's time you get to do your own checkins. There's a protocol
but I forget how to do it -- I think you mail your ssh key to Martin.
On 8/28/07, Bill Janssen <janssen(a)parc.com> wrote:
> So, the patch is attached to issue 1052. I sent it out to python-dev,
> but it got blocked (too big).
> This contains a number of things:
> 1) Improve the documentation of the SSL module, with a fuller
> explanation of certificate usage, another reference, proper
> formatting of this and that.
> 2) Fix Windows bug in ssl.py, and general bug in sslsocket.close().
> Remove some unused code from ssl.py. Allow accept() to be called on
> sslsocket sockets.
> 3) Use try-except-else in import of ssl in socket.py. Deprecate use of
> 4) Remove use of socket.ssl() in every library module, except for
> test_socket_ssl.py and test_ssl.py.
--Guido van Rossum (home page: http://www.python.org/~guido/)
On 8/26/07, Bill Janssen <janssen(a)parc.com> wrote:
> > This occurs on at least 3 of the buildbots (ubuntu and debian on ia64,
> > ppc, and hppa). Here's one example:
> > http://python.org/dev/buildbot/all/ia64%20Ubuntu%20trunk%20trunk/builds/832…
> If I'm reading this right, it's passing tests on "amd64 gentoo trunk",
> "x86 gentoo trunk", "g4 osx.4 trunk" (no surprise there).
> And looking at the community buildbots, it works on "x86 Redhat 9",
> "x86 Debian unstable", "amd64 Ubuntu gutsy", "G5 OS X", and so on.
> I've tested it myself on FC 7 and it works.
> And looking at the "ppc Debian unstable" case, test_socket is also
> failing there, so the test_ssl failure is not a big surprise.
> I'm not familiar with what's in Debian "trunk" or Ubuntu "trunk"; any
> idea what version of OpenSSL they have in them?
For ia64 http://python.org/dev/buildbot/all/ia64%20Ubuntu%20trunk%20trunk/builds/833…
pybot@noisy:~$ openssl version
OpenSSL 0.9.8b 04 May 2006
I have access to some of the machines but not all of them. All of
these run inside a chroot which might be causing a problem. I
remember some issues with getting socket stuff to work right on them.
But that was over a year ago and I don't remember the details now.
:-( svn/google probably knows if you want to trawl through checkins.
I'm not sure that will help much though.
On this machines I was able to successfully make a key. That's why
I'm thinking it might be some strange socket issue.
> But I think this exposes a more generic bug in test_ssl.py, which is
> that the server thread doesn't die when one of these failures occurs.
> It probably should. I'll make a patch -- but I don't have a system
> that this fails on, how will I test it?
Yeah, I know this is difficult. Hopefully someone with WIndows will
step up to help. We can at least make the test more robust and verify
the files exist and are non-zero in size. I will do that now. At
least the it shouldn't cause the test to time out.
Mark Dickinson helped a lot (*a lot*) with the decimal branch, and
we're near to pass the brand new test cases from Cowlishaw.
My original idea is to update all the documentation before merging the
branch into the trunk, but now that they changed so much, I don't know
what to do:
- Update all the Doc dir in the branch with the new Doc dir in the
trunk, fix the docs, and make the merge.
- Merge the branch, and fix the docs directly in the trunk (I promise
to fix them months before 2.6a0).
Thanks for the advice!
Could you also look into this problem:
Traceback (most recent call last):
line 486, in __bootstrap_inner
line 144, in run
line 98, in __init__
cert_reqs, ssl_version, ca_certs)
sslerror: _ssl.c:271: SSL_CTX_use_PrivateKey_file error
This occurs on at least 3 of the buildbots (ubuntu and debian on ia64,
ppc, and hppa). Here's one example:
This also looks like it's not working on windows, but there is no info
The system cannot find the path specified.
Which happens after it hangs for 1200 seconds.
On 8/25/07, Bill Janssen <janssen(a)parc.com> wrote:
> I've gone through the other open SSL issues. Looks like some can be
> closed with the adoption of 1018 and 1024:
> 1027394 4 months ago socket.ssl should explain that it is a 2/3 connection
> 889813 4 months ago making the version of SSL configurable when creating sockets
> 1583946 9 months ago SSL "issuer" and "server" names cannot be parsed
> 783188 46 months ago support for server side transactions in _ssl
> Others are about various standard libraries that interact with SSL
> in various ways. I'm working on another patch that converts all the
> standard library modules over to use the new ssl module, and I'll look
> at the rest of the SSL-related bugs as part of that work.
> Python-Dev mailing list
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/nnorwitz%40gmail.com