Change by jan matejek :
--
versions: +Python 3.9
___
Python tracker
<https://bugs.python.org/issue44762>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by jan matejek :
--
versions: -Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8,
Python 3.9
___
Python tracker
<https://bugs.python.org/issue44
jan matejek added the comment:
For that matter, in standard Windows Command Prompt `sys.stdin` and
`sys.__stdin__` are also identical, but `isatty()` reports True.
I suspect is that the code has drifted and `sys.stdin` is _always_ identical to
`sys.__stdin__
jan matejek added the comment:
...this is a problem because:
When the check incorrectly infers that it can use `msvcrt` while its stdin is a
pipe, the calls to `putwch` and `getwch` are going into the void and the
program effectively freezes waiting for input that never comes.
See also
New submission from jan matejek :
The fallback detection for `win_getpass` checks that `sys.stdin` is different
from `sys.__stdin__`. If yes, it assumes that it's incapable of disabling echo,
and calls `default_getpass` which reads from stdin.
If they are the same object, it assumes it
Changes by jan matejek :
--
pull_requests: +3682
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue1294959>
___
___
Python-bugs-list mai
Changes by jan matejek :
--
pull_requests: +94
___
Python tracker
<http://bugs.python.org/issue29324>
___
___
Python-bugs-list mailing list
Unsubscribe:
jan matejek added the comment:
the attached patch fixes the test for me
--
keywords: +patch
Added file: http://bugs.python.org/file46494/test_socket_aead_kernel49.patch
___
Python tracker
<http://bugs.python.org/issue29
jan matejek added the comment:
The "'0' * taglen" part is now considered part of plaintext. Which makes a lot
of sense :)
Removing the "empty taglen" fixes the encryption part of the tests for me.
Similarly, for the decryption test, we must only read and chec
jan matejek added the comment:
Attached is a patch that I'd like to propose for inclusion.
It introduces a new configure option "--with-custom-platlibdir=", which
defaults to `basename $libdir`. This is converted to makefile variable
"platlibdir", which is used in ge
New submission from jan matejek:
Lib/site-packages directory now contains README.txt in addition to README. Both
files are identical. One of them should probably go away?
--
components: Installation
messages: 28
nosy: matejcik
priority: normal
severity: normal
status: open
title
jan matejek added the comment:
at this again, when porting SUSE patches to 3.6.0 :) ( :( )
Last time there was a discussion, Barry suggested using sysconfig variables to
find the proper libdir. Trouble is, to fill out the variables, sysconfig itself
uses two sources:
a) compiled-in
jan matejek added the comment:
some instances are present in unicodeobject.c too
--
Added file: http://bugs.python.org/file46156/unicode-overflow.patch
___
Python tracker
<http://bugs.python.org/issue29
jan matejek added the comment:
No, your changes from issue 27473 are OK. However functions like
replace_interleave and replace_single_character etc. still use the broken code:
/* use the difference between current and new, hence the "-1" */
/* result_len = self_len + count *
jan matejek added the comment:
It does, but "-fwrapv" is not automatically added when you specify custom OPT
flags. I should have clarified that in the original report.
--
___
Python tracker
<http://bugs.python.o
New submission from jan matejek:
Related to http://bugs.python.org/issue1621 and
http://bugs.python.org/issue27473
GCC 6 optimizes away broken overflow checks. This leads to segfaults on
test_replace_overflow, at least for strings and bytearrays.
--
components: Interpreter Core
jan matejek added the comment:
unlike #26839, however, there is no workaround for "import random".
so i maintain that this issue is in fact very specific to the random module
--
___
Python tracker
<http://bugs.python.o
Changes by jan matejek :
--
nosy: +matejcik
___
Python tracker
<http://bugs.python.org/issue26252>
___
___
Python-bugs-list mailing list
Unsubscribe:
jan matejek added the comment:
attaching a first draft of what i'd consider a solution? not sure if this is
the right way to go, and i don't know how to write a test for an import
statement
--
Added file: http://bugs.python.org/file40820/ra
jan matejek added the comment:
let me reiterate that what I consider a bug is the fact that "import random"
statement calls os.urandom (which per the proposed documentation may sometimes
block)
IOW, "import random" may sometimes block, even though it is not actually used
jan matejek added the comment:
On 18.10.2015 23:09, STINNER Victor wrote:
> Hum ok, so your issue is specific to Linux.
yes, should have specified that, sorry
> Hum, the problem was already fixed some months/years ago: you must attach a
> RNG virtio device to your VM. Python is
New submission from jan matejek:
When imported, the random module creates and seeds an implicit instance, even
when it is never used.
The RNG is seeded from os.urandom, which as of python 3.5 uses the potentially
blocking getrandom() call.
This causes problems e.g. on our build VMs that
New submission from jan matejek:
The pep 476 commit to Python 2.7 [1] adds unconditional "import ssl" to
test_urllib2_localnet.py. This causes the test to fail with an ImportError if
ssl module is not built.
Note that like 5 lines later, ssl is imported conditionally, and all the
Changes by jan matejek :
--
nosy: +matejcik
___
Python tracker
<http://bugs.python.org/issue21082>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by jan matejek :
--
versions: -Python 2.7, Python 3.1
___
Python tracker
<http://bugs.python.org/issue21070>
___
___
Python-bugs-list mailing list
Unsub
New submission from jan matejek:
Testcases derived from BaseServerTestCase will launch a server process in a
separate thread. This server will shut itself down after handling a specified
number of requests. If the test case fails before performing enough requests,
the server thread will
Changes by jan matejek :
--
nosy: +matejcik
___
Python tracker
<http://bugs.python.org/issue16043>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by jan matejek :
--
nosy: +matejcik
___
Python tracker
<http://bugs.python.org/issue20763>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from jan matejek:
When compiling "make profile-opt", the instrumented python executable segfaults
upon exit, even though it appears to run fine.
This breaks the build process, because make evaluates the segfault as if the
respective compilation step failed.
GDB
jan matejek added the comment:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dne 7.11.2013 16:56, Matthias Klose napsal(a):
>
> Matthias Klose added the comment:
>
> the patch in msg202343 is wrong, hardcoding lib64 on Debian/Ubuntu.
This patch is provided for reference only -
jan matejek added the comment:
Yes. We still have a patch for two things:
1. fix setup.py script to look for libraries in correct (lib64) prefixes, and
2. fix values returned from sysconfig, to reflect that python resides in lib64
"$prefix/lib" is hardcoded in many places. Lib64 is pr
jan matejek added the comment:
hmm, but it's caused by a private patch claiming that _testcapimodule.c is
PY_SSIZE_T_CLEAN. sorry for the noise.
--
___
Python tracker
<http://bugs.python.org/is
jan matejek added the comment:
The fix causes regression on my 64bit little-endian machine. It seems that
while parsing the arguments, the length value overwrites part of the string
pointer.
--
nosy: +matejcik
___
Python tracker
<h
jan matejek added the comment:
so apparently the problem was that we're using the borked original patch for
issue #16962, instead of the fixed version that's actually in repos.
(The d_type field was missing, so every filename had an extra character
prepended to it.
AFAICT, all
jan matejek added the comment:
i don't think that's it, look at the result output in comment #183756: the list
of fds is correct, except that they aren't closed as they should be.
i can't reproduce the result when running code by hand, so it's either a race
or an i
jan matejek added the comment:
Not just yet, please. I can now reproduce the test_subprocess failures outside
autobuild too. Interestingly, it's the reverse here: test_subprocess passes
when /proc is not present, but fails when it is.
I'm pretty sure that we hijacked a completely
jan matejek added the comment:
Ismail, the sem_open thing is because in autobuild you don't get /proc or
somesuch - it's a problem of our buildsystem, otherwise the test passes.
I can reproduce the failure in autobuild, but not separately yet. Will keep you
posted, signs point to y
New submission from jan matejek :
from Demo/scripts/newslist.py :
# Feel free to copy, distribute and modify this code for
# non-commercial use. If you make any useful modifications, let me
# know!
#
# (c) Quentin Stafford-Fraser 1994
# fra...@europarc.xerox.com qs
Changes by jan matejek :
--
nosy: +matejcik
___
Python tracker
<http://bugs.python.org/issue12801>
___
___
Python-bugs-list mailing list
Unsubscribe:
jan matejek added the comment:
please check my logic here, but the patched code seems to throw away perfectly
valid return codes:
in wait(), self._handle_exitstatus(sts) gets called unconditionally, and it
resets self.returncode also unconditionally.
now, if a _cleanup() already did
jan matejek added the comment:
i was able to reproduce this in clean 2.7
Sandro, this is only reproducible on systems without python - so by definition,
you can hit this only during installation
as for issue8335, yes, i think that it's a duplicate
distutils2 is irrelevant here, becaus
Changes by jan matejek :
--
nosy: +matejcik
___
Python tracker
<http://bugs.python.org/issue6706>
___
___
Python-bugs-list mailing list
Unsubscribe:
jan matejek added the comment:
this affects 2.7 as well. the problem was introduced by r78136 which skips out
of the directory containing newly built libpython2.7, so the linking command
cannot find it in -L. and fails (unless a systemwide libpython is already
present)
the tests should
jan matejek added the comment:
the problem this patch was solving is "python libraries install into
"prefix/lib" regardless of what is the correct local LIBDIR" - which is
obviously broken on systems where LIBDIR is something other than "prefix/lib",
most notab
jan matejek added the comment:
Tarek,
the error output is this:
/usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../x86_64-suse-linux/bin/ld:
cannot find -lpython2.6
the chdir is the problem - because in an environment where you don't have an
existing Python installation, you will not
jan matejek added the comment:
yes, reverting r72637 fixes this problem for me
it reintroduces the original bug (there is some temporary file left behind),
but i don't care about that
--
___
Python tracker
<http://bugs.python.org/i
jan matejek added the comment:
see issue 8335
--
nosy: +matejcik
___
Python tracker
<http://bugs.python.org/issue6022>
___
___
Python-bugs-list mailing list
Unsub
New submission from jan matejek :
when running testsuite in a clean environment without pre-installed system
python, test_distutils fail in test_build_ext, test_get_outputs:
/usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../x86_64-suse-linux/bin/ld:
cannot find -lpython2.6
LinkError: command
jan matejek added the comment:
well in our patch, at least, the directory is governed by sys.lib which
is defined through configure.
i don't understand the configure language well enough, but i'd assume
that making it parametrized isn&
jan matejek added the comment:
for completenes, here's a patch that's in use in SUSE. it's advantage
over Fedora's is that it works on both 32bit and 64bit installs
--
Added file: http://bugs.python.org/file14726/Python-
New submission from jan matejek :
test_bdist_wininst.py fails in non-windows environment, depending on the
order of execution of tests in the test_distutils suite
When this test is not run on windows, msvccompiler.py fails to load
win32 registry modules and emits a warning-level message to the
jan matejek added the comment:
i believe that the bug lies in bad implementation/backport of feature
from 3.0 patch for issue1251.
see this revision:
http://svn.python.org/view/python/branches/release30-maint/Lib/ssl.py?r1=59339&r2=59340
where the code was added for py3k branch.
the l
Changes by jan matejek :
--
nosy: +matejcik
___
Python tracker
<http://bugs.python.org/issue5103>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by jan matejek :
--
nosy: +matejcik
___
Python tracker
<http://bugs.python.org/issue6386>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by jan matejek :
--
nosy: +matejcik
___
Python tracker
<http://bugs.python.org/issue1298813>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by jan matejek :
--
nosy: +matejcik
nosy_count: 3.0 -> 4.0
___
Python tracker
<http://bugs.python.org/issue1019715>
___
___
Python-bugs-list mai
Changes by jan matejek :
--
nosy: +matejcik
nosy_count: 3.0 -> 4.0
___
Python tracker
<http://bugs.python.org/issue891930>
___
___
Python-bugs-list mai
jan matejek added the comment:
...the patch is absolutely trivial, doesn't have any deep consequences
and applies cleanly to head and all branches i know of.
...i wonder if the patch-fasttracking offer still applies...
___
Python tracker
jan matejek added the comment:
well, seeing as redesign of distutils probably won't happen anytime soon...
why don't we fix the obvious bug (broken configure) now and redesign
distutils later?
___
Python tracker
<http://bugs.python.or
Changes by jan matejek :
--
nosy: +matejcik
___
Python tracker
<http://bugs.python.org/issue858809>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by jan matejek :
--
nosy: +matejcik
___
Python tracker
<http://bugs.python.org/issue1294959>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from jan matejek :
documentation for PySys_SetArgv states that the function sets sys.argv,
but fails to mention that it also resolves script's path and prepends it
to sys.path. Or, in case no script was specified, it prepends empty
string (which in versions <2.6 allowed
New submission from jan matejek :
since 2.6 httplib supports reading from file-like objects.
Now consider the following situation:
There are two handlers in urrlib2, first is plain http, second is basic
auth.
I want to POST a file to a service, and pass the open file object as
data parameter to
Changes by jan matejek <[EMAIL PROTECTED]>:
--
nosy: +matejcik
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3620>
___
___
Python
New submission from jan matejek <[EMAIL PROTECTED]>:
python 2.6's compatibility socket.ssl() method does not handle 'sock'
parameter in the same way.
in 2.5, ssl() looked like this:
def ssl(sock, keyfile=None, certfile=None):
if hasattr(sock, "_sock"):
Changes by jan matejek <[EMAIL PROTECTED]>:
--
nosy: +matejcik
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1424152>
___
__
Changes by jan matejek <[EMAIL PROTECTED]>:
--
nosy: +matejcik
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3886>
___
___
Python
Changes by jan matejek <[EMAIL PROTECTED]>:
--
nosy: +matejcik
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3879>
___
___
Python
jan matejek <[EMAIL PROTECTED]> added the comment:
> "as it doesn't seem /dev/shm is the culprit"
Mounting /dev/shm seems to fix the problem in suse's autobuild (chroot)
environment, so for me it actually was the culprit. Perhaps you should
recheck your buildbots
Changes by jan matejek <[EMAIL PROTECTED]>:
--
nosy: +matejcik
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1179>
__
___
Python-bugs-list mailing
Changes by jan matejek <[EMAIL PROTECTED]>:
--
nosy: +matejcik
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1621>
__
___
Python-bugs-list mailing
jan matejek added the comment:
if that can be considered "official stance", it's fine by me. feel free
to close the bug.
__
Tracker <[EMAIL PROTECTED]>
<http://b
jan matejek added the comment:
no change to extract() ?
otherwise looks good to me. if you don't object, i am applying this to
SUSE's python 2.5
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.p
73 matches
Mail list logo
