Currently nvidia-settings stable (180.60) refers to a lower version number than nvidi-drivers (190.42-r3). These won't work together and hence the combination of the two is not stable. Reproducible: Always Currently nvidia marks as certified on linux 190.53. Are there open issues that prevent us from going equal?
Please re-assign correctly to the nvidia-settings maintainer
*** Bug 313031 has been marked as a duplicate of this bug. ***
*** Bug 317075 has been marked as a duplicate of this bug. ***
As pointed out in the two duplicate bugs, =nvidia-settings-180* doesn't compile with >=nvidia-drivers-190 being installed. This affects mostly stable users as we don't have some >=nvidia-settings-190 stable.
(In reply to comment #4) Just to be clear: nvidia-settings 190 compiles well if unmasked (and works for me).
(In reply to comment #4) > As pointed out in the two duplicate bugs, =nvidia-settings-180* doesn't > compile with >=nvidia-drivers-190 being installed. This affects mostly > stable users as we don't have some >=nvidia-settings-190 stable. If I can ask a stupid question (obviously, there are a lot of things I don't understand), why does it take more than three months to mark a version 190* of nvidia-settings stable? No surprise that people (including myself) keep running into this bug.
(In reply to comment #6) > (In reply to comment #4) > > As pointed out in the two duplicate bugs, =nvidia-settings-180* doesn't > > compile with >=nvidia-drivers-190 being installed. This affects mostly > > stable users as we don't have some >=nvidia-settings-190 stable. > > If I can ask a stupid question (obviously, there are a lot of things I > don't understand), why does it take more than three months to mark a > version 190* of nvidia-settings stable? > > No surprise that people (including myself) keep running into this bug. > The real bug for stable users is, that nvidia-settings and nvidia-drivers MUST always match version number (in fact, nvidia distributes them as ONE package), so neither should be marked stable earlier than the other but both must always go stable together. If then gentoo decides to wait with marking stable newer versions, is less an issue as you can unmask them.
(In reply to comment #7) > The real bug for stable users is, that nvidia-settings and nvidia-drivers MUST > always match version number (in fact, nvidia distributes them as ONE package), > so neither should be marked stable earlier than the other but both must always > go stable together. If then gentoo decides to wait with marking stable newer > versions, is less an issue as you can unmask them. OK, let's talk about merging the two ebuilds.
Ok, just to clarify. nvidia-settings and nvidia-drivers don't need the match. nvidia-settings is rarely updated within a series (e.g. 190.x). The two talk through an NVIDIA defined protocol called NVCONTROL and everything works through that. Now that being said, in the before time, in the long long ago, nvidia-settings was installed by nvidia-drivers. But while I was on an extended absence someone got the bright idea to separate them out into their own ebuilds cause if it can be built in source by god it should be, or some other idealist crap. Then more recently when I attempted to remove nvidia-settings from the tree and have it installed via nvidia-drivers, I had a Gentoo developer tell me he could maintain the package better than myself (etc, etc, etc) then a few short months (maybe even weeks) later he's sending an e-mail to gentoo-dev saying he can't maintain it anymore if someone else will. I'm not the Gentoo community's personal IT guy about any and every issue they may have with their desktop experience. I maintain nvidia-drivers for one simple reason, I need it to work. I use their cards in every single one of my machines and I need their binary drivers. I would love for the day to happen that someone could come along and maintain it and do an outstanding job to the point that I can walk away from it and it will always just work for me. But unfortunately that hasn't happened yet. Additionally over the years, I've maintained a good relationship with the various guys working at NVIDIA on their UNIX platforms and that's honestly much of what my maintainership is, working with upstream to get code into the next package release. So basically in summary, nvidia-settings should go away and die, I completely agree. No, its not vital. Anyone can maintain nvidia-drivers as long as they do it right. I don't believe we should use nvidia-settings source package at all, just use the binary from the drivers package.
Created attachment 239113 [details, diff] Example patch against 173.14.27 Please remove nvidia-settings and change gtk USE flag handling in nvidia-drivers to install nvidia-settings (and pull gtk+ in RDEPEND). If someone is intersted in dealing with nvidia-settings alone (from source), one can do it in overlay. There's little point in having this package (often out of sync with corresponding driver release) maintained separately. Especially when it often fails to compile (like the one I was testing but I gave up - 173.24.27). Attached patch against nvidia-drivers-173.14.27 (it fixes missing cuda headers bug meanwhile). Applying it to other driver releases should be straighforward. Please proceed.
Created attachment 239115 [details, diff] nvidia-drivers-173.14.27 diff (fixed)
I just spent a good part of the afternoon trying to get nvidia-settings installed, because I wasn't aware of the changes introduced through this bug and after looking at my logs and at the ebuilds, I noticed that no one thought about adding a pkg_postinst message to nvidia-settings explaining that it no longer installs the executable nor to nvidia-drivers warning that to build nvidia-settings one has to enable the gtk use flag. I'm sure some people would like to read about this in the ebuild messages. If you want, I can attach a patch or commit an update to the tree adding the warnings.
I have fixed this for 96.43.19. I can't confirm the attached patch, though.
There are two packages involved, so no maintainer-needed is needed.
Comment on attachment 239115 [details, diff] nvidia-drivers-173.14.27 diff (fixed) This patch fails. Could you fix that? cvs/gentoo-x86/x11-drivers/nvidia-drivers $ wget 'https://bugs.gentoo.org/attachment.cgi?id=239115' -O - | patch -p0 --2011-04-09 17:49:01-- https://bugs.gentoo.org/attachment.cgi?id=239115 Resolving bugs.gentoo.org (bugs.gentoo.org)... 94.100.119.165 Connecting to bugs.gentoo.org (bugs.gentoo.org)|94.100.119.165|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 2952 (2.9K) [text/plain] Saving to: `STDOUT' 100%[==========================================================================================>] 2,952 --.-K/s in 0s 2011-04-09 17:49:01 (24.9 MB/s) - written to stdout [2952/2952] patching file nvidia-drivers-173.14.27.ebuild Hunk #5 FAILED at 335. 1 out of 6 hunks FAILED -- saving rejects to file nvidia-drivers-173.14.27.ebuild.rej cvs/gentoo-x86/x11-drivers/nvidia-drivers $ cat nvidia-drivers-173.14.27.ebuild.rej *************** *** 327,333 **** die "failed to create libXvMCNVIDIA.so symlink" # CUDA headers (driver to come) - if use kernel_linux; then dodir /usr/include/cuda insinto /usr/include/cuda doins usr/include/cuda/*.h || die "failed to install cuda headers" --- 335,341 ---- die "failed to create libXvMCNVIDIA.so symlink" # CUDA headers (driver to come) + if use kernel_linux && [[ -d usr/include/cuda ]]; then dodir /usr/include/cuda insinto /usr/include/cuda doins usr/include/cuda/*.h || die "failed to install cuda headers"
