Created attachment 244353 [details] x11/nvidia-driver, x11/linux-nvidia-libs: update to 535.104.05
ashafer, can you decouple the nvidia-drm-kmod port from your personal github. Will it merge into the distributed tarball? It looks like it should live as part of nvidia-driver.
Populated a 535.104.05 branch in github, I can update the distinfos for the nvidia-drm ports tomorrow unless you want that to be part of this update. What exactly did you have in mind with "decouple"? Unfortunately there is a bit of an annoying process copying files from the Linux release and replaying patches onto the distributed tarball to get a working nvidia-drm, which is why it's coupled this way. I find this works best in git since it's easy to keep track of what's been applied and half automate it. That being said I am (slowly) working on getting this merged into the regular distribution to avoid this problem. I agree it isn't ideal, but it lets me handle the significant churn in patches in an organized way. See: https://github.com/amshafer/nvidia-driver/blob/baseline/UPDATING.md and populate_driver.sh Note two related reviews: - https://reviews.freebsd.org/D41591 (the PRIME fix in this one is included in the 535.104.05 branch, so this is really just a Makefile update now) - https://reviews.freebsd.org/D41574
What I mean by decoupling is now all driver updates are coupled on your personal github repo. This is a regression. The patches should live in the ports tree in the nvidia-drm directory. How you generate them can use whatever tooling you want, but applying them is a simple matter and hopefully wouldn't need much for a simple bump like this.
Created attachment 244394 [details] x11/nvidia-driver, x11/linux-nvidia-libs: update to 535.104.05 Regen nvidia-drm distinfo
Created attachment 244396 [details] x11/nvidia-driver, x11/linux-nvidia-libs, nvidia-drm-*-kmod: update to 535.104.05 Regen
Ah I see what you mean. I'll take a stab at moving things into the ports tree. Are you wanting the patches to be part of x11/nvidia-driver then? I would prefer if they stayed separate in a nvidia-drm-kmod port, mostly to signify that they are an unofficial extension of the base driver and not something shipped by NVIDIA (at the moment). It would still remove the dependence on my github and hopefully allow for easier version bumps.
(In reply to Austin Shafer from comment #6) I agree with Austin here. I use nivida-driver but don't have the linuxkpi enabled and don't want to be forced to do that due to the nvidia-drm-kmod becoming in some way part of the driver. However, if the nvidia-drm-kmod can be disabled in the driver I wouldn't have a big problem with it.
(In reply to Austin Shafer from comment #6) > I would prefer if they stayed separate in a nvidia-drm-kmod port I concur, our official driver ports are convoluted enough already, let's keep them clean of this newish DRM stuff. Update itself looks fine.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=a3727749f7d3bae98a0ab72d672c890cbf73c7a5 commit a3727749f7d3bae98a0ab72d672c890cbf73c7a5 Author: Kevin Bowling <kbowling@FreeBSD.org> AuthorDate: 2023-09-08 18:12:08 +0000 Commit: Kevin Bowling <kbowling@FreeBSD.org> CommitDate: 2023-09-08 18:12:08 +0000 x11/nvidia-driver, x11/linux-nvidia-libs, nvidia-drm-*-kmod: update to 535.104.05 PR: 273357 Approved by: danfe graphics/nvidia-drm-510-kmod/Makefile | 1 - graphics/nvidia-drm-510-kmod/distinfo | 6 +++--- graphics/nvidia-drm-515-kmod/Makefile | 1 - graphics/nvidia-drm-515-kmod/distinfo | 6 +++--- x11/linux-nvidia-libs/distinfo | 6 +++--- x11/nvidia-driver/Makefile.version | 2 +- x11/nvidia-driver/distinfo | 6 +++--- 7 files changed, 13 insertions(+), 15 deletions(-)
Slight potential for confusion with 535.98 still shown for the meta port that installs nvidia-drm-510-kmod 535.104.05. <https://www.freshports.org/graphics/nvidia-drm-kmod/> I'm inclined to treat this as negligible – I do understand why it's not strictly necessary to bump the meta port. NVIDIA aside, meta port <https://www.freshports.org/graphics/drm-kmod/> uses a date-oriented versioning scheme.
Hm I had used NVIDIA_DISTVERSION thinking the metaport would also get rebuilt and pick up the new version string. If that isn't happening then yes maybe a date-based version would make more sense.
(In reply to Austin Shafer from comment #11) It is something wrong with the third party site, not the meta port.