[issue42545] Check that all symbols in the limited ABI are exported
Change by Igor Skochinsky : -- nosy: +Igor.Skochinsky ___ Python tracker <https://bugs.python.org/issue42545> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40939] Remove the old parser
Igor Skochinsky added the comment: > I am currently working on test that checks that the stable API symbols are > correctly exported. Thank you very much! For added motivation, the 3.8.0 release was unusable thanks to issue37633 which was somewhat similar (also in pythonrun). For reference, I've attached a list of symbols we currently use (a few more we have to import dynamically since they're not in the stable ABI but we'd like to keep that list as short as possible). -- Added file: https://bugs.python.org/file49647/py3.txt ___ Python tracker <https://bugs.python.org/issue40939> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40939] Remove the old parser
Igor Skochinsky added the comment: Thanks for the fix! I'd like to submit a test to avoid this and similar issues in future. Are there any guidelines for this? Sorry if this is a wrong place to ask. -- ___ Python tracker <https://bugs.python.org/issue40939> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40939] Remove the old parser
Igor Skochinsky added the comment: Attached is a sample program which works on 3.9 but fails linking with 3.10.0a2 The .so is missing the symbol: igor@LAPTOP:~/py_limited_api_example$ nm /home/igor/lib/libpython3.9.so | grep Py_CompileString 00212720 T Py_CompileString 0020fe30 T Py_CompileStringExFlags 00212730 T Py_CompileStringFlags 0020fd40 T Py_CompileStringObject igor@LAPTOP:~/py_limited_api_example$ nm /home/igor/lib/libpython3.10.so | grep Py_CompileString 00201a40 T Py_CompileStringExFlags 00201980 T Py_CompileStringObject Please stop breaking the Stable ABI :/ -- Added file: https://bugs.python.org/file49642/py_limited_api_example.zip ___ Python tracker <https://bugs.python.org/issue40939> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40939] Remove the old parser
Igor Skochinsky added the comment: > But Py_CompileString() function was not removed, it's still in the master > branch (future Python 3.10). Why do you think that it has been removed? Thank you. It looked that way because of the removed block of lines in the commit 1ed83adb0e95305af858bd41af531e487f54fee7 (pythonrun.c). We were also getting a missing symbol error. We'll check again to be sure. -- ___ Python tracker <https://bugs.python.org/issue40939> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40939] Remove the old parser
Igor Skochinsky added the comment: Hi All, It seems this patch removes some functions provided by the Stable ABI (PEP 384), most notably Py_CompileString. Was this the intention? If not, is there still a chance to reintroduce it before the release? -- nosy: +Igor.Skochinsky ___ Python tracker <https://bugs.python.org/issue40939> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31767] Windows Installer fails with error 0x80091007 when trying to install debugging symbols
Igor Skochinsky <skochin...@gmail.com> added the comment: Hi Steve, Thanks for the suggestion! I tried that and while it did not succeed it gave me an idea of what went wrong last time since it complained about lack of disk space. I have *not* run the /layout but now that I checked I indeed had core_d.msi and core_pdb.msi (and a few more) in the Downloads directory, so I think maybe the installer tried to download them but ran out of space and the download was incomplete. Another possibility is that the .msi was for the wrong installer - I first tried installing the x86 version but later changed my mind but since I did not expect it to download extra files into the same directory I did not clean them. Also it seems the downloaded .msi files have the original timestamp (16-09-27) so I did not notice them when sorting my downloads by date until I tried to look for .msi files specifically. In the end I guess this could be closed as PEBKAC but I think maybe some more testing in low-disk-space conditions and/or installing x86 then x64 from the same directory could uncover some real issues. In general, I found the 3.3 install experience not very straightforward compared to 2.7 - I expected that the installer contains everything necessary (since I did *not* pick "webinstall" one) and won't download extra files (with the exception of the PDB option which did say "download"). If the .msi files came from the .exe itself, I'd expect them to be extracted into a unique temporary directory and not next to the exe. I will work on freeing some space and then try again. > Steve Dower <steve.do...@python.org> added the comment: > > Can you try moving the installer exe to its own (empty) directory before > running it? > -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31767> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31767] Windows Installer fails with error 0x80091007 when trying to install debugging symbols
New submission from Igor Skochinsky <skochin...@gmail.com>: Trying to install 3.6.3 on Windows 10 and getting this error. Repro steps: 1. Download python-3.6.3.exe or python-3.6.3-amd64.exe, run it 2. Select "Customize Installation" 3. Next 4. In Advanced Options, select [x] Install for all users (not sure if important) [x] Download debugging symbols change path to F:\Python36 (not sure if it matters but my system drive is F: and C: is missing except for when I plug in a USB drive) Ucheck [ ] Associate files with Python Click Install and accept elevation prompt. After a while it fails with Error 0x80091007 - Hash value not correct. Interestingly, "log file" link does not work. I had to go hunt for the log in %temp% myself. The relevant parts: Error 0x80091007: Hash mismatch for path: F:\ProgramData\Package Cache\.unverified\core_AllUsers_pdb, expected: A4B6E4A818E49F000513774F034EC98A194E3C3D, actual: 36C7B852E586D26F4D239ED72EFE5FFBEBA21825 Error 0x80091007: Failed to verify hash of payload: core_AllUsers_pdb Failed to verify payload: core_AllUsers_pdb at path: F:\ProgramData\Package Cache\.unverified\core_AllUsers_pdb, error: 0x80091007. Deleting file. Application requested retry of payload: core_AllUsers_pdb, encountered error: 0x80091007. Retrying... There are a few more retries basically with the same result. However, this one is interesting: Acquiring package: core_AllUsers_pdb, payload: core_AllUsers_pdb, copy from: F:\Users\Igor\Downloads\core_pdb.msi I don't have such a file there, just the installer .exe -- components: Installation messages: 304182 nosy: Igor.Skochinsky priority: normal severity: normal status: open title: Windows Installer fails with error 0x80091007 when trying to install debugging symbols type: security versions: Python 3.6 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31767> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28687] Python 2.7.12 windows x64 installer fails after previous bad uninstall
New submission from Igor Skochinsky:
It's somewhat my fault but I think it's not such an uncommon scenario.
I had installed 2.7.10 x64 some time ago into C:\Python27_64 but then had to
delete it to save space. Rather foolishly instead of using the uninstaller, I
just trashed the directory and now I have a problem: neither the Control Panel
uninstall item, nor the fresh 2.7.12 installer work. The latter fails when it
tries to use the nonexisting Python to remove pip:
MSI (s) (04:B0) [11:00:09:881]: Product: Python 2.7.10 (64-bit) -- Error 1721.
There is a problem with this Windows Installer package. A program required for
this install to complete could not be run. Contact your support personnel or
package vendor. Action: RemovePip, location: C:\Python27_64\python.exe,
command: -B -m ensurepip._uninstall
In the UI just the first message is shown, without the failed commandline, so
it's not at all clear what went wrong.
I think at the very least the user should be informed about the failed command
so they can clean up the old installer's remains, or maybe the installation
should be allowed to proceed anyway, replacing the bad paths in the registry.
In the end, I had to use "Msizap TWA {E2B51919-207A-43EB-AE78-733F9C6797C3}"
after which I could install 2.7.12 into a separate directory
--
components: Installation
messages: 280747
nosy: Igor.Skochinsky
priority: normal
severity: normal
status: open
title: Python 2.7.12 windows x64 installer fails after previous bad uninstall
type: behavior
versions: Python 2.7
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28687>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17213] ctypes loads wrong version of C runtime, leading to error message box from system
Igor Skochinsky added the comment: Just had this issue when using networkx (which imports uuid). One keyword that would help visibility is R6034 (the runtime error number). A couple of reports related to this: https://projects.blender.org/tracker/index.php?func=detailaid=27666 http://forums.boxee.tv/showthread.php?t=15425 The proper solution is to fix ctypes, but in the meantime we can at least fix uuid. The error seems to be triggered by this snippet: # The uuid_generate_* routines are provided by libuuid on at least # Linux and FreeBSD, and provided by libc on Mac OS X. for libname in ['uuid', 'c']: try: lib = ctypes.CDLL(ctypes.util.find_library(libname)) except: continue if hasattr(lib, 'uuid_generate_random'): _uuid_generate_random = lib.uuid_generate_random if hasattr(lib, 'uuid_generate_time'): _uuid_generate_time = lib.uuid_generate_time Since this code is useless on Windows, protecting it in if os.name not in ['nt', 'ce'] does the trick. BTW, instead of going all way with activation context etc., a simpler solution would be to add to ctypes something like this in CDLL.__init__: if os.name in ['nt', 'ce'] and name == util.find_msvcrt(): # TODO: handle the extension self._handle = windll.kernel32.GetModuleHandleA(self._name) i.e. use the already present runtime DLL instead of trying to load it again. -- nosy: +Igor.Skochinsky ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17213 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
