[issue9026] argparse subcommands not printed in the same order they were added
ddve...@ucar.edu added the comment: You are right, this problem is not coming from python itself, but more from setuptools and its use by scoop. See https://github.com/soravux/scoop/issues/16 and http://stackoverflow.com/questions/29374044/ for details Regards, Davide Del Vento, NCAR Computational Information Services Laboratory Consulting Services Software Engineer http://www2.cisl.ucar.edu/uss/csg/ SEA Chair http://sea.ucar.edu/ office: Mesa Lab, Room 55G phone: (303) 497-1233 On Thu, Apr 2, 2015 at 1:45 AM, Ned Deily rep...@bugs.python.org wrote: Ned Deily added the comment: @ddvento: This issue has been closed and the fixes for it released several years ago. Comments added here will likely be ignored. If you believe there is a problem with current releases (for Python 2, Python 2.7.9 is current), please open a new issue and document how to reproduce, including on what platform(s) and with which versions of Python. FWIW, the original test case in this issue works correctly with both a 2.7.6 and current 2.7.9 on the platforms I tried it with. -- nosy: +ned.deily ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9026 ___ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9026 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9026] argparse subcommands not printed in the same order they were added
ddve...@ucar.edu added the comment: This problem is occurring again in python 2.7.7, can we open it again? -- nosy: +ddve...@ucar.edu ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9026 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21278] Running the test suite with -v makes the test_ctypes and the test_zipimport erroneously reported as failed
ddve...@ucar.edu added the comment: If no one is able to reproduce it, I guess we can close it. I am sure I can reproduce it if I run it in the same situation I ran it the first time. However, I initially reported the bug for python 2.7.6 i.e. two versions ago, so it might have been fixed by something that happened meanwhile (or did the ones who tried used the exact version I reported the bug against?) If I experience the bug again while installing v2.7.9, I will report it here again (you all receive updates even if the bug is closed, right? I am asking because I don't thing I have the rights to re-open it). Thanks, Davide On Sat, Oct 4, 2014 at 6:47 PM, Mark Lawrence rep...@bugs.python.org wrote: Mark Lawrence added the comment: As there has been no response can this be closed? -- nosy: +BreamoreBoy status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21278 ___ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21278 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17126] test_gdb fails
ddve...@ucar.edu added the comment:
I am not sure what you mean by Double Dutch, but let me try to restate the
problem.
This test fails (even with current python 2.7.7) with the stated version of
gdb (given the lack of feedback since I initially opened this ticket, I
have not verified that the failure mode is still exactly the same, and I
cannot check it right now, but let's assume it is).
Let's just pick one of the simple failures:
==
FAIL: test_exceptions (test.test_gdb.PrettyPrintTests)
--
Traceback (most recent call last):
File /glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-
without-tipc/Lib/test/test_gdb.py, line 307, in test_exceptions
exceptions.RuntimeError('I am an error',))
AssertionError: op@entry=exceptions.RuntimeError('I am an error',) !=
exceptions.RuntimeError('I am an error',)
==
So this fails because there is a op@ prefix in the strings being compared
(many, but not all failures have this problem with string prefix). I do not
know anything about the test itself or the module under test, so I have no
idea whether or not that string prefix is essential for the module to work
properly.
Regards,
Davide
On Sun, Jun 29, 2014 at 4:46 PM, Mark Lawrence rep...@bugs.python.org
wrote:
Mark Lawrence added the comment:
Can we have a follow up on this please as most of the data in msg181358 is
Double Dutch to me.
--
nosy: +BreamoreBoy
type: - behavior
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17126
___
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17126
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20934] test_multiprocessing is broken by design
Changes by ddve...@ucar.edu ddve...@ucar.edu: -- nosy: +ddve...@ucar.edu ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20934 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21278] Running the test suite with -v makes the test_ctypes and the test_zipimport erroneously reported as failed
ddve...@ucar.edu added the comment: This bug is extremely hard to reproduce in a controlled manner. I mean, if I run EXTRATESTOPTS='-x test_gdb -uall -v' make testall it appears 100% of the times (whereas the same command without the -v works just fine, as I initially mentioned). But I do not want to run the whole thing, so I resorted to EXTRATESTOPTS='-uall -v -f ctypes_and_zipimport' make testall where the ctypes_and_zipimport file contains test_ctypes, test_zipimport and a handful of other tests. For all the tries I did, this always succeeded. So I can't debug this issue, sorry. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21278 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17160] test_urllib2net fails
ddve...@ucar.edu added the comment: Well, ok, thanks :-) But I'm still wondering if it's not possible to use mocks for this test. or at least example.com (as in issue #20939) which is supposed to be more stable than python.org -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17160 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21278] Running the test suite with -v makes the test_ctypes and the test_zipimport erroneously reported as failed
ddve...@ucar.edu added the comment: Ok, let me dig into it and see if I can figure it out On 04/20/2014 05:10 PM, Ezio Melotti wrote: Ezio Melotti added the comment: Do you want to propose a patch? -- components: +Tests nosy: +ezio.melotti type: - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21278 ___ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21278 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21246] test_ssl handshake failure
ddve...@ucar.edu added the comment: Despite this being Red Hat, this is not at all the case! OpenSSL 1.0.1f has been released on Jan 6th, 2014 at 15:39:19 -- see https://www.openssl.org/source/ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21246 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21246] test_ssl handshake failure
ddve...@ucar.edu added the comment: Just to make sure I'm using the right version: Python 2.7.6 (default, Apr 14 2014, 15:12:21) [GCC 4.8.2] on linux2 Type help, copyright, credits or license for more information. import ssl ssl.OPENSSL_VERSION 'OpenSSL 1.0.1f 6 Jan 2014' On 04/16/2014 08:49 AM, Davide Del Vento wrote: ddve...@ucar.edu added the comment: Despite this being Red Hat, this is not at all the case! OpenSSL 1.0.1f has been released on Jan 6th, 2014 at 15:39:19 -- see https://www.openssl.org/source/ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21246 ___ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21246 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20896] test_ssl.test_get_server_certificate() should use PROTOCOL_SSLv23, not PROTOCOL_SSLv3
ddve...@ucar.edu added the comment: This bug affected also the other versions I marked. Updating it, so people don't open duplicate bugs as I did with issue #21246 -- nosy: +ddve...@ucar.edu versions: +Python 2.7, Python 3.1, Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20896 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21246] test_ssl handshake failure
ddve...@ucar.edu added the comment: Thanks. The reason why I overlook it is that #20896 did not list 2.7 as an affected version. I changed #20896 to prevent other people doing the same mistake -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21246 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21278] Running the test suite with -v makes the test_ctypes and the test_zipimport erroneously reported as failed
New submission from ddve...@ucar.edu:
Running
EXTRATESTOPTS='-x test_gdb -uall -v' make testall
Produces:
test_csv
test_ctypes
test test_ctypes produced unexpected output:
**
Trying:
from ctypes import *
Expecting nothing
ok
Trying:
array = (c_char_p * 5)()
Expecting nothing
ok
Trying:
print array._objects
Expecting:
None
ok
Trying:
array[4] = 'foo bar'
Expecting nothing
ok
Trying:
array._objects
Expecting:
{'4': 'foo bar'}
ok
Trying:
array[4]
Expecting:
'foo bar'
ok
Trying:
class X(Structure):
_fields_ = [(x, c_int), (y, c_int), (array, c_char_p * 5)]
Expecting nothing
ok
Trying:
x = X()
Expecting nothing
ok
Trying:
print x._objects
Expecting:
None
ok
Trying:
print x.array._b_base_ # doctest: +ELLIPSIS
Expecting:
ctypes.test.test_objects.X object at 0x...
ok
Trying:
x.array[0] = 'spam spam spam'
Expecting nothing
ok
Trying:
x._objects
Expecting:
{'0:2': 'spam spam spam'}
ok
Trying:
x.array._b_base_._objects
Expecting:
{'0:2': 'spam spam spam'}
ok
2 items had no tests:
ctypes.test.test_objects.TestCase
ctypes.test.test_objects.TestCase.test
1 items passed all tests:
13 tests in ctypes.test.test_objects
13 tests in 3 items.
13 passed and 0 failed.
Test passed.
**
test_curses
.
test_zipimport
test test_zipimport produced unexpected output:
**
Trying:
log.append(True)
Expecting nothing
ok
1 items passed all tests:
1 tests in xyz.txt
1 tests in 1 items.
1 passed and 0 failed.
Test passed.
Trying:
log.append(True)
Expecting nothing
ok
1 items passed all tests:
1 tests in xyz.txt
1 tests in 1 items.
1 passed and 0 failed.
Test passed.
**
test_zipimport_support
test_zlib
366 tests OK.
4 tests failed:
test_ctypes test_urllib2net test_urllibnet test_zipimport
26 tests skipped:
test_aepack test_al test_applesingle test_bsddb test_bsddb185
test_bsddb3 test_cd test_cl test_curses test_dl test_gl
test_imageop test_imgfile test_kqueue test_linuxaudiodev
test_macos test_macostools test_msilib test_ossaudiodev
test_pep277 test_scriptpackages test_startfile test_sunaudiodev
test_winreg test_winsound test_zipfile64
2 skips unexpected on linux2:
test_bsddb test_bsddb3
Clearly the test_ctypes and the test_zipimport are not failing but the test
suite thinks so. In fact, rerunning without the -v let them succeed.
--
messages: 216616
nosy: ddve...@ucar.edu
priority: normal
severity: normal
status: open
title: Running the test suite with -v makes the test_ctypes and the
test_zipimport erroneously reported as failed
versions: Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21278
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20939] test_geturl of test_urllibnet fails with 'https://www.python.org/' != 'http://www.python.org/'
Changes by ddve...@ucar.edu ddve...@ucar.edu: -- nosy: +ddve...@ucar.edu ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20939 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17160] test_urllib2net fails
ddve...@ucar.edu added the comment: Reopening, since this is still broken in Python 2.7.6 I wonder why do we have to use real websites instead of mocks for this test. And if there are really really really really good reasons, if we can use example.com instead as in issue #20939 (maybe that is more stable than python.org) -- status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17160 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21246] test_ssl handshake failure
New submission from ddve...@ucar.edu:
Not sure if this is related with issue #13626 which is the only thing that
Google knows about these handshake failures. In case it matters:
$ openssl version
OpenSSL 1.0.1f 6 Jan 2014
== CPython 2.7.6 (default, Apr 14 2014, 15:12:21) [GCC 4.8.2]
== Linux-2.6.32-358.el6.x86_64-x86_64-with-redhat-6.4-Santiago little-endian
== /glade/scratch/ddvento/build/Python-2.7.6/build/test_python_18521
Testing with flags: sys.flags(debug=0, py3k_warning=0, division_warning=0,
division_new=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0,
no_user_site=0, no_site=0, ignore_environment=0, tabcheck=0, verbose=0,
unicode=0, bytes_warning=0, hash_randomization=0)
test_ssl
test_sslwrap_simple (test.test_ssl.BasicTests) ... ok
test_DER_to_PEM (test.test_ssl.BasicSocketTests) ... ok
test_ciphers (test.test_ssl.BasicSocketTests) ... ok
test_constants (test.test_ssl.BasicSocketTests) ... ok
test_openssl_version (test.test_ssl.BasicSocketTests) ... ok
test_parse_cert (test.test_ssl.BasicSocketTests) ...
{'notAfter': 'Oct 5 23:01:56 2020 GMT',
'subject': ((('countryName', u'XY'),),
(('localityName', u'Castle Anthrax'),),
(('organizationName', u'Python Software Foundation'),),
(('commonName', u'localhost'),)),
'subjectAltName': (('DNS', 'localhost'),)}
{'issuer': ((('countryName', u'US'),),
(('organizationName', u'VeriSign, Inc.'),),
(('organizationalUnitName', u'VeriSign Trust Network'),),
(('organizationalUnitName',
u'Terms of use at https://www.verisign.com/rpa (c)10'),),
(('commonName',
u'VeriSign Class 3 International Server CA - G3'),)),
'notAfter': 'Sep 20 23:59:59 2012 GMT',
'notBefore': 'Sep 21 00:00:00 2011 GMT',
'serialNumber': '2EE6EA7640A075CEE5005F4D7C79549A',
'subject': ((('countryName', u'FI'),),
(('stateOrProvinceName', u'Espoo'),),
(('localityName', u'Espoo'),),
(('organizationName', u'Nokia'),),
(('organizationalUnitName', u'BI'),),
(('commonName', u'projects.developer.nokia.com'),)),
'subjectAltName': (('DNS', 'projects.developer.nokia.com'),
('DNS', 'projects.forum.nokia.com')),
'version': 3}
ok
test_parse_cert_CVE_2013_4238 (test.test_ssl.BasicSocketTests) ...
{'issuer': ((('countryName', u'US'),),
(('stateOrProvinceName', u'Oregon'),),
(('localityName', u'Beaverton'),),
(('organizationName', u'Python Software Foundation'),),
(('organizationalUnitName', u'Python Core Development'),),
(('commonName', u'null.python.org\x00example.org'),),
(('emailAddress', u'python-...@python.org'),)),
'notAfter': 'Aug 7 13:12:52 2013 GMT',
'notBefore': 'Aug 7 13:11:52 2013 GMT',
'serialNumber': '00',
'subject': ((('countryName', u'US'),),
(('stateOrProvinceName', u'Oregon'),),
(('localityName', u'Beaverton'),),
(('organizationName', u'Python Software Foundation'),),
(('organizationalUnitName', u'Python Core Development'),),
(('commonName', u'null.python.org\x00example.org'),),
(('emailAddress', u'python-...@python.org'),)),
'subjectAltName': (('DNS', 'altnull.python.org\x00example.com'),
('email', 'n...@python.org\x00u...@example.org'),
('URI', 'http://null.python.org\x00http://example.org'),
('IP Address', '192.0.2.1'),
('IP Address', '2001:DB8:0:0:0:0:0:1\n')),
'version': 3}
ok
test_random (test.test_ssl.BasicSocketTests) ...
RAND_status is 1 (sufficient randomness)
ok
test_refcycle (test.test_ssl.BasicSocketTests) ... ok
test_wrapped_unconnected (test.test_ssl.BasicSocketTests) ... ok
test_algorithms (test.test_ssl.NetworkedTests) ... skipped 'remote host needs
SNI, only available on Python 3.2+'
test_connect (test.test_ssl.NetworkedTests) ... ok
test_connect_ex (test.test_ssl.NetworkedTests) ... ok
test_connect_ex_error (test.test_ssl.NetworkedTests) ... ok
test_get_server_certificate (test.test_ssl.NetworkedTests) ... ERROR
test_makefile_close (test.test_ssl.NetworkedTests) ... ok
test_non_blocking_connect_ex (test.test_ssl.NetworkedTests) ... ok
test_non_blocking_handshake (test.test_ssl.NetworkedTests) ...
Needed 3 calls to do_handshake() to establish session.
ok
test_timeout_connect_ex (test.test_ssl.NetworkedTests) ... ok
test_asyncore_server (test.test_ssl.ThreadedTests)
Check the example asyncore integration. ...
server: new connection from 127.0.0.1:48912
client: sending 'TEST MESSAGE of mixed case\n'...
client: read 'test message of mixed case\n'
client: closing connection.
cleanup: stopping server.
cleanup: joining server thread.
server: closed connection ssl.SSLSocket object at 0x2399140
cleanup: successfully joined.
ok
test_default_ciphers (test.test_ssl.ThreadedTests) ... ok
test_echo
[issue17085] test_socket crashes the whole test suite
ddve...@ucar.edu added the comment: The problem is that test_sendall_interrupted and test_sendall_interrupted_with_timeout make an assumption which is false on my hw, namely that it will take a long time for sendall() to complete. In fact, the following snippet: from timeit import default_timer import socket c,s=socket.socketpair() start = default_timer() c.sendall(x * (1024**2)) end= default_timer() print end-start probably fits some cache and runs in well less than 1ms (prints something between 0.000797 and 0.000876) on the server where this test is crashing (it takes forever on my laptop). Sending 1024**3 instead takes forever on the server too and makes the test pass. So the following patch is the least different for what you have now and it works on my server: --- original/Python-2.7.5/Lib/test/test_socket.py2013-05-11 21:32:47.0 -0600 +++ Python-2.7.5/Lib/test/test_socket.py2013-06-05 11:20:59.390516537 -0600 @@ -685,11 +685,11 @@ c.settimeout(1.5) with self.assertRaises(ZeroDivisionError): signal.alarm(1) -c.sendall(bx * (1024**2)) +c.sendall(bx * (1024**3)) if with_timeout: signal.signal(signal.SIGALRM, ok_handler) signal.alarm(1) -self.assertRaises(socket.timeout, c.sendall, bx * (1024**2)) +self.assertRaises(socket.timeout, c.sendall, bx * (1024**3)) finally: signal.signal(signal.SIGALRM, old_alarm) c.close() However this is just waiting for a failure when a different hw will make the sendall faster again. I believe two more robust tests should be designed, without making assumptions about timing. Not sure it's possible, but it's certainly desirable. Regards, Davide Del Vento, NCAR Computational Information Services Laboratory Consulting Services Software Engineer http://www2.cisl.ucar.edu/uss/csg/ SEA Chair http://sea.ucar.edu/ office: Mesa Lab, Room 55G office: (303) 497-1233 mobile: (303) 720-6338 On 05/19/2013 07:33 AM, Antoine Pitrou wrote: Antoine Pitrou added the comment: ddvento, I'm afraid you'll have to diagnose a bit more by tracing what happens during test_sendall_interrupted and test_sendall_interrupted_with_timeout. These test cases have a legitimate use for arming an alarm signal, but for some reason it seems the signal is triggered after those tests finish. Try printing exactly what happens at each step in those tests. Etienne, I'm not sure what the issue specifically is. Is Linux TIPC has a memory leak issue, it isn't really Python's problem. If any case, it is a separate issue and therefore should be discussed on a separate bug entry. -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17085 ___ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17085 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17085] test_socket crashes the whole test suite
ddve...@ucar.edu added the comment: Note that the previous patch would still let the test suite crash if the sendall() takes a short enough time. Having the test suite crash is so bad that I believe this should be the first issue to be fixed! The following patch prevents the test suite from crashing (however, without the previous patch, it lets this particular test fail on my machine). --- Python-2.7.5/Lib/test/test_socket.py2013-05-11 21:32:47.0 -0600 +++ Python-2.7.5-socket-fix/Lib/test/test_socket.py2013-06-05 12:05:41.038089911 -0600 @@ -691,6 +691,15 @@ signal.alarm(1) self.assertRaises(socket.timeout, c.sendall, bx * (1024**2)) finally: +# If c.sendall finishes before this process receives SIGALRM and +# the original signal handler is restored, the process will receive +# it and execute its default behavior of killing the +# interpreter. Make sure this doesn't happen by sleeping before +# restoring the original signal handler. Since only one alarm +# handler can be registered at once, we only need to sleep for 1 +# second since both have been called with the same 1 second time +# argument. +time.sleep(1) signal.signal(signal.SIGALRM, old_alarm) c.close() s.close() Regards, Davide Del Vento, NCAR Computational Information Services Laboratory Consulting Services Software Engineer http://www2.cisl.ucar.edu/uss/csg/ SEA Chair http://sea.ucar.edu/ office: Mesa Lab, Room 55G -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17085 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4483] Error to build _dbm module during make
ddve...@ucar.edu added the comment: This is still an issue in Python 2.7.3 but there is a quick manual workaround. I know it's trivial and one can easily develop it from what is said in the thread or maybe looking at the patches, but for reference this is a nice recipe as oppose to digging through many messages 1) build as usual, but redirect the output/error stream in a file, for example if your shell is bash (I find this to always be a good idea): make make.log 21 2) Towards the end of make.log there will be the following message. If you don't see this message, you don't have this problem, but possibly a different one: Failed to build these modules: dbm 3) execute grep \-o .*/dbmmodule.o make.log This will find a compiler line. Cut, paste and and execute that command 4) grep \-o .*/dbm.so make.log This will find another compiler line. Cut, paste and and execute that command, ADDING (this is essential) -lgdbm_compat 5) (optional) you may want to remove dbm_failed.so (in the same directory where the previous bullet creates dbm.so) -- nosy: +ddve...@ucar.edu ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4483 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17160] test_urllib2net fails
New submission from ddve...@ucar.edu: test_urllib2net fails as follows. Looking at test_urllib2net.py line 165 does not reveal anything interesting to me ./python Lib/test/regrtest.py -uall -v test_urllib2net == CPython 2.7.3 (default, Feb 8 2013, 08:28:21) [GCC 4.7.2] == Linux-2.6.32-220.13.1.el6.x86_64-x86_64-with-redhat-6.2-Santiago little-endian == /glade/scratch/ddvento/build/Python-2.7.3-westmere/build/test_python_7544 Testing with flags: sys.flags(debug=0, py3k_warning=0, division_warning=0, division_new=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, tabcheck=0, verbose=0, unicode=0, bytes_warning=0, hash_randomization=0) test_urllib2net test_custom_headers (test.test_urllib2net.OtherNetworkTests) ... ok test_file (test.test_urllib2net.OtherNetworkTests) ... ok test_fileno (test.test_urllib2net.OtherNetworkTests) ... ok test_ftp (test.test_urllib2net.OtherNetworkTests) ... ok test_sites_no_connection_close (test.test_urllib2net.OtherNetworkTests) ... ok test_urlwithfrag (test.test_urllib2net.OtherNetworkTests) ... FAIL test_close (test.test_urllib2net.CloseSocketTest) ... ok test_ftp_basic (test.test_urllib2net.TimeoutTest) ... ok test_ftp_default_timeout (test.test_urllib2net.TimeoutTest) ... ok test_ftp_no_timeout (test.test_urllib2net.TimeoutTest) ... ok test_ftp_timeout (test.test_urllib2net.TimeoutTest) ... ok test_http_basic (test.test_urllib2net.TimeoutTest) ... ok test_http_default_timeout (test.test_urllib2net.TimeoutTest) ... ok test_http_no_timeout (test.test_urllib2net.TimeoutTest) ... ok test_http_timeout (test.test_urllib2net.TimeoutTest) ... ok == FAIL: test_urlwithfrag (test.test_urllib2net.OtherNetworkTests) -- Traceback (most recent call last): File /glade/scratch/ddvento/build/Python-2.7.3-westmere/Lib/test/test_urllib2net.py, line 165, in test_urlwithfrag http://docs.python.org/glossary.html#glossary;) AssertionError: 'http://docs.python.org/2/glossary.html' != 'http://docs.python.org/glossary.html#glossary' -- Ran 15 tests in 14.684s FAILED (failures=1) test test_urllib2net failed -- Traceback (most recent call last): File /glade/scratch/ddvento/build/Python-2.7.3-westmere/Lib/test/test_urllib2net.py, line 165, in test_urlwithfrag http://docs.python.org/glossary.html#glossary;) AssertionError: 'http://docs.python.org/2/glossary.html' != 'http://docs.python.org/glossary.html#glossary' 1 test failed: test_urllib2net -- components: Tests messages: 181682 nosy: ddve...@ucar.edu priority: normal severity: normal status: open title: test_urllib2net fails versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17160 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17161] make install misses the man and the static library
New submission from ddve...@ucar.edu: This is for python 2.7.3 built with 0) ./configure --enable-shared --with-system-expat 1) I need both static and shared object, however libpython2.7.a is not copied in the installation target lib. Is this on purpose, or am I missing a flag in configure? 2) In share/man/man1/ there are two issues: 2a) the manual is for 2.7.1 instead of 2.7.3 2b) the man command looks for a python.1 file, therefore one must issue: ln -s python2.7.1 python.1 -- components: Installation messages: 181684 nosy: ddve...@ucar.edu priority: normal severity: normal status: open title: make install misses the man and the static library versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17161 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17160] test_urllib2net fails
ddve...@ucar.edu added the comment: Yes, it is possible, do you want me to investigate more with my network people? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17160 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17092] Disable TIPC in configure
ddve...@ucar.edu added the comment: Ok, I'm closing this ticket, since it does not seem there is interested in fixing it. I still believe it would be a nice feature, but life is short, let's concentrate efforts on more useful things. Moreover (see Issue17085 for details) TIPC was not the root cause of the that other issue. -- resolution: - wont fix status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17092 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17085] test_socket crashes the whole test suite
ddve...@ucar.edu added the comment: So I rebuild python withou tipc (basically deleting it from configure, since it cannot be cleanly avoided, see Issue17092). The 'sudo modprobe tipc' message of course disappears, but the uncaught alarm is still there, see below: ./python Lib/test/regrtest.py -v test_socket == CPython 2.7.3 (default, Feb 2 2013, 11:27:13) [GCC 4.7.2] == Linux-2.6.32-220.13.1.el6.x86_64-x86_64-with-redhat-6.2-Santiago little-endian == /glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/build/test_python_9390 Testing with flags: sys.flags(debug=0, py3k_warning=0, division_warning=0, division_new=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, tabcheck=0, verbose=0, unicode=0, bytes_warning=0, hash_randomization=0) test_socket testCrucialConstants (test.test_socket.GeneralModuleTests) ... ok testDefaultTimeout (test.test_socket.GeneralModuleTests) ... ok testGetServBy (test.test_socket.GeneralModuleTests) ... ok testGetSockOpt (test.test_socket.GeneralModuleTests) ... ok testGetaddrinfo (test.test_socket.GeneralModuleTests) ... ok testHostnameRes (test.test_socket.GeneralModuleTests) ... ok testIPv4_inet_aton_fourbytes (test.test_socket.GeneralModuleTests) ... ok testIPv4toString (test.test_socket.GeneralModuleTests) ... ok testIPv6toString (test.test_socket.GeneralModuleTests) ... ok testInterpreterCrash (test.test_socket.GeneralModuleTests) ... ok testListenBacklog0 (test.test_socket.GeneralModuleTests) ... ok testNewAttributes (test.test_socket.GeneralModuleTests) ... ok testNtoH (test.test_socket.GeneralModuleTests) ... ok testNtoHErrors (test.test_socket.GeneralModuleTests) ... ok testRefCountGetNameInfo (test.test_socket.GeneralModuleTests) ... ok testSendAfterClose (test.test_socket.GeneralModuleTests) ... ok testSendtoErrors (test.test_socket.GeneralModuleTests) ... ok testSetSockOpt (test.test_socket.GeneralModuleTests) ... ok testSockName (test.test_socket.GeneralModuleTests) ... ok testSocketError (test.test_socket.GeneralModuleTests) ... ok testStringToIPv4 (test.test_socket.GeneralModuleTests) ... ok testStringToIPv6 (test.test_socket.GeneralModuleTests) ... ok test_flowinfo (test.test_socket.GeneralModuleTests) ... ok test_getsockaddrarg (test.test_socket.GeneralModuleTests) ... ok test_sendall_interrupted (test.test_socket.GeneralModuleTests) ... FAIL test_sendall_interrupted_with_timeout (test.test_socket.GeneralModuleTests) ... FAIL test_sock_ioctl (test.test_socket.GeneralModuleTests) ... skipped 'Windows specific' test_weakref (test.test_socket.GeneralModuleTests) ... ok testDup (test.test_socket.BasicTCPTest) ... ok testFromFd (test.test_socket.BasicTCPTest) ... ok testOverFlowRecv (test.test_socket.BasicTCPTest) ... ok testOverFlowRecvFrom (test.test_socket.BasicTCPTest) ... ok testRecv (test.test_socket.BasicTCPTest) ... ok testRecvFrom (test.test_socket.BasicTCPTest) ... ok testSendAll (test.test_socket.BasicTCPTest) ... ok testShutdown (test.test_socket.BasicTCPTest) ... ok testClose (test.test_socket.TCPCloserTest) ... Alarm clock -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17085 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17085] test_socket crashes the whole test suite
ddve...@ucar.edu added the comment:
Just to see this test running to completion, I applied the following (ugly)
patch:
--- Lib/test/test_socket.py.orig2012-04-09 17:07:32.0 -0600
+++ Lib/test/test_socket.py 2013-02-03 06:56:11.778118985 -0700
@@ -14,7 +14,7 @@
import array
import contextlib
from weakref import proxy
-import signal
+#import signal
import math
def try_address(host, port=0, family=socket.AF_INET):
@@ -33,6 +33,12 @@
MSG = b'Michael Gilfix was here\n'
SUPPORTS_IPV6 = socket.has_ipv6 and try_address('::1', family=socket.AF_INET6)
+signal = not a signal
+
try:
import thread
With it, the test case completed as follows, which at least confirmed that the
only broken part is sendall_interrupted. I'll live with it for now, but I'll be
happy to work with the maintainer of these tests to understand what are they
trying to accomplish, how to make them fail more gracefully (I tried installing
a signal handler without success), and how to tell what to do to users of
systems affected by the issue.
./python Lib/test/regrtest.py -v test_socket
== CPython 2.7.3 (default, Feb 2 2013, 11:27:13) [GCC 4.7.2]
== Linux-2.6.32-220.13.1.el6.x86_64-x86_64-with-redhat-6.2-Santiago
little-endian
==
/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/build/test_python_16005
Testing with flags: sys.flags(debug=0, py3k_warning=0, division_warning=0,
division_new=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0,
no_user_site=0, no_site=0, ignore_environment=0, tabcheck=0, verbose=0,
unicode=0, bytes_warning=0, hash_randomization=0)
test_socket
testCrucialConstants (test.test_socket.GeneralModuleTests) ... ok
testDefaultTimeout (test.test_socket.GeneralModuleTests) ... ok
testGetServBy (test.test_socket.GeneralModuleTests) ... ok
testGetSockOpt (test.test_socket.GeneralModuleTests) ... ok
testGetaddrinfo (test.test_socket.GeneralModuleTests) ... ok
testHostnameRes (test.test_socket.GeneralModuleTests) ... ok
testIPv4_inet_aton_fourbytes (test.test_socket.GeneralModuleTests) ... ok
testIPv4toString (test.test_socket.GeneralModuleTests) ... ok
testIPv6toString (test.test_socket.GeneralModuleTests) ... ok
testInterpreterCrash (test.test_socket.GeneralModuleTests) ... ok
testListenBacklog0 (test.test_socket.GeneralModuleTests) ... ok
testNewAttributes (test.test_socket.GeneralModuleTests) ... ok
testNtoH (test.test_socket.GeneralModuleTests) ... ok
testNtoHErrors (test.test_socket.GeneralModuleTests) ... ok
testRefCountGetNameInfo (test.test_socket.GeneralModuleTests) ... ok
testSendAfterClose (test.test_socket.GeneralModuleTests) ... ok
testSendtoErrors (test.test_socket.GeneralModuleTests) ... ok
testSetSockOpt (test.test_socket.GeneralModuleTests) ... ok
testSockName (test.test_socket.GeneralModuleTests) ... ok
testSocketError (test.test_socket.GeneralModuleTests) ... ok
testStringToIPv4 (test.test_socket.GeneralModuleTests) ... ok
testStringToIPv6 (test.test_socket.GeneralModuleTests) ... ok
test_flowinfo (test.test_socket.GeneralModuleTests) ... ok
test_getsockaddrarg (test.test_socket.GeneralModuleTests) ... ok
test_sendall_interrupted (test.test_socket.GeneralModuleTests) ... skipped
'signal.alarm and socket.socketpair required for this test'
test_sendall_interrupted_with_timeout (test.test_socket.GeneralModuleTests) ...
skipped 'signal.alarm and socket.socketpair required for this test'
test_sock_ioctl (test.test_socket.GeneralModuleTests) ... skipped 'Windows
specific'
test_weakref (test.test_socket.GeneralModuleTests) ... ok
testDup (test.test_socket.BasicTCPTest) ... ok
testFromFd (test.test_socket.BasicTCPTest) ... ok
testOverFlowRecv (test.test_socket.BasicTCPTest) ... ok
testOverFlowRecvFrom (test.test_socket.BasicTCPTest) ... ok
testRecv (test.test_socket.BasicTCPTest) ... ok
testRecvFrom (test.test_socket.BasicTCPTest) ... ok
testSendAll (test.test_socket.BasicTCPTest) ... ok
testShutdown (test.test_socket.BasicTCPTest) ... ok
testClose (test.test_socket.TCPCloserTest) ... ok
testInterruptedTimeout (test.test_socket.TCPTimeoutTest) ... ok
testTCPTimeout (test.test_socket.TCPTimeoutTest) ... ok
testTimeoutZero (test.test_socket.TCPTimeoutTest) ... ok
testExceptionTree (test.test_socket.TestExceptions) ... ok
testRecvFromIntoArray (test.test_socket.BufferIOTest) ... ok
testRecvFromIntoBytearray (test.test_socket.BufferIOTest) ... ok
testRecvFromIntoMemoryview (test.test_socket.BufferIOTest) ... ok
testRecvIntoArray (test.test_socket.BufferIOTest) ... ok
testRecvIntoBytearray (test.test_socket.BufferIOTest) ... ok
testRecvIntoMemoryview (test.test_socket.BufferIOTest) ... ok
testDup (test.test_socket.BasicTCPTest2) ... ok
testFromFd (test.test_socket.BasicTCPTest2) ... ok
testOverFlowRecv (test.test_socket.BasicTCPTest2) ... ok
testOverFlowRecvFrom (test.test_socket.BasicTCPTest2) ... ok
testRecv (test.test_socket.BasicTCPTest2) ... ok
testRecvFrom (test.test_socket.BasicTCPTest2) ... ok
testSendAll
[issue1326841] SIGALRM alarm signal kills interpreter
ddve...@ucar.edu added the comment: Paul, I agree with you, this default behavior is painful. And in fact even the author of the test_socket case for the python regression suite agree with us (maybe even implicitly and by mistake, but regardless...) See Issue17085 for details -- nosy: +ddve...@ucar.edu ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1326841 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17092] Disable TIPC in configure
New submission from ddve...@ucar.edu: This is related to Issue17085 and Issue1646 My system is a cluster Red Hat Enterprise Linux Server release 6.2 (Santiago) and it happens to have /usr/include/linux/tipc.h but probably tipc disabled in the kernel for some reasons which I ignore. There is little interest and no time from the sysadministrators to investigate TIPC, or to remove unneeded files or packages. When I configure and build Python 2.7.3, it seems to build correctly. However the test suite crashes as described in Issue17085. Therefore, I want to rebuild Python 2.7.3 with TIPC disabled. Unfortunately, configure seems to ignore all of the followings: ./configure --without-tipc ./configure --without-TIPC HAVE_LINUX_TIPC_H=0 ./configure HAVE_LINUX_TIPC_H=0 ./configure HAVE_LINUX_TIPC_H=0 (for the record, my other configure options are --enable-shared --with-system-expat --prefix=my-path) I also tried to manually editing config.status as follows: --- config.status.orig 2013-01-31 09:24:04.109311726 -0700 +++ config.status 2013-01-31 09:28:28.397660288 -0700 @@ -854,7 +854,7 @@ D[HAVE_SYS_RESOURCE_H]= 1 D[HAVE_NETPACKET_PACKET_H]= 1 D[HAVE_SYSEXITS_H]= 1 -D[HAVE_LINUX_TIPC_H]= 1 +D[HAVE_LINUX_TIPC_H]= 0 D[HAVE_SPAWN_H]= 1 D[HAVE_DIRENT_H]= 1 D[HAVE_TERM_H]= 1 then run it and check that pyconfig.h has #define HAVE_LINUX_TIPC_H 0 (which it did). Running make and make test after this, produces exactly the same issue as described in Issue17085. Is there a way to force configure to ignore TIPC? -- components: Build messages: 181037 nosy: ddve...@ucar.edu priority: normal severity: normal status: open title: Disable TIPC in configure versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17092 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17092] Disable TIPC in configure
ddve...@ucar.edu added the comment: Antoine, the exact reason why I want to disable TIPC in configure, is that either the test suite or the TIPC test case or both has/have a bug (not my system). Therefore I suggest that you re-post your comment in Issue17085, and I'll be happy to provide more details that would be off-topic here. However, regardless of my particular needs, disabling TIPC in configure is something useful for a variety of other reasons (e.g. one having a functional TIPC but not wanting to have it enabled in python), and therefore I asked it here. It is customary to have autotools being able to individually select packages that one wants or does not want to use. In fact ./configure --help reports the --without-PACKAGE option which does not work for TIPC and this is the bug of present Issue17092 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17092 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17085] test_socket crashes the whole test suite
New submission from ddve...@ucar.edu: While running make test on my build of python 2.7.3 the suite aborts with [..omiss..] test_socket make: *** [test] Alarm clock Trying to run individually the offending test reveals a little more $ ./python Lib/test/regrtest.py -v test_socket == CPython 2.7.3 (default, Jan 29 2013, 11:23:48) [GCC 4.7.2] == Linux-2.6.32-220.13.1.el6.x86_64-x86_64-with-redhat-6.2-Santiago little-endian == /glade/scratch/ddvento/build/Python-2.7.3-westmere/build/test_python_12171 Testing with flags: sys.flags(debug=0, py3k_warning=0, division_warning=0, division_new=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, tabcheck=0, verbose=0, unicode=0, bytes_warning=0, hash_randomization=0) test_socket TIPC module is not loaded, please 'sudo modprobe tipc' testCrucialConstants (test.test_socket.GeneralModuleTests) ... ok testDefaultTimeout (test.test_socket.GeneralModuleTests) ... ok testGetServBy (test.test_socket.GeneralModuleTests) ... ok testGetSockOpt (test.test_socket.GeneralModuleTests) ... ok testGetaddrinfo (test.test_socket.GeneralModuleTests) ... ok testHostnameRes (test.test_socket.GeneralModuleTests) ... ok testIPv4_inet_aton_fourbytes (test.test_socket.GeneralModuleTests) ... ok testIPv4toString (test.test_socket.GeneralModuleTests) ... ok testIPv6toString (test.test_socket.GeneralModuleTests) ... ok testInterpreterCrash (test.test_socket.GeneralModuleTests) ... ok testListenBacklog0 (test.test_socket.GeneralModuleTests) ... ok testNewAttributes (test.test_socket.GeneralModuleTests) ... ok testNtoH (test.test_socket.GeneralModuleTests) ... ok testNtoHErrors (test.test_socket.GeneralModuleTests) ... ok testRefCountGetNameInfo (test.test_socket.GeneralModuleTests) ... ok testSendAfterClose (test.test_socket.GeneralModuleTests) ... ok testSendtoErrors (test.test_socket.GeneralModuleTests) ... ok testSetSockOpt (test.test_socket.GeneralModuleTests) ... ok testSockName (test.test_socket.GeneralModuleTests) ... ok testSocketError (test.test_socket.GeneralModuleTests) ... ok testStringToIPv4 (test.test_socket.GeneralModuleTests) ... ok testStringToIPv6 (test.test_socket.GeneralModuleTests) ... ok test_flowinfo (test.test_socket.GeneralModuleTests) ... ok test_getsockaddrarg (test.test_socket.GeneralModuleTests) ... ok test_sendall_interrupted (test.test_socket.GeneralModuleTests) ... FAIL test_sendall_interrupted_with_timeout (test.test_socket.GeneralModuleTests) ... FAIL test_sock_ioctl (test.test_socket.GeneralModuleTests) ... skipped 'Windows specific' test_weakref (test.test_socket.GeneralModuleTests) ... ok testDup (test.test_socket.BasicTCPTest) ... ok testFromFd (test.test_socket.BasicTCPTest) ... ok testOverFlowRecv (test.test_socket.BasicTCPTest) ... ok testOverFlowRecvFrom (test.test_socket.BasicTCPTest) ... ok testRecv (test.test_socket.BasicTCPTest) ... ok testRecvFrom (test.test_socket.BasicTCPTest) ... ok testSendAll (test.test_socket.BasicTCPTest) ... ok testShutdown (test.test_socket.BasicTCPTest) ... ok testClose (test.test_socket.TCPCloserTest) ... Alarm clock $ echo $? 142 Of course my installation has an issue (which I'm trying to identify), but the test suite should not crash on a failure of individual test. I believe this is related to Issue1326841 in that the test author forgot to install the signal handler, or maybe was expecting the behavior Paul Rubin suggested in said bug. -- components: Tests messages: 180993 nosy: ddve...@ucar.edu priority: normal severity: normal status: open title: test_socket crashes the whole test suite versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17085 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
