User Details
- User Since
- May 7 2015, 2:41 AM (496 w, 5 d)
Mar 30 2022
Feb 9 2022
Nov 10 2021
Nov 8 2021
Nov 1 2021
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.
Oct 18 2021
Oct 15 2021
I have no objections to this, as long as the default is to install all firmware, to avoid confusion for users.
Sep 17 2021
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.
Sep 6 2021
@danfe maintains seexpr, so pass this to him.
Aug 6 2021
Fix the comment above, and this is good to go.
Jul 19 2021
Jul 15 2021
Jul 9 2021
LGTM, thanks for doing this!
Jul 7 2021
Thanks for looking into this!
Just two questions above.
Jun 30 2021
Jun 25 2021
May 31 2021
I would like upstream to at least comment on the MR before we merge it into the FreeBSD ports tree.
May 28 2021
May 15 2021
Sorry, thought I'd approved this already.
May 13 2021
May 11 2021
Have you checked that the xorg stack builds with this change?
Have you checked that the xorg stack builds with this change?
Apr 14 2021
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.
Apr 4 2021
@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.
Mar 10 2021
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. :)
Jan 26 2021
Dec 26 2020
Dec 3 2020
Dec 1 2020
Nov 11 2020
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?
Oct 28 2020
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.
Oct 26 2020
Oct 25 2020
Oct 21 2020
Oct 13 2020
Oct 11 2020
Two small nits, but this looks good.
I haven't yet had time to test on 12.1 and 11.4.
Reviewed-by: zeising
Oct 9 2020
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?
Oct 5 2020
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.
Oct 3 2020
Sep 30 2020
Sep 29 2020
Sep 28 2020
Sep 26 2020
Sep 23 2020
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.
Sep 19 2020
Sep 18 2020
Sep 17 2020
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.
Sep 16 2020
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.