Differential D7569
x11/nvidia-driver: Update to 367.35 Authored by cem on Aug 18 2016, 6:42 PM. Tags None Referenced Files
Details
The ancient version of Nvidia driver in ports is holding back more recent Xorg A patch to update the port has been submitted and tested. It just needs to be Maintainer has not responded for 13 months as of yesterday, so I consider this The related PR is https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201340 . See also https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209951 . poudriere bulk -tC:
304 340 367.27
12amd64: success success success
12i386: success success success
101amd64:success success success
101i386: success success success
93amd64: spdylay requires OpenSSL 1.0.1+
93i386: spdylay requires OpenSSL 1.0.1+
Diff Detail
Event TimelineThere are a very large number of changes, so older changes are hidden. Show Older Changes Comment Actions This works for me on an GTX 560 Ti as well as before. I played an OpenGL-using game for about an hour to test. Comment Actions @cem While I understand this change has been tested, I note no test details in the TEST PLAN section detailing what/how was tested, and in order to actually provide substantive (not necessarily long) review rather than a cursory 'yeh it looks ok to me' Can you please
This will help provide the context for the change as a whole and allow reviewers to review intent against execution as well Edit: This is just the standard I set for myself when providing changes for other peoples ports, and what makes it simple/quick for me to review and put my (Reviewed/Approved by:) name to. Comment Actions As a side note, maintainer timeout is 14 days. When you reach 3 months, it's absent without leave, and the port's maintainership can be resetted. Comment Actions There is a material difference between doesn't respond on an bugzilla issue for 3 months and doesn't respond at all for 3 months. The documentation is ambiguous on this point [1]. If the former also applies, then a large proportion of our ports would have no maintainers based on that fact. Go and look in Bugzilla for ports issues that are assigned to *@freebsd accounts with last mod times greater than 3 months. You yourself would not have maintainership of nagios-plugins and tmux based on your argument and: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197193 Would you consider it rude if someone reset maintainership on those ports, or even suggested it was OK to do so, particularly if they knew you were active? Additionally, the fact that there is evidence that the maintainer is active, nullifies the option to use 'in absentia > 3 months' argument Further, independent to whether or not you dispute the points above, the maintainer should be on the review. Further, technicalities aside, and what is appreciably the most important thing, is the example your suggestion is setting for others, as a portmgr member. Please think about the impacts of what you post before you do so. [1] https://www.freebsd.org/doc/en/books/porters-handbook/makefile-maintainer.html Comment Actions Yes it should've been updated months ago. There were several things that I was (and still is) not happy about (the way it deals with libglx.so and libGL.so et al., and that it did not package under tinderbox) that held me back, sorry. One thing I'm unhappy about this patch that it's pretty huge. Do you mind if I first deorbit no longer needed legacy driver support and clean up Makefile and patches? Comment Actions Agreed.
I don't think so.
If you can do it *today*, ok. But I'm not happy to wait for any vague promise of cleanups, like has happened repeatedly in the bug. Comment Actions @danfe regarding the changing how the libglx / libGL etc are handled I'm all ears for any suggestions. Those changes should be a separate PR/review issue. Comment Actions @kwm of course; I have a half-baked patch ready that I wanted to eventually pass through you before updating nVidia driver, but never pushed myself far and hard enough to finish it. Since now updating the driver is the top priority, I'll hold it off and get back to you once we're done here. Comment Actions I believe I'm done for the night. Would you please rebase your patchset against the current tree? I realize it might require some work, but resulting patch should be significantly smaller, less cluttered, and thus easier to review. I like it in principal, but would probably add some inline comments. Thanks! Comment Actions Rebase the patch over r420482, r420490, r420496, r420499. I haven't had a chance to build or test it, but I've got to run for now.
Comment Actions Remove extra-patch x11/driver/Makefile.
Comment Actions Now it builds fine and running for stable/11 (r304528) and head (r304535), both amd64. Comment Actions @cem yes, I'm currently reviewing it. I want to make sure those newly added NVVERSION checks are accurate and thus have to download quite a few driver versions which takes a bit of time on my slow Internet connection. Meanwhile, have a look at in-place comments, thanks.
Comment Actions Thanks!
Comment Actions Fix issues noted by danfe@.
Comment Actions Two more inline comments, please address. I need to sleep now, and would rather review NVVERSION checks on the morrow. Should not take too long, the patch looks pretty good, but I want it to be nearly perfect. :-) Your comment on the modeset patch is just fine. It's good to keep all comments in one place (that is, port's Makefile).
Comment Actions Fix cap_rights_t OSVERSION check and make comment more specific and accurate.
Comment Actions Confirmed. Thanks! Build, install and run: 367.35
Build only: 364.19, 361.45.11, 361.42, 361.28, 358.16, 355.11, 352.79,
352.55, 352.41, 352.30, 352.21, 349.16, 346.72, 346.59
Comment Actions Works for me with a variant of 11-STABLE when I use nvidia-modeset. If I just try to use kldload nvidia by itself, however, I get strange artifacts and no visible X. Comment Actions I have couple of more inline comments, take a look. NVVERSION checks look accurate, I didn't check every single version in-between, but didn't encounter mismatches so far and I don't want to delay the progress further. Now, about the patches, I'd appreciate if you do the following prior to final commit (relative to files/):
Then apply changes to files paths (patch header) and minor context changes to extra-patch-src_nv-freebsd.h. Thanks!
Comment Actions Thanks. At least @junchoon_dec.sakura.ne.jp has tested every version, so it should be okay.
This was already done. :-)
Ok. Comment Actions
Comment Actions Let's just commit what we have tested now. Any remaining changes, small and big fixes (like new version update) should follow normally.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||