[issue2698] Extension module build fails for MinGW: missing vcvarsall.bat

2012-01-02 Thread Bill Janssen

Bill Janssen  added the comment:

Actually, when using setup.py with MinGW, you just need to say the right thing:

  % python setup.py build --compiler=mingw32 install

That removes the check for vcvarsall.bat.

Bill

On Mon, Jan 2, 2012 at 6:19 AM, Piotr Dobrogost  wrote:
>
> Piotr Dobrogost  added the comment:
>
> @Lehmann
>
> You have to have either Visual Studio 2008 or Visual C++ Express 2008 
> installed. The folder where vcvarsall.bat file is being looked for is read 
> from the registry. It's either 
> HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\9.0\Setup\VC 
> (for Visual Studio) or 
> HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VCExpress\9.0\Setup\VC (for 
> Visual C++ Express).
>
> --
> nosy: +piotr.dobrogost
>
> ___
> Python tracker 
> <http://bugs.python.org/issue2698>
> ___

--

___
Python tracker 
<http://bugs.python.org/issue2698>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue6560] socket sendmsg(), recvmsg() methods

2011-09-12 Thread Bill Janssen

Bill Janssen  added the comment:

I'm guessing these things are due to interaction with some Apple
security update, as the buildbots were working well 8 months ago.

Bill

On Wed, Sep 7, 2011 at 4:01 PM, Nick Coghlan  wrote:
>
> Nick Coghlan  added the comment:
>
> If Bill gets a chance to investigate this before the weekend, great, 
> otherwise my plan to stop making noise in the buildbot results will be to:
>
> 1. Create a separate issue specifically for the errors reported by the Mac OS 
> X buildbots (allowing the problem to be spelled out more clearly for readers, 
> and also allowing the feature request itself to be closed)
>
> 2. Flag the offending tests as expected failures on Mac OS X, with a pointer 
> back to the new tracker issue.
>
> That way, if these failures are due to underlying OS bugs or limitations (as 
> they appear to be), we'll get a clear indication in the buildbots when Apple 
> have fixed the relevant problems.
>
> --
>
> ___
> Python tracker 
> <http://bugs.python.org/issue6560>
> ___
>

--

___
Python tracker 
<http://bugs.python.org/issue6560>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue6560] socket sendmsg(), recvmsg() methods

2011-09-02 Thread Bill Janssen

Bill Janssen  added the comment:

I'll take a look at this next week, when I'm more on-line again.

Bill

2011/8/25 Charles-François Natali :
>
> Charles-François Natali  added the comment:
>
>> The OS X buildbots show some failures:
>
> It seems to fail consistently on every OS X version.
> I've had another look both at the code and the test, and couldn't find 
> anything wrong with it.
> Since there are a number of known bugs pertaining to FD passing on OS X - 
> even on recent versions - I'd suggest to skip those tests on this platform.
> As for sendto/sendmsg not being interrupted by the signal, I'd be curious to 
> see if running test_socket alone solves the problem (just to make sure no 
> other thread is running, which might receive the signal).
>
> --
>
> ___
> Python tracker 
> <http://bugs.python.org/issue6560>
> ___
>

--

___
Python tracker 
<http://bugs.python.org/issue6560>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue12765] test_packaging failure under Snow Leopard

2011-08-31 Thread Bill Janssen

Bill Janssen  added the comment:

I'm on vacation right now and can't get to it...

Bill

On Thu, Aug 18, 2011 at 12:22 PM, Antoine Pitrou  wrote:
>
> Antoine Pitrou  added the comment:
>
> Bill is the owner of that buildbot.
>
> --
> nosy: +janssen
>
> ___
> Python tracker 
> <http://bugs.python.org/issue12765>
> ___
>

--

___
Python tracker 
<http://bugs.python.org/issue12765>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue5117] os.path.relpath problem with root directory

2010-10-18 Thread Bill Janssen

Bill Janssen  added the comment:

Then we need to revert this patch and find one that works.

--
resolution: fixed -> 

___
Python tracker 
<http://bugs.python.org/issue5117>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue5117] os.path.relpath problem with root directory

2010-10-18 Thread Bill Janssen

Bill Janssen  added the comment:

Broke bunches of 2.7 buildbots.  But why are we running test_ntpath on OS X, 
anyway?  Shouldn't this be skipped everywhere except win32 platforms?

--
nosy: +janssen

___
Python tracker 
<http://bugs.python.org/issue5117>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue8845] Expose sqlite3 connection inTransaction as read-only in_transaction attribute

2010-10-16 Thread Bill Janssen

Bill Janssen  added the comment:

PPC Tiger is using Python 2.7, so it's 3.6.11.

Python 3.X also seems to be failing the sqlite tests on PPC Leopard.  Is the 
required version # different between 3.1 and 3.x?

--

___
Python tracker 
<http://bugs.python.org/issue8845>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue9455] platform test borked in 2.7 branch on Power PC

2010-08-02 Thread Bill Janssen

Bill Janssen  added the comment:

So the problem is in the _mac_ver_xml() routine in Lib/platform.py, which says:


machine = os.uname()[4]
if machine == 'ppc':
# for compatibility with the gestalt based code
machine = 'PowerPC'

and perhaps should say:

machine = os.uname()[4]
if machine in ('ppc', 'Power Macintosh'):
# for compatibility with the gestalt based code
machine = 'PowerPC'

--

___
Python tracker 
<http://bugs.python.org/issue9455>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue9455] platform test borked in 2.7 branch on Power PC

2010-08-02 Thread Bill Janssen

Bill Janssen  added the comment:

This is on a PowerPC machine running Leopard:

>>> os.uname()[4]
'Power Macintosh'
>>>

--

___
Python tracker 
<http://bugs.python.org/issue9455>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue9455] platform test borked in 2.7 branch on Power PC

2010-08-02 Thread Bill Janssen

New submission from Bill Janssen :

Looks like some test borked the 2.7 tests on the buildbots.  Here's the 
offending test:


test test_platform failed -- Traceback (most recent call last):
  File 
"/Users/buildbot/buildarea/2.7.parc-leopard-1/build/Lib/test/test_platform.py", 
line 196, in test_mac_ver
self.assertEquals(res[2], 'PowerPC')
AssertionError: 'Power Macintosh' != 'PowerPC'

Re-running test 'test_platform' in verbose mode
test_architecture (test.test_platform.PlatformTest) ... ok
test_architecture_via_symlink (test.test_platform.PlatformTest) ... [17052 refs]
[17052 refs]
ok
test_dist (test.test_platform.PlatformTest) ... ok
test_java_ver (test.test_platform.PlatformTest) ... ok
test_libc_ver (test.test_platform.PlatformTest) ... ok
test_mac_ver (test.test_platform.PlatformTest) ... FAIL
test_mac_ver_with_fork (test.test_platform.PlatformTest) ... ok
test_machine (test.test_platform.PlatformTest) ... ok
test_node (test.test_platform.PlatformTest) ... ok
test_parse_release_file (test.test_platform.PlatformTest) ... ok
test_platform (test.test_platform.PlatformTest) ... ok
test_processor (test.test_platform.PlatformTest) ... ok
test_release (test.test_platform.PlatformTest) ... ok
test_sys_version (test.test_platform.PlatformTest) ... ok
test_system (test.test_platform.PlatformTest) ... ok
test_system_alias (test.test_platform.PlatformTest) ... ok
test_uname (test.test_platform.PlatformTest) ... ok
test_uname_win32_ARCHITEW6432 (test.test_platform.PlatformTest) ... skipped 
'windows only test'
test_version (test.test_platform.PlatformTest) ... ok
test_win32_ver (test.test_platform.PlatformTest) ... ok

==
FAIL: test_mac_ver (test.test_platform.PlatformTest)
--
Traceback (most recent call last):
  File 
"/Users/buildbot/buildarea/2.7.parc-leopard-1/build/Lib/test/test_platform.py", 
line 196, in test_mac_ver
self.assertEquals(res[2], 'PowerPC')
AssertionError: 'Power Macintosh' != 'PowerPC'

--
Ran 20 tests in 6.468s

FAILED (failures=1, skipped=1)
test test_platform failed -- Traceback (most recent call last):
  File 
"/Users/buildbot/buildarea/2.7.parc-leopard-1/build/Lib/test/test_platform.py", 
line 196, in test_mac_ver
self.assertEquals(res[2], 'PowerPC')
AssertionError: 'Power Macintosh' != 'PowerPC'

--
assignee: ronaldoussoren
components: Library (Lib), Tests
messages: 112516
nosy: janssen, ronaldoussoren
priority: normal
severity: normal
status: open
title: platform test borked in 2.7 branch on Power PC
type: behavior
versions: Python 2.7

___
Python tracker 
<http://bugs.python.org/issue9455>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue8447] buildbot: test_httpservers failure (No module named operator)

2010-06-26 Thread Bill Janssen

Bill Janssen  added the comment:

Failing on my PPC Tiger OS X buildbot, with 2.6, too.

--
nosy: +janssen
versions: +Python 2.6

___
Python tracker 
<http://bugs.python.org/issue8447>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue8621] uuid.uuid4() generates non-unique values on OSX

2010-06-26 Thread Bill Janssen

Bill Janssen  added the comment:

Stefan, I tried your suggestion of starting threading.  Test still succeeds on 
my 10.5.8 system when test_uuid is run separately.

Ronald, your fix works on my 10.5.8 system.  Why not check it in, and let's see 
if the buildbots turn green again?

--

___
Python tracker 
<http://bugs.python.org/issue8621>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue9048] no OS X buildbots in the stable list

2010-06-23 Thread Bill Janssen

Bill Janssen  added the comment:

Bit of a chicken/egg issue here.  Since we haven't had OS X buildbots for very 
long, and the ones we do have represent odd configurations, I think it's 
premature to say that "the port *doesn't* pass the test suite on
a regular manner".  I think it's just as reasonable to say that the developers 
making changes just aren't aware of bad side-effects on OS X.  A good way to 
remedy that would be to make those bad side-effects more apparent, for example 
by adding an OS X buildbot into the "stable" set.

Another issue is that none of the three OS X buildbots now running are really 
good representatives of the technology that most people I know who use OS X 
really use.  That would be an Intel Core 2 Duo machine running Snow Leopard.

--

___
Python tracker 
<http://bugs.python.org/issue9048>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue8621] uuid.uuid4() generates non-unique values on OSX

2010-06-21 Thread Bill Janssen

Bill Janssen  added the comment:

This is on an Intel machine running OS X 10.5.8.  I downloaded and built 2.7rc2 
from source with "./configure ; make".  I then ran the tests with "make test".  
test_uuid fails with this output:


test test_uuid failed -- Traceback (most recent call last):
  File "/private/tmp/Python-2.7rc2/Lib/test/test_uuid.py", line 472, in 
testIssue8621
self.assertNotEqual(parent_value, child_value)
AssertionError: '751ca85de22f4450b7f95dd3f82c7e5f' == 
'751ca85de22f4450b7f95dd3f82c7e5f'

However, when I run the test standalone with this command-line, it passes:

% ./python.exe -Wd -3 -E -tt ./Lib/test/regrtest.py -l test_uuid
test_uuid
1 test OK.

Not sure what's going on.

--
nosy: +janssen

___
Python tracker 
<http://bugs.python.org/issue8621>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue9052] 2.7rc2 fails test_urllib_localnet tests on OS X

2010-06-21 Thread Bill Janssen

New submission from Bill Janssen :

% ./python.exe -Wd -3 -E -tt ./Lib/test/regrtest.py -v test_urllib2_localnet
== CPython 2.7rc2 (r27rc2:82137, Jun 21 2010, 12:50:22) [GCC 4.0.1 (Apple Inc. 
build 5493)]
==   Darwin-9.8.0-i386-32bit little-endian
==   /private/tmp/Python-2.7rc2/build/test_python_58063
test_urllib2_localnet
test_proxy_qop_auth_int_works_or_throws_urlerror 
(test.test_urllib2_localnet.ProxyAuthTests) ... ok
test_proxy_qop_auth_works (test.test_urllib2_localnet.ProxyAuthTests) ... ok
test_proxy_with_bad_password_raises_httperror 
(test.test_urllib2_localnet.ProxyAuthTests) ... FAIL
test_proxy_with_no_password_raises_httperror 
(test.test_urllib2_localnet.ProxyAuthTests) ... FAIL
test_200 (test.test_urllib2_localnet.TestUrlopen) ... ok
test_200_with_parameters (test.test_urllib2_localnet.TestUrlopen) ... ok
test_404 (test.test_urllib2_localnet.TestUrlopen) ... ok
test_bad_address (test.test_urllib2_localnet.TestUrlopen) ... ok
test_basic (test.test_urllib2_localnet.TestUrlopen) ... ok
test_geturl (test.test_urllib2_localnet.TestUrlopen) ... ok
test_info (test.test_urllib2_localnet.TestUrlopen) ... ok
test_redirection (test.test_urllib2_localnet.TestUrlopen) ... ok
test_sending_headers (test.test_urllib2_localnet.TestUrlopen) ... ok

==
FAIL: test_proxy_with_bad_password_raises_httperror 
(test.test_urllib2_localnet.ProxyAuthTests)
--
Traceback (most recent call last):
  File "/private/tmp/Python-2.7rc2/Lib/test/test_urllib2_localnet.py", line 
264, in test_proxy_with_bad_password_raises_httperror
self.URL)
AssertionError: HTTPError not raised

==
FAIL: test_proxy_with_no_password_raises_httperror 
(test.test_urllib2_localnet.ProxyAuthTests)
--
Traceback (most recent call last):
  File "/private/tmp/Python-2.7rc2/Lib/test/test_urllib2_localnet.py", line 
270, in test_proxy_with_no_password_raises_httperror
self.URL)
AssertionError: HTTPError not raised

--
Ran 13 tests in 9.050s

FAILED (failures=2)
test test_urllib2_localnet failed -- multiple errors occurred
1 test failed:
test_urllib2_localnet
/tmp/Python-2.7rc2 397 %

--
messages: 108314
nosy: janssen
priority: high
severity: normal
stage: needs patch
status: open
title: 2.7rc2 fails test_urllib_localnet tests on OS X
type: behavior
versions: Python 2.7

___
Python tracker 
<http://bugs.python.org/issue9052>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue9048] no OS X buildbots in the stable list

2010-06-21 Thread Bill Janssen

Changes by Bill Janssen :


--
components: +None
keywords: +buildbot
versions:  -Python 2.7

___
Python tracker 
<http://bugs.python.org/issue9048>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue9048] no OS X buildbots in the stable list

2010-06-21 Thread Bill Janssen

New submission from Bill Janssen :

Considering the number of OS X machines running Python programs, it would be 
good idea to get this platform into the "stable" list of buildbots so that 
releases are checked against it.

--
messages: 108302
nosy: janssen
priority: normal
severity: normal
status: open
title: no OS X buildbots in the stable list
versions: Python 2.7

___
Python tracker 
<http://bugs.python.org/issue9048>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue8446] buildbot: DeprecationWarning not raised for icglue (test_py3kwarn.TestStdlibRemovals)

2010-05-23 Thread Bill Janssen

Bill Janssen  added the comment:

Not sure I understand this patch.  Either the icglue module is removed in 
python 3, in which case it should raise the deprecation warning, or it is not, 
in which case it should be removed from the list of modules checked in 
test_py3kwarn.  Shouldn't the patch also address one of these two cases?

--
nosy: +janssen

___
Python tracker 
<http://bugs.python.org/issue8446>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue8716] test_tk fails on OS X if run from buildbot slave daemon -- crashes Python

2010-05-14 Thread Bill Janssen

Bill Janssen  added the comment:

It's fairly easy to create a restricted process tree for testing.  ssh into a 
Mac which has no one logged into the console, from another machine, and use 
that connection to launch an xterm or Xemacs window to the other machine.  Then 
log out of the ssh session.  The session running in the xterm will now have no 
access privileges to the window server, and can be used for testing.

--

___
Python tracker 
<http://bugs.python.org/issue8716>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue8716] test_tk fails on OS X if run from buildbot slave daemon -- crashes Python

2010-05-14 Thread Bill Janssen

Bill Janssen  added the comment:

[More info from Ronald Oussoren]

This is a bug in Tk: 

>>> root = Tkinter.Tk()
Thu May 13 20:45:13 Rivendell.local python[84887] : kCGErrorFailure: Set 
a breakpoint @ CGErrorBreakpoint() to catch errors as they are logged.
_RegisterApplication(), FAILED TO establish the default connection to the 
WindowServer, _CGSDefaultConnection() is NULL.
>>> 2010-05-13 20:45:16.751 Python[84887:d07] An uncaught exception was raised
2010-05-13 20:45:16.762 Python[84887:d07] Error (1002) creating CGSWindow
2010-05-13 20:45:16.955 Python[84887:d07] *** Terminating app due to uncaught 
exception 'NSInternalInconsistencyException', reason: 'Error (1002) creating 
CGSWindow'
*** Call stack at first throw:
(
0   CoreFoundation  0x7fff85e31d24 
__exceptionPreprocess + 180
1   libobjc.A.dylib 0x7fff86f3 
objc_exception_throw + 45
2   CoreFoundation  0x7fff85e31b47 
+[NSException raise:format:arguments:] + 103
3   CoreFoundation  0x7fff85e31ad4 
+[NSException raise:format:] + 148
4   AppKit  0x7fff84614aba 
_NSCreateWindowWithOpaqueShape2 + 473
5   AppKit  0x7fff845a9055 -[NSWindow 
_commonAwake] + 1214
6   AppKit  0x7fff845c6d3d -[NSWindow 
_makeKeyRegardlessOfVisibility] + 96
7   AppKit  0x7fff845c6cb2 -[NSWindow 
makeKeyAndOrderFront:] + 24
8   Tk  0x00010075b86c XMapWindow + 
155
9   Tk  0x0001006ca6d0 Tk_MapWindow 
+ 89
10  Tk  0x0001006d35e6 
TkToplevelWindowForCommand + 2658
11  Tcl 0x0001006300d3 
TclServiceIdle + 76
12  Tcl 0x0001006162ce 
Tcl_DoOneEvent + 329
13  _tkinter.so 0x000100595683 
Tkapp_CallDeallocArgs + 277
14  readline.so 0x0001001f1f9a initreadline 
+ 1280
15  Python  0x000176a1 
PyOS_Readline + 239
16  Python  0x00018a57 
PyTokenizer_FromString + 1322
17  Python  0x000190a0 
PyTokenizer_Get + 154
18  Python  0x00015698 
PyParser_AddToken + 1018
19  Python  0x0001000a2320 
PyParser_ASTFromFile + 146
20  Python  0x0001000a443f 
PyRun_InteractiveOneFlags + 345
21  Python  0x0001000a4615 
PyRun_InteractiveLoopFlags + 206
22  Python  0x0001000a4685 
PyRun_AnyFileExFlags + 76
23  Python  0x0001000b0286 Py_Main + 
2718
24  Python  0x00010e6c start + 52
25  ??? 0x0001 0x0 + 1
)
terminate called after throwing an instance of 'NSException'
Abort trap


This is running /usr/bin/python in a session as a user that doesn't have access 
to the GUI.  The text above says that there is an uncaught ObjC exception, 
caused by the lack of a connection to the window server. Tk should have 
converted that to its own style of errors but didn't.

--

___
Python tracker 
<http://bugs.python.org/issue8716>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue8716] test_tk fails on OS X if run from buildbot slave daemon -- crashes Python

2010-05-14 Thread Bill Janssen

New submission from Bill Janssen :

test_tk fails on OS X if test is run from a daemon process without the 
privilege to access the window server, say a buildbot slave without anyone 
logged in to the console.  The Tk support needs to check whether it has access 
rights to the window server before trying to access it.

Workaround is to log buildbot into the console of the OS X machine (which 
usually but not always works), or to run tests manually.

--
components: Tests, Tkinter
messages: 105733
nosy: janssen
priority: normal
severity: normal
stage: needs patch
status: open
title: test_tk fails on OS X if run from buildbot slave daemon -- crashes Python
type: crash
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

___
Python tracker 
<http://bugs.python.org/issue8716>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue8552] msilib can't create large CAB files

2010-04-29 Thread Bill Janssen

Bill Janssen  added the comment:

Ah, found the size problem -- I was measuring something in 512 blocks not 1KB 
blocks.  Never mind.

--

___
Python tracker 
<http://bugs.python.org/issue8552>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue8552] msilib can't create large CAB files

2010-04-29 Thread Bill Janssen

Bill Janssen  added the comment:

Another bit of info.  It's the frequent commits that seem to fix the problem; 
when I comment those out of the __del__ method, it fails as before.  I also 
notice that the finished installer is about twice the size of the two data 
files in it (the CAB file and my zip file).  Seems like a lot of overhead.

--

___
Python tracker 
<http://bugs.python.org/issue8552>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue8552] msilib can't create large CAB files

2010-04-28 Thread Bill Janssen

Bill Janssen  added the comment:

I've now been able to build my installer.

I applied Travis Oliphant's patch from http://bugs.python.org/issue2399 to 
Lib/msilib/__init__.py, then added a __del__ method to the Directory class:

def __del__(self):
if self._numfiles_wo_commit > 0:
self.db.Commit()
self.db = None
self.keyfiles = None
self.cab = None
self.ids = None

This seems to release enough memory that I can deal with a larger number of 
files.

I don't think there's a good way to write a unit test for this, though.  
Success or failure will depend on the machine you're running it on, I think.

--

___
Python tracker 
<http://bugs.python.org/issue8552>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue8552] msilib can't create large CAB files

2010-04-28 Thread Bill Janssen

Changes by Bill Janssen :


Removed file: http://bugs.python.org/file17118/unnamed

___
Python tracker 
<http://bugs.python.org/issue8552>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue8552] msilib can't create large CAB files

2010-04-28 Thread Bill Janssen

Bill Janssen  added the comment:

Yes, I've tried that.  No joy.  Right now I'm trying an approach which
packages each top-level directory as a separate cab.

What I'm finding is that if I get up around 4200 files, it breaks,
regardless of the file sizes.  Out of curiosity, how many files are in the
Python MSI file?

Bill

On Tue, Apr 27, 2010 at 11:37 PM, Martin v. Löwis 
wrote:

>
> Martin v. Löwis  added the comment:
>
> You could also try to commit the MSI file in-between, which may release
> memory.
>
> --
>
> ___
> Python tracker 
> <http://bugs.python.org/issue8552>
> ___
>

--
Added file: http://bugs.python.org/file17118/unnamed

___
Python tracker 
<http://bugs.python.org/issue8552>
___Yes, I've tried that.  No joy.  Right now I'm trying an approach 
which packages each top-level directory as a separate 
cab.What I'm finding is that if I get up around 4200 
files, it breaks, regardless of the file sizes.  Out of curiosity, how many 
files are in the Python MSI file?
BillOn Tue, Apr 27, 2010 
at 11:37 PM, Martin v. Löwis <mailto:rep...@bugs.python.org";>rep...@bugs.python.org> 
wrote:

Martin v. Löwis <mailto:mar...@v.loewis.de";>mar...@v.loewis.de> added the 
comment:

You could also try to commit the MSI file in-between, which may release 
memory.

--

___
Python tracker <mailto:rep...@bugs.python.org";>rep...@bugs.python.org>
<http://bugs.python.org/issue8552"; 
target="_blank">http://bugs.python.org/issue8552>
___

___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue8554] suspicious comment in msilib.py/__init__.py

2010-04-27 Thread Bill Janssen

New submission from Bill Janssen :

Take a look at the first line of make_id().  What does that comment mean?  Is 
the wrong line commented out?

def make_id(str, add_num=True):
#str = str.replace(".", "_") # colons are allowed

--
components: Library (Lib), Windows
messages: 104393
nosy: janssen, loewis
priority: low
severity: normal
status: open
title: suspicious comment in msilib.py/__init__.py
versions: Python 2.6

___
Python tracker 
<http://bugs.python.org/issue8554>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue8552] msilib can't create large CAB files

2010-04-27 Thread Bill Janssen

Bill Janssen  added the comment:

So, I subclassed msilib.CAB, and re-wrote commit() so that the CAB file is 
created in a different process, a la Tools/msi/msilib.py.  Still have the same 
problem, though.  So now I'm thinking it's not a memory problem, but I'm 
wondering if there's something about the length of the path names in the CAB 
file, or some such.

--

___
Python tracker 
<http://bugs.python.org/issue8552>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue8552] msilib can't create large CAB files

2010-04-27 Thread Bill Janssen

Bill Janssen  added the comment:

Ummm, just in case the packager wanted to.

In my case, I was putting the files which were registered as part of the 
installation in one CAB file, and another set of temporary files which were 
used by some of the installation scripts, but not part of the installation file 
set, in a second CAB file.  I've since changed that second package to a zip 
file.

--

___
Python tracker 
<http://bugs.python.org/issue8552>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue8552] msilib can't create large CAB files

2010-04-27 Thread Bill Janssen

New submission from Bill Janssen :

I'm trying to create a CAB file containing about 69MB of data, in 4555 files.  
msilib fails in CAB.commit():

$ python build-msi-installer.py /c/UpLib/1.7.9 ~/uplib 1.7.9 ./uplib-1.7.9.msi
c:\Documents and Settings\wjanssen\uplib\win32\uplib-1.7.9.msi
install_location c:/UpLib/1.7.9
c:\docume~1\wjanssen\locals~1\temp\tmpu5dwz6 68943045
gc: collecting generation 0...
gc: objects in each generation: 670 702 8255
gc: done, 0.s elapsed.
gc: collecting generation 0...
gc: objects in each generation: 707 1364 8255
gc: done, 0.s elapsed.
gc: collecting generation 0...
gc: objects in each generation: 699 2031 8255
gc: done, 0.s elapsed.
gc: collecting generation 0...
gc: objects in each generation: 794 2680 8255
gc: done, 0.s elapsed.
gc: collecting generation 0...
gc: objects in each generation: 730 3373 8255
gc: done, 0.s elapsed.
gc: collecting generation 0...
gc: objects in each generation: 765 4018 8255
gc: done, 0.s elapsed.
gc: collecting generation 0...
gc: objects in each generation: 741 4697 8255
gc: done, 0.s elapsed.
(1, 4555, None, '#prereqs', None, None)
Traceback (most recent call last):
  File "build-msi-installer.py", line 780, in 
p.run()
  File "build-msi-installer.py", line 243, in run
self.add_files()
  File "build-msi-installer.py", line 312, in add_files
cab.commit(self.db)
  File "c:\Python26\lib\msilib\__init__.py", line 223, in commit
[(1, self.index, None, "#"+self.name, None, None)])
  File "c:\Python26\lib\msilib\__init__.py", line 97, in add_data
v = db.OpenView("SELECT * FROM `%s`" % table)
_msi.MSIError: 1: 2229 2: c:\Documents and 
Settings\wjanssen\uplib\win32\uplib-1.7.9.msi 3: Media 4: SELECT * FROM `Media` 
gc: collecting generation 2...
gc: objects in each generation: 416 5351 8254
gc: done, 0.s elapsed.
$

(I added a bit of code to print out the Media table record, and the size of the 
file created with FCICreate.)

This works fine if I choose a slightly smaller subset, such as 
/c/UpLib/1.7.9/lib, for instance.  So I'm guessing this is a memory problem; at 
some point there's just not enough memory to open the MSI file and load the 
Media table.

I opened the MSI file with orca and sure enough, there is no Media table in it. 
 Not sure how to take that, though;  perhaps the table only appears after a 
record has been written to it.

Another reason to allow multiple CAB files in a single installer?

--
components: Library (Lib), Windows
messages: 104379
nosy: janssen, loewis
priority: normal
severity: normal
status: open
title: msilib can't create large CAB files
type: resource usage
versions: Python 2.6

___
Python tracker 
<http://bugs.python.org/issue8552>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue3216] Scarce msilib documentation

2010-04-27 Thread Bill Janssen

Bill Janssen  added the comment:

Here's another one:

class Directory shows an extra arg, "component", which isn't in the code.

--
nosy: +janssen

___
Python tracker 
<http://bugs.python.org/issue3216>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com




[issue8526] msilib doesn't support multiple CAB instances in same installer

2010-04-25 Thread Bill Janssen

Bill Janssen  added the comment:

I'm certainly using the API provided by msilib, but perhaps I'm using it badly. 
 Which API did you have in mind?  I'm using msilib directly, not through 
bdist_msi.

This seems like an artificial limitation to put on the Python library; the 
standard MSI spec supports 65K different cabs in a single installer.

--

___
Python tracker 
<http://bugs.python.org/issue8526>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue8526] msilib doesn't support multiple CAB instances in same installer

2010-04-24 Thread Bill Janssen

New submission from Bill Janssen :

Working with Python 2.6.5, I find I cannot put multiple CABs in the same 
installer.  This is due to this statement in msilib.CAB.commit():

add_data(db, "Media",
[(1, self.index, None, "#"+self.name, None, None)])

The key, 1, must be different for each record in the 'Media' table.  The 
symptom is an exception something like this:

_msi.MSIError: Could not insert [(1, 3, None, '#foo', None, None)] into Media

--
assignee: loewis
components: Distutils, Library (Lib), Windows
keywords: easy
messages: 104135
nosy: janssen, loewis
severity: normal
status: open
title: msilib doesn't support multiple CAB instances in same installer
versions: Python 2.6, Python 2.7, Python 3.3

___
Python tracker 
<http://bugs.python.org/issue8526>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1128] msilib.Directory.make_short only handles file names with a single dot in them

2010-04-23 Thread Bill Janssen

Bill Janssen  added the comment:

Here's how Microsoft does it:  http://support.microsoft.com/kb/142982/en-us

--

___
Python tracker 
<http://bugs.python.org/issue1128>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue7639] bdist_msi fails on files with long names

2010-04-23 Thread Bill Janssen

Bill Janssen  added the comment:

This looks a lot like bug 1128, too.  I think the patch there would also fix 
this one.

--
nosy: +janssen

___
Python tracker 
<http://bugs.python.org/issue7639>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1128] msilib.Directory.make_short only handles file names with a single dot in them

2010-04-23 Thread Bill Janssen

Bill Janssen  added the comment:

So what happens if the original file name is something like "foo~1.txt"?  
Couldn't there be a name collision?

--
nosy: +janssen

___
Python tracker 
<http://bugs.python.org/issue1128>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue8222] enabling SSL_MODE_AUTO_RETRY on SSL sockets

2010-03-25 Thread Bill Janssen

Bill Janssen  added the comment:

Looks like a good idea.

--

___
Python tracker 
<http://bugs.python.org/issue8222>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2445] Use The CygwinCCompiler Under Cygwin

2010-03-18 Thread Bill Janssen

Bill Janssen  added the comment:

Shouldn't the import library name end with .lib?  I've run up against this 
building PyLucene with MinGW.  There seems to be code to figure this out 
already in CygwinCCompiler, but it's commented out (and arguably incomplete).

--
nosy: +janssen

___
Python tracker 
<http://bugs.python.org/issue2445>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2698] Extension module build fails for MinGW: missing vcvarsall.bat

2010-03-18 Thread Bill Janssen

Bill Janssen  added the comment:

My bad.  Adding --compiler=mingw32 eliminates this error.

--
resolution:  -> rejected
status: open -> closed

___
Python tracker 
<http://bugs.python.org/issue2698>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2698] Extension module build fails for MinGW: missing vcvarsall.bat

2010-03-18 Thread Bill Janssen

Bill Janssen  added the comment:

Re-opening.

--
keywords: +26backport
priority: high -> normal
resolution: invalid -> 
status: closed -> open

___
Python tracker 
<http://bugs.python.org/issue2698>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2698] Extension module build fails for MinGW: missing vcvarsall.bat

2010-03-18 Thread Bill Janssen

Bill Janssen  added the comment:

I'm seeing this on Python 2.6.4 on Windows XP with the latest MinGW/msys.

--
nosy: +janssen

___
Python tracker 
<http://bugs.python.org/issue2698>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue8108] test_ftplib fails with OpenSSL 0.9.8m

2010-03-14 Thread Bill Janssen

Bill Janssen  added the comment:

>> Depends on what we want.  It just suppresses information that's now
>> available.  What we'd really like is for the caller to recognize that
>> close() can fail, and should be re-tried if it does.  That requires
>> that we signal the error back up and out of the ssl module.  It seems
>> to me that any non-blocking code should recognize this and respect it.

> Well, first, it will break code which used to work perfectly well (as > the 
> failing tests show). That OpenSSL decided to break compatibility
> in what looks like a minor bugfix release (0.9.8m) doesn't mean we
> should propagate the breakage.

I admit to being powerfully swayed by this argument.  Of course, you could also 
say that it exposes bugs in code which hasn't been tested enough.  Again, look 
at where this stack trace is coming from.  It's a default error handler in code 
that was written 10 years ago.  Perhaps that code needs more than just a 
default error handler; perhaps the handler in FTP_TLS should be more 
sophisticated.

> Second, I'm not an SSL expert, but it's not obvious to me that the
> application should have to ensure a "complete shutdown" before
> closing the socket. Often, stateful applicative protocols close
> their "session" anyway (*) before shutting down the transport layer,
> so I don't see what this additional precaution can buy
> (apart from code complication).

What it buys is the ability for careful code to properly shut down an SSL 
session when using non-blocking sockets.  If we apply the fix, we deny that, 
and I'm sure someone will immediately file a bug about it :-).

--

___
Python tracker 
<http://bugs.python.org/issue8108>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue8108] test_ftplib fails with OpenSSL 0.9.8m

2010-03-14 Thread Bill Janssen

Bill Janssen  added the comment:

> Maybe because only the FTP test uses an SSL socket in non blocking mode.

No, the SSL unit tests also do this.  I think Giampaolo is right, what we're 
seeing is bad error handling in the FTP test code.

--

___
Python tracker 
<http://bugs.python.org/issue8108>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue8108] test_ftplib fails with OpenSSL 0.9.8m

2010-03-14 Thread Bill Janssen

Bill Janssen  added the comment:

> AFAICT, his proposed "quick fix" snippet should be good enough for us.

Depends on what we want.  It just suppresses information that's now available.  
What we'd really like is for the caller to recognize that close() can fail, and 
should be re-tried if it does.  That requires that we signal the error back up 
and out of the ssl module.  It seems to me that any non-blocking code should 
recognize this and respect it.

Again, why does this failure only show up in the FTP test?  Why aren't we 
seeing it elsewhere?

--

___
Python tracker 
<http://bugs.python.org/issue8108>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue8108] test_ftplib fails with OpenSSL 0.9.8m

2010-03-12 Thread Bill Janssen

Bill Janssen  added the comment:

And it would be interesting to know why all the SSL module tests don't fail in 
the same way.

--

___
Python tracker 
<http://bugs.python.org/issue8108>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue8108] test_ftplib fails with OpenSSL 0.9.8m

2010-03-12 Thread Bill Janssen

Bill Janssen  added the comment:

I think Giampaolo is right about this not being an ssl.py issue.  Could the 
exception handling in ftp.py perhaps also be made more sophisticated?  I'd 
really love to understand what the state of the TCP connection is here.  I'm 
presuming that it's still open, because otherwise you'd get a different error 
from OpenSSL.  So what's the error that's triggering this call?  Is it simply 
that the sender has run out of stuff to send?

Also, I think that asyncore.py is stingy about what information it sends.  At 
the very least, it could invoke handle_error() with the exception it's handling 
as an argument.

--

___
Python tracker 
<http://bugs.python.org/issue8108>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue8108] test_ftplib fails with OpenSSL 0.9.8m

2010-03-12 Thread Bill Janssen

Bill Janssen  added the comment:

Looking at this further, what we're seeing is the trace of an ineffective 
attempt to handle an exception presumably raised from the FTP code.  Can we see 
that exception?  What's the actual state of the TCP connection at this point?

--

___
Python tracker 
<http://bugs.python.org/issue8108>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue8108] test_ftplib fails with OpenSSL 0.9.8m

2010-03-12 Thread Bill Janssen

Bill Janssen  added the comment:

What's happening is that the new state returns from SSL_shutdown() are saying, 
"the shutdown you asked for didn't happen this time, but call me again when you 
get a chance.  And here is a hint about why it didn't happen, so that if you 
are sophisticated enough, you can get better information about whether 
subsequent calls to shutdown() will succeed."

Given the underlying architectures we are dealing with, is it possible to 
handle this properly?  Basically, what the SSL_shutdown code is saying is that 
all higher-level event loops should understand an additional kind of event, 
"shutting down the SSL socket", on a par with "read bytes" and "write bytes".  
But our event processing handlers, like asyncore, basically only deal with read 
and write.  I don't see how to tell them that a "close" operation should turn 
into a "read" or "write".

We could also think about turning non-blocking sockets into blocking sockets, 
by adding a time.sleep(0.1) and re-calling SSL_shutdown().  But maybe the right 
thing to do would be for the write handler in the asyncore loop to catch this, 
and re-try the write when it gets a chance.

--

___
Python tracker 
<http://bugs.python.org/issue8108>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue8108] test_ftplib fails with OpenSSL 0.9.8m

2010-03-12 Thread Bill Janssen

Bill Janssen  added the comment:

Victor, I'll take a look.

--

___
Python tracker 
<http://bugs.python.org/issue8108>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue7672] _ssl module causes segfault

2010-01-12 Thread Bill Janssen

Bill Janssen  added the comment:

Martin, I'm thinking that the module object has a __del__ method, and we could 
un-register the callbacks there.  But I don't know if that method would ever 
get called.  How does the act of "unloading a library" interact with the 
initialized Python interpreter?

--

___
Python tracker 
<http://bugs.python.org/issue7672>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue3890] ssl.SSLSocket.recv() implementation may not work with non-blocking sockets

2009-09-30 Thread Bill Janssen

Bill Janssen  added the comment:

On Tue, Sep 29, 2009 at 12:47 PM, Giampaolo Rodola'
wrote:

>
> Giampaolo Rodola'  added the comment:
>
> Uhm... I'm sorry but actually I'm not sure about this patch anymore.
> Now that I look at ssl.py again I'm noticing that send() is trapped in a
> "while True" loop as well and the patch doesn't cover it.
>
> Not sure if that has been added recently or it was already there at the
> time I submitted the report but it's another thing that need to be
> fixed.
>
>
> Moreover, I'm sure that removing the "while" loop is good for non-
> blocking sockets but what about blocking ones?
> Are SSL_ERROR_WANT_READ and SSL_ERROR_WANT_WRITE supposed to be raised
> in a blocking environment?
>

No.

> If they aren't then the current patch just needs to take care of send()
> method too, then it's fine.
>

Yes, it's fine.

Bill

--
Added file: http://bugs.python.org/file15010/unnamed

___
Python tracker 
<http://bugs.python.org/issue3890>
___On Tue, Sep 29, 2009 at 12:47 PM, Giampaolo 
Rodola' <mailto:rep...@bugs.python.org";>rep...@bugs.python.org> 
wrote:

Giampaolo Rodola' <mailto:billiej...@users.sourceforge.net";>billiej...@users.sourceforge.net>
 added the comment:

Uhm... I'm sorry but actually I'm not sure about this patch anymore.
Now that I look at ssl.py again I'm noticing that send() is trapped in a
"while True" loop as well and the patch doesn't cover it.

Not sure if that has been added recently or it was already there at the
time I submitted the report but it's another thing that need to be
fixed.


Moreover, I'm sure that removing the "while" loop is good for 
non-
blocking sockets but what about blocking ones?
Are SSL_ERROR_WANT_READ and SSL_ERROR_WANT_WRITE supposed to be raised
in a blocking 
environment?No. 
If they aren't then the current patch just needs to take care of send()
method too, then it's fine.Yes, it's 
fine.Bill 
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue3890] ssl.SSLSocket.recv() implementation may not work with non-blocking sockets

2009-09-29 Thread Bill Janssen

Bill Janssen  added the comment:

I wonder if there is any way to test this, aside from the tests that
are already in the test suite?  The bug here is that the code effectively
does a blocking read on a non-blocking socket, and we can't tell the
difference.  The fact that this patch passes all the existing tests and
also seems to be a fix (through inspection) may have to be sufficient.

After all, the tests for the previous SSL support (Python 2.5 and
earlier) were extremely sketchy.

--

___
Python tracker 
<http://bugs.python.org/issue3890>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue4033] python search path - .pth recursion

2009-09-17 Thread Bill Janssen

Bill Janssen  added the comment:

Looks like 1431 was closed by removing a line from the documentation, so
it's not surprising that it's not clear.

--
nosy: +janssen

___
Python tracker 
<http://bugs.python.org/issue4033>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue6587] interrupts during long writes cause connection corruption with SSL module

2009-07-27 Thread Bill Janssen

New submission from Bill Janssen :

The behavior when a write or send is interrupted is suboptimal.  If the
write buffer moves before a retry is attempted in response to
SSL_ERROR_WANT_OUTPUT, OpenSSL rejects the retry attempt.  See

http://www.mail-archive.com/openssl-us...@openssl.org/msg07806.html.

Looks like a simple fix.

--
assignee: janssen
messages: 90999
nosy: janssen
priority: high
severity: normal
stage: needs patch
status: open
title: interrupts during long writes cause connection corruption with SSL module
type: behavior
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2

___
Python tracker 
<http://bugs.python.org/issue6587>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue4848] MacPython build script uses Carbon and MacOS modules slated for removal

2009-03-04 Thread Bill Janssen

Bill Janssen  added the comment:

Looks good.  The contrast is stark.

___
Python tracker 
<http://bugs.python.org/issue4848>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue4471] IMAP4 missing support for starttls

2009-03-03 Thread Bill Janssen

Bill Janssen  added the comment:

I brought this up on pydotorg, and Barry suggests that someone put
together a Twisted environment which could be downloaded and run locally
on the test machine.  It would provide IMAP and POP servers, perhaps
NNTP and others as well.  Now, all we need is someone to make that
happen :-).

___
Python tracker 
<http://bugs.python.org/issue4471>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1978] Python(2.5.1) will be crashed when i use _ssl module in multi-threads environment in linux.

2009-03-03 Thread Bill Janssen

Bill Janssen  added the comment:

Yes, the reason is that the supplied patch doesn't provide enough test
cases.  This is a big patch; 2.5.x is a bug-fix release; a newer version
of the SSL code is available from PyPI as a work-around; I don't have
time right now to write more tests myself.  All of which means that I
won't look at it more till the patch (or another patch) includes more
test cases.

___
Python tracker 
<http://bugs.python.org/issue1978>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue4471] IMAP4 missing support for starttls

2009-03-01 Thread Bill Janssen

Bill Janssen  added the comment:

Why can't we use python.org for tests?  Do we need IMAP/POP servers
running?  Let's send some mail to pydotorg to get that set up.

___
Python tracker 
<http://bugs.python.org/issue4471>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2437] Distutils runtime_library_dirs broken on Windows

2009-03-01 Thread Bill Janssen

Bill Janssen  added the comment:

Tarek writes:

> Laurent, right. but we need to figure out how to get the CC name in
> MinGW/Cygwin environment.

> I am not familiar with them.

Since this bug is specifically about that environment, shouldn't it be
handled by someone who is familiar with them?  Not objecting, here, but
it seems unlikely to result in a rapid fix.  And MinGW and Cygwin are
pretty different, IMHO; don't mix them together here.

___
Python tracker 
<http://bugs.python.org/issue2437>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2437] Distutils runtime_library_dirs broken on Windows

2009-03-01 Thread Bill Janssen

Bill Janssen  added the comment:

No, Tarek, I don't have a MinGW machine right now.  But it should be
easy to reproduce; just invoke that call I originally reported.  The
distutils code is just making assumptions that it shouldn't be making.

___
Python tracker 
<http://bugs.python.org/issue2437>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue5238] ssl makefile never closes socket

2009-03-01 Thread Bill Janssen

Bill Janssen  added the comment:

I'd recommend running the whole suite of tests here.  The issue is
mainly with httplib, as I recall it, which "closes" the socket before it
finishes reading from it.

___
Python tracker 
<http://bugs.python.org/issue5238>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue4471] IMAP4 missing support for starttls

2009-02-02 Thread Bill Janssen

Bill Janssen  added the comment:

Lorenzo, do we have test cases for this?  I think you should try to add
some test cases.  We may need to set up some test mail servers on
python.org to accommodate such tests.

--
nosy: +janssen

___
Python tracker 
<http://bugs.python.org/issue4471>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1251] ssl module doesn't support non-blocking handshakes

2009-01-13 Thread Bill Janssen

Bill Janssen  added the comment:

Well, maybe he found something -- never reported back.  But it was a few
months ago...  I'm in no hurry to close it, though.

___
Python tracker 
<http://bugs.python.org/issue1251>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue4870] ssl module is missing SSL_OP_NO_SSLv2

2009-01-07 Thread Bill Janssen

Bill Janssen  added the comment:

Actually, that's not quite true.  Specifying TLSv1 or SSLv3 on the
server side will disable SSLv2.  However, there's currently no way to
specify SSLv3 *or* TLSv1 *but not* SSLv2.  This looks easy to fix; I'll
add another entry to the list of protocol versions, which when selected
will cause the server to use SSLv23, but will cause SSLv2 clients to be
rejected.

--
assignee:  -> janssen
resolution:  -> accepted
stage:  -> needs patch

___
Python tracker 
<http://bugs.python.org/issue4870>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue4848] MacPython build script uses Carbon and MacOS modules slated for removal

2009-01-05 Thread Bill Janssen

New submission from Bill Janssen :

The build script for a Mac OS installer, in
Mac/BuildScript/build-installer.py, currently requires OS 10.4 and
Python 2.3.  At some point it will have to be ported to a newer version
of Python (and Mac OS).  It uses a number of modules which are slated
for future removal, particularly Carbon and MacOS.  These modules are
only used in the function "setIcon".  They can be replaced with a call
to a Cocoa method via PyObjC.  The "setIcon" function using PyObjC would
look like this:

def setIcon(folder, imagefile):

try:

import os, AppKit

AppKit.NSApplicationLoad()  # initialize Cocoa

return
AppKit.NSWorkspace.sharedWorkspace().setIcon_forFile_options_(
AppKit.NSImage.alloc().initWithContentsOfFile_(imagefile),
os.path.abspath(folder), 0)

except ImportError:
return False

--
components: Build, Macintosh
messages: 79169
nosy: janssen
priority: low
severity: normal
status: open
title: MacPython build script uses Carbon and MacOS modules slated for removal
type: feature request
versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1

___
Python tracker 
<http://bugs.python.org/issue4848>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue3890] ssl.SSLSocket.recv() implementation may not work with non-blocking sockets

2008-12-10 Thread Bill Janssen

Bill Janssen <[EMAIL PROTECTED]> added the comment:

Unrelated?  OK, but in fact I fixed this in 3.0 by providing a different
internal API to _ssl.c.  But you're right, that's an optimization.

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3890>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue3890] ssl.SSLSocket.recv() implementation may not work with non-blocking sockets

2008-12-04 Thread Bill Janssen

Bill Janssen <[EMAIL PROTECTED]> added the comment:

Thanks for the patch.  It looks pretty good to me, but I can't help
thinking that there must be a better way of handling the recv() case; I
don't like copying that buffer several times (from the SSL code to
Python, from the Python to the buffer).

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3890>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue4171] SSL handshake fails after TCP connection in getpeername()

2008-10-24 Thread Bill Janssen

Changes by Bill Janssen <[EMAIL PROTECTED]>:


--
assignee:  -> janssen

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4171>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue3890] ssl.SSLSocket.recv() implementation may not work with non-blocking sockets

2008-10-21 Thread Bill Janssen

Bill Janssen <[EMAIL PROTECTED]> added the comment:

I agree, too.

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3890>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1210] imaplib does not run under Python 3

2008-10-14 Thread Bill Janssen

Bill Janssen <[EMAIL PROTECTED]> added the comment:

Maybe the first thing to do is to expand the Lib/test/test_imaplib.py
file, which right now is pretty darn minimal.  We really need an IMAP
server somewhere to test against, with a standard library of varied
messages.

Perhaps Python.org is running an IMAP server?

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1210>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1210] imaplib does not run under Python 3

2008-10-14 Thread Bill Janssen

Bill Janssen <[EMAIL PROTECTED]> added the comment:

Victor, what kind of content have you tried this with?  For instance, have
you passed unencoded (Content-Transfer-Encoding: binary) binary data through
it, by mailing a JPEG, for instance?  These things are strings really only
at the application level; the data is still bytes.  In addition, the use of
Latin-1 goes against the explicit directives of the IMAP group, doesn't it?
They're pushing UTF-8.

Bill

On Tue, Oct 14, 2008 at 4:27 AM, STINNER Victor <[EMAIL PROTECTED]>wrote:

>
> STINNER Victor <[EMAIL PROTECTED]> added the comment:
>
> Here is a patch for imaplib:
>  - add encoding attribute to IMAP4 class (as ftplib and see also issue
> 3727 for my poplib patch)
>  - use makefile('r', encoding=self.encoding) instead of a binary file
> (mode='rb')
>  - remove duplicate code in IMAP4_SSL
>
> I choosed ISO-8859-1 as the default charset. I tested the library on
> my local IMAP4 server using IMAP4 and IMAP4_SSL classes. But the
> library needs more unit tests as done for poplib.
>
> --
> keywords: +patch
> nosy: +haypo
> Added file: http://bugs.python.org/file11786/imaplib_unicode.patch
>
> ___
> Python tracker <[EMAIL PROTECTED]>
> <http://bugs.python.org/issue1210>
> ___
>

Added file: http://bugs.python.org/file11790/unnamed

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1210>
___Victor, what kind of content have you tried this with?  For 
instance, have you passed unencoded (Content-Transfer-Encoding: binary) binary 
data through it, by mailing a JPEG, for instance?  These things are 
strings really only at the application level; the data is still bytes.  In 
addition, the use of Latin-1 goes against the explicit directives of the IMAP 
group, doesn't it?  They're pushing UTF-8.
BillOn Tue, Oct 14, 2008 at 4:27 AM, 
STINNER Victor <mailto:[EMAIL PROTECTED]">[EMAIL 
PROTECTED]> wrote:

STINNER Victor <mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]> 
added the comment:

Here is a patch for imaplib:
 - add encoding attribute to IMAP4 class (as ftplib and see also issue
3727 for my poplib patch)
 - use makefile('r', encoding=self.encoding) instead of a binary 
file
(mode='rb')
 - remove duplicate code in IMAP4_SSL

I choosed ISO-8859-1 as the default charset. I tested the library on
my local IMAP4 server using IMAP4 and IMAP4_SSL classes. But the
library needs more unit tests as done for poplib.

--
keywords: +patch
nosy: +haypo
Added file: http://bugs.python.org/file11786/imaplib_unicode.patch"; 
target="_blank">http://bugs.python.org/file11786/imaplib_unicode.patch

___
Python tracker <mailto:[EMAIL PROTECTED]">[EMAIL 
PROTECTED]>
<http://bugs.python.org/issue1210"; 
target="_blank">http://bugs.python.org/issue1210>
___

___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2276] distutils out-of-date for runtime_library_dirs flag on OS X

2008-10-07 Thread Bill Janssen

Bill Janssen <[EMAIL PROTECTED]> added the comment:

Yes, we were looking at using this for linking PyLucene's JCC extension.
 I believe we came up with a different way of doing it.  It would still
be useful to have distutils.unixccompiler.runtime_library_dir_option()
updated to understand the right flags for Leopard.

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2276>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue3991] urllib.request.urlopen does not handle non-ASCII characters

2008-09-30 Thread Bill Janssen

Bill Janssen <[EMAIL PROTECTED]> added the comment:

I'm not concerned about any example inputs.  I was just trying to
explain why this isn't a bug.

On the other hand, the IRI spec (RFC 3897) is another thing we might
try to implement for Python.

--
type:  -> feature request

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3991>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue3991] urllib.request.urlopen does not handle non-ASCII characters

2008-09-30 Thread Bill Janssen

Bill Janssen <[EMAIL PROTECTED]> added the comment:

It's not immediately clear to me how an auto-quote function can be
written; as you say (and as the URI spec points out), you have to take
a URL apart before quoting it, and you can't parse an invalid URL,
which is what the input is.

Best to think of this as a difference from 2.x.

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3991>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue3991] urllib.request.urlopen does not handle non-ASCII characters

2008-09-29 Thread Bill Janssen

Bill Janssen <[EMAIL PROTECTED]> added the comment:

As I read RFC 2396,

1.5:  "A URI is a sequence of characters from a very
   limited set, i.e. the letters of the basic Latin alphabet, digits,
   and a few special characters."

2.4:  "Data must be escaped if it does not have a representation using an
   unreserved character; this includes data that does not correspond to
   a printable character of the US-ASCII coded character set, or that
   corresponds to any US-ASCII character that is disallowed, as
   explained below."

So your URL string is invalid.  You need to escape the characters properly.

(RFC 2396 is what the HTTP RFC cites as its authority on URLs.)

--
nosy: +janssen

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3991>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue3910] 2.6 regression in socket.ssl method

2008-09-29 Thread Bill Janssen

Bill Janssen <[EMAIL PROTECTED]> added the comment:

OK, I found the fix.

--
resolution:  -> fixed
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3910>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue3910] 2.6 regression in socket.ssl method

2008-09-29 Thread Bill Janssen

Bill Janssen <[EMAIL PROTECTED]> added the comment:

Maybe not.  test_ssl hangs when I run it "-u all -v".  It's hanging on
testSimpleSSLWrap.  This is on OS X 10.5.5.

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3910>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue3910] 2.6 regression in socket.ssl method

2008-09-29 Thread Bill Janssen

Bill Janssen <[EMAIL PROTECTED]> added the comment:

Will do.

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3910>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue3899] test_ssl.py doesn't properly test ssl integration with asyncore

2008-09-19 Thread Bill Janssen

Bill Janssen <[EMAIL PROTECTED]> added the comment:

Sure, no argument.  I was just making clear what was going on.

Bill

On Thu, Sep 18, 2008 at 7:33 PM, Josiah Carlson <[EMAIL PROTECTED]>wrote:

>
> Josiah Carlson <[EMAIL PROTECTED]> added the comment:
>
> Being able to test the async features of both sides of the SSL
> connection is a good thing.
>
> Also, the subclass provides a useful example for users who want to use
> asyncore and ssl servers without blocking on an incoming connection.
>
> ___
> Python tracker <[EMAIL PROTECTED]>
> <http://bugs.python.org/issue3899>
> ___
>

Added file: http://bugs.python.org/file11528/unnamed

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3899>
___Sure, no argument.  I was just making clear what was going 
on.BillOn Thu, Sep 18, 2008 at 7:33 
PM, Josiah Carlson <mailto:[EMAIL 
PROTECTED]">[EMAIL PROTECTED]> wrote:

Josiah Carlson <mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]> 
added the comment:

Being able to test the async features of both sides of the SSL
connection is a good thing.

Also, the subclass provides a useful example for users who want to use
asyncore and ssl servers without blocking on an incoming connection.

___
Python tracker <mailto:[EMAIL PROTECTED]">[EMAIL 
PROTECTED]>
<http://bugs.python.org/issue3899"; 
target="_blank">http://bugs.python.org/issue3899>
___

___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue3910] 2.6 regression in socket.ssl method

2008-09-19 Thread Bill Janssen

Bill Janssen <[EMAIL PROTECTED]> added the comment:

Looks OK to me.  I think this is a back-port problem from 3.0.

I'll put it in if no one objects.

--
assignee:  -> janssen

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3910>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue3899] test_ssl.py doesn't properly test ssl integration with asyncore

2008-09-18 Thread Bill Janssen

Bill Janssen <[EMAIL PROTECTED]> added the comment:

The server wasn't meant to be non-blocking.  The non-blocking test is
performed when the client (which is non-blocking) connects to it.

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3899>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2574] Add RFC 3768 SSM Multicast support to "socket"

2008-09-17 Thread Bill Janssen

Bill Janssen <[EMAIL PROTECTED]> added the comment:

On Wed, Sep 17, 2008 at 10:45 AM, bms <[EMAIL PROTECTED]> wrote:

>
> Exercising the API fully requires an SSM capable multicast LAN.
>

Let's hope the PARC network is still up-to-date.  It was when we were
developing multicast here some 15-20 years ago :-).

Bill

Added file: http://bugs.python.org/file11512/unnamed

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2574>
___On Wed, Sep 17, 2008 at 10:45 
AM, bms <mailto:[EMAIL PROTECTED]">[EMAIL 
PROTECTED]> wrote:

Exercising the API fully requires an SSM capable multicast LAN.
Let's hope the PARC network is still 
up-to-date.  It was when we were developing multicast here some 15-20 
years ago :-).Bill
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue2574] Add RFC 3768 SSM Multicast support to "socket"

2008-09-17 Thread Bill Janssen

Bill Janssen <[EMAIL PROTECTED]> added the comment:

I tried applying this patch to a clean SVN checkout of the 2.6 trunk on
an OS X Leopard machine and it works (except for the part which patches
configure.in).  I then built the source tree and ran the test_socket
test, which also worked fine.  I don't see any tests for the specific
functionality in the patch, or any patch to the documentation of the
socket module.

--
nosy: +janssen

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2574>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1589] New SSL module doesn't seem to verify hostname against commonName in certificate

2008-09-11 Thread Bill Janssen

Bill Janssen <[EMAIL PROTECTED]> added the comment:

I think that, where it's appropriate, you can do that.  Just don't put it in
the SSL module.

Bill

On Wed, Sep 10, 2008 at 11:24 PM, Heikki Toivonen <[EMAIL PROTECTED]>wrote:

>
> Heikki Toivonen <[EMAIL PROTECTED]> added the comment:
>
> Ok, thank you for clarifications. Now I understand why the hostname
> checking isn't the solution that fits every problem. I am still not
> completely clear how you'd do the checking otherwise, for example to
> verify the service you are talking to is what you think it is.
>
> But still, I think dealing with email servers is another common use case
> where hostname check is adequate most of the time. I am sure there are
> other cases like this. Therefore I am still of the opinion that the
> default should be to do the hostname check. Yes, make it overridable,
> but doing the check is safer than not doing any checking IMO because
> even if the check is incorrect for a certain purpose the developer is
> likely to notice an error quickly and inclined to do some other security
> check instead of not doing anything and thinking they have a secure system.
>
> If you want to continue the discussion, we should maybe take this to
> some other forum, like comp.lang.python.
>
> ___
> Python tracker <[EMAIL PROTECTED]>
> <http://bugs.python.org/issue1589>
> ___
>

Added file: http://bugs.python.org/file11463/unnamed

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1589>
___I think that, where it's appropriate, you can do that.  
Just don't put it in the SSL module.BillOn Wed, Sep 10, 2008 at 11:24 PM, Heikki Toivonen <mailto:[EMAIL PROTECTED]">[EMAIL 
PROTECTED]> wrote:

Heikki Toivonen <mailto:[EMAIL PROTECTED]">[EMAIL 
PROTECTED]> added the comment:

Ok, thank you for clarifications. Now I understand why the hostname
checking isn't the solution that fits every problem. I am still not
completely clear how you'd do the checking otherwise, for example to
verify the service you are talking to is what you think it is.

But still, I think dealing with email servers is another common use case
where hostname check is adequate most of the time. I am sure there are
other cases like this. Therefore I am still of the opinion that the
default should be to do the hostname check. Yes, make it overridable,
but doing the check is safer than not doing any checking IMO because
even if the check is incorrect for a certain purpose the developer is
likely to notice an error quickly and inclined to do some other security
check instead of not doing anything and thinking they have a secure system.

If you want to continue the discussion, we should maybe take this to
some other forum, like comp.lang.python.

___
Python tracker <mailto:[EMAIL PROTECTED]">[EMAIL 
PROTECTED]>
<http://bugs.python.org/issue1589"; 
target="_blank">http://bugs.python.org/issue1589>
___

___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue3823] ssl.wrap_socket() is incompatible with servers that drop privileges, due to keyfile requirement

2008-09-10 Thread Bill Janssen

Bill Janssen <[EMAIL PROTECTED]> added the comment:

Sure -- but the point of the SSL module was to do something
small and compatible with the existing socket.ssl module; I really don't
want to get into a full-fledged Python interface to OpenSSL.  Perhaps
incremental progress would be OK...

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3823>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue3823] ssl.wrap_socket() is incompatible with servers that drop privileges, due to keyfile requirement

2008-09-10 Thread Bill Janssen

Bill Janssen <[EMAIL PROTECTED]> added the comment:

Thanks, Simon.

I remember digging through all this last year, and finally deciding
to keep things simple and use the strategy the current codebase uses.

It almost sounds like we'd need to create Key and Certificate objects
in the _ssl module, which could be used to load up all the keys and/or
certificates the server uses, before it changes UID (and presumbably
loses access to the files the data is kept in).  I was resisting
going down that path; there's a lot of complexity there I want to avoid.
But much of the mechanism of a Certificate object is already there;
perhaps adding an opaque Key object wouldn't be too bad.

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3823>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1589] New SSL module doesn't seem to verify hostname against commonName in certificate

2008-09-09 Thread Bill Janssen

Bill Janssen <[EMAIL PROTECTED]> added the comment:

Sorry to be so brief there -- I was off on vacation.

Verifying hostnames is a prescription that someone (well, OK, Eric
Rescorla, who knows what he's talking about) put in the https IETF RFC
(which, by the way, is only an informational RFC, not standards-track).
 It's a good idea if you're a customer trying to talk to Wells-Fargo,
say, over an https connection, but isn't suitable for all https traffic.
 I support putting it in the httplib Https class by default, but there
should be a way to override it, as there is with the Java APIs for https
connections.  (Take a look at javax.net.ssl.HostnameVerifier; one of the
more popular Java classes at PARC is a version of this that verifies any
hostname).

So what's wrong with it?  There are two problems.  The first is that
certificates for services are all about the hostname, and that's just
wrong.  You should verify the specific service, not just the hostname. 
So a client that really cares about what they are talking to should
have the certificate for that service, and verify that it is the service
it's talking to, and ignore the hostname in the URL.

But the larger problem is that hostnames are a DNS construct for humans,
and not really well supported on computers, or by the services that run
on those computers.  Most computers have only the haziest notion of what
their hostname is, and many have lots of different hostnames (my laptop
has at least five hostnames that I know of, all meaning the same
computer, but with five different PARC IP addresses).  So the services
running on that computer aren't real clear about their hostnames,
either.  If I run a service on that computer that I secure with SSL, so
that packets going over my WiFi are encrypted, which hostname should
that service declare itself to be in the certificate?  And the services
on that computer keep running, even when it switches its IP address (and
thus its set of hostnames).  So doing hostname matching provokes lots of
false negatives, especially when it's not needed.  I think it by and
large isn't a good idea, though I support having it (in an overrideable
form) for the client-side https class in httplib.

This is all exacerbated by the fact that HTTP isn't what it was when
Eric wrote that RFC eight years ago.  The growth of Web 2.0 and
"RESTful" services means that lots of new things are using https in a
much less formal way, more to get encrypted packets than to verify
endpoints.  So false negatives caused by mindless hostname verification
cause real damage.

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1589>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue3823] ssl.wrap_socket() is incompatible with servers that drop privileges, due to keyfile requirement

2008-09-09 Thread Bill Janssen

Changes by Bill Janssen <[EMAIL PROTECTED]>:


--
resolution:  -> accepted

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3823>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue3805] sslobj.read py3k takes odd arguments

2008-09-09 Thread Bill Janssen

Bill Janssen <[EMAIL PROTECTED]> added the comment:

But I should say...  Greg, I do appreciate the review and the comments.
 I was waiting for the bytes work in 3K to settle down before looking at
that code again.  When I do, I'll take your comments to heart.

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3805>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue3805] sslobj.read py3k takes odd arguments

2008-09-09 Thread Bill Janssen

Changes by Bill Janssen <[EMAIL PROTECTED]>:


Removed file: http://bugs.python.org/file11446/unnamed

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3805>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue3805] sslobj.read py3k takes odd arguments

2008-09-09 Thread Bill Janssen

Bill Janssen <[EMAIL PROTECTED]> added the comment:

Please, guys, let's not deep-end on this.  It's an admittedly eccentric but
working and purely internal interface.  There are actual release-blockers
that need to be addressed.

On Tue, Sep 9, 2008 at 4:14 AM, Amaury Forgeot d'Arc <[EMAIL PROTECTED]
> wrote:

>
> Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
>
> The same function has two distinct behaviours:
> - If you pass a number, it return a bytes object.
> - If you pass a buffer, it returns a number!
> Different arguments and different return types: they should have
> different names IMO.
>
> io.py proposes read(n) and readinto(buf) for this distinction, and I
> fail to see a reason why PySSL_SSLread need to be different:
>
> - readinto(buf, count=-1) could be similar to the actual PySSL_SSLread.
> the "count" defaults to len(buf).
> - read(count) could be implemented in C or python (or not at all), it is
> equivalent to:
>def read(self, count=1024):
>buf = bytearray(count)
>nb = self.readinto(buf)
>return bytes(buf[:nb])
>
> --
> nosy: +amaury.forgeotdarc
>
> ___
> Python tracker <[EMAIL PROTECTED]>
> <http://bugs.python.org/issue3805>
> ___
>

Added file: http://bugs.python.org/file11446/unnamed

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3805>
___Please, guys, let's not deep-end on this.  It's an 
admittedly eccentric but working and purely internal interface.  There are 
actual release-blockers that need to be addressed.
On Tue, Sep 9, 2008 at 4:14 AM, Amaury Forgeot d'Arc <mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]> 
wrote:

Amaury Forgeot d'Arc <mailto:[EMAIL PROTECTED]">[EMAIL 
PROTECTED]> added the comment:

The same function has two distinct behaviours:
- If you pass a number, it return a bytes object.
- If you pass a buffer, it returns a number!
Different arguments and different return types: they should have
different names IMO.

io.py proposes read(n) and readinto(buf) for this distinction, and I
fail to see a reason why PySSL_SSLread need to be different:

- readinto(buf, count=-1) could be similar to the actual PySSL_SSLread.
the "count" defaults to len(buf).
- read(count) could be implemented in C or python (or not at all), it is
equivalent to:
    def read(self, count=1024):
        buf = bytearray(count)
        nb = self.readinto(buf)
        return bytes(buf[:nb])

--
nosy: +amaury.forgeotdarc

___
Python tracker <mailto:[EMAIL PROTECTED]">[EMAIL 
PROTECTED]>
<http://bugs.python.org/issue3805"; 
target="_blank">http://bugs.python.org/issue3805>
___

___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue3805] sslobj.read py3k takes odd arguments

2008-09-08 Thread Bill Janssen

Changes by Bill Janssen <[EMAIL PROTECTED]>:


--
priority: high -> low

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3805>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue3805] sslobj.read py3k takes odd arguments

2008-09-08 Thread Bill Janssen

Bill Janssen <[EMAIL PROTECTED]> added the comment:

There was a reason to do it that way.  Now if I can only remember what
it was...

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3805>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue3162] ssl.SSLSocket implements methods that are overriden by socket.socket.__init__ and methods with incorrect names.

2008-09-08 Thread Bill Janssen

Bill Janssen <[EMAIL PROTECTED]> added the comment:

And for the 3K branch.  Thanks!

--
resolution: accepted -> fixed
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3162>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue3162] ssl.SSLSocket implements methods that are overriden by socket.socket.__init__ and methods with incorrect names.

2008-09-08 Thread Bill Janssen

Bill Janssen <[EMAIL PROTECTED]> added the comment:

I've applied Simon's patch to the 2.6 trunk.

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3162>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue3162] ssl.SSLSocket implements methods that are overriden by socket.socket.__init__ and methods with incorrect names.

2008-09-05 Thread Bill Janssen

Bill Janssen <[EMAIL PROTECTED]> added the comment:

Re: nomenclature

I think this is partly a design bug on my part, supporting the old
pre-2.6 "read" and "write" methods on the SSL context.  Users should
really call "makefile" to get something they can "read" and "write";
those methods should, in 2.6, only be internal, and not exposed outside
the class.  Of course, that would complicate the socket.ssl
compatibility code.

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3162>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1291446] SSLObject breaks read semantics

2008-09-05 Thread Bill Janssen

Bill Janssen <[EMAIL PROTECTED]> added the comment:

Ah, sorry.  I was looking at the 2.6 documentation, not the 2.5
documentation.  In 2.6 (which is what the new SSL code is for),
documentation of socket.ssl has been removed entirely, along with the
text that you cite, although the functionality from 2.5 socket.ssl is
still provided for backwards compatibility.  In 2.6, the ssl.SSLSocket
type is a subclass of socket.socket, so you call "makefile" on it to get
a file-like object for reading and writing.

If you'd like to submit a patch for 2.5 and 2.6, I think this is
backwards-compatible enough to qualify as a fix, not a feature enhancement.

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1291446>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue3162] ssl.SSLSocket implements methods that are overriden by socket.socket.__init__ and methods with incorrect names.

2008-09-05 Thread Bill Janssen

Bill Janssen <[EMAIL PROTECTED]> added the comment:

Simon, thanks, this patch looks good to me (2.6 only, right?).  I'll try
it out and report back.  If it looks good, I'll commit it.

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3162>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1291446] SSLObject breaks read semantics

2008-09-04 Thread Bill Janssen

Bill Janssen <[EMAIL PROTECTED]> added the comment:

The way I read the documentation, file.read() (and that's what we're
talking about) is still not guaranteed to read all the bytes of the
file.  But, you're right, that is the accepted semantics.  So the
documentation should change, too.

However, the "read" method on an SSLSocket, which is not a file()
subclass, is *not* guaranteed to return N bytes, it's guaranteed to
return at most N bytes.  Call "makefile" on SSLSocket if you need a
file-like object.

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1291446>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1210] imaplib does not run under Python 3

2008-09-03 Thread Bill Janssen

Bill Janssen <[EMAIL PROTECTED]> added the comment:

Take a look at the thread here:

http://mailman2.u.washington.edu/mailman/htdig/imap-protocol/2008-February/000811.html

I think the summary is, arbitrary bytes may occur in some places, but
they're likely to be UTF-8.  Otherwise, it's mainly ASCII, but purposely
left vague to see what convention developed.

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1210>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



  1   2   3   4   >