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.python.org/issue1044
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://bugs.python.org/issue1044
Changes by jan matejek [EMAIL PROTECTED]:
--
nosy: +matejcik
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1621
__
___
Python-bugs-list mailing list
Unsubscribe
jan matejek jmate...@suse.cz 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 rep...@bugs.python.org
jan matejek jmate...@suse.cz 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
jan matejek jmate...@suse.cz 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 notable example being
jan matejek jmate...@suse.cz 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
Changes by jan matejek jmate...@suse.cz:
--
nosy: +matejcik
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6706
___
___
Python-bugs-list mailing
jan matejek jmate...@suse.cz 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
Changes by jan matejek [EMAIL PROTECTED]:
--
nosy: +matejcik
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3879
___
___
Python-bugs-list mailing list
Changes by jan matejek [EMAIL PROTECTED]:
--
nosy: +matejcik
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3886
___
___
Python-bugs-list mailing list
Changes by jan matejek [EMAIL PROTECTED]:
--
nosy: +matejcik
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1424152
___
___
Python-bugs-list mailing
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):
sock = sock._sock
return
Changes by jan matejek [EMAIL PROTECTED]:
--
nosy: +matejcik
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3620
___
___
Python-bugs-list mailing list
New submission from jan matejek jmate...@suse.cz:
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
New submission from jan matejek jmate...@suse.cz:
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
New submission from jan matejek jmate...@suse.cz:
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
jan matejek jmate...@suse.cz added the comment:
see issue 8335
--
nosy: +matejcik
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6022
Changes by jan matejek [EMAIL PROTECTED]:
--
nosy: +matejcik
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1179
__
___
Python-bugs-list mailing list
Unsubscribe
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?
--
nosy: +matejcik
Changes by jan matejek jmate...@suse.cz:
--
nosy: +matejcik
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1298813
___
___
Python-bugs-list mailing
Changes by jan matejek jmate...@suse.cz:
--
nosy: +matejcik
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6386
___
___
Python-bugs-list mailing
Changes by jan matejek jmate...@suse.cz:
--
nosy: +matejcik
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5103
___
___
Python-bugs-list mailing
jan matejek jmate...@suse.cz 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=59339r2=59340
where the code was added for py3k branch
New submission from jan matejek jmate...@suse.cz:
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
jan matejek jmate...@suse.cz 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-2.6.2-multilib.patch
jan matejek jmate...@suse.cz 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't too hard
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 yet another
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 different
jan matejek jmate...@suse.cz 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
Changes by jan matejek jmate...@suse.cz:
--
nosy: +matejcik
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12801
___
___
Python-bugs-list mailing
New submission from jan matejek jmate...@suse.cz:
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
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 issue with test setup.
so
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 mysterious
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 rep
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 rep...@bugs.python.org
http://bugs.python.org/issue17928
Changes by jan matejek jmate...@suse.cz:
--
nosy: +matejcik
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1294959
___
___
Python-bugs-list mailing
Changes by jan matejek jmate...@suse.cz:
--
nosy: +matejcik
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue858809
___
___
Python-bugs-list mailing
jan matejek jmate...@suse.cz 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 rep...@bugs.python.org
http
jan matejek jmate...@suse.cz 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 rep
Changes by jan matejek jmate...@suse.cz:
--
nosy: +matejcik
nosy_count: 3.0 - 4.0
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue891930
Changes by jan matejek jmate...@suse.cz:
--
nosy: +matejcik
nosy_count: 3.0 - 4.0
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1019715
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 probably
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 - it works for us
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 yields
Changes by jan matejek jmate...@suse.cz:
--
nosy: +matejcik
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20763
___
___
Python-bugs-list mailing
Changes by jan matejek jmate...@suse.cz:
--
nosy: +matejcik
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16043
___
___
Python-bugs-list mailing
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
Changes by jan matejek jmate...@suse.cz:
--
versions: -Python 2.7, Python 3.1
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21070
___
___
Python
Changes by jan matejek jmate...@suse.cz:
--
nosy: +matejcik
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21082
___
___
Python-bugs-list mailing
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
relevant
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
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:
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/random.patch
Changes by jan matejek <jmate...@suse.cz>:
--
nosy: +matejcik
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26252>
___
__
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 <rep...@bugs.python.org>
<htt
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 check the mess
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 <rep...@bugs.python.org>
<http://bugs.python.org/i
Changes by jan matejek <jmate...@suse.com>:
--
pull_requests: +94
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29324>
___
__
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 getpath
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
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:
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 <rep...@bugs.python.org>
<htt
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 <rep...@bugs.python.org>
<http://bugs.python.org/i
Changes by jan matejek <jmate...@suse.com>:
--
pull_requests: +3682
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pytho
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's
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
Change by jan matejek :
--
versions: +Python 3.9
___
Python tracker
<https://bugs.python.org/issue44762>
___
___
Python-bugs-list mailing list
Unsubscribe:
72 matches
Mail list logo
