Created attachment 206658 [details] Switch to default python version for build Tested with python 3.6 and 3.7 on 12.0 amd64 and i386.
So, is this supposed to solve errors like: ===> mesa-libs-18.3.2_1 depends on file: /usr/local/bin/python2.7 - found ===> mesa-libs-18.3.2_1 depends on package: llvm80>=3.9.0_4 - not found ===> llvm80-8.0.1_3 needs Python 3.6 at least, but 2.7 was specified. E.g. somehow mesa is forcing the internal python version to 2.7, then the sub-make for building llvm80 inherits that, and dies.
Right, I should just have tried your patch. This works for me! [...] ===> mesa-libs-18.3.2_1 depends on file: /usr/local/libdata/pkgconfig/pthread-stubs.pc - found ===> mesa-libs-18.3.2_1 depends on executable: bison - found ===> mesa-libs-18.3.2_1 depends on executable: msgfmt - found ===> mesa-libs-18.3.2_1 depends on executable: gmake - found ===> mesa-libs-18.3.2_1 depends on package: pkgconf>=1.3.0_1 - found ===> mesa-libs-18.3.2_1 depends on file: /usr/local/bin/python3.7 - found ===> mesa-libs-18.3.2_1 depends on package: llvm80>=3.9.0_4 - not found ===> Building for llvm80-8.0.1_3
There are still several python scripts in the sources that look for something to do with python2. I have to look into the details of if they are needed and/or executed. The documentation only says 2.7 is needed with scons, but I don't know about what's needed with autotools.
(In reply to Niclas Zeising from comment #3) I removed python27 and mesa rebuild fine.
Does this patch have any problems? If no - commit it, please.
I applied the same patch when building mesa-libs 19.0.8, and it works fine.
(In reply to rsmith from comment #6) mesa-dri and mesa-libs, that is.
Comment on attachment 206658 [details] Switch to default python version for build This works for me, too. Both mesa-dri and mesa-libs build fine in poudriere with python37 (and no python27) installed. [1] A PORTREVISION bump is not be needed - this does not changes the contents of the package. I don't think there's any rush to do this before python27 expires - it can wait to piggyback on an update for other reasons. [1] There is a failure with stage-qa, but that is unrelated and existed before this change: ====> Running Q/A tests (stage-qa) Error: /usr/local/lib/libGL.so.1.2.0 is linked to /usr/local/lib/libXxf86vm.so.1 from x11/libXxf86vm but it is not declared as a dependency Warning: you need USE_XORG+=xxf86vm Warning: Possible REINPLACE_CMD issues sed failed: file content unchanged from backup: src/util/xmlconfig.c
Created attachment 212657 [details] [patch] fix stage-qa findings & speed up the build a bit (In reply to John Hein from comment #8) In addition to removing the python2.7 restriction, the attached patch fixes the warnings and speeds up the build (maybe 5% depending on your hardware) - no need to build some of the things that mesa-libs builds. That helps with the stage-qa error, too (missing dep). Note that the former sed(1) for xmlConfig.c has not been needed for a while. Install directories are configured correctly without it. The sed expr was wrong anyway (no trailing /, so the sed was a no-op). This could (should) go into a separate bug. Sorry to piggy back on the bug. I'll open a separate bug if desired. But otherwise, this patch's additions with the python 2.7 removal could be committed together. There is no need to bump PORTREVISION, I believe - no pkg change.
Can everyone also make sure that graphics/libosmesa, graphics/mesa-dri, graphics/mesa-libs and lang/clover also build perfectly with these changes - these ports all pull in Makefile.common from this port directory. And if this change isn't made, all these ports should be marked as DEPRECIATED with the rest of the python27-dependent ports.
Mesa is quite complex, both the build and runtime. I'm quite hesitant to change the build options, especially those that disable egl, glsv2 and so on, because that might also affect how the gl drivers are built. At least the CFLAGS from checking for for instance EGL are added to the driver build. There are also several tools that still hard code python2. We will of course fix the python issues before python is EOL, there is no need to mark the port as deprecated, that will only cause confusion. There is also ongoing work to update mesa, but it is complicated because mesa switched from autotools to meson, so it takes time. In any case, patches are not approved.
Comment on attachment 212657 [details] [patch] fix stage-qa findings & speed up the build a bit ^Triage: User maintainer-approval flag to signify approval (or not)
Comment on attachment 206658 [details] Switch to default python version for build ^Triage: User maintainer-approval flag to signify approval (or not)
^Triage: Maintainer feedback was provided (+) @Niclas If this issue is considered Resolved -> Not Accepted, please close the issue accordingly, otherwise clarify next steps for the issue as reported.
It is your decision to make, but be aware that all ports that rely on python27 are currently broken because python27 is on the vulnerable list, and with python 2.7 already being out of support, that is unlikely to change. https://vuxml.FreeBSD.org/freebsd/a27b0bb6-84fc-11ea-b5b4-641c67a117d8.html It's only a DOS, but it is only a matter of time before more severe ones are found. We do need to get python2 out of our ports tree.
(In reply to robbak from comment #15) Currently all python ports are vulnerable, and there are patches in the works to update python 2.7 to a non-vulnerable version, so this is a non-argument.
(In reply to Niclas Zeising from comment #11) I am trying to understand the concern with the patch that disables things that are already built by mesa-libs (upon which this port depends). If this port (mesa-dri) somehow built egl, gles2, glx differently than the mesa-libs port, then wouldn't it be worse to build against one version and than have a run-time link against the other? I am inclined to think that it would be safer to not build them and force the mesa-dri build to referennce headers and link to libs that are part of the mesa-libs package. The build time improvement is less important of course. The QA admonishment is a little more important. But I think it's probably best to build against a consistent set of mesa libs & headers.
*** Bug 246810 has been marked as a duplicate of this bug. ***
lang/python27 support was dropped in ports r537998.