- User Since
- May 7 2015, 2:41 AM (215 w, 6 d)
Update patch again.
Move things around in Uses/autoreconf.mk to check for libtool things later. Uses/autoreconf.mk checks if libtool is being used, by checking libtool_ARGS, and if it's set, add a dependency on libtoolize. Move this check later, in the POSTMKINCLUDED phase, to avoid issues where we're hitting autoreconf before setting libtool_ARGS, and then not bringing in libtoolize.
Updated diff based on comments from @mat
Mon, Jun 24
Sun, Jun 23
Updated based on comments from @tobik .
Thank you very much for the review @tobik !
I think I've fixed everything, I'm just going to do a local smoke test, and then I'll update the patch in phabricator as well.
Sat, Jun 22
Some notes about the patch: Uses/xorg.mk and possibly Uses/xorg-cat.mk will be copied from bsd.xorg.mk using svn cp or svn mv as needed. Current patch is pulled from our git repo with rename detection turned off when generating the patch.
Mon, Jun 17
Sun, Jun 16
Updates based on comments from @imp and some wordsmithing.
One minor nit, otherwise you're good to go.
Sat, Jun 15
Fixes based on comments from @bcr .
mandoc -Tlint complains a lot about useless macro: Tn for all the .Tn PCI. This style is all over the file, and should probably be changed in a separate pass.
I assume you've run it through poudriere to ensure it builds and packages OK.
should libxatracker be made amd64 and i386 only? I assume it's only relevant for those architectures.
Mon, Jun 10
Tue, Jun 4
I think editing xf86-input-mouse is the better option as well.
This is for current only, where changes to the drivers has been made as well, and evdev is the default. Which version of FreeBSD are you using? Can you provide logs, and output from libinput list-devices.
Also enable trackpad support by default.
Mon, Jun 3
May 24 2019
May 23 2019
May 22 2019
May 21 2019
May 20 2019
May 19 2019
May 16 2019
This has been running fine during the night. From a graphics drivers no apparent regressions are visible, from light testing.
May 15 2019
Running the latest version of this patch on top of r347562M.
Machine boots and graphics comes up no problems, this with the built in Intel graphics in i7-3520M.
I'll leave the machine running during the night, in case something happens.
What is remaining in this review?
May 7 2019
I'll give this a spin and look for regressions in graphics land, but it might take a day or two. Can you add x11 as group reviewer?
May 3 2019
This is still running fine from a graphics perspective.
DRM has been broken for some time now, what's needed to get this in?
May 2 2019
I've been running the new version of the patch for about 2 hours without any graphics issues. I'll let the computer run through the night.
May 1 2019
I've had further success stories graphics wise, and my laptop is still running, so from a graphics perspective, this is good to go.
I've been running this for about 8 hours, on a mostly idle laptop with Firefox running, so far so good. I would like to give the reporters on the mailing list some time to test as well, since the hang is very random (I might have been lucky). I'll keep running the patch though.
Apr 30 2019
Apr 29 2019
Is this related to the recent graphics GPU hungs, or is this another issue?
Just checking so that I know what to look for.
Apr 27 2019
In general, I'm not sure -devel ports are usually slave ports, slave ports are more often to have ports with different options, such as nox11 variants. You also need to check with the owner of the original port for approval, since you're touching that one. You also need do add CONFLICTS since I assume both ports can't be installed at the same time (installing things in the same place).