New submission from Michał Górny mgo...@gentoo.org:
I was reported an issue where the user was unable to install my package [1]
using python3.1. I was able to guess the issue comes from locale being set to
POSIX and reproduce it.
It seems that the reasons are utf8-encoded characters
Changes by Michał Górny mgo...@gentoo.org:
--
nosy: +mgorny
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9561
___
___
Python-bugs-list mailing
Changes by Michał Górny mgo...@gentoo.org:
--
nosy: +mgorny
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10419
___
___
Python-bugs-list mailing
New submission from Michał Górny:
The distutils.command.config module reads:
def _gen_temp_sourcefile(self, body, headers, lang):
filename = _configtest + LANG_EXT[lang]
which means that every time one of the functions is used, a temporary file with
the same name will be created
Michał Górny added the comment:
While using. We run parallel merges with out-of-source builds in Gentoo, and I
found this to result in a failure when building the 'egenix-mx-base' package
[1] which uses the 'config' command.
[1]:http://pypi.python.org/pypi/egenix-mx-base
Michał Górny mgo...@gentoo.org added the comment:
Now that installing scripts with unicode characters was fixed, shall I open a
separate bug for writing egg files with utf8 chars in author name?
--
___
Python tracker rep...@bugs.python.org
http
Changes by Michał Górny mgo...@gentoo.org:
--
nosy: +mgorny
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12087
___
___
Python-bugs-list mailing
Michał Górny mgo...@gentoo.org added the comment:
Ping. What's the progress on this? Will this ever be fixed?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9561
Michał Górny added the comment:
Oh, sorry. I've looked throughout the code again and it seems that distutils is
doing the right thing. It's setuptools/distribute that is broken.
--
resolution: - invalid
status: open - closed
___
Python tracker rep
New submission from Michał Górny:
We're doing heavy wrapping of Python scripts on Gentoo in order to efficiently
support having multiple versions of Python installed. For that reason, every
Python script installed using the package manager is renamed, and a symlink to
a common wrapper binary
Changes by Michał Górny mgo...@gentoo.org:
--
type: - behavior
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18201
___
___
Python-bugs-list
Michał Górny added the comment:
Well, I don't see much relevance between the two bugs, to be honest :). I think
this bug is more of a symptom of a deeper issue with the way distutils is
installing files.
But the issue is causing repeating issues for our users, and I don't really
know what
Michał Górny added the comment:
In CPython, the _ssl module is compiled in C. How can we check if libssl
provides RAND_egd() or not at compile time?
How about... checking whether the function is provided? Unless I'm missing some
major point, AC_CHECK_FUNC should be good enough
New submission from Michał Górny:
Since 3.5, optimized Python modules for -O and -OO are installed using
different names. The Python build system itself seems to been prepared for this
as Python itself is built with both .opt-1.pyc and .opt-2.pyc files built.
However, distutils at the moment
Changes by Michał Górny <mgo...@gentoo.org>:
--
keywords: +patch
Added file:
http://bugs.python.org/file43231/0001-distutils-make-OO-enable-both-opt-1-and-opt-2-optimi.patch
___
Python tracker <rep...@bugs.python.org>
<http://
Michał Górny added the comment:
Brett, .pyc was controlled by --compile and .pyo by --optimize (either 1 or 2).
Technically only two variants could be used simultaneously, and distutils
accounted for that.
Now you have .pyc + .opt-1.pyc + .opt-2.pyc, so three variants instead of two
Michał Górny added the comment:
Yes, you could put it like this.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27226>
___
___
Michał Górny added the comment:
Christian, since the code is now integrated in Python 3.6+ (with some bugfixes
AFAICS), could you consider updating your bitbucket package to match it? It
would be helpful as a backport package for older Python versions.
--
nosy: +mgorny
Changes by Michał Górny <mgo...@gentoo.org>:
--
keywords: +patch
pull_requests: +3754
stage: needs patch -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Michał Górny added the comment:
I've submitted a pull request with another fix. I've tried to keep the changes
at minimal but I couldn't stand keeping meaningless 'echo $x | sed -e s/$x/$y/'
;-).
I have to point out that the attached patch is wrong since it does readlink on
CFLAGS
Changes by Michał Górny <mgo...@gentoo.org>:
--
nosy: +mgorny
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue22140>
___
__
Change by Michał Górny <mgo...@gentoo.org>:
--
keywords: +patch
pull_requests: +4036
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
New submission from Michał Górny <mgo...@gentoo.org>:
The setup.py file for Python states:
if (not cross_compiling and
os.uname().machine == "x86_64" and
sys.maxsize > 2**32):
# Every x86_64 machine has at least SSE2. Ch
New submission from Michał Górny <mgo...@gentoo.org>:
While debugging PyPy test failure on backports.lzma [1], I've noticed that
PySequence_Check() on a dict type raises TypeError, e.g.:
Traceback (most recent call last):
File "test/test_lzma.py", line 273, in test_
Michał Górny <mgo...@gentoo.org> added the comment:
So is the documentation mistaken or just confusing? It says straight:
> For objects that do not provide sequence protocol, this is equivalent to the
> Python expression len(o).
So it the 'do not' mistaken or does it
Michał Górny <mgo...@gentoo.org> added the comment:
Well, my two main concerns are:
1) whether it is acceptable for PyPy to not raise TypeError in this case, or if
I should report it to PyPy upstream as a bug,
2) and whether programmers can appropriately rely on PySequence_Length()
r
Change by Michał Górny :
--
keywords: +patch
pull_requests: +8198
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue34366>
___
___
Py
New submission from Michał Górny :
The _uuid extension fails to build on my Gentoo/FreeBSD system:
building '_uuid' extension
x86_64-gentoo-freebsd11.1-gcc -pthread -fPIC -Wno-unused-result -Wsign-compare
-DNDEBUG -O2 -pipe -march=native -fwrapv -std=c99 -Wextra -Wno-unused-result
-Wno-unused
Michał Górny <mgo...@gentoo.org> added the comment:
Well, according to the reporters disabling GC doesn't help at all. Maybe it's
another issue.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Michał Górny <mgo...@gentoo.org> added the comment:
Could you get this fixed in earlier versions of CPython? Given that 3.7 is not
yet released, having this broken in 3.5 and 3.6 is highly undesirable. This
apparently seems to affect our tooling [1] and telling our users to use 3.7
New submission from Michał Górny :
Currently, the tarfile module only supports adding files if their size is known
prior to adding. However, I think it'd be helpful to be able to store large
dynamically generated streams straight into the (uncompressed) .tar file
without being able
New submission from Michał Górny :
xz-utils has four options to configure codecs supported by liblzma:
--enable-encoders
--enable-decoders
--enable-match-finders
--enable-checks
In Gentoo, we're using those options to optionally provide smaller footprint
liblzma builds that include
Michał Górny added the comment:
> Adding this API would require to provide a way to set file status like mode,
> uid, gid, mtime, type, linkname, uname and gname.
That's why I mentioned addfile() -- it takes TarInfo object for that purpose.
I suppose the new function should have th
Michał Górny added the comment:
Thanks a lot! I've left a few comments based on eyeball review. I'm going to
test it later today.
--
___
Python tracker
<https://bugs.python.org/issue35
Michał Górny added the comment:
This is not really an upstream issue, it is due to Gentoo-specific patching.
--
nosy: +mgorny
___
Python tracker
<https://bugs.python.org/issue36
Change by Michał Górny :
--
nosy: +mgorny
___
Python tracker
<https://bugs.python.org/issue39503>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Michał Górny :
--
nosy: +mgorny
___
Python tracker
<https://bugs.python.org/issue38826>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Michał Górny :
PEP 518 uses the TOML format to specify build system requirements. AFAIU this
means that all new build systems will require a TOML parser. Could you
consider adding one to the standard library to reduce the number of chicken-egg
problems?
The referenced
Michał Górny added the comment:
Does this mean that platforms using /usr/lib64 for shared libraries are now
forced to install Python into /usr/lib64/python*?
--
nosy: +mgorny
___
Python tracker
<https://bugs.python.org/issue1294
Michał Górny added the comment:
> Not at all. This means that it is possible to do so. It remains optional.
...but then sys.platlibdir is going to incorrectly list 'lib', isn't it?
According to https://docs.python.org/3.9/library/sys.html#sys.platlibdir it's
used 'to build the p
Michał Górny added the comment:
> Can you please propose a different wording? English is not my first language.
Mine neither but I'll try. How about:
'Name of the platform-specific library directory. It is used to build the path
of the standard library and C extension modu
Michał Górny added the comment:
Can we clarify the wording to clearly indicate it's to be used only for Python
modules/extensions and not system dynamic libs?
--
___
Python tracker
<https://bugs.python.org/issue1294
Michał Górny added the comment:
Ok, it seems that I misunderstood it at first. Judging by the code, it also
affects extensions installed into site-packages, so I've tried to make that
clear and add one more example to the bullet list
Change by Michał Górny :
--
pull_requests: +19600
pull_request: https://github.com/python/cpython/pull/20332
___
Python tracker
<https://bugs.python.org/issue1294
New submission from Michał Górny :
Currently, the bz2 extension functions raise a generic OSError() on
BZ_DATA_ERROR and BZ_DATA_ERROR_MAGIC. When working on files, this makes it
unnecessarily hard to catch compressor errors (i.e. invalid bz2 input file)
without catching system I/O errors
Michał Górny added the comment:
> An OSError for a file the OS can read seems a bit off. What is the
> accompanying message?
For example:
OSError: Invalid data stream
(I've just put random string into a file, and opened it as bzip2)
> Would something like ValueError("
Michał Górny added the comment:
I'm sorry but does this change mean that it's not final or...?
My main concern is whether we should be adjusting our packages to the new
behavior in py3.9, or wait for further changes.
--
___
Python tracker
<ht
Michał Górny added the comment:
Thank you!
--
___
Python tracker
<https://bugs.python.org/issue1294959>
___
___
Python-bugs-list mailing list
Unsubscribe:
Michał Górny added the comment:
Do I understand correctly that the new behavior is intentional in 3.9, or is
that still being discussed?
--
nosy: +mgorny
___
Python tracker
<https://bugs.python.org/issue27
Michał Górny added the comment:
I can reproduce test_socket hanging in 2 out of 3 runs. However, in my case
testPeek doesn't seem to be the (only) culprit. Disabling whole RDSTest helps.
--
nosy: +mgorny
___
Python tracker
<ht
Michał Górny added the comment:
I wonder if it would be feasible to support new behavior in earlier versions of
Python via __future__. I suppose that could help software avoid having Python
version-dependent behavior in the long run
Michał Górny added the comment:
Given that a CVE was assigned for this, I think it'd be better if the news were
in the 'Security' category and not 'Library'.
--
nosy: +mgorny
___
Python tracker
<https://bugs.python.org/issue39
Michał Górny added the comment:
Any reason this wasn't backported to 3.6? FWICS it's supposed to be security
supported still.
--
nosy: +mgorny
___
Python tracker
<https://bugs.python.org/issue40
Michał Górny added the comment:
Thank you for debugging this. I can confirm that this patch resolves my issue.
--
___
Python tracker
<https://bugs.python.org/issue42
New submission from Michał Górny :
I'm still investigating the problem and I will include more information
shortly. However, I'm filing the bug early, as I'd like to prevent this
regression from hitting 3.8.7 release.
When running backports-zoneinfo-0.2.1 test suite using cpython 3.8.7rc1
Michał Górny added the comment:
aeb66c1abbf4ec214e2e80eb972546996d1a1571 is the first bad commit
commit aeb66c1abbf4ec214e2e80eb972546996d1a1571
Author: Miss Skeleton (bot) <31488909+miss-isling...@users.noreply.github.com>
Date: Thu Oct 15 08:51:48 2020 -0700
bpo-41984: GC tra
Michał Górny added the comment:
A more complete backtrace:
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49
#1 0x7fa633b20536 in __GI_abort () at abort.c:79
#2 0x7fa633b79bf7 in __libc_message (action=action@entry=do_abort,
fmt=fmt@entry=0x7fa633c8c3b5 "
Michał Górny added the comment:
The test added for this bug is insufficient to verify the fix. If I revert the
Lib/http/client.py change, the test still passes. This is because a subclass
of client.HTTPException is still raised.
If I add an explicit begin() call to trigger the exception
Michał Górny added the comment:
> If it takes years for users to get to 3.10, we should reevaluate our
> release cycle, not whether we aggressively break maintenance releases.
I don't really understand how that would help. The problem is that users have
major inertia for switching to
Michał Górny added the comment:
In my opinion, raising an exception would have been safer.
Botocore and django do precisely what you say — provide a validator. To make
this validator easier, they do the validation on splitted up URL parts.
I disagree with the premise that they were stupid
Michał Górny added the comment:
I hate to be the bearer of bad news but I've already found this change to be
breaking tests of botocore and django. In both cases, the test failure is
apparently because upstream used to reject URLs after finding newlines in the
split components, and now
Michał Górny added the comment:
I'm not convinced we need something that complex here but I think it would make
sense to make 'unittest discover' fail when it doesn't discover a single test.
As packagers, we've been bitten more than once by packages whose tests suddenly
stopped being
Change by Michał Górny :
--
keywords: +patch
pull_requests: +23655
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/24893
___
Python tracker
<https://bugs.python.org/issu
Change by Michał Górny :
--
versions: +Python 3.10 -Python 3.4
___
Python tracker
<https://bugs.python.org/issue18232>
___
___
Python-bugs-list mailing list
Unsub
New submission from Michał Górny :
There is a race condition in distutils' build_ext implementation. When the
same source file is used to build multiple extensions, distutils attempts to
build it multiple times using the same output file, in parallel. This means
that the link editor can
New submission from Michał Górny :
So I've finally found time to bisect this.
Long story short, test_ctypes started hanging on Gentoo package builds since
3.10.0a2. Previously, the test took less than a second. Now, it just keeps
running for minutes until I kill it.
The weird thing
Michał Górny added the comment:
Nevermind, I've been testing wrong and this is most likely our fault. I'm
sorry about the noise. I am going to investigate further and reopen if it
turns out the problem's on CPython end.
--
stage: -> resolved
status: open ->
Michał Górny added the comment:
It seems that the spec has reached 1.0.0:
> 1.0.0 / 2021-01-11
I guess that there are still ~2 months left to do this before 3.10 reaches beta.
--
___
Python tracker
<https://bugs.python.org/issu
Michał Górny added the comment:
Is there any progress happening? FWIU the common "toml" module on pypi has
been discontinued now, projects are switching to yet another one and this is
exactly the kind of problem a built-in module would ha
Michał Górny added the comment:
Jack, are you still working on this? I was considering allocating the time to
write the bindings for the C library myself but I've stumbled upon this bug and
I suppose there's no point in duplicating work. I'd love to see it on pypi, so
we could play
Michał Górny added the comment:
I've already asked that, and the author said it's fine but with the deprecated
text file support removed:
https://github.com/hukkin/tomli/issues/141#issuecomment-968056905
That said, for consistency with json and so on we'd probably want to combine
tomli
Michał Górny added the comment:
I would still find it helpful to have a "proper" "blake3-c" package on normal
pypi, for those of us who can't rely on Rust being present immediately.
--
___
Python tracker
<https://bug
Michał Górny added the comment:
After updating PyPy3 to use Python 3.9's stdlib, we hit very bad hangs because
of this — literally compiling a single file with "parallel" compileall could
hang. In the end, we had to revert the change in how Python 3.9 starts workers
because
Michał Górny added the comment:
BTW there are test regressions with expat 2.4.5, apparently due to some test
snippets now being rejected as invalid XML:
==
ERROR: test_issue3151 (test.test_xml_etree.BugsTest
Michał Górny added the comment:
Could you make a PR to fix the test failures? I suppose that could speed
things up and if not, I'd at least have something to pull into Gentoo.
--
___
Python tracker
<https://bugs.python.org/issue46
75 matches
Mail list logo
