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
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
<http://bugs.python.org/issue9
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
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
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).
Changes by ddve...@ucar.edu :
--
nosy: +ddve...@ucar.edu
___
Python tracker
<http://bugs.python.org/issue20934>
___
___
Python-bugs-list mailing list
Unsubscribe:
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.melo
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
--
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 *
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
<http://bugs.python.
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, Pytho
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 s
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
<http://bugs.python.
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
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
Changes by ddve...@ucar.edu :
--
nosy: +ddve...@ucar.edu
___
Python tracker
<http://bugs.python.org/issue20939>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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
ddve...@ucar.edu 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
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
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
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 di
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 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
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
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 no
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
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
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
29 matches
Mail list logo
