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.

Awesome! Great work!

Ran it through my poudriere setup withot any issues.

In D26367#586347, @manu wrote:

In D26367#586341, @zeising wrote:

One small nit above, nothing important.

As a side note, I wonder if we really should keep the SOURCE option enabled, it has caused issues in the past when people first do a buildkernel (with the old sources) and then update ports and think they have the new stuff, while still loading the old module built with buildkernel.

Well, installing the source will always causes problems when you update ports/package after building kernel but can help (sometimes) if nothing in base breaks building the module but it needs to be recompiled. It's the best solution that we have right now.

One more thing, can you update the version check in graphics/drm-kmod/Makefile as well?

One small nit above, nothing important.

In D26371#586337, @arichardson wrote:

I'm not very familiar with the ports workflow and am not sure if I have commit access, so if someone could commit this for me that would reduce the chance of me messing up.

I tested building this locally using make clean all.

@arichardson I'm not sure that is enough, there might be ports that include bsd.lib.mk from Makefiles in their respective tarballs.

Note, I haven't test built this, I trust that you've given it a spin in poudriere or similar.

You might want to bump portrevision as well, just to be sure.

In D26044#585469, @arichardson wrote:

I think this is unlikely to break anything other than duplicated sources so I was planning to commit it on Monday. @imp is this okay or should I ask for an exprun?