John Beck added the comment:
Solaris has this problem also, and Chris' patch fixes it for us.
--
nosy: +jbeck
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
New submission from John Beck:
Solaris ships Python versions 2.7, 3.4 and 3.5 at present. For 2.7,
we ship both 32-bit and 64-bit versions; for 3.4 and 3.5 we only ship
64-bit versions. For 2.7, we ship /usr/lib/python2.7/config/ with the
usual suspects (Makefile, Setup.config, config.c
New submission from John Beck:
A bug has been filed against Solaris' internal version of Python, which is
largely the same (including in this case) as the base version we get from
python.org. The bug is that os.defpath starts with ':' and thus any Python
script run with a null PATH environment
John Beck added the comment:
Confirmed that test_os runs cleanly on Solaris 12, for each of:
* 2.7.10 (plus your patch from 98454:202c827f86df)
* 3.4.3 (plus your patch from 98455:83dc79eeaf7f)
* 3.5.0 (plus your patch from 98452:835085cc28cd)
* 3.6 (tip
John Beck added the comment:
I have tested your patch with 3.5, and it works fine, although I did have to
make a minor change to get test_os to pass. In test_os.py you had:
...
USE_GETENTROPY = ((sysconfig.get_config_var('HAVE_GETENTROPY') == 1
John Beck added the comment:
I have queried the engineer who owns the kernel bug and will post an update
once I hear back from him. But as it is already almost midnight on Friday in
his geo, it may well be Monday before I hear back.
--
___
Python
John Beck added the comment:
Yes, those patches work, with a caveat. While testing this, I found out why I
had needed EINVAL earlier (and still do, for now): there is a bug in the
Solaris implementation of getrandom(2). If flags are 0 and the buffer size >
1024, then it fails with EIN
John Beck added the comment:
Sorry, let me try to clarify. ENOSYS is the correct errno value to check for,
for the situation (e.g., Solaris < 11.3) of a non-existent system call. But
EINVAL should also be checked for to make sure the system call was invoked with
proper parameters. My bui
John Beck added the comment:
Yes, the syscall was failing with EINVAL.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25003>
___
__
John Beck added the comment:
@haypo: Yes, that patch works (applied to 3.5.0rc3; proxy problems are
preventing me from updating my clone of the default branch at the moment) i.e.,
pyconfig.h shows:
#define HAVE_GETRANDOM_SYSCALL 1
To answer your other questions:
* Calling syscall
New submission from John Beck:
A recent Solaris build upgrade resulted in a massive slowdown of a package
operation (our package client is written in Python). Some DTrace revealed this
was because os.urandom() calls had slowed down by a factor of over 300. This
turned out to be caused
New submission from John Beck:
When running test_mmap on a partition with < 4GB free, it back-traced:
Traceback (most recent call last):
File "/usr/lib/python3.4/test/test_mmap.py", line 728, in _make_test_file
f.flush()
OSError: [Errno 28] No space left on device
Du
John Beck added the comment:
First, there are two related but somewhat separate issues here.
Regarding the patches attached to http://bugs.python.org/issue20664
they seem fine. In theory, they should not be needed, as though it
is true that dump(1) moved from /usr/ccs/bin to /usr/bin
John Beck added the comment:
(Apologies for not responding on May 27 when you posted the patch;
I failed to notice the Added file: line in the e-mail notification.)
Yes! The patch you posted fixes the issue. Thank you!
--
___
Python tracker rep
New submission from John Beck:
The upgrade from 2.7.9 to 2.7.10 resulted in test__locale failing.
This test had previously succeeded. The difference is that the
thousands-separator for the fr_FR locale in known_numerics was
changed from '' (i.e., unknown) to ' ' (i.e. space). But on Solaris
Changes by John Beck john.b...@oracle.com:
--
nosy: +jbeck
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1298835
___
___
Python-bugs-list mailing
New submission from John Beck:
The man page for Python (3.4 and 3.5) says:
-I Run Python in isolated mode. This also implies -E and -S. In
isolated mode sys.path contains neither the scripts directory
nor the users site-packages directory. All PYTHON
John Beck added the comment:
Thank you very much for clarifying that. I have updated the bug Title
accordingly.
--
title: man page says -I implies -S. code says -s. Should it be both? - man
page says -I implies -S. code says -s.
___
Python tracker
John Beck added the comment:
Adding Christian Heimes to the nosy list; as the author of the fix for
issue 16499, he seems an excellent person to answer the question and
offer advice on the approaches discussed herein.
--
nosy: +christian.heimes
John Beck added the comment:
We (Solaris engineering) have hit this issue after migrating from 2.6
being our default version of Python to 2.7 being the default. The
specific component that broke was vim (version 7.4), trying to compile
if_python.c:
/usr/include/python2.7/pyport.h, line 645
New submission from John Beck:
Issue 8473 fixed a problem with lineendings in test_doctest, but it
appears not to work in verbose mode. Adding verbose=False to the
doctest.testfile() invocations in test_lineendings() fixes this.
Attaching a patch to fix this for both 2.7 and 3.4
New submission from John Beck:
On Solaris, in Lib/ctypes/util.py, we have code that looks for
/usr/bin/crle and calls it to parse its output to try to determine
the Default Library Path. This code broke recently (Solaris 12 build
65), as it expects to find a line starting with
Default
John Beck added the comment:
Ned: yes, I can confirm that the patch from http://bugs.python.org/issue21166
does indeed fix the problem. Thank you very much!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21412
John Beck added the comment:
Hm, that is strange. My reading of the semantics of foo.h vs
foo.h was that they are almost the same, except that foo.h has
the additional semantic of searching the local directory (wherever
the .c file is that is #include'ing it) first. So if other platforms
New submission from John Beck:
Background: on Solaris, we build Python and various modules 64-bit. To
make this work with our general 64-bit changes, we use foo/64 as the path
for our shared objects (.so files) rather than foo, for various values
of foo (e.g., /usr/lib, /usr/lib/python3.4, etc
John Beck added the comment:
Victor:
* This is not a SPARC-specific issue; the exact same failure occurs
on x86.
* I had built Python 3.3 (some time ago) but only --without-pymalloc.
But I tried just now rebuilt Python 3.3 --with-pymalloc, and it
failed in the exact same way
John Beck added the comment:
Victor: sure; see attached.
--
Added file: http://bugs.python.org/file35140/where.out
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21412
New submission from John Beck:
I am porting Python 3.4.0 to Solaris 12. The Makefile I inherited from my
predecessor had --without-pymalloc as an option to be passed to configure.
Curious why, I removed this line, only to find that after python was built, it
core dumped:
LD_LIBRARY_PATH
John Beck added the comment:
Using Oracle Studio 12.3, same as mentioned in
http://bugs.python.org/issue15963#msg170661 (as Stefan pointed out). I am
using some of those flags but not all of them. I will try the others when I
have a chance, then report back
Changes by John Beck john.b...@oracle.com:
--
nosy: +jbeck
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13405
___
___
Python-bugs-list mailing
30 matches
Mail list logo
