To get rid of strange dependencies and runtime errors in nvidia-settings the ebuild from nvidia-drivers should build nvidia-settings from source (like at the moment the extra ebuild 'nvidi-settings' does) when USE="tools" is set. Reproducible: Always
Patch welcome.
The alternative is that the nvidia-settings maintainers do a better job.
Obviously this is not happening. Nvidia-settings is frozen at media-video/nvidia-settings-358.16 and forcing x11-drivers/nvidia-drivers to stay at 358.16-r1. Is there any update on merging the two ebuilds?
I have had very little time, but I'll look into converting all those branches to produce useful tools and libraries from source.
Please try =x11-drivers/nvidia-drivers-361.18-r2 . If that's good, then I can start work on backporting that to the other branches. Adding maintainers of users of media-video/nvidia-settings: app-admin/conky mate-extra/mate-sensors-applet media-video/nvidia-settings sys-apps/hwloc xfce-extra/xfce4-sensors-plugin
(In reply to Jeroen Roovers from comment #5) > Please try =x11-drivers/nvidia-drivers-361.18-r2 . If that's good, then I > can start work on backporting that to the other branches. > > Adding maintainers of users of media-video/nvidia-settings: > > app-admin/conky > mate-extra/mate-sensors-applet > media-video/nvidia-settings > sys-apps/hwloc > xfce-extra/xfce4-sensors-plugin mate-extra/mate-sensors-applet compiles successfully with 361.18-r2. Let me know when you've updated the ebuilds and I'll adjust our deps to nvidia-drivers[tools]. Is there a point to keeping the standalone nvidia-settings at this point (with the ebuild now building nvidia-settings and providing NVCtrl), or does this mean that nvidia-settings will be deprecated/removed?
(In reply to NP-Hardass from comment #6) > mate-extra/mate-sensors-applet compiles successfully with 361.18-r2. Let me > know when you've updated the ebuilds and I'll adjust our deps to > nvidia-drivers[tools]. Great. I think you would need to depend on USE=static-libs too. > Is there a point to keeping the standalone nvidia-settings at this point Yes, because users need to make the switch and other ebuilds still depend on it _at this point_. > (with the ebuild now building nvidia-settings and providing NVCtrl), or does > this mean that nvidia-settings will be deprecated/removed? It should eventually be removed. Branches updated so far: nvidia-drivers-304.131-r1.ebuild nvidia-drivers-340.96-r2.ebuild nvidia-drivers-352.79-r1.ebuild nvidia-drivers-358.16-r2.ebuild nvidia-drivers-361.18-r2.ebuild
nvidia-drivers-346.96-r3.ebuild added.
Looks like nvidia-drivers 358.16-r1 was stabilized as part of this bug report, I want to object to that decision, as there is a known stability issue related to multithreaded gl, and appears to end users as general chaos, usually blaming libc. Affected versions are nvidia 358.* and 361.16 (fixed in 361.18). Regularly reproduced with steam-for-linux.
(In reply to Jeroen Roovers from comment #5) > Please try =x11-drivers/nvidia-drivers-361.18-r2 . If that's good, then I > can start work on backporting that to the other branches. I've installed nvidia-drivers-361.18-r2 and found a little issue: The path in nvidia-drivers-settings.desktop points to the wrong location (/opt/bin/nvidia-settings). Apart from that, great job! PS: Is there a reason why nvidia-settings is not stripped?
(In reply to kisak42 from comment #9) > Looks like nvidia-drivers 358.16-r1 was stabilized as part of this bug > report, No, it wasn't.
(In reply to Christian Strahl from comment #10) > (In reply to Jeroen Roovers from comment #5) > > Please try =x11-drivers/nvidia-drivers-361.18-r2 . If that's good, then I > > can start work on backporting that to the other branches. > > I've installed nvidia-drivers-361.18-r2 and found a little issue: The path > in nvidia-drivers-settings.desktop points to the wrong location > (/opt/bin/nvidia-settings). Thanks, I'll fix that. > PS: Is there a reason why nvidia-settings is not stripped? Portage strips it and if you care to configure it that way (FEATURES=split-debug), it drops the symbols into alternative files that are stored out of the way for debugging purposes.
(In reply to Jeroen Roovers from comment #5) > Please try =x11-drivers/nvidia-drivers-361.18-r2 . If that's good, then I > can start work on backporting that to the other branches. > > Adding maintainers of users of media-video/nvidia-settings: > > app-admin/conky > mate-extra/mate-sensors-applet > media-video/nvidia-settings > sys-apps/hwloc > xfce-extra/xfce4-sensors-plugin Thanks for your work. app-admin/conky requires x11-drivers/nvidia-drivers with USE="static-libs,tools". Can only do a compile test as I do not own a nvidia card.
(In reply to Jeroen Roovers from comment #5) > Adding maintainers of users of media-video/nvidia-settings: > > app-admin/conky > mate-extra/mate-sensors-applet > media-video/nvidia-settings > sys-apps/hwloc > xfce-extra/xfce4-sensors-plugin Thanks for the good work to finally solve this long-term issue! I think media-video/bino is missing from this list, though - it depends on nvidia-settings if VIDEO_CARDS="nvidia" and is what's currently blocking me from getting rid of nvidia-settings (apart from conky).
(In reply to Jeroen Roovers from comment #12) > Portage strips it and if you care to configure it that way > (FEATURES=split-debug), it drops the symbols into alternative files that are > stored out of the way for debugging purposes. I don't use split-debug, but nvidia-settings is not stripped: # file /usr/bin/nvidia-settings /usr/bin/nvidia-settings: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, not stripped
(In reply to Christian Strahl from comment #15) > (In reply to Jeroen Roovers from comment #12) > > Portage strips it and if you care to configure it that way > > (FEATURES=split-debug), it drops the symbols into alternative files that are > > stored out of the way for debugging purposes. > > I don't use split-debug, but nvidia-settings is not stripped: Right, that's because of RESTRICT=strip.
(In reply to Jeroen Roovers from comment #16) commit 6f6fb00f8e1e93b27679f1ccd1ac474fbd6dbdcc Author: Jeroen Roovers <jer@gentoo.org> Date: Sat Feb 13 14:51:06 2016 +0100 x11-drivers/nvidia-drivers: Remove RESTRICT=strip. Package-Manager: portage-2.2.27 x11-drivers/nvidia-drivers/nvidia-drivers-304.131-r4.ebuild | 488 +++++++++ x11-drivers/nvidia-drivers/nvidia-drivers-340.96-r5.ebuild | 517 +++++++++ x11-drivers/nvidia-drivers/nvidia-drivers-346.96-r6.ebuild | 528 +++++++++ x11-drivers/nvidia-drivers/nvidia-drivers-352.79-r4.ebuild | 527 +++++++++ x11-drivers/nvidia-drivers/nvidia-drivers-355.11-r4.ebuild | 500 +++++++++ x11-drivers/nvidia-drivers/nvidia-drivers-358.16-r5.ebuild | 539 ++++++++++ x11-drivers/nvidia-drivers/nvidia-drivers-361.28-r2.ebuild | 529 +++++++++ 7 files changed, 3628 insertions(+)
Is nvidia-settings package going to be removed? If we fix reverse packages RDEPENDs we are going to need to revbump them and, then, it would be interesting if we need to go for || ( ) dependencies for allowing nvidia-drivers AND nvidia-settings to fulfill the dep or, if nvidia-settings is going to die, we can go directly with RDEPENDing on nvidia-drivers alone. That would allow us to not need to revbump again in the future to drop the || () statements if nvidia-settings is going to disappear Thanks
(In reply to Pacho Ramos from comment #18) > Is nvidia-settings package going to be removed? x11-drivers/nvidia-drivers[tools,static-libs] blocks media-video/nvidia-settings so whatever happens to the latter, it's obsolete. > we can go directly with RDEPENDing on > nvidia-drivers alone. That would allow us to not need to revbump again in > the future to drop the || () statements if nvidia-settings is going to > disappear We do not yet have any x11-drivers/nvidia-drivers ebuilds stable that fully replace media-video/nvidia-settings. The switchover involves stabilising newer ebuilds of nvidia-drivers and packages that depend on nvidia-settings/libraries. Any help is welcome.
Wouldn't it be easier to add a temporary media-video/nvidia-settings metapackage that would pull in newer -drivers (and block only older versions)? This way you'd be able to stabilize drivers (+ settings meta) without having to match all revdeps at the same time.
(In reply to Michał Górny from comment #20) > Wouldn't it be easier to add a temporary media-video/nvidia-settings > metapackage that would pull in newer -drivers (and block only older > versions)? This way you'd be able to stabilize drivers (+ settings meta) > without having to match all revdeps at the same time. I don't know about easier. It's only a few packages that need to be updated + stabilised.
It looks like everything is in place for stabilisation: sys-apps/hwloc - bug #595656 app-admin/conky - bug #595652 mate-extra/mate-sensors-applet - already stable media-video/bino - bug #596818 sci-libs/vtk - bug #595654
