File setup.py, line 9, in <module> from setuptools import setup, Extension ModuleNotFoundError: No module named setuptools make[2]: *** [Makefile:621: all-local] Error 1 make[2]: Leaving directory /var/tmp/portage/dev-util/systemtap-4.0-r1/work/systemtap-4.0/python make[1]: *** [Makefile:2103: all-recursive] Error 1 ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 17.1_desktop_gnome_systemd-libressl-20200430-031932 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-9.3.0 * clang version 10.0.0 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/lib/llvm/10/bin /usr/lib/llvm/10 10.0.0 Available Python interpreters, in order of preference: [1] python3.6 [2] python3.8 [3] python3.7 (fallback) [4] python2.7 (fallback) Available Ruby profiles: [1] ruby24 (with Rubygems) [2] ruby25 (with Rubygems) * Available Rust versions: [1] rust-bin-1.43.0 * The following VMs are available for generation-2: *) AdoptOpenJDK 8.252_p09 [openjdk-bin-8] Available Java Virtual Machines: [1] openjdk-bin-8 system-vm timestamp(s) of HEAD at this tinderbox image: /var/db/repos/gentoo Fri 08 May 2020 04:05:37 PM UTC /var/db/repos/libressl Sat 11 Apr 2020 05:02:25 AM UTC emerge -qpvO dev-util/systemtap [ebuild N ] dev-util/systemtap-4.0-r1 USE="ssl -libvirt (-selinux) -sqlite -zeroconf" PYTHON_SINGLE_TARGET="python3_7 -python3_6 -python3_8"
Created attachment 636874 [details] emerge-info.txt
Created attachment 636876 [details] dev-util:systemtap-4.0-r1:20200508-163434.log
Created attachment 636878 [details] emerge-history.txt
Created attachment 636880 [details] environment
Created attachment 636882 [details] etc.portage.tbz2
Created attachment 636884 [details] logs.tbz2
Created attachment 636886 [details] temp.tbz2
I am having the same issue; I am thinking it may have to do with a notice I received after syncing my system; that portage is updating the python version of packages. It could means packages installed on different virtual environments, then they do not know each other. It complicates that setuptools have so many reverse dependencies, so if you try to upgrade it without a system upgrade, likely portage will complain about many things, though looking on my mtimedb (see at man emerge) reverse dependencies seems not to be a problem but it is an issue that systemtap looks for setuptools and it does not find it, maybe for different environments; independent of it being considered or not as reverse dependency
indeed adding setuptools as dependency on the ebuild resolved the compilation issue
This is a duplicate of https://bugs.gentoo.org/719436
*** This bug has been marked as a duplicate of bug 719436 ***
