Bernhard M. Wiedemann added the comment:
ping.
Another 19th of January passed.
I'd still like to see progress on this, because this hinders my other y2038 bug
discovery work.
--
versions: +Python 3.5, Python 3.8, Python 3.9
___
Python tracker
Change by Bernhard M. Wiedemann :
--
keywords: +patch
pull_requests: +12308
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issu
New submission from Bernhard M. Wiedemann :
While working on reproducible builds for openSUSE, I found countless python
modules that come with binary .so files that did not build reproducibly from
non-deterministic filesystem readdir order.
One contributing factor is bpo-30461
Bernhard M. Wiedemann added the comment:
unreproducible .pyc files are still one of the major headaches for my work on
openSUSE reproducible builds.
There is also one aspect where i586 builds end up with different .pyc files
than x86_64 builds. And then we randomly chose one of them for our
Bernhard M. Wiedemann added the comment:
It does not need to be fixed tomorrow, but 2037 is too late, because by then
there will be a lot of legacy systems around.
(Un)fortunately many systems live 10+ years now
--
___
Python tracker
<ht
New submission from Bernhard M. Wiedemann :
To reproduce:
touch -d 2038-01-20 /usr/lib/python3.6/site-packages/six.py
python3 /usr/lib64/python3.6/compileall.py
File "/usr/lib64/python3.6/compileall.py", line 198, in compile_path
legacy=legacy, optimize=optimize)
File &
Bernhard M. Wiedemann added the comment:
also related to this topic: https://github.com/pypa/pip/pull/5525 for pip's
RECORD file.
--
___
Python tracker
<https://bugs.python.org/issue29
Bernhard M. Wiedemann <pythonb...@lsmod.de> added the comment:
Serhiy, can you test https://github.com/python/cpython/pull/5557
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Change by Bernhard M. Wiedemann <pythonb...@lsmod.de>:
--
keywords: +patch
pull_requests: +5379
stage: needs patch -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Bernhard M. Wiedemann <pythonb...@lsmod.de> added the comment:
@Serhiy IMHO, just because we fix one problem, we do not have to fix all other
problems at the same time. You can still open a pull-request for the others,
but I know too little about those to test them.
And having commits p
Bernhard M. Wiedemann <pythonb...@lsmod.de> added the comment:
Any chance we can get the (somewhat related) patch for
https://bugs.python.org/issue30693 also merged?
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Change by Bernhard M. Wiedemann <pythonb...@lsmod.de>:
--
keywords: +patch
pull_requests: +5054
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Bernhard M. Wiedemann <pythonb...@lsmod.de> added the comment:
I think, there is no single nice and clean solution with time-based .pyc files,
but to get a whole distribution to build reproducibly, there are two other ways:
1) if the SOURCE_DATE_EPOCH environment variable is set,
mak
Bernhard M. Wiedemann added the comment:
note: recent GNU tar versions (1.28?) added an option --sort=name
and the overhead of sorting (e.g. I measured 4ms for 1 files) is negligible
compared to the other processing done on the files here
Changes by Bernhard M. Wiedemann <pythonb...@lsmod.de>:
--
pull_requests: +2313
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
New submission from Bernhard M. Wiedemann:
Filesystems do not give any guarantees about ordering of files returned in
directory listings, thus tarfile.add adds files in random order, when using
os.listdir in recursion.
See also https://reproducible-builds.org/docs/stable-inputs/ on that topic
Bernhard M. Wiedemann added the comment:
>From my performance measurements, the overhead was negligible (not even
>counting the processing done on files returned by glob).
And also glob in C, bash, perl all do sort by default and these are generally
pretty fast languages, yet they still
Changes by Bernhard M. Wiedemann <pythonb...@lsmod.de>:
--
pull_requests: +1877
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
New submission from Bernhard M. Wiedemann:
because POSIX readdir does not guarantee any order
glob often gives unexpectedly random results.
Some background:
for openSUSE Linux we build packages in the Open Build Service (OBS)
which tracks dependencies, so when e.g. a new glibc is submitted,
all
Bernhard M. Wiedemann added the comment:
Tracking this in https://bugzilla.opensuse.org/show_bug.cgi?id=1038906
now.
It turned out to be a problem with (our?) openssl-1.0.2
which Debian stable does not have yet
and Debian/9 (stretch) has openssl-1.1.0 without this problem
The nicest python
Bernhard M. Wiedemann added the comment:
getting to a similar size on Debian, so I'll move this into the openSUSE
bugtracker to find out why it is so slow there.
--
resolution: -> third party
stage: -> resolved
status: open -> closed
_
Bernhard M. Wiedemann added the comment:
This might work in some places, but if you look at real-world users like
urllib3/util/ssl_.py
> from hashlib import md5, sha1, sha256
or
twisted/words/protocols/jabber/xmlstream.py
> from hashlib import sha1
It would probably not need any openssl
Bernhard M. Wiedemann added the comment:
I'm running openSUSE Tumbleweed with python-2.7.13 and python3-3.6.1
on an Intel Pentium N3530 with linux-4.10.12
There the total time of the "import _hashlib" oneliner varies between 100 and
250 ms (python3 is a bit slower and the machine is s
Bernhard M. Wiedemann added the comment:
traced it down a bit further.
nearly all that time is spent in
import _hashlib
which probably means, it is spent in functions like PyInit__hashlib in
Modules/_hashopenssl.c
I can see in strace that after loading libssl, libcrypto and libz,
it calls
New submission from Bernhard M. Wiedemann:
Steps to Reproduce:
echo import hashlib > test.py
time python -m cProfile -s tottime test.py 2>&1 | head
Actual Results:
shows 27ms spent in hashlib.py
The problem goes away when dropping everything after line 133
in hashlib.py
see also i
Bernhard M. Wiedemann added the comment:
backports are optional.
It can help reduce duplicated work for the various distributions.
Currently, I think master and 2.7 are the most relevant targets.
--
versions: +Python 3.7
___
Python tracker <
New submission from Bernhard M. Wiedemann:
See https://reproducible-builds.org/ and
https://reproducible-builds.org/docs/buy-in/ for why this is a good thing to
have in general.
Fedora, openSUSE and possibly other Linux distributions package .pyc files as
part of their binary rpm packages
Bernhard M. Wiedemann added the comment:
should probably be
lines = [x[n*64:(n+1)*64] for n in range(((len(x)-1)//64)+1)]
to avoid an empty line added when the last line is full
which once again shows why people prefer to use standard libraries
for this kind of work
New submission from Bernhard M. Wiedemann:
Many python scripts use textwrap to break base64-encoded strings from openssl
into lines - e.g. https://bugs.launchpad.net/python-keystoneclient/+bug/1404402
and https://github.com/diafygi/acme-tiny/blob/master/acme_tiny.py#L166
Steps To Reproduce
29 matches
Mail list logo
