Changes by Matthias Klose :
--
nosy: +doko
___
Python tracker
<http://bugs.python.org/issue8032>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Matthias Klose :
[forwarded from http://bugs.debian.org/577005]
seen with 2.5.5, 2.6.5 and 2.7alpha4:
The imp.find_module function causes a glibc double free or corruption if
it would be invoked with a directory with a ".py" ending. It can be
reproduced with:
mk
Matthias Klose added the comment:
this was caused by r76567, introduction of the sem_open configure checks. The
build machines building the binary packages for lucid use kernels from the last
stable LTS release:
./a.out; echo $?
sem_open: Function not implemented
1
$ uname -r
2.6.24-25
Matthias Klose added the comment:
the ARMv4 buildbot is a 500Mhz Xscale, with a SATA disk attached, 256MB RAM. It
can't go faster :-/
the ARMv7 buildbot is a cortex-a8, 500Mhz, 512MB RAM. I found here five or six
python processes still running, now killed. The machine may be unrespo
Matthias Klose added the comment:
attached is a search for execlp for all files found in Ubuntu lucid, there's
one package which uses just one argument to execlp.
--
Added file: http://bugs.python.org/file16980/execlp.log
___
Python tracker
Matthias Klose added the comment:
> Does Ubuntu use a small stack size?
it's 8192 on all architectures.
--
nosy: +doko
___
Python tracker
<http://bugs.python.or
Matthias Klose added the comment:
I'm told it's 10240 on Fedora 12, x86 and x86_64
--
___
Python tracker
<http://bugs.python.org/issue7332>
___
___
Matthias Klose added the comment:
PATH_MAX/MAXPATHLEN is 4096
--
___
Python tracker
<http://bugs.python.org/issue7332>
___
___
Python-bugs-list mailing list
Unsub
Changes by Matthias Klose :
--
nosy: +doko
___
Python tracker
<http://bugs.python.org/issue8437>
___
___
Python-bugs-list mailing list
Unsubscribe:
Matthias Klose added the comment:
> That would explain why it's only reported on Ubuntu
the original report is from the rPath distribution.
--
___
Python tracker
<http://bugs.python.or
New submission from Matthias Klose :
the attached patch adds quoting to help strings and code snippets, following
the autoconf quotation rule of thumb "One pair of quotes per pair of
parentheses".
checked that the generated files are identical.
--
components: B
New submission from Matthias Klose :
update to autoconf2.65
--
components: Build
files: autoconf2.65.diff
keywords: needs review, patch
messages: 104018
nosy: doko
severity: normal
status: open
title: update to autoconf2.65
versions: Python 2.7, Python 3.2
Added file: http
Matthias Klose added the comment:
see http://mail.python.org/pipermail/python-dev/2010-April/099639.html
--
___
Python tracker
<http://bugs.python.org/issue8
Matthias Klose added the comment:
applied the changes for 2.7 and 3.2. there is a diff for the regenerated
configure like
-rm -f -r conftest*
+rm -f conftest*
I explicitely used a vanilla autoconf-2.61 download for regenerating the
configure script. Why the diff
Matthias Klose added the comment:
here is the diff for configure.in. The __EXTENSIONS__ macro is defined by 2.65
for Solaris, removed this explicit definition. running a test build
--
Added file: http://bugs.python.org/file17070/configure.in.diff
Matthias Klose added the comment:
r80474: Replace AC_HELP_STRING with AS_HELP_STRING
--
___
Python tracker
<http://bugs.python.org/issue8510>
___
___
Python-bug
Matthias Klose added the comment:
r80475: s/AC_AIX/AC_USE_SYSTEM_EXTENSIONS/
--
___
Python tracker
<http://bugs.python.org/issue8510>
___
___
Python-bugs-list m
Matthias Klose added the comment:
r80478 converts all obsolete AC_TRY_* macros to AC_*_IFELSE, the outcome is ...
nothing (but whitespace changes):
$ svn diff --diff-cmd diff -x -uEwB configure
Index: configure
===
--- configure
Matthias Klose added the comment:
r80481: configure.in: Avoid autoconf warning: Assume C89 semantics that
RETSIGTYPE is always void (issue #8510).
Keep the definition, although the python code itself doesn't use it anymore.
--
___
Python tr
Matthias Klose added the comment:
r80483: Makefile.pre.in (autoconf): Call autoconf/autoheader with -Wall to help
the configure script to stay warning free.
--
___
Python tracker
<http://bugs.python.org/issue8
Matthias Klose added the comment:
libffi 3.0.9 is installed. the buildbot master needs to pass
--with-system-libffi to configure.
--
nosy: +doko
___
Python tracker
<http://bugs.python.org/issue8
New submission from Matthias Klose :
Building with -flto (GCC 4.5.0) requires passing the very same optimization
flags to the linker (lto1) as well. The attached patch just does this. Tested
on Linux only, I don't know what will/could break on on other systems/compilers.
Tested with a s
Matthias Klose added the comment:
> It's probably better to just pass OPT to the linker instead.
not enough, because -fno-strict-aliasing might be passed in BASE_CFLAGS.
--
___
Python tracker
<http://bugs.python.or
Matthias Klose added the comment:
> You don't need to add source in case of
> AC_COMPILE_IFELSE([AC_LANG_SOURCE([[]])] ..
> when the the test is ..main() { return 0 ;} ...
is there a version of the cross configure patch for 3.x?
--
Matthias Klose added the comment:
my understanding is that the builder is allowed to overwrite OPT, but not
BASE_CFLAGS.
--
___
Python tracker
<http://bugs.python.org/issue8
Matthias Klose added the comment:
the update to 2.65 on the py3k branch only did show whitespace changes,
applying these changes to the trunk.
r80964: require autoconf-2.65
--
___
Python tracker
<http://bugs.python.org/issue8
Matthias Klose added the comment:
r80965: Replace AC_HELP_STRING with AS_HELP_STRING
r80966: s/AC_AIX/AC_USE_SYSTEM_EXTENSIONS/
r80969: convert all obsolete AC_TRY_* macros to AC_*_IFELSE
r80970: Avoid autoconf warning: Assume C89 semantics that RETSIGTYPE is always
void
New submission from Matthias Klose:
as seen in the logs from
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=455400
both pyconfig.h and png.h define _BSD_SOURCE, which leads to a build
failure with current GCC from the trunk, when both headers are included
by an extension. Either define it
Changes by Matthias Klose:
--
nosy: +loewis
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1699>
__
___
Python-bugs-list mailing list
Unsubs
Matthias Klose added the comment:
there's a buildbot for mips-linux, none for mips64, so lets close this one.
--
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pyt
New submission from Matthias Klose <[EMAIL PROTECTED]>:
r61009 on the 2.5 branch
- Bug #1389051, 1092502: fix excessively large memory allocations when
calling .read() on a socket object wrapped with makefile().
causes a regression compared to 2.4.5 and 2.5.2:
When reading from u
New submission from Matthias Klose <[EMAIL PROTECTED]>:
[forwarded from http://bugs.debian.org/470645]
"SimpleXMLRPCDispatcher.__init__ used to take a single argument
(self) in python2.4 and now it takes three. The two new arguments
need to get default values or else this break
Changes by Matthias Klose <[EMAIL PROTECTED]>:
--
nosy: +doko
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2632>
__
___
Python-bugs-list mailin
New submission from Matthias Klose <[EMAIL PROTECTED]>:
ctypes fails to build on arm-linux-gnu, see
http://python.org/dev/buildbot/2.5/ARM Linux 2.5/builds/3/step-compile/0
gcc -pthread -fPIC -fno-strict-aliasing -g -Wall -Wstrict-prototypes -I.
-I/home/pybot/buildarea-arm/2.5.klose-lin
Changes by Matthias Klose <[EMAIL PROTECTED]>:
--
assignee: -> theller
components: +ctypes
nosy: +theller
type: -> compile error
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
New submission from Matthias Klose <[EMAIL PROTECTED]>:
as seen in issue4303, the buildbots don't complain about build failures
in extensions. it would be nice to have a mode, where the build fails
when an extension doesn't build, but is expected to build. exceptions to
this
New submission from Matthias Klose <[EMAIL PROTECTED]>:
seen on the mipsel buildbot
running build
running build_ext
INFO: Can't locate Tcl/Tk libs and/or headers
Traceback (most recent call last):
File "./setup.py", line 1880, in
main()
File "./setup.py&quo
New submission from Matthias Klose <[EMAIL PROTECTED]>:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=507317
needs backport of rev 61350 from the trunk.
fixed in newer versions.
--
components: Interpreter Core
messages: 76638
nosy: doko
priority: release blocker
severity:
New submission from Matthias Klose <[EMAIL PROTECTED]>:
Python-2.6/Doc/tools/sphinxext/patchlevel.pyc
Python-2.6/Doc/tools/sphinxext/pyspecific.pyc
Python-2.6/Doc/tools/roman.pyc
same for 3.0
--
assignee: barry
components: Build
messages: 76875
nosy: barry, doko
severity: normal
New submission from Matthias Klose <[EMAIL PROTECTED]>:
Doc/tools/sphinxext not included in the 2.6.1 tarball, but it is checked in.
--
components: Build
messages: 77067
nosy: doko
priority: deferred blocker
severity: normal
status: open
title: Doc/tools/sphinxext not included
Matthias Klose <[EMAIL PROTECTED]> added the comment:
> In my opinion the tar balls should contain all necessary bits and pieces
> to build the docs yourself. It makes no sense to include the Doc/ folder
> w/o any means to use them.
+ 1
> Let's include sphinxext an
New submission from Matthias Klose :
there are some problems with ctypes.util.find_library(), which I would
like to see fixed on active branches.
- find_library is not robust, if either objdump or gcc are not
installed. fixed by raising an exception if the tools are not
found. Is OSError
Matthias Klose added the comment:
new version of the patch using os instead of platform, and selecting the
correct library for biarch platforms, tested on ia64, sparc, s390,
amd64, ppc64. unsure if there's a better way to find out if the
executable is 32 or 64bit.
Added file:
Matthias Klose added the comment:
I think 4861 provides a solution for this issue. I don't see any system
where objdump is in /sbin or /usr/sbin.
--
nosy: +doko
___
Python tracker
<http://bugs.python.org/i
Matthias Klose added the comment:
now fixed in 2.6, 2.7, 3.0 and 3.1.
objdump is never installed in /sbin. I don't think we should assume a
specific path for objdump. we don't do this for gcc either.
--
assignee: theller -> doko
resolution: -> fixed
status
Matthias Klose added the comment:
I keep this open for now, I don't have access to AIX. Yes, if objdump is
found in some /sbin PATH, then maybe we should search there explicitely.
___
Python tracker
<http://bugs.python.org/i
New submission from Matthias Klose :
these tests fail, when python is built with builddir != srcdir.
==
ERROR: test_build_ext (distutils.tests.test_build_ext.BuildExtTestCase
New submission from Matthias Klose :
==
ERROR: testExtractDir (test.test_zipfile.TestWithDirectory)
--
Traceback (most recent call last):
File
"/home/pac
Matthias Klose added the comment:
still seen on the 2.6 branch. applying r69374 on the branch doesn't fix
it there.
--
nosy: +doko
resolution: fixed ->
status: closed -> open
versions: +Python 2.6
___
Python tracker
<http://b
Matthias Klose added the comment:
no, still seen on the branches. I'll have a look at backporting these
changes to the 2.6 branch before 2.6.2.
--
versions: -Python 2.7, Python 3.1
___
Python tracker
<http://bugs.python.org/i
New submission from Matthias Klose :
the test_multiprocessing_fork test is a bit unreliable, at least on both the
Debian and Ubuntu test infrastructures, sometimes running for 100+ hours. When
running locally, I cannot reproduce these issues. Note that the test and build
infrastructure is
Change by Matthias Klose :
--
keywords: +3.7regression -patch
___
Python tracker
<https://bugs.python.org/issue38368>
___
___
Python-bugs-list mailing list
Unsub
Matthias Klose added the comment:
Some distros have two include directories in the path,
/usr/include
/usr/include/
The latter for architecture specific files, so on these distributions the
python config file is installed there. Then you'll need to have both include
direct
Matthias Klose added the comment:
I'll get back on this
--
___
Python tracker
<https://bugs.python.org/issue36852>
___
___
Python-bugs-list mailing list
Matthias Klose added the comment:
that looks fine. Maybe also set LANG=C ?
--
___
Python tracker
<https://bugs.python.org/issue23767>
___
___
Python-bugs-list m
New submission from Matthias Klose :
On Posix targets, the file names for extensionsions are currently
foo.cpython-39-x86_64-linux-gnu.so
foo.abi3.so
for platforms which have PLATFORM_TRIPLET defined. This makes it clear which
extension belongs to which interpreter, and at least on Debian
Matthias Klose added the comment:
> How will these filenames be generated? Won't build tools like setuptools need
> to be changed as well?
If the preferred file name stays the same, it would be up to the distro
specific packaging tools. But yes, if the platform specific name w
Matthias Klose added the comment:
A bunch of people, consisting of Filipe Lains himself, Geoffrey Thomas, Donald
Stufft, Tzu-Ping Chung, Pradyun Gedam, Stefano Rivera, Elana Hashman, and
myself (Matthias Klose), and with feedback from Carol Willing and Christian
Heimes were preparing a PEP
New submission from Matthias Klose :
[reported in Debian as https://bugs.debian.org/998854]
3.9.8, compared to 3.9.7 introduces a regression, making at least one third
party extension fail at runtime. The symbol changes in 3.9.8 are:
- _PyUnicode_DecodeUnicodeEscape@Base
Matthias Klose added the comment:
the two users of typed-ast (at least in Debian) are black and mypy. Apparently
black stopped using typed-ast recently.
--
___
Python tracker
<https://bugs.python.org/issue45
Matthias Klose added the comment:
The idea with the extension names is to have different names for different
ABIs. See https://wiki.debian.org/Multiarch/Tuples for the list of ABIs that
are "known", or documented.
mips-linux-gnu is documented as MIPS32r2+FPXX, which is a differen
Matthias Klose added the comment:
You misunderstand. The GNU triplets are ambiguous. mips 32bit big endian soft
float, and mips 32bit big endian hard float are *not* ABI compatible, but map
to the same GNU triplet.
The check *is* cross compiler aware, it's run with the target
preproc
Matthias Klose added the comment:
seen with the current 3.8 branch.
--
keywords: +3.8regression
nosy: +doko, lukasz.langa
priority: normal -> release blocker
___
Python tracker
<https://bugs.python.org/issu
Matthias Klose added the comment:
I think the patch is wrong. why would you want to differentiate between native
and cross builds? There should be a generic way to pick up those for both
cross and native builds.
--
___
Python tracker
<ht
Matthias Klose added the comment:
the multiarch approach allows you to install libraries and headers for many
architectures in the same installation/chroot. This can then be used to
cross-build stuff.
you can check that on WSL with having Debian or Ubuntu installed. A short
reference is
Matthias Klose added the comment:
I don't agree with this decision, but ok.
In this case, please also provide a way to provide the value of the VERSION_ID
field. It doesn't make sense to blacklist whole distributions in tests.
--
New submission from Matthias Klose :
regression compared to 3.8:
$ python3.9
Python 3.9.1rc1 (default, Nov 27 2020, 19:38:39)
[GCC 10.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> ctypes.util.find
Matthias Klose added the comment:
ctypes.util.find_library("c") works in both 3.8 and 3.9
--
___
Python tracker
<https://bugs.python.org/issue42580>
___
__
Matthias Klose added the comment:
Ubuntu 20.04 LTS still sees subminor Python 3.8 version updates, and needs to
use sphinx 1.8.5.
--
nosy: +doko
___
Python tracker
<https://bugs.python.org/issue42
New submission from Matthias Klose :
[forwarded from https://bugs.debian.org/961396]
$ cat > foo.c
#include
int main(int argc, char *argv[])
{
Py_UNICODE x = 0;
return Py_UNICODE_ISSPACE(x);
}
$ gcc -Wsign-compare -Werror $(pkg-config --cflags python3) foo.c
In file inclu
Matthias Klose added the comment:
# 26 "/usr/include/stdlib.h" 2 3 4
# 1 "/usr/lib/gcc/x86_64-linux-gnu/10/include/stddef.h" 1 3 4
# 321 "/usr/lib/gcc/x86_64-linux-gnu/10/include/stddef.h" 3 4
typedef int wchar_t;
# 32 "/usr/include/stdlib.h" 2 3 4
[.
New submission from Matthias Klose :
[forwarded from https://bugs.debian.org/969776]
"""
rust-webbrowser tries to open URLs via "gvfs-open $URL" and
"gnome-open $URL". Both are obsolete; the replacement is "gio open $URL",
using the gio(1) tool fr
Matthias Klose added the comment:
ctypes.util.find_library("libc") used to work in 3.8, not working in 3.9. As I
said before, ctypes.util.find_library("c") works in both 3.8 and 3.9.
--
___
Python tracker
<https://bug
Matthias Klose added the comment:
Please could you edit
/usr/lib/python3.9/_sysconfigdata__x86_64-linux-gnu.py
setting LIBDIR to /usr/lib/x86_64-linux-gnu
and see if that fixes the freeze issue?
that could also be fixed by configuring with --libdir=/usr/lib/x86_64-linux-gnu
but that also
Matthias Klose added the comment:
see also https://github.com/pypa/pip/issues/9617
--
nosy: +doko
___
Python tracker
<https://bugs.python.org/issue43
Matthias Klose added the comment:
The Debian/Ubuntu packages have a local patch for distutils/setuptools
introducing an --install-layout option. Maybe have the same for pip?
The intention with renaming/moving site-packages to
/usr/lib/python3/dist-packages is to avoid users damaging their
Matthias Klose added the comment:
I can't reproduce that:
$ python3.7 -c 'import sys; print (sys.path)'
['', '/usr/lib/python37.zip', '/usr/lib/python3.7',
'/usr/lib/python3.7/lib-dynload', '/usr/local/lib/python3.7/dist-packages
Matthias Klose added the comment:
I'm +-0 on if that should be integrated into 3.9. Only a few people are using
--with-system-libmpdec. However the way that mpdecimal 2.4 and 2.5 are
released, they are not usable for Debian or Ubuntu for the transition from 3.8
to 3.9. For that, bot
Change by Matthias Klose :
--
nosy: +ivyl
___
Python tracker
<https://bugs.python.org/issue41206>
___
___
Python-bugs-list mailing list
Unsubscribe:
Matthias Klose added the comment:
that's a regression for the 3.8 branch, marking as a release blocker for 3.8.4.
This should be a documented change for 3.9, and probably reverted/fixed for
3.8.
--
keywords: +3.8regression, 3.9regression
nosy: +doko, lukasz.langa
priority: n
Matthias Klose added the comment:
please note that pinning usually is not a solution for Linux distributions.
Yes, the most wanted fix would be to fix sphinx 3.x not to break compatibility
with 2.x. Or limit 3.9 to 2.x features for now.
--
nosy: +doko
Matthias Klose added the comment:
> It's too late to add a new deprecation in the Python 3.9 cycle
Please can we add a note in 3.9, that it will be deprecated in 3.10?
--
nosy: +doko
___
Python tracker
<https://bugs.python.org
Matthias Klose added the comment:
Renaming distutils to _buildutils only delays the problem to remove it. But
yes, it explicitly makes it explicit that code needs to be changed.
I would like to see that neither distutils or _buildutils is installed by
default, and only is available
Matthias Klose added the comment:
> A PEP may be a good idea, but I do think the change doesn't have a
> particularly large magnitude. Anyone using setuptools or pip has
> already been getting setuptools' monkey-patched version of distutils
> for ages now, and soo
Matthias Klose added the comment:
David, which issue number is this?
--
nosy: +doko
___
Python tracker
<https://bugs.python.org/issue41295>
___
___
Python-bug
Matthias Klose added the comment:
3.9.0 rc1 fails to build the docs with Sphinx 3.2.0, even with setting
c_allow_pre_v3 = True
c_warn_on_allowed_pre_v3 = False
Warning, treated as error:
/packages/python/3.9/python3.9-3.9.0~rc1/Doc/c-api/buffer.rst:92:Error in
declarator or parameters
New submission from Matthias Klose :
the 3.8.6 rc1 documentation fails to build with sphinx 3.2.1:
[...]
reading sources... [ 98%] whatsnew/3.1
reading sources... [ 98%] whatsnew/3.2
reading sources... [ 98%] whatsnew/3.3
reading sources... [ 98%] whatsnew/3.4
reading sources... [ 98
Change by Matthias Klose :
--
nosy: +ned.deily
___
Python tracker
<https://bugs.python.org/issue41760>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Matthias Klose :
--
nosy: +lukasz.langa
___
Python tracker
<https://bugs.python.org/issue41760>
___
___
Python-bugs-list mailing list
Unsubscribe:
Matthias Klose added the comment:
it's easy to say "we need it". It took a while to remove that, so I don't think
it should be easily re-introduced.
so why do you need it, and why should it be exposed as part of t
Matthias Klose added the comment:
I became aware of this by the patch proposal "Please submit a PR to skip on
Ubuntu", which results in the re-introduction of a distro specific API.
I would rather help fixing this issue, instead on relying on some distro
behavor.
--
n
Matthias Klose added the comment:
> Since the filename is now fixed and the format is well specified,
> IMO it's perfectly fine to add PR 23492.
I disagree with that. The distro module is the preferred way to do this (which
cannot be used in the Python core). The rationale give
Matthias Klose added the comment:
"The os-release file has been a well-defined standard for over 8 years."
... doesn't implicate that it's a good style to base your checks on that
information.
--
___
Python tracker
<
Matthias Klose added the comment:
the Chef repo seems to be a little bit out-of-date, but anyway. I don't see the
relevance for this issue.
--
___
Python tracker
<https://bugs.python.org/is
Matthias Klose added the comment:
> * /etc/os-release file <= this PR
> * /etc/*release file <= covered by the PyPI distro module
no Victor, you are wrong. os-release is covered by the distro module. There's
no need to expose a second implementation as another API in the
Matthias Klose added the comment:
Christian, is it necessary to start with threats?
> Python could also follow the lead of other software like D-Bus
> and make the presence of os-release mandatory on Linux.
> Any Linux platform without it would be considered broken.
> I don&#
Matthias Klose added the comment:
how is this test run on the CI? at least it succeeds for me when run locally.
--
___
Python tracker
<https://bugs.python.org/issue42
Matthias Klose added the comment:
> In the case of this it's mood to even discuss requiring
> os-release. (a) the PR does not add a hard dependency
> on os-release, and (b) the file is present anyway.
For anything outside cpython, there is the distro module, and the distro modul
Matthias Klose added the comment:
> Where do you draw the line?
there's a module available outside cpython. Your use case is to add some work
around for some tests (like issue42142). If you need it for the tests, add it
to the test f
Matthias Klose added the comment:
> I just needed such functionality for PTY tests
another use case for a test. so please add it to the test framework, also
suggested by Marc.
--
___
Python tracker
<https://bugs.python.org/issu
101 - 200 of 827 matches
Mail list logo
