[issue43158] uuid won't build when libuuid is installed in a non-standard place
Alexandru Ardelean added the comment: I confirm that this works on OpenWrt :) I actually started testing shortly after the PR was created. Many thanks for the quick patch. -- ___ Python tracker <https://bugs.python.org/issue43158> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43158] uuid won't build when libuuid is installed in a non-standard place
Alexandru Ardelean added the comment: I've added Christian Heimes to this, mostly to help us get this further. (i.e. to refer someone else here, that can help). So, there is a fix for this in Buildroot's tree: https://github.com/buildroot/buildroot/blob/76c7fed85f7a822663cf0c8828e7d282198d0803/package/python3/0030-Fix-cross-compiling-the-uuid-module.patch I am porting this patch to OpenWrt. And it seems to work as well. I'd like to know how to proceed with this patch and submit it upstream. I did not author this patch, so it may be tricky. We may need to contact the original author? Or would it be fine for me to open a PR and mention the original source/author? -- nosy: +Alexandru Ardelean, christian.heimes ___ Python tracker <https://bugs.python.org/issue43158> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45627] OpenSSL 1.1.1 still implements some disable-flags for Blake2, Scrypt
Alexandru Ardelean added the comment: > Thanks for you detailed explanation. I kinda agree that it makes sense for > small, embedded systems like OpenWRT to reduce the size of binaries. After > all storage and memory are precious on these systems. So, OpenWrt is not as tiny as it used to be. A large part is due to the Linux kernel increasing in default size. But other libs do a small increase as well (with each new revision). I think a new micro-OpenWrt (or similar project) would be required in some future to support the devices with less than 4 MB of flash and less than 32 MB of RAM. OpenWrt last supported the 4/32 combination in 2018 (with the 18.06 release). (But that's another topic I for when I retire maybe :p ) I think where users still install Python is where they have at least 64/128 MB of persistent storage/flash memory. I am still surprised about the desire of users to install Python on such devices (even after doing this for ~7 years of [co-]maintaining it it on OpenWrt). The Turris devices/routers (are one example that) use a lot of CPython for some userspace stuff. > PEP 644 favors usability over flexibility. 3rd party library developers can > now rely on the presence of hashlib features. Before 3.10 they could not be > sure that a Python build had certain features. Ack. > A downstream patch in OpenWRT makes sense. I've started down that path. But guess what... I hit LibreSSL (on the host build) :P Now I have a bigger job (than I thought) to update to 3.10 But that's fine. These events are rare, and I do enjoy to fix them (when I can). > By the way, you might be interested in --with-builtin-hashlib-hashes > configure flag. It lets you disable builtin modules like _md5 and _sha3. The > shared libraries are large. If you disable the builtin blake2 module, then > certain features like MAC and tree hashing are not working. I would not add too many flags in the Python build (on our side). For now we have some ways to "modularize" a Python installation. It's basically a hack-job of splitting Core-Python libraries into separate packages. That's when someone really wants to do a minimal installation of Python, and add only 2-3 libraries on top. Essentially, we build Python with all defaults possible, then some libs (.so & .py files) get packaged together (like ssl.py and _ssl.so from python). The more immediate benefits (in this example) are that you can avoid installing OpenSSL libs on your device, but have some Python. I know... crazy stuff, but people seem to do it. I do admit some Python fans and developers would cringe at this but ¯\_(ツ)_/¯ -- ___ Python tracker <https://bugs.python.org/issue45627> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45627] OpenSSL 1.1.1 still implements some disable-flags for Blake2, Scrypt
Alexandru Ardelean added the comment: So, I've read through: https://www.python.org/dev/peps/pep-0644/#compatibility I also stumbled over: https://lwn.net/Articles/841664/ Which also led to: https://www.python.org/dev/peps/pep-0644/#libressl-support The answer is loud and clear now: will keep this downstream. Thank you and apologies for the noise. -- resolution: -> wont fix stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue45627> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45627] OpenSSL 1.1.1 still implements some disable-flags for Blake2, Scrypt
Alexandru Ardelean added the comment: Apologies for the slow reply. It was the end of work-day when I submitted the bug & patch. I know, not a good method, but I do what I can :) So, OpenWrt's OpenSSL does not build BLAKE2 by default. See: https://github.com/openwrt/openwrt/blob/master/package/libs/openssl/Makefile#L190 Scrypt is on by default. In the sense that there is no disable flag. I only care about BLAKE2, but I was trying not to half-ass the implementation, given that Scrypt is also disable-able. Now there are 2 options that I feel could be reasonable (anyone is free to disagree with me here): 1. this is patch upstream as I'm trying here 2. keep this patch downstream (i.e. just in our tree for OpenWrt's Python) until OpenSSL (or OpenWrt) enables BLAKE2 by default There are several options that feel a bit more difficult (to me): 3. Enable OpenSSL BLAKE2 on by default in OpenWrt core; this may also work, but requires some discussion with the OpenWrt core-team that handles OpenSSL; though usually OpenWrt tries to be minimal, so I'm feeling there would be some resistance 4. Not build hashlib (in Python) if BLAKE2 is not enabled in OpenSSL ; this is doable, but maybe a bit too complicated (for what is worth); it can cause support issues (in OpenWrt) like "hey, where did hashlib go?" I may have missed a few possible options. But these are the more obvious ones. Moving forward, I am fine with either of the first 2 options. I am feeling that option 2 is closer to what is desired by upstream Python (which I am fine to do). Thank you :) Alex -- ___ Python tracker <https://bugs.python.org/issue45627> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45627] OpenSSL 1.1.1 still implements some disable-flags for Blake2, Scrypt
Change by Alexandru Ardelean : -- keywords: +patch pull_requests: +27500 stage: -> patch review pull_request: https://github.com/python/cpython/pull/29237 ___ Python tracker <https://bugs.python.org/issue45627> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45627] OpenSSL 1.1.1 still implements some disable-flags for Blake2, Scrypt
Alexandru Ardelean added the comment: Note: PKCS5_v2_scrypt_keyivgen() will not cause an error, but EVP_PBE_scrypt() will -- ___ Python tracker <https://bugs.python.org/issue45627> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45627] OpenSSL 1.1.1 still implements some disable-flags for Blake2, Scrypt
New submission from Alexandru Ardelean : This follows update https://bugs.python.org/issue43669 Which is present in Python 3.10 Some OpenSSL 1.1.1 can be built without Blake2 support or Scrypt. SHA3 and SHAKE do not seem to have any enable/disable flags. This results in compiler errors where EVP_blake2b512, EVP_blake2s256, EVP_PBE_scrypt and PKCS5_v2_scrypt_keyivgen can be un-defined. This is unfortunate behavior on the part of OpenSSL 1.1.1. So, for BLAKE2 and SCRYPT, we should still check that the OPENSSL_NO_SCRYPT and OPENSSL_NO_BLAKE2 defines are not-define. -- assignee: christian.heimes components: Build, Extension Modules, SSL messages: 405093 nosy: Alexandru Ardelean, christian.heimes priority: normal severity: normal status: open title: OpenSSL 1.1.1 still implements some disable-flags for Blake2, Scrypt versions: Python 3.10, Python 3.11 ___ Python tracker <https://bugs.python.org/issue45627> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38684] hashlib: build fails when blake2 is disabled in OpenSSL
Change by Alexandru Ardelean : -- keywords: +patch pull_requests: +16556 stage: -> patch review pull_request: https://github.com/python/cpython/pull/17043 ___ Python tracker <https://bugs.python.org/issue38684> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38684] hashlib: build fails when blake2 is disabled in OpenSSL
New submission from Alexandru Ardelean :
This was caught via OpenWrt's build, when upgrading to 3.8.
By default, Blake2 is not enabled in OpenWrt's OpenSSL.
Not sure if this is an issue in OpenSSL or Python or both.
After digging through the _hashopenssl.c, it seems that the check for Blake2
being enabled/present in OpenSSL is not consistent with how OpenSSL does it.
The build error is:
86_64-openwrt-linux-musl-gcc -shared
-L/home/sandu/work/openwrt/openwrt/staging_dir/target-x86_64_musl/usr/lib
-L/home/sandu/work/openwrt/openwrt/staging_dir/target-x86_64_musl/lib
-L/home/sandu/work/openwrt/openwrt/staging_dir/toolchain-x86_64_gcc-8.3.0_musl/usr/lib
-L/home/sandu/work/openwrt/openwrt/staging_dir/toolchain-x86_64_gcc-8.3.0_musl/lib
-znow -zrelro
-L/home/sandu/work/openwrt/openwrt/build_dir/target-x86_64_musl/Python-3.8.0
-L/home/sandu/work/openwrt/openwrt/staging_dir/target-x86_64_musl/usr/lib
-L/home/sandu/work/openwrt/openwrt/staging_dir/target-x86_64_musl/lib
-L/home/sandu/work/openwrt/openwrt/staging_dir/toolchain-x86_64_gcc-8.3.0_musl/usr/lib
-L/home/sandu/work/openwrt/openwrt/staging_dir/toolchain-x86_64_gcc-8.3.0_musl/lib
-znow -zrelro
-L/home/sandu/work/openwrt/openwrt/build_dir/target-x86_64_musl/Python-3.8.0
-L/home/sandu/work/openwrt/openwrt/staging_dir/target-x86_64_musl/usr/lib
-L/home/sandu/work/openwrt/openwrt/staging_dir/target-x86_64_musl/lib -L/home
/sandu/work/openwrt/openwrt/staging_dir/toolchain-x86_64_gcc-8.3.0_musl/usr/lib
-L/home/sandu/work/openwrt/openwrt/staging_dir/toolchain-x86_64_gcc-8.3.0_musl/lib
-znow -zrelro
-L/home/sandu/work/openwrt/openwrt/build_dir/target-x86_64_musl/Python-3.8.0
-Os -pipe -fno-caller-saves -fno-plt -fhonour-copts
-Wno-error=unused-but-set-variable -Wno-error=unused-result
-ffile-prefix-map=/home/sandu/work/openwrt/openwrt/build_dir/target-x86_64_musl/Python-3.8.0=Python-3.8.0
-Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1
-Wl,-z,now -Wl,-z,relro -DNDEBUG -fno-inline
-I/home/sandu/work/openwrt/openwrt/staging_dir/target-x86_64_musl/usr/include
-I/home/sandu/work/openwrt/openwrt/staging_dir/toolchain-x86_64_gcc-8.3.0_musl/usr/include
-I/home/sandu/work/openwrt/openwrt/staging_dir/toolchain-x86_64_gcc-8.3.0_musl/include/fortify
-I/home/sandu/work/openwrt/openwrt/staging_dir/toolchain-x86_64_gcc-8.3.0_musl/include
build/temp.linux2-3.8/home/sandu/work/openwrt/openwrt/buil
d_dir/target-x86_64_musl/Python-3.8.0/Modules/_curses
_panel.o -L.
-L/home/sandu/work/openwrt/openwrt/staging_dir/target-x86_64_musl/usr/lib
-L/home/sandu/work/openwrt/openwrt/staging_dir/target-x86_64_musl/lib
-L/home/sandu/work/openwrt/openwrt/staging_dir/toolchain-x86_64_gcc-8.3.0_musl/usr/lib
-L/home/sandu/work/openwrt/openwrt/staging_dir/toolchain-x86_64_gcc-8.3.0_musl/lib
-L/home/sandu/work/openwrt/openwrt/build_dir/target-x86_64_musl/Python-3.8.0
-L/home/sandu/work/openwrt/openwrt/staging_dir/toolchain-x86_64_gcc-8.3.0_musl/x86_64-openwrt-linux-musl/lib
-lpanelw -lncursesw -o build/lib.linux2-3.8/_curses_panel.cpython-38.so
/home/sandu/work/openwrt/openwrt/build_dir/target-x86_64_musl/Python-3.8.0/Modules/_hashopenssl.c:
In function 'py_digest_by_name':
/home/sandu/work/openwrt/openwrt/build_dir/target-x86_64_musl/Python-3.8.0/Modules/_hashopenssl.c:220:22:
error: implicit declaration of function 'EVP_blake2s256'; did you mean
'SN_blake2s256'? [-Werror=implicit-function-declaration]
digest = EVP_blake2s256();
^~
SN_blake2s256
/home/sandu/work/openwrt/openwrt/build_dir/target-x86_64_musl/Python-3.8.0/Modules/_hashopenssl.c:220:20:
warning: assignment to 'const EVP_MD *' {aka 'const struct evp_md_st *'} from
'int' makes pointer from integer without a cast [-Wint-conversion]
digest = EVP_blake2s256();
^
/home/sandu/work/openwrt/openwrt/build_dir/target-x86_64_musl/Python-3.8.0/Modules/_hashopenssl.c:223:22:
error: implicit declaration of function 'EVP_blake2b512'; did you mean
'LN_blake2b512'? [-Werror=implicit-function-declaration]
digest = EVP_blake2b512();
^~
LN_blake2b512
/home/sandu/work/openwrt/openwrt/build_dir/target-x86_64_musl/Python-3.8.0/Modules/_hashopenssl.c:223:20:
warning: assignment to 'const EVP_MD *' {aka 'const struct evp_md_st *'} from
'int' makes pointer from integer without a cast [-Wint-conversion]
digest = EVP_blake2b512();
^
--
assignee: christian.heimes
components: Build, SSL
messages: 355940
nosy: Alexandru Ardelean, christian.heimes
priority: normal
severity: normal
status: open
title: hashlib: build fails when blake2 is disabled in OpenSSL
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue38684>
___
___
Python-bugs-list m
[issue37916] distutils: allow overriding of the RANLIB command on macOS (darwin)
Alexandru Ardelean added the comment: ping here :) any thoughts/feedback? the fix looks interesting, and I'm also interested in seeing a resolution for this -- nosy: +Alexandru Ardelean ___ Python tracker <https://bugs.python.org/issue37916> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35264] SSL Module build fails with OpenSSL 1.1.0 for Python 2.7
Change by Alexandru Ardelean : -- keywords: +patch pull_requests: +9818 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue35264> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35264] SSL Module build fails with OpenSSL 1.1.0 for Python 2.7
New submission from Alexandru Ardelean :
The Modules/_ssl.c build fails.
Error is:
```
building '_ssl' extension
arm-openwrt-linux-muslgnueabi-gcc -fPIC -fno-strict-aliasing -Os -pipe
-mcpu=xscale -fno-caller-saves -fno-plt -fhonour-copts
-Wno-error=unused-but-set-variable -Wno-error=unused-result -mfloat-abi=soft
-iremap/build_dir/target-arm_xscale_musl_eabi/Python-2.7.15:Python-2.7.15
-Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1
-Wl,-z,now -Wl,-z,relro -DNDEBUG -fno-inline -DNDEBUG -Os -pipe -mcpu=xscale
-fno-caller-saves -fno-plt -fhonour-copts -Wno-error=unused-but-set-variable
-Wno-error=unused-result -mfloat-abi=soft
-iremap/build_dir/target-arm_xscale_musl_eabi/Python-2.7.15:Python-2.7.15
-Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1
-Wl,-z,now -Wl,-z,relro -I. -IInclude -I./Include
-I/staging_dir/target-arm_xscale_musl_eabi/include
-I/staging_dir/toolchain-arm_xscale_gcc-7.3.0_musl_eabi/usr/include
-I/staging_dir/toolchain-arm_xscale_gcc-7.3.0_musl_eabi/include/fortify
-I/staging_dir
/toolchain-arm_xscale_gcc-7.3.0_musl_eabi/include
-I/staging_dir/target-arm_xscale_musl_eabi/usr/include
-I/staging_dir/hostpkg/bin/Include -I/staging_dir/hostpkg/bin
-c /build_dir/target-arm_xscale_musl_eabi/Python-2.7.15/Modules/_ssl.c
-o
build/temp.linux2-2.7//build_dir/target-arm_xscale_musl_eabi/Python-2.7.15/Modules/_ssl.o
cc1: note: someone does not honour COPTS correctly, passed 2 times
/build_dir/target-arm_xscale_musl_eabi/Python-2.7.15/Modules/_ssl.c:2117:44:
error: 'PySSL_selected_npn_protocol' undeclared here (not in a function); did
you mean 'PySSL_selected_alpn_protocol'?
{"selected_npn_protocol", (PyCFunction)PySSL_selected_npn_protocol,
METH_NOARGS},
^~~
PySSL_selected_alpn_protocol
```
This is on OpenWrt.
--
assignee: christian.heimes
components: Build, SSL
messages: 329995
nosy: Alexandru Ardelean, christian.heimes
priority: normal
severity: normal
status: open
title: SSL Module build fails with OpenSSL 1.1.0 for Python 2.7
versions: Python 2.7
___
Python tracker
<https://bugs.python.org/issue35264>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34710] SSL Module build fails with more pedantic compiler flags
Change by Alexandru Ardelean : -- keywords: +patch pull_requests: +8770 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue34710> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34710] SSL Module build fails with more pedantic compiler flags
New submission from Alexandru Ardelean : See: https://github.com/openwrt/packages/pull/7051 The issue seems a bit older ; see comment: https://github.com/python/cpython/pull/3943#discussion_r148949292 Build error happens on OpenWrt as well: --- /build_dir/target-i386_pentium4_musl/Python-3.7.0/Modules/_ssl.c:4000:5: error: implicit declaration of function 'DH_free'; did you mean 'lh_free'? [-Werror=implicit-function-declaration] DH_free(dh); ^~~ lh_free cc1: some warnings being treated as errors Python build finished successfully! The necessary bits to build these optional modules were not found: _tkinter _uuid nis To find the necessary bits, look in setup.py in detect_modules() for the module's name. The following modules found by detect_modules() in setup.py, have been built by the Makefile instead, as configured by the Setup files: _abc atexitpwd time zlib Failed to build these modules: _ssl Makefile:618: recipe for target 'sharedmods' failed --- The fix seems to be to include . -- assignee: christian.heimes components: Build, SSL messages: 325518 nosy: Alexandru Ardelean, christian.heimes priority: normal severity: normal status: open title: SSL Module build fails with more pedantic compiler flags versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue34710> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29708] support reproducible Python builds
Alexandru Ardelean <ardeleana...@gmail.com> added the comment: PYTHONHASHSEED does help on 3.6.4 I'll use it during build. Thanks for help -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue29708> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29708] support reproducible Python builds
Alexandru Ardelean <ardeleana...@gmail.com> added the comment: Yeah, I also see it with 3.6.4. I wanted to try 3.7 to see if it's fixed by chance. Otherwise I may have to start digging deep into compilation logic. Looking here: https://tests.reproducible-builds.org/lede/lede_ar71xx.html More specifically here: https://tests.reproducible-builds.org/lede/dbd/packages/mips_24kc/packages/python3-asyncio_3.6.4-5_mips_24kc.ipk.html it looks like 2 byte-codes are inverted build1: 7f80:·0100·003e·0200··72b6··0072·b500··...>....r....r.. build2: 7f80:·0100·003e·0200··72b5··0072·b600··...>....r....r.. 72b6 and 72b5 like to swap positions sometimes. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue29708> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29708] support reproducible Python builds
Alexandru Ardelean <ardeleana...@gmail.com> added the comment: Hey, Sorry, if I'm a bit late to the party with this. The road to reproducible builds has a few more steps. The way I validate whether Python is reproducible is with this link: https://tests.reproducible-builds.org/lede/lede_ar71xx.html There is a need to also patch getbuildinfo.c to make Python reproducible. I have opened a PR for this : https://github.com/python/cpython/pull/5313 I've waited for the periodic build to trigger on that reproducible page. In OpenWrt, the packages to look for [that is affected by this getbuildinfo.c patch] are python-base & python3-base. There are still some python3 packages that need patching. Seems that python3-asyncio, pydoc, and some other pyc files need investigation. I'll check. Maybe this isn't an issue in 3.7. Alex -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue29708> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29708] support reproducible Python builds
Change by Alexandru Ardelean <ardeleana...@gmail.com>: -- pull_requests: +5159 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue29708> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29708] support reproducible Python builds
Alexandru Ardelean <ardeleana...@gmail.com> added the comment: Thank you for the heads-up. I did not follow-up too in-depth on the resolution. I just stumbled over this last night. Will keep an eye for 3.7, and see about 2.7. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue29708> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29708] support reproducible Python builds
Alexandru Ardelean <ardeleana...@gmail.com> added the comment: Hey, Allow me to join the discussion here. Context: - I'm the maintainer of Python & Python3 in the OpenWrt distro, and (since a while) we also care about reproducible builds. - The person [Alexander Couzens] who's leading the effort for OpenWrt, has pinged me about Python(3) and packages [to see about making them reproducible] - In OpenWrt we *only* ship .pyc files, because of performance considerations [.pyc can be 10x faster than .py on some SoCs], and size limitation [we cannot allow auto .pyc generation since it can be expensive on RAM [ < 32 MB systems ] or flash [ ~8 MB sizes ] ; believe it or not, people run Python on something like this Current status: - so far I've implemented a simple change to Python & Python3 here: https://github.com/openwrt/packages/pull/5303/commits/1b6dd4781f901a769718c49f6f255c15fd376f6e - that has improved reproduce-ability quite a bit : only binaries are not reproduce-able now - when I did this [1-2 weeks ago] I did not think of checking of any bug/issue opened here [ I only thought if this now ] - I only checked what other distros may do regarding Python: https://tests.reproducible-builds.org/debian/reproducible.html References: - initial discussion on OpenWrt: https://github.com/openwrt/packages/issues/5278 - PR with discussion: https://github.com/openwrt/packages/pull/5303 - current OpenWrt reproducible state [with the patch applied]: https://tests.reproducible-builds.org/lede/lede_ar71xx.html I wanted to share my [and our] interest in this. If we can help in any way, feel free to ping. I will try to hack/patch some more stuff in the current Python releases to make them fully reproducible [for us], and probably share the results here. When PEP 552 gets implemented and there will be a Python we will switch to them. Atm, in trunk we package Python 2.7.14 & Python 3.6.4 Thanks Alex ------ nosy: +Alexandru Ardelean ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue29708> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30645] imp.py: load_package() appends to its own loop variable
Alexandru Ardelean added the comment: Admittedly, that PR refers to `imp.load_module()` But, `imp.load_modules()` also calls `imp.load_package()` -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30645> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30645] imp.py: load_package() appends to its own loop variable
Alexandru Ardelean added the comment: FWIW, I took a look over the virtualenv repo. There's an issue raised there https://github.com/pypa/virtualenv/issues/955 And a PR to address it https://github.com/pypa/virtualenv/pull/947 Though, it seems like they still want to keep `imp.load_package()` for a while, in order to keep compatibility with Python 2.6. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30645> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30645] imp.py: load_package() appends to its own loop variable
Changes by Alexandru Ardelean <ardeleana...@gmail.com>: -- pull_requests: +2318 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30645> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30645] imp.py: load_package() appends to its own loop variable
Alexandru Ardelean added the comment: I already completed those steps. Question is: what do I do with the output from that eSign ? Or, how do I use it ? It only mentions "Finally, click the "eSign" button to have the form sent to the PSF Secretary, Ewa Jodlowska." It's unclear from there-on if my patch is acceptable, or whether I can submit it [or anything], wait for a reply ; basically, how to continue once the form is signed. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30645> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30645] imp.py: load_package() appends to its own loop variable
Alexandru Ardelean added the comment: Damn. You guys are more corporate than... ... anyway. Please tell me, how to send you my signed CLA. Not sure if posting the link or PDF is fine here, but I'd be fine with that too. To resolve your first 2 notes: I am not using the imp module, nor the imp.load_package() function. I did see it was marked DEPRECATED. But, virtualenv uses it in it's latest release [15.1.0]. This is from trunk: https://github.com/pypa/virtualenv/blob/master/virtualenv_embedded/distutils-init.py#L17 But that's not the actual code that's used. Seems virtualenv, has a twisted way of keeping Python code base64 encoded & zipped within the virtualenv.py script. https://github.com/pypa/virtualenv/blob/master/virtualenv.py#L2117 So, maybe we can tell them not to use it, but let's see. In my case, I just have a bug report [I was notified via email directly], that this is an issue with Python3 + virtualenv on LEDE & OpenWrt. Python + virtualenv is not affected. While I'm here, maybe I could use this opportunity to start sending a few more patches from the OpenWrt/LEDE package build. But let's see how we resolve the legal matter first. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30645> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30645] imp.py: load_package: function has a buggy loop with `path = os.path.join(path, '__init__'+extension)`
Changes by Alexandru Ardelean <ardeleana...@gmail.com>: -- type: -> behavior ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30645> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30645] imp.py: load_package: function has a buggy loop with `path = os.path.join(path, '__init__'+extension)`
New submission from Alexandru Ardelean: On OpenWrt, the Python & Python3 are shipped with bytecodes [also, bytecode compiling is disabled by default]. 2 reasons for that: 1) that would fill up flash/RAM 2) bytecodes can be up to 10x faster than Python source code I got a report of an issue with virtualenv on Python3, that had a weird path: the `virtualenv /test` would generate `/test/lib/virtualenv/__init__.py/__init__.pyc` The fix is here in the patch file: https://github.com/openwrt/packages/pull/4475/commits/576c45eb0a5314121aeb2f8d8931644b65e5be99 -- components: Library (Lib) messages: 295865 nosy: Alexandru Ardelean priority: normal severity: normal status: open title: imp.py: load_package: function has a buggy loop with `path = os.path.join(path, '__init__'+extension)` versions: Python 3.6, Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30645> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
