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?

Exclude ARM

This is mostly intended to be committed to 13 to be merged to 12.

Nice work!
How is the backlight adjustments exposed to users?
Do we need to change drm-current-kmod?

both freebsd-gcc6@amd64 and @i386 builds fine on amd64, @i386 also builds fine on i386. I didn't try @amd64 on i386, but I see no reason it shouldn't work.

I'm wrong in that you can remove char cupsfilter completely from options.c, I misread the code the first time.

So, I've just had a quick look at the code.
char cupsfilter is defined in foomaticrip.c, and also options.c (which this patch changes). It is also declared in foomaticrip.h. I think it should be enough to remove it completely from options.c, since options.c includes foomaticrip.h.
I'm testing the build currently, but it will take a bit of time. I'll let you know once I'm done.