[email protected] 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
[email protected] 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
Changes by [email protected] :
--
nosy: [email protected]
___
Python tracker
<http://bugs.python.org/issue20939>
___
___
Python-bugs-list mailing list
Unsubscribe:
[email protected] 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
New submission from [email protected]:
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
[email protected] 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
<http://bugs.python.
[email protected] 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 s
[email protected] 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: [email protected]
versions: +Python 2.7, Python 3.1, Python 3.2, Pytho
[email protected] 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
<http://bugs.python.
New submission from [email protected]:
Running
EXTRATESTOPTS='-x test_gdb -uall -v' make testall
Produces:
test_csv
test_ctypes
test test_ctypes produced unexpected output:
**
Trying:
from ctypes import *
[email protected] 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
--
[email protected] 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.melo
Changes by [email protected] :
--
nosy: [email protected]
___
Python tracker
<http://bugs.python.org/issue20934>
___
___
Python-bugs-list mailing list
Unsubscribe:
[email protected] 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).
New submission from [email protected]:
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
New submission from [email protected]:
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
[email protected] 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
[email protected] 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 no
[email protected] 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
[email protected] 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
[email protected] 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
[email protected] 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 di
New submission from [email protected]:
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
New submission from [email protected]:
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
[email protected] added the comment:
Yes, it is possible, do you want me to investigate more with my network
people?
--
___
Python tracker
<http://bugs.python.org/issue17
[email protected] 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
[email protected] 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
[email protected] added the comment:
This problem is occurring again in python 2.7.7, can we open it again?
--
nosy: [email protected]
___
Python tracker
<http://bugs.python.org/issue9
[email protected] 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
29 matches
Mail list logo
