Bug#1010284: python3-pip: runs into infinite loop when installing package with pyproject.toml file
I've encountered the same issue when attempting to install the aiohttp
package or anything that depends on it, which seems to be a lot.
File "/usr/lib/python3.10/_distutils_system_mod.py", line 125, in
_inject_headers
scheme['headers'] =
orig_install._load_schemes()['posix_prefix']['headers']
File "/usr/lib/python3.10/_distutils_system_mod.py", line 137, in
wrapped_load_schemes
_inject_headers(name, scheme)
File "/usr/lib/python3.10/_distutils_system_mod.py", line 125, in
_inject_headers
scheme['headers'] =
orig_install._load_schemes()['posix_prefix']['headers']
File "/usr/lib/python3.10/_distutils_system_mod.py", line 135, in
wrapped_load_schemes
schemes = _load_schemes()
File
"/usr/lib/python3/dist-packages/setuptools/_distutils/command/install.py",
line 103, in _load_schemes
sysconfig_schemes = _load_sysconfig_schemes() or {}
File
"/usr/lib/python3/dist-packages/setuptools/_distutils/command/install.py",
line 91, in _load_sysconfig_
schemes
with contextlib.suppress(AttributeError):
RecursionError: maximum recursion depth exceeded
[end of output]
Failed to build aiohttp
ERROR: Could not build wheels for aiohttp, which is required to install
pyproject.toml-based projects
Bug#926207: iotop: unable to run on kernels with retpoline (spectre)
> Any chance you could upgrade to either the Debian kernel or one based > on the Debian kernel or on 4.19 mainline and see if any of them fix it? > > Also, I suggest you try to get those quirks fixed in Linux mainline, > so that you don't have to keep building Linux yourself :) I'm afraid upgrading would be difficult. The use-case is one of fairly entrenched networking for my company, so there's significant regression-testing required to even move further within the same minor version. The quirks are also somewhat difficult to generalise: some of the hardware is rather antiquated, requiring driver hacks for initialisation, and many of the other changes are similarly niche and intended only as case-specific optimisations. (It's divergent in much the same way that much of the OpenWRT project's kernel patches will never be suitable for mainline, but we do submit bugfixes and stuff when we can) I was able to confirm that the problem doesn't occur with Debian's 4.19 series on unrelated hardware, however, and it looks like the problem has been resolved for a while in stock kernels. > Do you have any details about which patch this is? https://lists.ubuntu.com/archives/kernel-team/2018-May/092723.html I wasn't able to find an equivalent in Debian's patchsets, which led me to check upstream; more on that below. > Also, it would be great if you could try to get the patch into the > Linux kernel's mainline stable releases. After digging around for a while, it looks like this may be a side-effect of how LTSI works, though I'll report it anyway, in hopes that it can be addressed without violating the "don't break the userspace ABI" policy. Any semi-recent kernel version should be unaffected. The following patch adds a "NoNewPrivs" line to /proc//status, where the blank appears in 4.4. It doesn't look like it was ever backported into the tree, or, rather, it seems to be the case that retpoline logic, which assumed there was text right after the capabilities block, was backported directly, leading to the gap. NoNewPrivs patch: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=af884cd4a5ae62fcf5e321fecf0ec1014730353d In any case, this is definitely an issue that should be fixed in (specific versions of) the kernel. I still think iotop should be synced to gain tolerance to unexpected input, but it isn't a Debian-specific problem in light of what's been discussed here. Thanks for the sanity-checks here. -Neil
Bug#926207: iotop: unable to run on kernels with retpoline (spectre)
Ah, then that probably explains why it hasn't come up as a bug here before and I do apologise for the interruption, and greatly appreciate how quickly you responded. I am running a mostly vanilla upstream kernel (for a class of special-purpose devices that have some unusual quirks) that does include blank lines. $ uname -rv 4.4.163 #1 SMP Thu Nov 15 21:07:22 UTC 2018 (4.4 rather than 4.19 and not running Debian patches, where it looks like an Ubuntu patch was adopted to remove the newline) $ sudo sh -c 'grep -l "^ *$" /proc/*/status' /proc/1/status /proc/10/status /proc/1006/status ... 99 in total, which is the same as the number of running processes + 1 (for thread-self) $ cat /sys/devices/system/cpu/vulnerabilities/spectre_v2 Mitigation: Full generic retpoline So it looks like my problem here is due to my kernel not being Debian-stock. Because of this, I think the severity of this issue can be dropped, likely to minor: this problem is not likely to affect most users, and it was pretty straightforward for me to sync upstream source and rebuild using the Debian packaging you had put together to make a usable internal build. I don't think it should be closed outright, though, because what I've done to reach this point is documented: https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s-common-official (though I could also just rebuild my kernel with the blank-line suppressing patch); it just probably doesn't make sense to prioritise addressing an atypical usecase. -Neil On Mon, Apr 1, 2019 at 10:44 PM Paul Wise wrote: > Control: tags -1 + unreproducible fixed-upstream > Control: forwarded -1 > https://repo.or.cz/iotop.git/commit/7c51ce0e29bd135c216f18e18f0c4ab769af0d6f > https://repo.or.cz/iotop.git/commit/0392b205b5c3973a326721c2e9f97f0fa2eefa82 > > On Mon, 2019-04-01 at 16:43 -0600, Neil Tallim wrote: > > > I'm afraid there's a flaw in the version of iotop available in Debian > (even in > > sid): retpoline support adds a blank line to /proc//status, which > iotop was > > not able to deal with before May of 2018. The effect of this is a crash > with a > > Python stack-trace. It affects all usage of iotop on any kernels with > spectre > > mitigation. > > As far as I can tell the commit that added blank lines to the > /proc/*/status files was never added to Debian or mainline kernels and > indeed iotop works for me with Linux 4.19.28-2 from Debian unstable. > > Could you provide some info I can use to reproduce this? > > $ uname -rv > 4.19.0-4-amd64 #1 SMP Debian 4.19.28-2 (2019-03-15) > > $ sudo sh -c 'grep -l "^ *$" /proc/*/status' > > $ cat /sys/devices/system/cpu/vulnerabilities/spectre_v2 > Mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, STIBP: > disabled, RSB filling > > -- > bye, > pabs > > https://wiki.debian.org/PaulWise > >
Bug#926207: iotop: unable to run on kernels with retpoline (spectre)
Package: iotop Version: 0.6-24-g733f3f8-1 Severity: important Tags: upstream I'm afraid there's a flaw in the version of iotop available in Debian (even in sid): retpoline support adds a blank line to /proc//status, which iotop was not able to deal with before May of 2018. The effect of this is a crash with a Python stack-trace. It affects all usage of iotop on any kernels with spectre mitigation. The upstream commit that addresses the issue is also the most recent one since then: https://repo.or.cz/iotop.git/commit/7c51ce0e29bd135c216f18e18f0c4ab769af0d6f -- System Information: Distributor ID: Debian Description:Debian Release:testing Codename: buster Architecture: x86_64 Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages iotop depends on: ii python3 3.7.1-3 iotop recommends no packages. iotop suggests no packages. -- no debconf information
