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
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
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:
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
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
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:
that looks fine. Maybe also set LANG=C ?
--
___
Python tracker
<https://bugs.python.org/issue23767>
___
___
Python-bugs-list m
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
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:
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:
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
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:
# 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/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:
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
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>
___
__
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:
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.
--
___
Python
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
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 framew
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 module
is
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:
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
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 stand
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/issue28
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
<https://bu
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
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:
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 the standar
Change by Matthias Klose :
--
nosy: +lukasz.langa
___
Python tracker
<https://bugs.python.org/issue41760>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Matthias Klose :
--
nosy: +ned.deily
___
Python tracker
<https://bugs.python.org/issue41760>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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
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:
> 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 soon they wil
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:
> 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/issu
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:
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: normal
Change by Matthias Klose :
--
nosy: +ivyl
___
Python tracker
<https://bugs.python.org/issue41206>
___
___
Python-bugs-list mailing list
Unsubscribe:
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, both 3.8
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',
'/usr/lib/python3/dist-packages']
--
resolution
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
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:
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:
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
preprocessor
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:
I'll get back on this
--
___
Python tracker
<https://bugs.python.org/issue36852>
___
___
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
directories
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:
what are the situations where the path for python and python-config is
different?
This proposal doesn't say anything how to retrieve the correct information for
cross builds using this module. From my point of view, python-config should
stay outside
Matthias Klose added the comment:
Luis, I'm still trying to figure out why you are seeing that. Please could you
report the package versions which are installed on the system?
dpkg -l python3.7 python3.8 python3-distutils
--
___
Python tracker
Matthias Klose added the comment:
this is issue #37561, making the sysconfigdata file name not changing with the
kernel version of the OS. I need to commit that patch to the trunk and 3.8.
But apparently pip needs to be aware of that as well
New submission from Matthias Klose :
so issue28046 decided to encode both MACHDEP and PLATFORM_TRIPLET/MULTIARCH in
the _sysconfigdata name. Unfortunately on KFreeBSD MACHDEP includes the kernel
version, so you end up with a changing MACHDEP. The _sysconfigdata name should
only encode
Matthias Klose added the comment:
so this might not be a sphinx 2.x issue, the docs build fine for the html
output, but the reported error is for building the texinfo files:
make -C Doc texinfo
That worked for 3.8 b1.
--
___
Python tracker
New submission from Matthias Klose :
3.8 b2 now requires sphinx2 (according to SilentGhost on IRC), but only has
documented 1.8. I'm aware of issue #36007, the last time that the requirements
were bumped.
So again, the dependencies were bumped without documenting, and why do we
require
Matthias Klose added the comment:
yes, that's for the minimal package.
zipfile is found in Lib/importlib/_bootstrap_external.py
Again, it's just a question here, having found an unmotivated distutils import
before in one of the standard modules.
--
resolution: -> not a
New submission from Matthias Klose :
compared to 3.8 alpha4, beta1's importlib has three new dependencies csv, email
and zipfile. Is this intended, or should the toplevel imports in
importlib.metadata be moved into the functions where these are once used?
--
components: Library (Lib
Matthias Klose added the comment:
"AFAICT, the purpose of python-config is to provide configuration info for
embedding Python"
If that's the intention, then at least it's not used as such. It's also used
to build/configure extensions using automake/cmake based build systems. The
Matthias Klose added the comment:
why is this an issue on Debian? Debian is already not linking with libpython.
--
nosy: +doko
___
Python tracker
<https://bugs.python.org/issue36
Change by Matthias Klose :
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
superseder: -> unaligned memory access in the _sha3 extension
___
Python tracker
<https://bugs.python
New submission from Matthias Klose :
This was seen when running an armhf binary on a 64bit kernel. The problem is
that the implementation uses unaligned memory accesses, and even is well aware
of that. The module allows misaligned memory accesses by default. The
NO_MISALIGNED_ACCESSES macro
New submission from Matthias Klose :
seen with 3.7,3, not 3.8 alpha3.
bus error in test_gil test on armhf with 64bit kernel, one more unaligned
access. not seen in debug builds.
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco
Matthias Klose added the comment:
no, please don't assume that if it builds for one cross build variant, that it
builds for all. re-opening.
--
resolution: fixed ->
status: closed -> open
___
Python tracker
<https://bugs.python.org/i
Matthias Klose added the comment:
setting to release-blocker for evaluation. the freebsd solution seems to be
wrong, just avoiding the error. Is the test correct, or do we have an issue
that TLSv1.3 isn't properly handled?
--
keywords: +3.7regression
nosy: +lukasz.langa, ned.deily
Matthias Klose added the comment:
seen in Ubuntu 19.04 as well. Started after the openssl update form 1.1.1 to
1.1.1b.
--
nosy: +doko
___
Python tracker
<https://bugs.python.org/issue35
Matthias Klose added the comment:
found it, Setup.dist was renamed to Setup.
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Matthias Klose added the comment:
Setup.local used:
# Edit this file for local setup changes
array arraymodule.c # array objects
cmath cmathmodule.c _math.c # -lm # complex math library functions
math mathmodule.c _math.c # -lm # math library functions, e.g. sin()
_struct _struct.c
New submission from Matthias Klose :
the build with building extension modules as builtins is broken in 3.8. I
assume that is some fallout from the header re-organization. It shows in the
link step by having undefined references. Undefined symbols are listed below.
Still looking where
Matthias Klose added the comment:
"if one uses the doc Makefile venv target". which is not possible for
distributions which are not allowed to use anything but the distro to build the
distro.
so why bumping the version requirement to 1.7 instead of 1.6.6? Afaicu this is
th
New submission from Matthias Klose :
python 3.7.2 rc1 bumped the build requirements apparently for no reason, now
requiring sphinx 1.7 instead of 1.6.x before. This is a major pain, if you
want to provide the build including the documentation on a stable release.
Pretty please can we avoid
New submission from Matthias Klose :
[3.6/3.7] idlelib/help.html mentions 3.8alpha0 docs:
Seen in the 3.6.8 and 3.7.2 release candidates
--
assignee: terry.reedy
components: IDLE
keywords: 3.6regression, 3.7regression
messages: 331671
nosy: doko, ned.deily, terry.reedy
priority
New submission from Matthias Klose :
seen at least on the 2.7, a new symbol polluting the symbol namespace.
the global symbol "freegrammar" should be made static ore renamed
--
components: Interpreter Core
messages: 330615
nosy: doko
priority: normal
severity: normal
status:
Matthias Klose added the comment:
Debian/Ubuntu doesn't link against the library because it would add
dependencies on all supported Python versions. Normally this is just during
transition times, but e.g. for the upcoming Ubuntu 18.10 release we didn't
finish the transition and so ship two
Matthias Klose added the comment:
well, it was top of the branch yesterday
--
___
Python tracker
<https://bugs.python.org/issue34806>
___
___
Python-bugs-list m
Matthias Klose added the comment:
issue34530 was already fixed on 20180904, so there's something else...
--
___
Python tracker
<https://bugs.python.org/issue34
Change by Matthias Klose :
--
nosy: +serhiy.storchaka, steve.dower
___
Python tracker
<https://bugs.python.org/issue34806>
___
___
Python-bugs-list mailin
New submission from Matthias Klose :
two distutils tests fail when running the tests from an installed location. 3.7
branch 20180925, succeeded with a 20180911 snapshot. Is there any locale
setting required?
==
ERROR
Matthias Klose added the comment:
+1
--
___
Python tracker
<https://bugs.python.org/issue26544>
___
___
Python-bugs-list mailing list
Unsubscribe:
Matthias Klose added the comment:
fine! what prevents merging and backporting this issue?
--
___
Python tracker
<https://bugs.python.org/issue26544>
___
___
Change by Matthias Klose :
Added file: https://bugs.python.org/file47755/platform-no-distutils.diff
___
Python tracker
<https://bugs.python.org/issue26544>
___
___
Pytho
Matthias Klose added the comment:
proposed patch attached
--
___
Python tracker
<https://bugs.python.org/issue26544>
___
___
Python-bugs-list mailing list
Unsub
Matthias Klose added the comment:
no, it's not fixed at all. Setting as a release blocker for 3.6 and 3.7.
--
keywords: +3.6regression, 3.7regression
nosy: +benjamin.peterson, ned.deily
priority: normal -> release blocker
___
Python tracker
<
Matthias Klose added the comment:
strange. I see it succeeding in the build location, not the install location.
Did you make sure to cd /tmp before running the test?
I still can reproduce it:
$ python3.7 -m test test_lib2to3
Run tests sequentially
0:00:00 load avg: 0.24 [1/1] test_lib2to3
New submission from Matthias Klose :
running the lib2to3 tests from an installed location, I see the following
failures on the 3.7 branch:
==
FAIL: test (lib2to3.tests.test_fixers.Test_reload
Matthias Klose added the comment:
ok, not working on that currently
--
resolution: -> rejected
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Matthias Klose added the comment:
this is the python3.7 build for Debian, so yes, installed via a package manager
;)
see
https://ci.debian.net/data/packages/unstable/amd64/p/python3.7/
for the test results.
and yes, that seems to be a regression compared to the 3.7.0 release
Matthias Klose added the comment:
seen on Linux x86_64, using Tcl 8.6.8, running the tests in the installed
location.
--
___
Python tracker
<https://bugs.python.org/issue34
New submission from Matthias Klose :
test_tcl fails at least on the 3.7 branch with:
==
FAIL: test_join (test.test_tcl.TclTest)
--
Traceback (most recent call
New submission from Matthias Klose :
Lib/trace.cover is not removed by the clean target, and apparently this file is
always created in the source tree, not in the build tree. It should be created
in the build tree, if that's not possible, it should be cleaned in any case
Matthias Klose added the comment:
a tuple comparison should be good enough
--
___
Python tracker
<https://bugs.python.org/issue26544>
___
___
Python-bugs-list m
Matthias Klose added the comment:
please don't close this yet. the patch introduces a dependency on the
distutils package. I don't see any reason to compare the libc version as a
python egg version, so please avoid that.
if we need to have a module to compare arbitrary version strings
New submission from Matthias Klose :
Seen with the 3.6 branch and the 3.7 branch at least. This file is installed by
default, so should be valid syntax? If it's supposed to be that way, maybe
call the template like template.py.in?
Unpacking libpython3.6-testsuite (3.6.6~rc1-3
New submission from Matthias Klose <d...@debian.org>:
==
ERROR: test_from_import_missing_attr_has_name_and_so_path
(test.test_import.ImportTests)
--
Tra
Matthias Klose <d...@debian.org> added the comment:
this seems to be fixed in 3.6 (3.6.5) and 3.7 (beta4).
--
resolution: -> fixed
stage: needs patch -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.
Matthias Klose <d...@debian.org> added the comment:
there is https://pypi.org/project/distro/
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Matthias Klose <d...@debian.org> added the comment:
New changeset 9da7ee40037fa30d0d28fd8d7c652cde14e5a834 by Matthias Klose (Miss
Islington (bot)) in branch '3.7':
bpo-33393: Update config.guess and config.sub files (GH-6658) (#6661)
https://github.com/python/cpython/
Matthias Klose <d...@debian.org> added the comment:
New changeset 7e3545c70cdecd86ffa8fcbffd79b4f78560679f by Matthias Klose in
branch 'master':
bpo-33393: Update config.guess and config.sub files (#6658)
https://github.com/python/cpython/commit/7e3545c70cdecd86ffa8fcbffd79b4f785
Change by Matthias Klose <d...@debian.org>:
--
pull_requests: +6355
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
New submission from Matthias Klose <d...@debian.org>:
the build of the shared modules is quiet/non-visible when GNU make gets passed
macros. This is was introduced by the change to support BSD make.
GNU make adds all make macros passed on the command line to MAKEFLAGS. If one
of these
1 - 100 of 819 matches
Mail list logo
