Created attachment 789878 [details] configure.log virtualbox-6.1.32-r2 fails to build on a system with only Python 3.10 installed, with the error "Python not found!". Luckily the masked 6.1.34-r1 does build successfully, so the easy solution here is to unmask it, its dependencies, and also similar versions of other virtualbox-* packages. Getting back to the error with 6.1.32-r2, it fails during the configure step: Checking for Python support: ** Python not found! Check /var/tmp/portage/app-emulation/virtualbox-6.1.32-r2/work/VirtualBox-6.1.32/configure.log for details I'll attach build.log and configure.log. The latter appears to show it looking for (and failing to find) Python.h in various /usr/local/include/python* directories for various versions, none of which were 3.10, even though the package was emerged with PYTHON_SINGLE_TARGET having only python3_10 enabled. The other odd thing is that I don't even have a /usr/local/include. If I run find on my system for Python.h, it's found at /usr/include/python3.10/Python.h.
Created attachment 789881 [details] build.log
Hello everyone! I have the same error here!
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0e7860b78e08743e7ba8a9d641a085e349811f83 commit 0e7860b78e08743e7ba8a9d641a085e349811f83 Author: Sam James <sam@gentoo.org> AuthorDate: 2022-07-06 02:59:20 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-07-06 03:01:21 +0000 app-emulation/virtualbox: drop Python 3.10 for now Didn't really want to do this but it's going to take substantially more work to get it running. Two issues (as described in the ebuild comment I've added): 1. The build system (not just configure) does a huge amount of autodetection; 2. Its infra isn't set up to build Python 3.10+ yet (as in, no targets defined, and they're all manually written). And it doesn't seem to even use the result of configure? It'll take more work to get this done and dropping 3.10 for now, while it's unfortunate, means it's at least not in a broken state until then. I've left in the partial work commented out given it gets us part of the way there. As far as I can tell, the configure stuff isn't even used for the subsequent actual building of the modules. Bug: https://bugs.gentoo.org/856121 Bug: https://bugs.gentoo.org/785835 Signed-off-by: Sam James <sam@gentoo.org> .../files/virtualbox-6.1.34-r3-python.patch | 14 +++++ .../virtualbox/virtualbox-6.1.34-r3.ebuild | 64 +++++++++++++++------- 2 files changed, 58 insertions(+), 20 deletions(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7dde6a6bd36cadd1c70d8ec3d3f956750231eeff commit 7dde6a6bd36cadd1c70d8ec3d3f956750231eeff Author: Sam James <sam@gentoo.org> AuthorDate: 2022-07-06 03:17:56 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-07-06 03:18:32 +0000 app-emulation/virtualbox: uncomment partial Python logic Went back and forth on this but I think it's worth hinting as much as possible for now, given it's completely guessing otherwise, and we can't easily just rip out / disable Python entirely until we fix this. Bug: https://bugs.gentoo.org/856121 Bug: https://bugs.gentoo.org/785835 Signed-off-by: Sam James <sam@gentoo.org> .../virtualbox/virtualbox-6.1.34-r3.ebuild | 24 ++++++++++------------ 1 file changed, 11 insertions(+), 13 deletions(-)
See, also, patches #002 and #003 from https://github.com/archlinux/svntogit-community/tree/b103146beee8b7c70d04685033a8536aed2e5aea/trunk. The first is a an application of https://www.virtualbox.org/changeset/90537/vbox, which is a larger patch than the one currently in the gentoo repo.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1fc46c8f5638d711c550447a86a13286bd79fe73 commit 1fc46c8f5638d711c550447a86a13286bd79fe73 Author: Sam James <sam@gentoo.org> AuthorDate: 2022-07-06 04:44:34 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-07-06 06:05:17 +0000 app-emulation/virtualbox: force usage of selected Python; add Python 3.10 - Finish off the work from earlier (started in 0e7860b78e08743e7ba8a9d641a085e349811f83 and then 7dde6a6bd36cadd1c70d8ec3d3f956750231eeff) for forcing the right Python implementation to be used for USE=python/bindings builds. We now hijack the script that the Makefile calls to get the list of available interpreters (which is separate from the weird configure thing!) and just create a stub which outputs the paths for the corresponding implementation chosen via PYTHON_SINGLE_TARGET using the normal eclass machinery. - Add a sanity check in src_install for when USE=python for /usr/$(get_libdir)/virtualbox/VBoxPython*.so to minimise the risk of silently not building & not realising it. (Noticed risk of this when in the middle of this work & noticed that w/o the extra (see next point) Makefile targets, it ends up silently just not doing anything). - Import Arch Linux / upstream (on trunk) patches for Python 3.10 (thanks to Kerin Millar for the pointer on that bit). We're resigned to having to update the Makefile every time a new Python comes out, but it's at least only one place, and it's not trivial for us to change it given.. kbuild. (It's not just a list, but a bunch of variables which get defined for each target.) Closes: https://bugs.gentoo.org/856121 Closes: https://bugs.gentoo.org/785835 Signed-off-by: Sam James <sam@gentoo.org> .../files/virtualbox-6.1.34-r3-python3.10.patch | 122 +++++ .../virtualbox/virtualbox-6.1.34-r4.ebuild | 585 +++++++++++++++++++++ 2 files changed, 707 insertions(+)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=430e969f9794911dad71a7a38c02590c1cca505d commit 430e969f9794911dad71a7a38c02590c1cca505d Author: Sam James <sam@gentoo.org> AuthorDate: 2022-07-06 09:22:53 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-07-06 09:23:07 +0000 app-emulation/virtualbox: fix disabling Python bindings Bug: https://bugs.gentoo.org/856121 Closes: https://bugs.gentoo.org/785835 Signed-off-by: Sam James <sam@gentoo.org> .../{virtualbox-6.1.34-r4.ebuild => virtualbox-6.1.34-r5.ebuild} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Hello everyone! I have here still the same error because I use app-emulation/virtualbox-6.1.32-r2 version... And not the version app-emulation/virtualbox-6.1.34-r*...
(In reply to Eduardo Coutinho Scalabrin from comment #8) > Hello everyone! > > I have here still the same error because I use > app-emulation/virtualbox-6.1.32-r2 version... And not the version > app-emulation/virtualbox-6.1.34-r*... Yeah, we'll stable the new fixed version soon, but sadly we've run into bug 856811 :( So it's masked for now.
This should work again w: commit 605d086c0214e6ca8fa1ff5b62cc5d5e33a3aa47 Author: Viorel Munteanu <ceamac.paragon@gmail.com> Date: Mon Jul 11 11:17:07 2022 +0300 app-emulation/virtualbox: revert QA fix for CFLAGS It causes worse issues (the virtual machines do not start at all) This is an emergency fix, so we can unmask the package Bug: https://bugs.gentoo.org/843437 Closes: https://bugs.gentoo.org/856811 Signed-off-by: Viorel Munteanu <ceamac.paragon@gmail.com> Closes: https://github.com/gentoo/gentoo/pull/26342 Signed-off-by: Sam James <sam@gentoo.org>
*** Bug 860810 has been marked as a duplicate of this bug. ***
