Bug 239939 - graphics/mesa-dri: switch to default python version for build
Summary: graphics/mesa-dri: switch to default python version for build
Status: Closed Overcome By Events
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Many People
Assignee: freebsd-x11 (Nobody)
URL:
Keywords:
: 246810 (view as bug list)
Depends on:
Blocks:
 
Reported: 2019-08-18 13:09 UTC by Vladimir Druzenko
Modified: 2020-06-26 20:21 UTC (History)
9 users (show)

See Also:
koobs: maintainer-feedback+


Attachments
Switch to default python version for build (349 bytes, patch)
2019-08-18 13:09 UTC, Vladimir Druzenko
koobs: maintainer-approval-
Details | Diff
[patch] fix stage-qa findings & speed up the build a bit (3.49 KB, patch)
2020-03-23 21:31 UTC, John Hein
koobs: maintainer-approval-
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Vladimir Druzenko freebsd_committer freebsd_triage 2019-08-18 13:09:26 UTC
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.
Comment 1 Dimitry Andric freebsd_committer freebsd_triage 2019-09-17 17:16:21 UTC
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.
Comment 2 Dimitry Andric freebsd_committer freebsd_triage 2019-09-17 17:18:52 UTC
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
Comment 3 Niclas Zeising freebsd_committer freebsd_triage 2019-09-17 18:38:04 UTC
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.
Comment 4 Vladimir Druzenko freebsd_committer freebsd_triage 2019-09-18 00:01:32 UTC
(In reply to Niclas Zeising from comment #3)
I removed python27 and mesa rebuild fine.
Comment 5 Vladimir Druzenko freebsd_committer freebsd_triage 2020-02-23 20:29:13 UTC
Does this patch have any problems?
If no - commit it, please.
Comment 6 rsmith 2020-03-03 06:29:45 UTC
I applied the same patch when building mesa-libs 19.0.8, and it works fine.
Comment 7 rsmith 2020-03-03 06:30:26 UTC
(In reply to rsmith from comment #6)

mesa-dri and mesa-libs, that is.
Comment 8 John Hein 2020-03-18 20:03:38 UTC
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
Comment 9 John Hein 2020-03-23 21:31:49 UTC
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.
Comment 10 robbak 2020-04-28 00:05:02 UTC
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.
Comment 11 Niclas Zeising freebsd_committer freebsd_triage 2020-04-28 06:23:58 UTC
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 12 Kubilay Kocak freebsd_committer freebsd_triage 2020-04-28 07:56:31 UTC
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 13 Kubilay Kocak freebsd_committer freebsd_triage 2020-04-28 07:56:46 UTC
Comment on attachment 206658 [details]
Switch to default python version for build

^Triage: User maintainer-approval flag to signify approval (or not)
Comment 14 Kubilay Kocak freebsd_committer freebsd_triage 2020-04-28 07:58:22 UTC
^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.
Comment 15 robbak 2020-05-01 02:54:18 UTC
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.
Comment 16 Niclas Zeising freebsd_committer freebsd_triage 2020-05-01 16:27:37 UTC
(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.
Comment 17 John Hein 2020-05-06 20:11:09 UTC
(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.
Comment 18 Jan Beich freebsd_committer freebsd_triage 2020-06-26 20:17:11 UTC
*** Bug 246810 has been marked as a duplicate of this bug. ***
Comment 19 Jan Beich freebsd_committer freebsd_triage 2020-06-26 20:21:36 UTC
lang/python27 support was dropped in ports r537998.