LGTM, approved!

good to go, approved!

LGTM

In the past we have done exp-runs to be sure when updating xorgproto. Even if the change set is small, it is probably a good idea to do that here as well, since this port has a lot of direct and indirect dependencies.

LGTM

LGTM

I have no objections to this, as long as the default is to install all firmware, to avoid confusion for users.

Please do an exp-run before this goes in. At least mesa ports provide their own endian stuff in some cases and should be checked that they still are OK.

@danfe maintains seexpr, so pass this to him.

Fix the comment above, and this is good to go.

LGTM, thanks for doing this!

Thanks for looking into this!
Just two questions above.

In D30930#696470, @evgeniy_khramtsov.org wrote:

Per discussion with x11@ libglvnd will be the only GL provider supported by ports.

Context missing; is there a log of the discussion?

There is no direct log, PRs and reviews were used to record decisions or needs for discussion

Seems like this was discussed somewhere else, mind providing links to these discussions?

It was my first meeting.

There is a lack of transparency here.

I would like upstream to at least comment on the MR before we merge it into the FreeBSD ports tree.

Sorry, thought I'd approved this already.

In D30203#678978, @jbeich wrote:

Have you checked that the xorg stack builds with this change?

libX11/xorgproto have plenty of consumers outside of X.org stack, total around 2219 ports. I've asked for exp-run in bug 255771 but you may need to approve in advance, so it doesn't end up like bug 246767.

Looks good!

Looks good

Looks good!

Have you checked that the xorg stack builds with this change?

Have you checked that the xorg stack builds with this change?

LGTM

This seems to create a lot of complexity for very little gain.
Normally, we have the -devel ports beside the regular ports, without having what is basically a meta port that acts as a slave port to *both* the -devel and release version.

@mat already gave you feedback which you haven't acted on. I agree with him that you need a good __FreeBSD_version for FreeBSD 12, probably the next bump after the relevant change went into base. If no such bump has happened yet, it is easy enough to ask for it.
You also need to bump portrevision. Even if the packages will be rebuilt by poudriere on OSVERSION bumps, they will normally not be reinstalled in such case.

Looks good.
I see upstream has switched things around a bit...
Thanks for doing this!

And thanks for taking the time to create a phab diff for me. :)

If it requires updates to drm-current-kmod and drm-devel-kmod, as well as might cause binary breakage, then it shouldn't be MFCd. We have enough trouble already with drm-kmod breaking between minor releases and in stable.

Why do we need a __FreeBSD_version bump? Especially if it is also slated for MFC?

I am wary about changing FONTDIR, it might be used elsewhere, there are references to such a variable in other places in the ports tree, but I don't have time to investigate those further right now.
Apart from the USES=metaport change, this feels like it is mostly churn for no apparent benefit.

In D26682#596061, @manu wrote:

In D26682#595808, @zeising wrote:

A few things, small nits.
What happened with the TLS (thread local storage) stuff? I know we talked about it, but I don't remember the result of the discussion. It looks like the patches to disable it has been removed locally. Are they added upstream or are we enabling TLS stuff now?

TLS is always disabled for us.
I'm not against enabling it for some version of FreeBSD but I need to test first (and on multiple arches too) so it's easier to leave it disabled for now.
See https://gitlab.freedesktop.org/mesa/mesa/-/blob/20.2/meson.build#L425

Two small nits, but this looks good.
I haven't yet had time to test on 12.1 and 11.4.
Reviewed-by: zeising

You also need to change the rename of xatracker in x11-drivers/xf86-video-vmware. Something like the attached should work.

A few things, small nits.
What happened with the TLS (thread local storage) stuff? I know we talked about it, but I don't remember the result of the discussion. It looks like the patches to disable it has been removed locally. Are they added upstream or are we enabling TLS stuff now?

Abandoning this, since these changes should be superseded by the update of xserver to 1.20.

A couple of things I found after looking briefly (and also from your WIP patch at some point). I'll do a more throughout check later in the week.

In D26535#590765, @emaste wrote:

Tag clusteradm too - do we have details about DNS changes for these mirrors?

As a side note, it might be good to add the CDN we have, and perhaps switch from ftp:// to http(s):// where it's available.

Libepoxy is some glue library, and it had an explicit dep on glesv2, so I thought it might do things with glesv1 as well. I just wanted to be sure.

Mabye put a NOT_FOR_ARCHS=sparc64 and NOT_FOR_ARCHS_REASON=not supported or something in mesa-dri/Makefile.common. Just in case someone is brave enough to try building this on sparc64.

Also, portmgr is blocking review because changes to Mk/, but Mk/Uses/gl.mk is x11@ responsibility, so it should be OK.

Can you double check that graphics/libepoxy doesn't need updating as well. Just build it in poudriere with this change to mesa and see if it works.
Looking good otherwise.

In D26450#588478, @imp wrote:

In D26450#588410, @zeising wrote:

You probably want to remove tools/build/options/WITHOUT_APM since that option is gone and update tools/build/options/WITHOUT_ACPI to indicate that it also governs the installation of the apm(8) userland utility. OptionalObsoleteFiles.inc probably need to take this into account also.

WITHOUT_APM already is on the remove list. OptionalObsoleteFiles has been updated. Please check to make sure it's been correctly updated. I've not re-run the script that generates src.conf.5, though.

You need to remove the .Xr to apmd(8) from rc.conf(5) and acpiconf(8) as well, and references to apm(4) from apm(8).

You probably want to remove tools/build/options/WITHOUT_APM since that option is gone and update tools/build/options/WITHOUT_ACPI to indicate that it also governs the installation of the apm(8) userland utility. OptionalObsoleteFiles.inc probably need to take this into account also.

Small nit.
Looking good otherwise.