Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 728290 - x11-drivers/nvidia-drivers:0/340 removal
Summary: x11-drivers/nvidia-drivers:0/340 removal
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Jeroen Roovers (RETIRED)
URL:
Whiteboard:
Keywords: PMASKED
Depends on:
Blocks: 728284 728286
  Show dependency tree
 
Reported: 2020-06-14 21:44 UTC by Matt Turner
Modified: 2020-09-13 10:54 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Matt Turner gentoo-dev 2020-06-14 21:44:08 UTC
The 340 branch has reached the end of its life and is receiving no more updates from NVIDIA. This version does not have support for libglvnd and still requires eselect-opencl.

Please tree clean.
Comment 1 Ionen Wolkens gentoo-dev 2020-06-15 02:40:24 UTC
I personally don't mind either way but seeing how often it comes up in support, I believe it still a decent amount of users and could wait until it's actually broken (aka no longer work with new xorg or current LTS kernel), or whenever eselect-opengl gets removed (although 390's support for libglvnd is still in a semi-broken state, and 430's ebuild is missing it)

For the matter of eselect-opencl, the original proposed patches did migrate 340 to virtual/opencl but I'm not sure why it was never committed.
https://archives.gentoo.org/gentoo-dev/message/9c2da71a159d860aea32ff2b1300ae84

I do believe anyone still using such old cards might as well use nouveau though.
Comment 2 Peter Gantner (a.k.a. nephros) 2020-06-22 15:51:27 UTC
Please don't if at all possible.

Plenty of laptops do not have the option to upgrade GFX hardware, and are working fine. There's other things like HTPCs which are stuck on older hw.

Nouveau still is not nearly on par wrt. 3D and video acceleration.
Comment 3 Adrien Tougas 2020-06-25 17:48:58 UTC
I second Peter's request.

Another thing to keep in mind is that not all applications support nouveau drivers. Autodesk's Maya works fine with the nvidia driver, but does not recognize the nouveau drivers at all.
Comment 4 Shiba 2020-07-13 16:23:30 UTC
Me too, old laptop. Switching to Nouveau would mean poor performance, bad battery life and no VDPAU.
Comment 5 Matt Turner gentoo-dev 2020-08-11 19:40:26 UTC
I would like to proceed with removal of :340. It's the only blocker to the removal of both eselect-opengl and eselect-opencl, which will enable quite a few clean ups.

To the users of :340 -- I'm sorry. There's not much I can do. I asked NVIDIA if they would make a new :340 release with libglvnd support and the answer was an unequivocal no:

> <mattst88> | aaronp: funny question... what are the chances of a 340-series driver release that supports libglvnd?
>   <aaronp> | 0%, 340 is EOL. Sorry.

It's not my objective to make things more difficult for you. This is inevitably what happens with proprietary drivers. Please remember that the next time you purchase hardware.

I suggest moving this version to an overlay.
Comment 6 Eric F. GARIOUD 2020-08-11 23:01:21 UTC
(In reply to Matt Turner from comment #5)
> I would like to proceed with removal of :340.

You already said that!

> It's the only blocker to the removal of both eselect-opengl and eselect-opencl, which will enable quite a few clean ups.

Could you precisely list them ?

> It's not my objective to make things more difficult for you.

Is'nt it the least we can expect from a gentoo dev ?

> This is
> inevitably what happens with proprietary drivers. Please remember that the
> next time you purchase hardware.

Linux kernel wisely keeps **much** older and **unsupported** drivers than 340 is.

Would **you** please, remember that, if **your** system does not support **my** hardware... I'll look for other systems supporting it.

I followed BSD since 4.2 up to freebsd 3. With V4, when removing the BKL, they stopped supporting ATM_CORE. I needed ATM... jumped to Gentoo!
Gentoo stops supporting my hardware when Debian does ? Ha...

Honestly! What is the point of removing whatever unsupported package that... does not need any support from upstream because it just runs troublefree ?

OK, I acknowledge that some gentoo dev did his very best to break it these last weeks.
  
> I suggest moving this version to an overlay.

Done!
Comment 7 Matt Turner gentoo-dev 2020-08-11 23:23:06 UTC
(In reply to Eric F. GARIOUD from comment #6)
> (In reply to Matt Turner from comment #5)
> > I would like to proceed with removal of :340.
> 
> You already said that!

I'm sure this is going to be a productive and level headed comment...

> > It's the only blocker to the removal of both eselect-opengl and eselect-opencl, which will enable quite a few clean ups.
> 
> Could you precisely list them ?

Bugzilla can. Click the 'tree' link in "Show dependency tree" above.

> > It's not my objective to make things more difficult for you.
> 
> Is'nt it the least we can expect from a gentoo dev ?
> 
> > This is
> > inevitably what happens with proprietary drivers. Please remember that the
> > next time you purchase hardware.
> 
> Linux kernel wisely keeps **much** older and **unsupported** drivers than
> 340 is.

What is your point? Those drivers are open source. A binary blob driver that supports a fixed set of Linux kernel versions and Xserver versions cannot possibly be kept as a supported option in the same way as a free software driver.

> Would **you** please, remember that, if **your** system does not support
> **my** hardware... I'll look for other systems supporting it.
>
> I followed BSD since 4.2 up to freebsd 3. With V4, when removing the BKL,
> they stopped supporting ATM_CORE. I needed ATM... jumped to Gentoo!
> Gentoo stops supporting my hardware when Debian does ? Ha...
> 
> Honestly! What is the point of removing whatever unsupported package that...
> does not need any support from upstream because it just runs troublefree ?

To be frank, this comment indicates to me that you're the exact kind of user that I don't want to support.

For the benefit of anyone else reading that has a minimal amount of emotional intelligence, the issue with keeping nvidia-drivers-340 in the tree is that it prevents long-planned clean ups of the distribution. Keeping a binary driver in the distribution isn't the issue. It's that it requires keeping a lot of *other* infrastructure in the distribution (eselect-opengl and eselect-opencl specifically) and those are full of bugs.

Again, I'm sorry that this has to happen, but I can't really accept the blame. It's a proprietary driver and the maker has decided to stop supporting it. If you want to be angry at someone, be angry at them, or perhaps acknowledge that you had all the information to predict this obvious outcome when you chose to purchase this hardware.

> > I suggest moving this version to an overlay.
> 
> Done!

FWIW, you'll need to take a few other packages and patches as well. Namely:

app-eselect/eselect-opencl
app-eselect/eselect-opencl
media-libs/mesa with USE=-libglvnd
x11-base/xorg-server USE=-libglvnd and with xorg-server-1.18-support-multiple-Files-sections.patch applied
Comment 8 Larry the Git Cow gentoo-dev 2020-08-11 23:24:51 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5fbfca46389144b136430e7ff235c075282f9be9

commit 5fbfca46389144b136430e7ff235c075282f9be9
Author:     Matt Turner <mattst88@gentoo.org>
AuthorDate: 2020-08-11 21:30:27 +0000
Commit:     Matt Turner <mattst88@gentoo.org>
CommitDate: 2020-08-11 23:24:24 +0000

    profiles: Mask x11-drivers/nvidia-drivers:0/340 for removal
    
    Bug: https://bugs.gentoo.org/728290
    Signed-off-by: Matt Turner <mattst88@gentoo.org>

 profiles/package.mask | 6 ++++++
 1 file changed, 6 insertions(+)
Comment 9 Bug Bugs 2020-08-12 03:45:50 UTC
(In reply to Matt Turner from comment #7)
> FWIW, you'll need to take a few other packages and patches as well. Namely:
> 
> app-eselect/eselect-opencl
> app-eselect/eselect-opencl
> media-libs/mesa with USE=-libglvnd
> x11-base/xorg-server USE=-libglvnd and with
> xorg-server-1.18-support-multiple-Files-sections.patch applied

Also FWIW, blob-only systems actually do not require media-libs/mesa. I experimented a bit and replaced every media-libs/mesa[egl,...] (or so) dependency for every installed package with media-libs/libglvnd, was able to completely remove media-libs/mesa and successfully rebuild all modified ones.

So, maybe even possible to use media-libs/libglvnd for x11-drivers/nvidia-drivers:0/340 with minimum modifications, but older x11-base/xorg-server version requirement will (likely) be the problem.
Comment 10 Matt Turner gentoo-dev 2020-08-12 04:01:54 UTC
(In reply to Bug Bugs from comment #9)
> (In reply to Matt Turner from comment #7)
> > FWIW, you'll need to take a few other packages and patches as well. Namely:
> > 
> > app-eselect/eselect-opencl
> > app-eselect/eselect-opencl
> > media-libs/mesa with USE=-libglvnd
> > x11-base/xorg-server USE=-libglvnd and with
> > xorg-server-1.18-support-multiple-Files-sections.patch applied
> 
> Also FWIW, blob-only systems actually do not require media-libs/mesa. I
> experimented a bit and replaced every media-libs/mesa[egl,...] (or so)
> dependency for every installed package with media-libs/libglvnd, was able to
> completely remove media-libs/mesa and successfully rebuild all modified ones.
> 
> So, maybe even possible to use media-libs/libglvnd for
> x11-drivers/nvidia-drivers:0/340 with minimum modifications, but older
> x11-base/xorg-server version requirement will (likely) be the problem.

Right. If someone interested in nvidia-drivers had ever bothered to sort out bug 301337, media-libs/mesa might not even be necessary on nvidia systems. But that never happened, and libglvnd is here now. :)
Comment 11 Ionen Wolkens gentoo-dev 2020-08-12 07:16:39 UTC
Unfortunate to see 340 go early. It was inevitable given EOL eventually but I hoped it'd stick around until it's really unusable rather than just to cleanup. Not that I don't understand wanting all this blockers nonsense away.

While inferior/limited, nouveau can keep old nvidia hardware alive with far less headaches, so I suggest people go that direction if not replacing the hardware.

Eventually new kernel/xorg will break 340 completely (like yet older drivers) and nvidia won't update it, so even overlays won't easily save it.

(In reply to Matt Turner from comment #10)
> Right. If someone interested in nvidia-drivers had ever bothered to sort out
> bug 301337, media-libs/mesa might not even be necessary on nvidia systems.
> But that never happened, and libglvnd is here now. :)
I've had media-libs/mesa in package.provided for a while and isn't installed. The only problem I've had, which I worked around, is that xorg-server still wanted a single header file from it (dri_interface.h), otherwise libglvnd+nvidia-drivers provides everything needed and together act as a mesa alternative which nothing properly depends on :( This also led to the glapi errors when switching to libglvnd given portage thought it was okay to rebuild nvidia-drivers last. Ah well.

Note to others reading: don't expect support if doing the same, just keep mesa.
Comment 12 Jeremy Drake 2020-08-16 05:06:31 UTC
(In reply to Matt Turner from comment #7)
> Again, I'm sorry that this has to happen, but I can't really accept the
> blame. It's a proprietary driver and the maker has decided to stop
> supporting it. If you want to be angry at someone, be angry at them, or
> perhaps acknowledge that you had all the information to predict this obvious
> outcome when you chose to purchase this hardware.

What I failed to predict was that graphics hardware would fail to progress enough, and prices would remain high enough, that I wouldn't feel the need to upgrade it in 10+ years. :)

> > > I suggest moving this version to an overlay.
> > 
> > Done!
> 
> FWIW, you'll need to take a few other packages and patches as well. Namely:
> 
> app-eselect/eselect-opencl
> app-eselect/eselect-opencl
> media-libs/mesa with USE=-libglvnd
> x11-base/xorg-server USE=-libglvnd and with
> xorg-server-1.18-support-multiple-Files-sections.patch applied

Where can this overlay be found?  I just took a look at layman -L and didn't see anything that screamed 'old nvidia drivers' to me.
Comment 13 Shiba 2020-08-18 18:44:19 UTC
I'm trying to get a hold on this, so please correct me if I'm wrong: nvidia-drivers-340 can coexist installed (as in no file collisions) with both media-libs/mesa[libglvnd] and media-libs/libglvnd. I don't have a full insight into how this actually works, but doesn't that mean that the only thing needed to make nvidia-drivers-340 work at runtime is the /etc/env.d/000opengl with LDPATH pointing at Nvidia's OpenGL created by eselect-opengl?

What I mean is: if eselect-opengl is simply dropped from nvidia-drivers-340 dependencies and I manually write that file, would everything work exactly as it is working now?

I don't know how to handle the opencl situation because I never used it, but at a quick glance it seems unrelated to libglvnd.

I also need to look at that xorg-server patch, but one thing at a time :D
Comment 14 Denis Tokarev 2020-09-03 10:58:36 UTC
A lot has been going on with the graphical packages the last weeks, so I'm not sure what is the current status, but I'd like to vote against this removal.
I have a 10 years old laptop that has been running gentoo that whole time and I'd expect a distribution that compiles everything to keep enabling this hardware, although unsupported, with some use flags magic.
This removal is not the gentoo way.
Comment 15 Ionen Wolkens gentoo-dev 2020-09-03 19:20:05 UTC
(In reply to Jeremy Drake from comment #12)
> Where can this overlay be found?  I just took a look at layman -L and didn't
> see anything that screamed 'old nvidia drivers' to me.
If really need to keep using 340 and/or eselect-opengl, then this overlay is probably the best option right now:
https://github.com/achurch/noglvnd

Mentioned on the forums too. May be better to keep overlay discussions regarding that there rather than bug tracker.
https://forums.gentoo.org/viewtopic-t-1117500.html
Comment 16 Shiba 2020-09-05 15:27:47 UTC
I only recently got time to setup a separate Gentoo partition to tinker with this and my conclusion is that nvidia 340 doesn't necessarily need to depend on the eselects. Here's what I did.

without eselect-opengl:
Configuration must be done manually.
We need the content of /etc/X11/xorg.conf.d/20opengl.conf and /etc/env.d/000opengl (the LDPATH line), then launch env-update to rebuild the shared libraries cache.

without eselect-opencl:
Seems to work fine with virtual/opencl, at least according to dev-util/clinfo. I don't know how to properly test OpenCL, but if you point me in the right direction I can do it for you.

about the xorg-server patch:
Only really needed for eselect-opengl.

My proposal is to release an -r2 dropping the eselects and update the nvidia-drivers wiki page with instructions to manually set Nvidia OpenGL for 340 (and maybe a post-upgrade message pointing at it). This way nvidia-drivers-340 doesn't get in the way of the planned Gentoo changes.

If that is done, since 340 should work fine at least until kernel-5.4 or xorg-server-1.20 are removed, I don't see any remaining reasons to get rid of it right now. As I already implied obviously the time will come, but such a disruptive change should be postponed until there really is no other way.
Comment 17 Shiba 2020-09-10 19:44:40 UTC
Since this bug report seems to be ignored, I opened a new one with my proposed solution: https://bugs.gentoo.org/741556
Comment 18 Jeroen Roovers (RETIRED) gentoo-dev 2020-09-10 20:25:55 UTC
*** Bug 741556 has been marked as a duplicate of this bug. ***
Comment 19 Piotr Karbowski (RETIRED) gentoo-dev 2020-09-12 20:41:30 UTC
commit bef5caa454213db9386868aba8dfe11bdb719e5d (HEAD -> master, origin/master, origin/HEAD)
Author: Piotr Karbowski <slashbeast@gentoo.org>
Date:   2020-09-12 22:39:18 +0200

    x11-drivers/nvidia-drivers: 340 series tree clean.
    
    Signed-off-by: Piotr Karbowski <slashbeast@gentoo.org>