[issue43617] Missing definition in configure.ac causing autoreconf to create damaged configure script
Eli Schwartz added the comment: Hmm, I've seen this accomplished elsewhere using m4_pattern_forbid, which would make autoreconf fail with the following message: ``` configure.ac:17: error: possibly undefined macro: AX_C_FLOAT_WORDS_BIGENDIAN If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.ac:5586: error: possibly undefined macro: AX_CHECK_OPENSSL autoreconf: error: /usr/bin/autoconf failed with exit status: 1 ``` Example patch attached. -- nosy: +eschwartz Added file: https://bugs.python.org/file49954/0001-configure-use-m4-forbidden-patterns-to-ensure-autore.patch ___ Python tracker <https://bugs.python.org/issue43617> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43282] Add split install targets to install tests separately from lib
Eli Schwartz added the comment: I started to look into this, but it seems like I'd need a bit of duplication to handle byte compiling the installed files in two different Makefile targets. The alternatives are templating, automake style, or GNU make'isms like the $(call) function, or possibly running `$(MAKE) bytecompile` to do all byte-compilation in a shareable submake. Do any of these sound good? Any other thoughts? -- ___ Python tracker <https://bugs.python.org/issue43282> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40059] Provide a toml module in the standard library
Change by Eli Schwartz : -- nosy: +eschwartz ___ Python tracker <https://bugs.python.org/issue40059> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27640] Add --disable-test-modules configure option to not build nor install tests
Eli Schwartz added the comment: I filed issue43282 for this. -- ___ Python tracker <https://bugs.python.org/issue27640> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43282] Add split install targets to install tests separately from lib
New submission from Eli Schwartz : cf. https://bugs.python.org/issue27640#msg386758 Carrying on from the addition of --disable-test-modules, I would find it convenient to be able to still provide the tests, but install them separately. The end result would be two distro packages, one slim package that does not include the test modules by default, and one package that adds in the test modules for people that need it. This is currently possible via running the install step twice and some hacky shell globbing to delete unneeded files from each install. Some sort of libinstall/testinstall target split target would be less hacky, and not require checking if the list of test modules is up to date. So I'd consider it nice to have. :) -- components: Build messages: 387438 nosy: eschwartz priority: normal severity: normal status: open title: Add split install targets to install tests separately from lib type: enhancement versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue43282> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27640] Add --disable-test-modules configure option to not build nor install tests
Eli Schwartz added the comment: I have a slightly different interest in declining to install tests... Arch Linux provides the tests as a split subpackage with currently some hacky shell globbing to delete the tests after make install, then do a second libinstall and delete everything but the tests. It would be more convenient if we had a Makefile option to install the tests separately. It's now possible to disable installing tests with a filthy hack: make install TEST_MODULES= TESTSUBDIRS= However, it's not possible to similarly hack make libinstall LIBSUBDIRS= Because it installs some toplevel stuff, then runs lib2to3.pgen2.driver on the grammar that got skipped by the LIBSUBDIRS= hack. Thoughts on maybe splitting this up at install time? Would probably mean duplicating some of libinstall as testinstall... -- nosy: +eschwartz ___ Python tracker <https://bugs.python.org/issue27640> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2504] Add gettext.pgettext() and variants support
Eli Schwartz added the comment: Interestingly enough, the final accepted patch (and the 2010 one) also fixes a bug where gettext.install(..., names='ngettext') would incorrectly work, in violation of the documentation. I think it would also incorrectly install 'gettext', too... It used to just check if names.__contains__ is a valid attribute, then check if 'foo' in names, so a dumb string "worked" and even matched more things than it should have. How I discovered this: I fixed a bug in a python project that stopped working on python 3.8, and had a bit of a head-scratch regarding how it ever worked to begin with: https://github.com/linuxmint/cinnamon/pull/8964 -- nosy: +eschwartz ___ Python tracker <https://bugs.python.org/issue2504> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1724822] provide a shlex.split alternative for Windows shell syntax
Change by Eli Schwartz : -- nosy: +eschwartz ___ Python tracker <https://bugs.python.org/issue1724822> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34022] 6 tests fail using SOURCE_DATE_EPOCH env var
Change by Eli Schwartz : -- nosy: +eschwartz ___ Python tracker <https://bugs.python.org/issue34022> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34095] [2.7] test_idle fails with: /usr/bin/xvfb-run: line 181: 3617 Segmentation fault
Eli Schwartz added the comment: Note the last line, which shows that the testsuite itself is executed using xvfb-run. The archlinux32 build script is based off the original PKGBUILD for archlinux: https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/python2 xvfb-run is only involved, because the testsuite depends on being run in a GUI environment in order to test GUI components... -- nosy: +eschwartz ___ Python tracker <https://bugs.python.org/issue34095> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29708] support reproducible Python builds
Eli Schwartz <eschwart...@gmail.com> added the comment: So, a couple of things. It seems to me, that properly supporting SOURCE_DATE_EPOCH means using exactly that and nothing else. To that end, I'm not entirely sure why things like --clamp-mtime even exist, as the original timestamp of a source file doesn't seem to have a lot of utility and it is better to be entirely predictable. But I'm not going to argue that, except insomuch as it seems IMHO to fit better for python to just keep things simple and override the timestamp with the value of SOURCE_DATE_EPOCH That being said, I see two problems with python implementing something analogous to --clamp-mtime rather than just --mtime. 1) Source files are extracted by some build process, and remain untouched. Python generates bytecode pinned to the original time, rather than SOURCE_DATE_EPOCH. Later, the build process packages those files and implements --mtime, not --clamp-mtime. Because Python and the packaging software disagree about which one to use, the bytecode fails. 2) Source files are extracted, and the build process even tosses all timestamps to the side of the road, by explicitly `touch`ing all of them to the date of SOURCE_DATE_EPOCH just in case. Then for whatever reason (distro patches, 2to3, the use of `cp`) the timestamps get updated to $currentime. But SOURCE_DATE_EPOCH is in the future, so the timestamps get downdated. Python bytecode is generated by emulating --clamp-mtime. The build process then uses --mtime to package the files. Again, because Python and the packaging software disagree about which one to use, the bytecode fails. Of course, in both those cases, blindly respecting SOURCE_DATE_EPOCH will seemingly break everything for people who use --clamp-mtime instead. I'm not happy with reproducible-builds.org for allowing either one. I don't think python should rely on --mtime users manually overriding the filesystem metadata of the source files outside of py_compile, as that is a hack that I think we'd like to remove if possible... that being said, Arch Linux will, on second thought, not be adversely affected even if py_compile tries to be clever and emulate --clamp-mtime to decide on its own whether to respect SOURCE_DATE_EPOCH. Likewise, I don't really expect people to try to reproduce builds using a future date for SOURCE_DATE_EPOCH. On the other hand, the reproducible builds spec doesn't forbid it AFAICT. But... neither of those mitigations seem "clean" to me, for the reasons stated above. There is something that would solve all these issues, though. From reading the importlib code (I haven't actually tried smoketesting actual imports), it appears that Python 2 accepts any bytecode that is dated at or later than the timestamp of its source .py, while Python 3 requires the timestamps to perfectly match. This seems bizarre to behave differently, especially as until @bmwiedemann mentioned it on the GitHub PR I blindly assumed that Python would not care if your bytecode is somehow dated later than your sources. If the user is playing monkey games with mismatched source and byte code, while backdating the source code to *trick* the interpreter into loading it... let them? They can break their stuff if they want to! On looking through the commit logs, it seems that Python 3 used to do the same, until https://github.com/python/cpython/commit/61b14251d3a653548f70350acb250cf23b696372 refactored the general vicinity and modified this behavior without warning. In a commit that seems to be designed to do something else entirely. This really should have been two separate commits, and modifying the import code to more strictly check the timestamp should have come with an explanatory justification. Because I cannot think of a good reason for this behavior, and the commit isn't giving me an opportunity to understand either. As it is, I am completely confused, and have no idea whether this was even supposed to be deliberate. In hindsight it is certainly preventing nice solutions to supporting SOURCE_DATE_EPOCH. -- nosy: +eschwartz ___ 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
