Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 447566 - x11-drivers/nvidia-drivers-* fails to build/load/run with kernel-*
Summary: x11-drivers/nvidia-drivers-* fails to build/load/run with kernel-*
Status: VERIFIED WONTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal with 4 votes (vote)
Assignee: Jeroen Roovers (RETIRED)
URL: https://wiki.gentoo.org/wiki/NVidia/n...
Whiteboard:
Keywords: PATCH
: 450952 454560 455496 455918 455940 455942 455974 456226 458246 458382 458738 458850 459036 459468 459488 459786 460014 460104 461266 463228 475382 475396 475406 475466 475694 475698 475700 475990 476046 476302 477298 477358 482164 482168 482224 482686 483480 483536 487014 487282 487644 487862 487986 489164 489200 489454 489710 490346 490606 498846 498892 499092 506466 510020 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-12-17 08:32 UTC by Martin Väth
Modified: 2014-05-11 15:36 UTC (History)
85 users (show)

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


Attachments
Fix vm_reserved error with nvidia-drivers-173.14.36 (nvidia-drivers-173.14.36-vm_reserved.patch,335 bytes, patch)
2012-12-22 09:08 UTC, Martin Väth
Details | Diff
Fix for x11-drivers/nvidia-drivers-313.18 (nvidia-drivers-kernel-3.7.patch,1.17 KB, patch)
2013-01-19 09:17 UTC, Martin Väth
Details | Diff
Fix for x11-drivers/nvidia-drivers-173.14.36 and kernel-3.7 (nvidia-drivers-173.14.36-kernel-3.7.patch,4.16 KB, patch)
2013-01-19 09:27 UTC, Martin Väth
Details | Diff
nvidia-drivers-304.64-kernel-3.7.patch (nvidia-drivers-304.64-kernel-3.7.patch,2.08 KB, patch)
2013-02-07 17:00 UTC, Matthew Schultz
Details | Diff
version checking fix for 313.18 (nvidia-drivers-313.18.patch,1.08 KB, patch)
2013-02-08 07:59 UTC, Tibor Vago
Details | Diff
nvidia-drivers-313.18-linux-3.8.patch (nvidia-drivers-313.18-linux-3.8.patch,430 bytes, patch)
2013-02-20 02:23 UTC, root
Details | Diff
Fix for x11-drivers/nvidia-drivers-173.14.36 with kernel-3.7 and 3.8 (nvidia-drivers-173.14.36-kernel-3.8.patch,4.22 KB, patch)
2013-02-24 20:37 UTC, Martin Väth
Details | Diff
Patch for 310.32 driver and 3.7 kernel (nvidia-drivers-310.32-kernel-3.7.patch,1.18 KB, patch)
2013-02-27 15:40 UTC, Tom Dexter
Details | Diff
nvidia-drivers-linux-3.10.patch.txt (nvidia-drivers-linux-3.10.patch.txt,17.24 KB, patch)
2013-07-04 07:51 UTC, Stephan Kupfer
Details | Diff
Patch to fix the compilation errors on 3.10 (nvidia-linux-3.10.patch,17.05 KB, patch)
2013-07-09 17:17 UTC, Clemens Gruber
Details | Diff
nvidia-drivers-num_physpages.patch (nvidia-drivers-num_physpages.patch,555 bytes, patch)
2013-10-02 19:10 UTC, Chris Slycord
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Väth 2012-12-17 08:32:17 UTC
With kernel-3.7 (gentoo-sources and hardened-sources),
if KBUILD_OUTPUT points to a different directory,
emerge nvidia-drivers (so far I was only testing 310.19)
fails with the message that the kernel is not yet configured.

This was not so with earlier kernel versions (e.g. 3.6.*)

Making a symlink from /usr/src/linux/.config to $KBUILD_OUTPUT/.config
fixes the issue, but this somewhat contradicts the idea of KBUILD_OUTPUT.

I guess that for kernel-3.7 some path needs to be patched so that
the autocheck of nvidia-drivers for .config goes to $KBUILD_OUTPUT/.config
if KBUILD_OUTPUT is set.
Comment 1 Jeroen Roovers (RETIRED) gentoo-dev 2012-12-17 19:02:33 UTC
Something tells me this bug report is going the way of all the previous bug reports about building nvidia-drivers against any unstable kernel version.
Comment 2 Martin Väth 2012-12-22 09:02:09 UTC
Same issue with
x11-drivers/nvidia-drivers-173.14.36

Moreover, x11-drivers/nvidia-drivers-173.14.36 will need additional patches
with kernel-3.7. It throws errors like

/var/tmp/portage/x11-drivers/nvidia-drivers-173.14.36/work/usr/src/nv/conftest.h:8:2: error: #error remap_page_range() conftest failed!

and many others.
Comment 3 Martin Väth 2012-12-22 09:08:36 UTC
Created attachment 333002 [details, diff]
Fix vm_reserved error with nvidia-drivers-173.14.36

The attached patch is an adaption of a patch for 304.60 which I found in the net:
It fixes one of the compile errors of 173.14.36 with kernel-3.7,
but not all of them.
Comment 4 Markus Rathgeb 2013-01-06 21:46:28 UTC
I could merge 310.19 for kernel v3.7.1 (the kernel build directory is out of the source).
The only thing I have to do was to create a symlink so
${KBUILD_OUTPUT}/include/linux/version.h
points to
${KBUILD_OUTPUT}/include/generated/uapi/linux/version.h

Without the symlink, i got the message:

If you are using a Linux 2.4 kernel, please make sure
you either have configured kernel sources matching your
kernel or the correct set of kernel headers installed
on your system.

If you are using a Linux 2.6 kernel, please make sure
you have configured kernel sources matching your kernel
installed on your system. If you specified a separate
output directory using either the "KBUILD_OUTPUT" or
the "O" KBUILD parameter, make sure to specify this
directory with the SYSOUT environment variable or with
the equivalent nvidia-installer command line option.

Depending on where and how the kernel sources (or the
kernel headers) were installed, you may need to specify
their location with the SYSSRC environment variable or
the equivalent nvidia-installer command line option.

*** Unable to determine the target kernel version. ***
Comment 5 Jeroen Roovers (RETIRED) gentoo-dev 2013-01-09 12:33:59 UTC
*** Bug 450952 has been marked as a duplicate of this bug. ***
Comment 6 Martin Väth 2013-01-17 20:56:27 UTC
Still broken with the new drivers x11-drivers/nvidia-drivers-313.18:
Still either the .config link or the link mentioned in Comment 4 must be manually created to make the tests work.
Comment 7 Mike Gilbert gentoo-dev 2013-01-17 21:04:38 UTC
Just confirming the behavior indicated by Martin with respect to out-of-source builds. The version.h symlink workaround works for me.
Comment 8 Martin Väth 2013-01-19 09:17:56 UTC
Created attachment 336100 [details, diff]
Fix for x11-drivers/nvidia-drivers-313.18

The attached patch fixes the problem with most recent nvidia-drivers (it will likely work also with 310.*, maybe also with 304.* or even 295.*, but I have not verified this).

Essentially, it fixes an explicit file-existence test in conftest.sh and also the added include paths (for linux-3.7 the previous two $OUTPUT/arch/x86/include/generated* paths visible in the patch are obsolete, but probably they are needed for earlier kernel versions, so the patch does not remove these).
Comment 9 Martin Väth 2013-01-19 09:27:01 UTC
Created attachment 336106 [details, diff]
Fix for x11-drivers/nvidia-drivers-173.14.36 and kernel-3.7

The attached patch fixes the same problem as the previous patch, but for the legacy nvidia-drivers-173.14.36. The same remarks hold as for the other patch.

In addition, this patch fixes other compilation problems with kernel-3.7 which are independent of this bug (current nvidia-drivers-173.14.36.ebuild does not compile at all with kernel-3.7, even if KBUILD_OUTPUT is used).

All attached patches should be nonintrusive in the sense that they should not change anything with earlier kernel versions and fix also other architectures, but I have not tested this:

I have tested only on x86 and amd64 with kernel-3.7.
Comment 10 Jan Psota 2013-01-22 02:17:59 UTC
(In reply to comment #9)
> Created attachment 336106 [details, diff] [details, diff]
> Fix for x11-drivers/nvidia-drivers-173.14.36 and kernel-3.7
> [...]
> I have tested only on x86 and amd64 with kernel-3.7.

Works great for me on both x86 and amd64 with kernel 3.7.2-pf and x11-drivers/nvidia-drivers-173.14.36 :-)

Does not apply, as expected, for 304.64.
Comment 11 Jan Psota 2013-01-22 02:38:29 UTC
Added to bleeding-edge overlay:
nvidia-drivers-173.14.36 patched for 3.7, thanks to Martin Väth! (bug 447566)
Comment 12 Dylan 2013-02-05 05:03:18 UTC
Attempting to compile 304.64 on 3.7.4 fails here, I've noticed both version.h files exist, and they have a different LINUX_VERSION_CODE, 198404 vs 198152. Wouldn't that make this a kernel (gentoo-sources) bug?
Comment 13 Jeroen Roovers (RETIRED) gentoo-dev 2013-02-05 12:18:42 UTC
*** Bug 455496 has been marked as a duplicate of this bug. ***
Comment 14 Evert 2013-02-05 19:03:57 UTC
Until yesterday I didn't know how easy it is to use this patch (in my case the 173.14.36 version), so for for those who don't know:

save the patch as kernel-3.7.patch
mkdir -p /etc/portage/patches/x11-drivers/nvidia-drivers-173.14.36-r0
mv kernel-3.7.patch /etc/portage/patches/x11-drivers/nvidia-drivers-173.14.36-r0/

Works great, thanks for the patch Martin!
Comment 15 Denis M. (Phr33d0m) 2013-02-07 01:02:44 UTC
*** Bug 455942 has been marked as a duplicate of this bug. ***
Comment 16 Denis M. (Phr33d0m) 2013-02-07 01:03:01 UTC
*** Bug 455940 has been marked as a duplicate of this bug. ***
Comment 17 Tom Wijsman (TomWij) (RETIRED) gentoo-dev 2013-02-07 01:33:10 UTC
*** Bug 455918 has been marked as a duplicate of this bug. ***
Comment 18 Lars Wendler (Polynomial-C) (RETIRED) gentoo-dev 2013-02-07 09:50:47 UTC
*** Bug 455974 has been marked as a duplicate of this bug. ***
Comment 19 Matthew Schultz 2013-02-07 16:56:06 UTC
I just verified this patch works with 304.64:

http://cvs.rpmfusion.org/viewvc/rpms/nvidia-kmod/F-18/3.7_kernel.patch?revision=1.1&root=nonfree&view=markup
Comment 20 Matthew Schultz 2013-02-07 17:00:12 UTC
Created attachment 338262 [details, diff]
nvidia-drivers-304.64-kernel-3.7.patch

Attaching patch from http://cvs.rpmfusion.org/viewvc/rpms/nvidia-kmod/F-18/3.7_kernel.patch?revision=1.1&root=nonfree&view=markup.
Comment 21 Matthew Schultz 2013-02-07 17:03:58 UTC
(In reply to comment #20)
> Created attachment 338262 [details, diff] [details, diff]
> nvidia-drivers-304.64-kernel-3.7.patch
> 
> Attaching patch from
> http://cvs.rpmfusion.org/viewvc/rpms/nvidia-kmod/F-18/3.7_kernel.
> patch?revision=1.1&root=nonfree&view=markup.

I tested with gentoo-sources 3.7.4 and a geforce 7 card on amd64 arch.
Comment 22 Matthew Schultz 2013-02-07 17:05:11 UTC
This patch might also be needed when 3.7.6 lands in the main tree:

http://cvs.rpmfusion.org/viewvc/rpms/nvidia-kmod/F-18/conftest.patch?revision=1.1&root=nonfree&view=markup
Comment 23 Vasilis Lourdas 2013-02-07 17:25:11 UTC
(In reply to comment #22)
> This patch might also be needed when 3.7.6 lands in the main tree:
> 
> http://cvs.rpmfusion.org/viewvc/rpms/nvidia-kmod/F-18/conftest.
> patch?revision=1.1&root=nonfree&view=markup

3.7.6 already landed and the current drivers fail to build against it.
Comment 24 Silvio 2013-02-08 07:03:53 UTC
I confirm problem here.
No compiling against kernel 3.7.6
Comment 25 Tibor Vago 2013-02-08 07:59:08 UTC
Created attachment 338290 [details, diff]
version checking fix for 313.18

Above 3.0.0 kernel we need Makefile.kbuild there is no need to check PATCHLEVEL and SUBLEVEL. First need to check if kernel VERSION -ge 3.
Comment 26 Thomas 2013-02-08 20:00:05 UTC
Thanks for the "version checking fix for 313.18" patch!
It made nvidia-drivers-304.64 compile against kernel 3.7.6 for me, in combination with nvidia-drivers-304.64-kernel-3.7.patch as mentioned in comment #14.
Comment 27 Tom Wijsman (TomWij) (RETIRED) gentoo-dev 2013-02-08 21:28:28 UTC
*** Bug 456226 has been marked as a duplicate of this bug. ***
Comment 28 Lee Trager 2013-02-09 11:28:08 UTC
Comment on attachment 338290 [details, diff]
version checking fix for 313.18

Just applying this patch allows me to build nvidia-drivers-313.18 against gentoo-sources-3.7.6
Comment 29 Chris Smith 2013-02-09 15:41:41 UTC
(In reply to comment #28)
> Comment on attachment 338290 [details, diff] [details, diff]
> version checking fix for 313.18
> 
> Just applying this patch allows me to build nvidia-drivers-313.18 against
> gentoo-sources-3.7.6

Odd. That doesn't work here at all.
Comment 30 Chris Smith 2013-02-09 15:52:20 UTC
(In reply to comment #29)
> (In reply to comment #28)
> > Comment on attachment 338290 [details, diff] [details, diff] [details, diff]
> > version checking fix for 313.18
> > 
> > Just applying this patch allows me to build nvidia-drivers-313.18 against
> > gentoo-sources-3.7.6
> 
> Odd. That doesn't work here at all.

Er...sorry, yes it does.
Comment 31 Kelly Price 2013-02-09 18:49:26 UTC
The patches for 313.18 work against vanilla-sources and allow me to compile the drivers.

BTW, thanks Everet for that tip with patches!
Comment 33 Dmitry Suloev 2013-02-19 08:10:16 UTC
Looks like same problem for linux 3.8.0
Comment 34 Jeroen Roovers (RETIRED) gentoo-dev 2013-02-19 20:26:12 UTC
*** Bug 458246 has been marked as a duplicate of this bug. ***
Comment 35 Denis M. (Phr33d0m) 2013-02-19 20:34:51 UTC
(In reply to comment #33)
> Looks like same problem for linux 3.8.0

Please rsync your trees and try again with the applied patch(es) and test it out.
Comment 36 Stefan Salewski 2013-02-20 01:32:08 UTC
(In reply to comment #35)
> (In reply to comment #33)
> > Looks like same problem for linux 3.8.0
> 
> Please rsync your trees and try again with the applied patch(es) and test it
> out.

Seems to work fine for vanilla-sources-3.8 and nvidia-drivers 304.64 as long as this external patch is available:

/etc/portage/patches/x11-drivers/nvidia-drivers-304.64/patch_nvidia_304_60.run_for_3.7.patch

After deleting that patch "emerge nvidia-drivers" fails. I mentioned the source of that patch some weeks ago on gentoo bugzilla, the bug report was marked duplicate.

Best regards

Stefan Salewski
Comment 37 Jeroen Roovers (RETIRED) gentoo-dev 2013-02-20 02:10:32 UTC
*** Bug 458382 has been marked as a duplicate of this bug. ***
Comment 38 root 2013-02-20 02:23:56 UTC
Created attachment 339470 [details, diff]
nvidia-drivers-313.18-linux-3.8.patch

Attached is the patch needed for gentoo-sources-3.8.0 and nvidia-drivers-313.18
Comment 39 Dmitry Suloev 2013-02-20 06:02:13 UTC
(In reply to comment #38)
> Created attachment 339470 [details, diff] [details, diff]
> nvidia-drivers-313.18-linux-3.8.patch
> 
> Attached is the patch needed for gentoo-sources-3.8.0 and
> nvidia-drivers-313.18

This patch helps. Thx.
Comment 40 tman 2013-02-20 06:49:02 UTC
can we have this now in portage?
Comment 41 Lee Trager 2013-02-20 10:41:58 UTC
(In reply to comment #38)
> Created attachment 339470 [details, diff] [details, diff]
> nvidia-drivers-313.18-linux-3.8.patch
> 
> Attached is the patch needed for gentoo-sources-3.8.0 and
> nvidia-drivers-313.18

Fix worked for me as well, thanks!
Comment 42 hal 2013-02-20 21:27:17 UTC
nvidida-drivers-304.64 requires both,

nvidida-drivers-304.64-kernel-3.7.patch

and

nvidia-drivers-313.18-linux-3.8.patch,

in order to get built with linux-3.8.0.
Comment 43 Matthew Schultz 2013-02-21 05:09:16 UTC
Just tested with 3.7.8 with geforce 6 on x86 with 304.64.  These patches are needed to compile:

http://cvs.rpmfusion.org/viewvc/rpms/nvidia-kmod/F-18/conftest.patch?revision=1.2&root=nonfree&view=markup

and  

nvidia-drivers-304.64-kernel-3.7.patch
Comment 44 Doug Goldstein (RETIRED) gentoo-dev 2013-02-22 14:29:53 UTC
*** Bug 458738 has been marked as a duplicate of this bug. ***
Comment 45 Jeroen Roovers (RETIRED) gentoo-dev 2013-02-23 16:37:27 UTC
*** Bug 458850 has been marked as a duplicate of this bug. ***
Comment 46 Tom Wijsman (TomWij) (RETIRED) gentoo-dev 2013-02-24 17:03:16 UTC
*** Bug 459036 has been marked as a duplicate of this bug. ***
Comment 47 Martin Väth 2013-02-24 20:37:39 UTC
Created attachment 340010 [details, diff]
Fix for x11-drivers/nvidia-drivers-173.14.36 with kernel-3.7 and 3.8

The attached update of the 173.14.36 series patch should work with kernel-3.7 and kernel-3.8.

Concerning nvidia-drivers-313.18: Since root's patch seems to solve all issues (including the separate KBUILD_OUTPUT/KERNEL_SOURCES) also with kernel-3.7 and is much shorter than my previous one, I mark also my previous patch for nvidia-drivers-313.18 and kernel-3.7 as obsolete.
Comment 48 Maciej Józiewicz 2013-02-24 23:34:34 UTC
I'm using 304.64 patched with what Matthew Schultz attached with (current amd64 stable) 3.7.9 kernel (with the version.h symlinked).

I've got an onboard integrated 6250SE.

Works fine - thank you.

(I suppose that users would appreciate an r1 ebuild in portage so that the driver package could be emerged with the currently stable kernel - not attaching since adding an epatch line is just to trivial a change for it to make sense)
Comment 49 Melendro 2013-02-25 19:40:32 UTC
A patch is also needed for x11-drivers/nvidia-drivers-310.32 because it was stabilized yesterday.
Comment 50 Tom Wijsman (TomWij) (RETIRED) gentoo-dev 2013-02-27 09:01:00 UTC
*** Bug 459468 has been marked as a duplicate of this bug. ***
Comment 51 Tom Wijsman (TomWij) (RETIRED) gentoo-dev 2013-02-27 13:36:25 UTC
*** Bug 459488 has been marked as a duplicate of this bug. ***
Comment 52 Tom Dexter 2013-02-27 15:40:54 UTC
Created attachment 340362 [details, diff]
Patch for 310.32 driver and 3.7 kernel

I'm attaching a patch I just used to install the current stable nvidia-drivers-310.32 with the 3.7.9 kernel.   It's based on the changes made in the patches for 313.18.  I have not tested this with the 3.8 kernel.
Comment 53 Tom Wijsman (TomWij) (RETIRED) gentoo-dev 2013-03-01 01:35:41 UTC
*** Bug 459786 has been marked as a duplicate of this bug. ***
Comment 54 Maciej Mrozowski gentoo-dev 2013-03-01 21:24:09 UTC
No need for new patches, nvidia-drivers-313.18-linux-3.7+.patch from FILESDIR already does the job.
Comment 55 Samuli Suominen (RETIRED) gentoo-dev 2013-03-02 11:31:22 UTC
(In reply to comment #38)
> Created attachment 339470 [details, diff] [details, diff]
> nvidia-drivers-313.18-linux-3.8.patch
> 
> Attached is the patch needed for gentoo-sources-3.8.0 and
> nvidia-drivers-313.18

I just updated my kernel to 3.8.x and hit this bug. This simple patch seems to fix things here. I've added it to portage for 313.18.
Comment 56 Doug Goldstein (RETIRED) gentoo-dev 2013-03-02 16:01:10 UTC
I've left this bug opened for people to collect at.

It is and has always been Gentoo's policy to support what NVIDIA supports. The current versions of the drivers do not support 3.7 or 3.8. You are more than welcome to use the capabilities of epatch_user (which are present in all the ebuilds) to make the changes yourself but they do not go into the main tree.
Comment 57 Eric F. GARIOUD 2013-03-02 16:23:41 UTC
(In reply to comment #56)
> It is and has always been Gentoo's policy to support what NVIDIA supports.
> The current versions of the drivers do not support 3.7 or 3.8.

Quoted from http://us.download.nvidia.com/XFree86/Linux-x86/310.32/README/minimumrequirements.html : (Chapter 2. Minimum Software Requirements) :
<< All official stable kernel releases from 2.4.22 and up are supported >>
Comment 58 Doug Goldstein (RETIRED) gentoo-dev 2013-03-02 16:33:18 UTC
(In reply to comment #57)
> (In reply to comment #56)
> > It is and has always been Gentoo's policy to support what NVIDIA supports.
> > The current versions of the drivers do not support 3.7 or 3.8.
> 
> Quoted from
> http://us.download.nvidia.com/XFree86/Linux-x86/310.32/README/
> minimumrequirements.html : (Chapter 2. Minimum Software Requirements) :
> << All official stable kernel releases from 2.4.22 and up are supported >>

Please contact NVIDIA and ask for support with 3.7 or 3.8 with the 310.32 driver and let me know what their response is.
Comment 59 Tom Wijsman (TomWij) (RETIRED) gentoo-dev 2013-03-02 17:40:27 UTC
*** Bug 460014 has been marked as a duplicate of this bug. ***
Comment 60 Pacho Ramos gentoo-dev 2013-03-02 18:57:56 UTC
Probably the optimal solution would be to:
- Apply the patches when kernel >= 3.7 are used
- Show the message informing people they are running an unsupported setup

That would make happy both parts
Comment 61 Vasilis Lourdas 2013-03-02 19:10:38 UTC
(In reply to comment #60)
> - Show the message informing people they are running an unsupported setup

This already happens. In fact, the install message says:

Gentoo supports kernel's which are supported by NVIDIA
which are limited to the following kernels:
<sys-kernel/gentoo-sources-3.7
<sys-kernel/vanilla-sources-3.7

So in fact, according to this message, the drivers don't officially support kernel 3.7.
Comment 62 László Szalma 2013-03-02 19:49:24 UTC
The patch works fine with 3.7 and 3.8. Officially not supported. And? It works. I don't see why every Gentoo users have to apply the patch themselves... We apply patches everywhere in the portage tree to make things work for the users... This is the whole thing is about, isn't it?
Comment 63 Pacho Ramos gentoo-dev 2013-03-02 20:12:37 UTC
Also, the main problem on forcing people to use their patches using epatch_user is that it's not obvious for ever one what patch they should use and where they should find it. Then, we will end with people simply not knowing how to get desired patch or they getting some ugly patch they could download from some random website
Comment 64 Doug Goldstein (RETIRED) gentoo-dev 2013-03-02 21:24:45 UTC
(In reply to comment #63)
> Also, the main problem on forcing people to use their patches using
> epatch_user is that it's not obvious for ever one what patch they should use
> and where they should find it. Then, we will end with people simply not
> knowing how to get desired patch or they getting some ugly patch they could
> download from some random website

Pacho,

I'm telling you right now Gentoo's policy has been for over 5 years that we only support what NVIDIA officially supports. If you contact NVIDIA about 3.7 and 3.8 with these versions, they will tell you that it will be supported in the next version (over half a dozen posts on their forums from their employees state this). Everyone's gotten used to NVIDIA supporting a kernel version in a release before the kernel is stabilized for a long time. I have to applaud their effort and their support for doing so. But this time around something has caused that cadence to get disrupted so people are upset because they got used to it.

We do not know why they haven't supported 3.7. Maybe its because their QA lead is on a really long vacation. Maybe its because they've discovered an issue where 3.7+ can in some cases brick hardware. Before you claim this can't happen, I have a GeForce 3 card which I will happily give you which was bricked by a simple kernel upgrade.

The drivers are binary only, there's absolutely nothing we can do to resolve any issues a user might have that's not related to our packaging. All we can do is forward them on to NVIDIA. If NVIDIA won't support them due to our packaging then we've failed as a distro. Due to the nature of users compiling everything themselves we aren't afforded the same level of support that Fedora, RHEL, Debian, and Ubuntu get. NVIDIA employees are involved in packaging on all of those distros. If you look at how the Linux kernel treats NVIDIA drivers from a support stand point I would say we are not outrageous. If you have NVIDIA drivers loaded in your kernel, then the kernel guys won't support you. And those guys are mostly paid to support the kernel per LWN's article. Gentoo devs (and myself) do this on a volunteer basis. No one pays me a dime to support Gentoo or work with Gentoo or help Gentoo users out. So why should I increase my maintenance burden by having to support configurations that the vendor won't support?

We have epatch_user so as to be as flexible as possible for our users. Users are welcome to do whatever they wish with our software, hence the freedom as in speech part of our distro. epatch_user makes it easier for users to do what they wish with the distro. It is however perfectly reasonable to say that if you modify what we can support or do support that we can't support you.

Please tell me what part of this is unreasonable.
Comment 65 Pacho Ramos gentoo-dev 2013-03-02 21:44:41 UTC
People can be informed about their unsupported setup via a message like:
https://bugs.gentoo.org/show_bug.cgi?id=447566#c60

suggests and you are already doing when kernel-3.7/8 is detected
Comment 66 Andriy Baranskyy 2013-03-02 23:30:11 UTC
Like everyone else I am having issue with upgrading my kernels due to incompatibility with nvidia. However, an interesting thing is that somehow I managed to compile kernel 3.7.8 with nvidia 313.18. Isn't it supposed to be incompatible?
Personally, I am ok to hold off from upgrading to 3.8.x as long as nvidia delivers new drivers in timely manner. Or is there something really cool in 3.8.x kernels?
Comment 67 Samuli Suominen (RETIRED) gentoo-dev 2013-03-03 06:55:54 UTC
313.18 works perfectly with 3.7/3.8 with these minor header location adjustments, the kernel part has always been FOSS in the drivers and can be patched
claiming something else is retarded
Comment 68 Tom Wijsman (TomWij) (RETIRED) gentoo-dev 2013-03-03 13:02:50 UTC
*** Bug 460104 has been marked as a duplicate of this bug. ***
Comment 69 Stefano 2013-03-03 13:54:20 UTC
(In reply to comment #64)

> I'm telling you right now Gentoo's policy has been for over 5 years that we
> only support what NVIDIA officially supports. If you contact NVIDIA about

If I may observe a little inconsistency, at the moment if you run (like me) a system with a stable profile, kernel 3.7.10 is marked as stable for x86, and nvidia-drivers 310.32 are also marked as stable. But the latter won't compile. This does not seem very logical to me.
Comment 70 Doug Goldstein (RETIRED) gentoo-dev 2013-03-03 18:22:28 UTC
(In reply to comment #69)
> (In reply to comment #64)
> 
> > I'm telling you right now Gentoo's policy has been for over 5 years that we
> > only support what NVIDIA officially supports. If you contact NVIDIA about
> 
> If I may observe a little inconsistency, at the moment if you run (like me)
> a system with a stable profile, kernel 3.7.10 is marked as stable for x86,
> and nvidia-drivers 310.32 are also marked as stable. But the latter won't
> compile. This does not seem very logical to me.

As I explained above, you've become used to the fast release cadence of NVIDIA. And do not remember when their support of newer kernels was a bit delayed. It would often occur that kernels were marked "stable" by Gentoo when there was no corresponding driver's package.

Stable for kernel releases (really any package) is relative as well. Its always use whatever works best for your as a user with your combination of hardware. If you search Gentoo's Bugzilla for gentoo-sources (or any kernel source package for that matter), you'll need to search closed bug reports as well, you will see hundreds of bugs that people had issues with a piece of hardware and developers responded telling them to use an older kernel version. Or the user supplied a patch and it wasn't applied and the bug was abandoned because the user went to a different kernel version.

The point is its impossible to expect every combination of hardware and software to always work 100% together. Its also impossible to support kernel versions newer than when the driver package was released. We also don't have the source to the drivers so we must rely on upstream's support. As a result we can only sensibly support what upstream supports.
Comment 71 Doug Goldstein (RETIRED) gentoo-dev 2013-03-03 18:34:08 UTC
(In reply to comment #67)
> 313.18 works perfectly with 3.7/3.8 with these minor header location
> adjustments, the kernel part has always been FOSS in the drivers and can be
> patched
> claiming something else is retarded

The kernel part of NVIDIA drivers is not FOSS. They have a large binary blob that is wrapped by an open source shim to glue it to the current kernel's API.

When 3.7/3.8 changes a function that that open sourced shim wraps for the binary blob and the resulting function call damages hardware are you willing to personally warranty that change and replace the hardware for the user? If so, we can apply the change.

While not damaging hardware an example of a kernel version change causing problems is bug #454560.

And lastly, in the future try to make your counter arguments a bit better than basic name calling. http://25.media.tumblr.com/tumblr_m93x01rSVK1qjvxfho1_1280.jpg
Comment 72 PaX Team 2013-03-03 19:34:56 UTC
(In reply to comment #71)
> When 3.7/3.8 changes a function that that open sourced shim wraps for the
> binary blob and the resulting function call damages hardware are you willing
> to personally warranty that change and replace the hardware for the user? If
> so, we can apply the change.

where's this 'provide warranty' requirement come from? do you provide it for kernel 3.6 and below (that you supposedly do support)? i didn't think so either. if you're so worried about having to deal with user bug reports for these driver/kernel combinations then just put the patches under USE=unsupported_kernel or something so everyone would have to choose their poison consciously.
Comment 73 Doug Goldstein (RETIRED) gentoo-dev 2013-03-03 19:43:18 UTC
(In reply to comment #72)
> (In reply to comment #71)
> > When 3.7/3.8 changes a function that that open sourced shim wraps for the
> > binary blob and the resulting function call damages hardware are you willing
> > to personally warranty that change and replace the hardware for the user? If
> > so, we can apply the change.
> 
> where's this 'provide warranty' requirement come from? do you provide it for
> kernel 3.6 and below (that you supposedly do support)? i didn't think so
> either. if you're so worried about having to deal with user bug reports for
> these driver/kernel combinations then just put the patches under
> USE=unsupported_kernel or something so everyone would have to choose their
> poison consciously.

We package the NVIDIA drivers for use in their supported configurations so users can receive support from NVIDIA for any issues. That's all we can provide. If we patch the build process and put users in an unsupported state by default then that harms everyone.
Comment 74 PaX Team 2013-03-03 20:16:50 UTC
(In reply to comment #73)
> We package the NVIDIA drivers for use in their supported configurations so
> users can receive support from NVIDIA for any issues. That's all we can
> provide. If we patch the build process and put users in an unsupported state
> by default then that harms everyone.

uhm, you didn't answer any of my questions, so once more:

1. where does the requirement of this 'provide warranty' come from?

2. do you provide this warranty you spoke of for earlier kernels then?

3. last i checked nvidia doesn't provide support for grsec kernels yet gentoo does (USE=pax_kernel). how do you explain that?

4. what about my suggestion of USE=unsupported_kernel?

5. why does providing *some* users with unsupported patches harm *everyone*?

6. why does providing *some* users with unsupported patches harm *anyone*?

please don't evade the questions, they directly relate to your arguments.
Comment 75 Doug Goldstein (RETIRED) gentoo-dev 2013-03-03 20:21:54 UTC
As I've said before, make an overlay with unofficial changes. I will change the ewarn message to say if you're using an unsupported kernel then use the overlay.

I personally have no intention of volunteering time to Gentoo to support unsupported configurations.
Comment 76 PaX Team 2013-03-03 20:37:06 UTC
(In reply to comment #75)
> As I've said before, make an overlay with unofficial changes.

there is such an 'overlay' of unofficial changes already, it's called the gentoo portage tree. see for yourself in /usr/portage/x11-drivers/nvidia-drivers/files/ .

> I will change the ewarn message to say if you're using an unsupported kernel

oh boy, does this 'use a supported kernel' remind me on someone like you (http://www.sourceware.org/bugzilla/show_bug.cgi?id=12492#c1 for those who missed this marvelous piece of history ;).

> then use the overlay.

but everyone's doing that already, all people ask for is to include the trivial fixes that enable these kernel drivers to compile/load under newer kernels. let the rest of tinkering to the users, that's what gentoo is about after all.

> I personally have no intention of volunteering time to Gentoo to support
> unsupported configurations.

rightly so because supporting unsupported configs would make those configs supported so your strawman would be dead right there. try a new excuse.

PS: it shows some real class that you post that pyramid but then go ignore all of my questions.
Comment 77 Doug Goldstein (RETIRED) gentoo-dev 2013-03-03 21:15:18 UTC
(In reply to comment #74)
> (In reply to comment #73)
> > We package the NVIDIA drivers for use in their supported configurations so
> > users can receive support from NVIDIA for any issues. That's all we can
> > provide. If we patch the build process and put users in an unsupported state
> > by default then that harms everyone.
> 
> uhm, you didn't answer any of my questions, so once more:
> 
> 1. where does the requirement of this 'provide warranty' come from?
> 
> 2. do you provide this warranty you spoke of for earlier kernels then?

I'm making a point that when people use their computers with a supported configuration they will get support from NVIDIA. I've had more than one card replaced via supply channels after NVIDIA worked with me and they were satisfied with the output of nvidia-bug-report.sh. 

> 
> 3. last i checked nvidia doesn't provide support for grsec kernels yet
> gentoo does (USE=pax_kernel). how do you explain that?

The Gentoo PaX team has previously said any bugs related to users on hardened-sources they would handle and would be directly assigned to them. If that's not the case I'll gladly revert them.

> 
> 4. what about my suggestion of USE=unsupported_kernel?

Conditional patches like this are frowned upon in Gentoo. This has all been discussed on the ML and been rejected by other developers as inappropriate. My suggestion of an overlay would work though.

> 
> 5. why does providing *some* users with unsupported patches harm *everyone*?
> 
> 6. why does providing *some* users with unsupported patches harm *anyone*?

The point is the same that the Linux kernel maintainers have. With binary only blobs, you have no idea how it can affect things with other dependencies change. They have chosen to never support anyone using the NVIDIA drivers. We have chosen to only support people that are using a configuration NVIDIA will support. It harms people when our default configuration can not allow them to be supported.

> 
> please don't evade the questions, they directly relate to your arguments.

I don't see any evasion. I have a life that does not involve sitting around hitting refresh on this bug for every last person's comments to instantly respond.
Comment 78 Doug Goldstein (RETIRED) gentoo-dev 2013-03-03 21:18:39 UTC
(In reply to comment #76)
> (In reply to comment #75)
> > As I've said before, make an overlay with unofficial changes.
> 
> there is such an 'overlay' of unofficial changes already, it's called the
> gentoo portage tree. see for yourself in
> /usr/portage/x11-drivers/nvidia-drivers/files/ .
> 
> > I will change the ewarn message to say if you're using an unsupported kernel
> 
> oh boy, does this 'use a supported kernel' remind me on someone like you
> (http://www.sourceware.org/bugzilla/show_bug.cgi?id=12492#c1 for those who
> missed this marvelous piece of history ;).
> 
> > then use the overlay.
> 
> but everyone's doing that already, all people ask for is to include the
> trivial fixes that enable these kernel drivers to compile/load under newer
> kernels. let the rest of tinkering to the users, that's what gentoo is about
> after all.
> 
> > I personally have no intention of volunteering time to Gentoo to support
> > unsupported configurations.
> 
> rightly so because supporting unsupported configs would make those configs
> supported so your strawman would be dead right there. try a new excuse.
> 
> PS: it shows some real class that you post that pyramid but then go ignore
> all of my questions.

At this point you're being hostile and trolling. But you've won. I've resigned from any involvement in x11-drivers/nvidia-drivers.
Comment 79 Kelly Price 2013-03-03 21:29:40 UTC
Partially upstreamed to nVidia's Linux driver dev forum:

https://devtalk.nvidia.com/default/topic/528786/linux/linux-3-8-incompatibility/1
Comment 80 boxcars 2013-03-03 23:05:23 UTC
After using the patch in
Comment 81 Rick Farina (Zero_Chaos) gentoo-dev 2013-03-04 23:18:54 UTC
I'd like to request a ruling from the council on this.

Not even this specifically but this whole idea.

We already support things upstream doesn't want such as running nvidia-drivers on a pax kernel (USE=pax_kernel), why must we insist that making it work on a newer kernel is a line that we won't cross?  The patches are _trivial_ at best, and I grant maybe a USE=+vanilla flag for users that want to report bugs to nvidia but this line seems arbitrary to me.

We should either fix all build errors like we are currently doing for pax, or we should fix none, make no changes, just straight install what upstream wants in a sandbox and then merge it to the filesystem.

Please, at least discuss this in the next council meeting.  Any ruling or even a basic guideline from the council on how to deal with these kinds of problems would take a huge weight of the maintainers' shoulders.
Comment 82 root 2013-03-05 03:04:37 UTC
While this thread is epic; it's also depressing. Devs can't agree to put aside thier own agenda and do what's best for the users. I've had several different people in the past couple weeks ask about this bug as they were either doing an update or a newbuild, and they couldn't complete it. It sucks when you want to update or build a fresh system and you have to scour bug reports and download patches manually just get packages already in the stable (or unstable) portage tree, compatible. 

As many others intellegently suggested - add some useflag to it for "unsupported kernels", remove yourself from responsibility and support, add in a pretty little ebuild warning message, and call it a day. That way it no longer effects the (assumingly) several hundred users it already has, and still is.

People read this, see where gentoo added the 3.7-patch to the tree a month ago, added the 3.8-patch to the tree a few days ago. Then mysteriously removed them both... why? It's almost embarassing. 

Meanwhile the other slow-to-update distros would have already had this patched, or not rolled out two conflicting updates that would've affected so many people, did a dependency block, SOMETHING to help out the users.

Zero Chaos - bring it up at the next meeting! Bring some order to this Chaos, lol, too lame of a pun?
Comment 83 Ryan Hill (RETIRED) gentoo-dev 2013-03-05 03:12:26 UTC
Complaints -> nvidia.
Comment 84 root 2013-03-05 03:15:56 UTC
(In reply to comment #83)
> Complaints -> nvidia.

I can complain about the way Gentoo is dealing with the issue, and not the issue itself.

Thanks
Comment 85 Anton Bolshakov 2013-03-05 04:56:13 UTC
This is ridiculous. The stable version(s) should just work/compile.

It gives Gentoo a bad reputation. Besides "hard to install/use/support" it will be known as "fails to compile every here and there".


I'm not even talking about attitude and manners of some devs.
Do not support packages if you can't support them. Really.
Comment 86 Dhalsim 2013-03-05 06:53:22 UTC
(In reply to comment #85)
> This is ridiculous. The stable version(s) should just work/compile.
> 
> It gives Gentoo a bad reputation. Besides "hard to install/use/support" it
> will be known as "fails to compile every here and there".
> 
> 
> I'm not even talking about attitude and manners of some devs.
> Do not support packages if you can't support them. Really.


Yes it is. I've been using gentoo for a while since 2005. I'm a little confused about the strategy of those nvidia-drivers and gentoo-sources mantainers. Everithing unmasked should compile. I could accept secondary pakages fail. Very few will complain about the new version of vi editor mod unmasked wont compile with certain kernels but there still be a lot of nvidia users complaining about two of the most important system packages, gentoo-sources and nvidia-drivers both unmasked, they are not compatible each other. The solution should be to remask gentoo-sources >= 3.7 till nvidia-drivers will support it with a new version or insert one of the above working patch into nvidia-drivers ebuild. There is no other valid and consistent solution I think and there is not other valid interpretation.
Regards Massimo.
Comment 87 Chris Stankevitz 2013-03-05 07:04:22 UTC
This is a pretty screwed up situation and I don't think it's right for anyone to say "well obviously solution XXX is the only answer and anyone who thinks otherwise is an idiot."

Also, I find it somewhat amusing that one vendor, NVIDIA, has the ability to "seize" our distribution.  I hope no new users with NVIDIA cards are attempting to install Gentoo right now.  If so it will be sad to have them bewildered at how difficult it is.  I know, I used to be one of them!  It was confusing enough without having to solve this problem.

Good luck to all involved.  I hope what comes out of this is a plan by which NVIDIA (or anyone else) can never again can "seize" our beloved distro.
Comment 88 Dhalsim 2013-03-05 07:37:59 UTC
(In reply to comment #87)
> This is a pretty screwed up situation and I don't think it's right for
> anyone to say "well obviously solution XXX is the only answer and anyone who
> thinks otherwise is an idiot."
> 
> Also, I find it somewhat amusing that one vendor, NVIDIA, has the ability to
> "seize" our distribution.  I hope no new users with NVIDIA cards are
> attempting to install Gentoo right now.  If so it will be sad to have them
> bewildered at how difficult it is.  I know, I used to be one of them!  It
> was confusing enough without having to solve this problem.
> 
> Good luck to all involved.  I hope what comes out of this is a plan by which
> NVIDIA (or anyone else) can never again can "seize" our beloved distro.

Uhm may be your missing something, here still needed a "solid and rapid" solution becouse:

1. 60% of x86 machines with discrete graphics have nvidia graphics cards on board
2. 18% of overall graphics PC shipment is by nvidia
3. more happy users -> more gentoo users -> more mantainers -> more life to gentoo
4. you missed "I think" keyword in my consideration
5. I never said to anyone here that is an idiot.

Regards Massimo.
Comment 89 Justin Lecher (RETIRED) gentoo-dev 2013-03-05 12:00:32 UTC
Thanks @maintainer for all your good work.
Everyone else, use epatch_user and use your energy to do something productive.
Comment 90 Kelly Price 2013-03-05 12:30:34 UTC
Sorry, can't be productive with this drama going on. This bug is a blocker for a project involving F2FS, and if I can't update a vanilla kernel to 3.9 because a driver I need (no, the open source one isn't up to par yet) requires a workaround that the devs can't be moved to fully document, then nothing is going to happen and the project FAILS.

Sounds like my day job. Now, which one of you has that yak that you want shaved?
Comment 91 Dhalsim 2013-03-05 12:56:45 UTC
(In reply to comment #90)
> Sorry, can't be productive with this drama going on. This bug is a blocker
> for a project involving F2FS, and if I can't update a vanilla kernel to 3.9
> because a driver I need (no, the open source one isn't up to par yet)
> requires a workaround that the devs can't be moved to fully document, then
> nothing is going to happen and the project FAILS.
> 
> Sounds like my day job. Now, which one of you has that yak that you want
> shaved?

I' ve applied by euser_pathc this https://bugs.gentoo.org/attachment.cgi?id=339470

And I've tested over a slot machine embedded system with discrete nvidia graphics after 36 hours of hard graphics slot reels automation all works fine and all is stable.

Gentoo-sources 3.7.9 and Nvidia-drivers-313.18 arch x86.

I'm also running the same configuration with same patch in my mobile workstation arch x86_64 with no problem at all. 

You should try it in your develop system.

Regards Massimo.
Comment 92 Iván Atienza 2013-03-05 15:24:44 UTC
new nvidia-drivers 313.26 seems no need patches, compiled without on 3.8.2 kernel.
patches removed:
nvidia-drivers-313.18-builddir-config.patch
nvidia-drivers-313.18-linux-3.7+.patch
nvidia-drivers-313.18-linux-3.8+.patch

the 1st one i check and seems applied upstream, the others 2 just remove for check cause they fail to apply.

Salud.
Comment 93 Mark Wright gentoo-dev 2013-03-05 15:33:38 UTC
I would like to commit these 2 patches (and add myself to maintainers),
as I have tested they both compile (no symlink required), I run 313-18
with kernel 3.8.0, and at least one user ported that the patch for
304-64 works with kernel 3.7.9. 

http://dev.gentoo.org/~gienah/unsupported/etc-portage-patches-x11-drivers-nvidia-drivers-304-64-and-313-18-for-kernel-3-8-0.tar.gz 

I haven't tested this one for nvidia-drivers-173.14.36 :

https://bugs.gentoo.org/attachment.cgi?id=340010

It would be neat if anyone would like to report test results for these patches
(without using symlink workarounds to the problem where the nvidia drivers can not find kernel header files).
Comment 94 Mark Wright gentoo-dev 2013-03-05 15:39:32 UTC
(In reply to comment #92)
> new nvidia-drivers 313.26 seems no need patches, compiled without on 3.8.2
> kernel.
> patches removed:
> nvidia-drivers-313.18-builddir-config.patch
> nvidia-drivers-313.18-linux-3.7+.patch
> nvidia-drivers-313.18-linux-3.8+.patch
> 
> the 1st one i check and seems applied upstream, the others 2 just remove for
> check cause they fail to apply.
> 
> Salud.

Thanks, bumping it to 313.26 makes it easier for the 313.X version, and better not requiring a patch for the 313.X version.
Comment 95 Mark Wright gentoo-dev 2013-03-05 15:40:34 UTC
trying again to take it, failed earlier due to mid air collision
Comment 96 Alexander Bezrukov 2013-03-05 16:20:33 UTC
(In reply to comment #93)
> and at least one user ported that the patch for 304-64
> works with kernel 3.7.9. 

At least two users. From the time nVidia stated this bug is only in the installer (not the driver) many weeks ago, I tested the (trivially adopted) patch with 304.64 and kernels sys-kernel/vanilla-sources-3.7.{6,7,8,9,10}.
Comment 97 Jose Quinteiro 2013-03-05 22:08:37 UTC
Step-by-step instructions for those, like me, who are trying to run a stable x86 system with nvidia drivers, and are new to epatch_user.

1. Create the patch directory (it didn't exist on my system)

"mkdir -p /etc/portage/patches/x11-drivers/nvidia-drivers"

2. Download the patch from this bug

"wget https://bugs.gentoo.org/attachment.cgi?id=340362 -O /etc/portage/patches/x11-drivers/nvidia-drivers/build-3.7.patch"

3. (Re-)Emerge nvidia-drivers.

You should see lines like these in your emerge output:

 * Applying user patches from /etc/portage/patches//x11-drivers/nvidia-drivers ...
 *   build-3.7.patch ...                                                                                                                  [ ok ]
 * Done with patching
Comment 98 Rick Farina (Zero_Chaos) gentoo-dev 2013-03-05 22:12:14 UTC
> 1. Create the patch directory (it didn't exist on my system)
> 
> "mkdir -p /etc/portage/patches/x11-drivers/nvidia-drivers"

You can also use dir like /etc/portage/patches/x11-drivers/nvidia-drivers-313.18 so that the patch doesn't get improperly applied and break when gentoo upgrades to the next version which may not need this patch.
Comment 99 Jose Quinteiro 2013-03-05 22:20:31 UTC
The stable drivers are 310.32, and the link in my instructions is for the patch that is appropriate or that version.

In any case, here are the step-by-step instructions updated as you suggest.

1. Create the patch directory (it didn't exist on my system)

"mkdir -p /etc/portage/patches/x11-drivers/nvidia-drivers-310.32"

2. Download the patch from this bug

"wget https://bugs.gentoo.org/attachment.cgi?id=340362 -O /etc/portage/patches/x11-drivers/nvidia-drivers-310.32/build-3.7.patch"

3. (Re-)Emerge nvidia-drivers.

You should see lines like these in your emerge output:

 * Applying user patches from /etc/portage/patches//x11-drivers/nvidia-drivers ...
 *   build-3.7.patch ...                                                                                                                  [ ok ]
 * Done with patching
Comment 100 Stefano 2013-03-06 00:04:18 UTC
(In reply to comment #94)

> Thanks, bumping it to 313.26 makes it easier for the 313.X version, and
> better not requiring a patch for the 313.X version.

This does not solve the issue on the stable set of packages, as stable versions are kernel-3.7.10 and nvidia-drivers-310.32

So no, the bump does not solve the problem for x86, maybe it does for ~x86
Comment 101 Marco DR 2013-03-12 00:44:07 UTC
Why is this bug closed? nvidia-drivers-313.26 is not stabilized, and the maintainer has no intention to do so yet (see bug #461266). Please reopen this bug. I understand that gentoo does not support >gentoo-sources-3.7 with nvidia-drivers, but at least keeping this bug open should allow users to easily find the patch.
Comment 102 Gustav Schaffter 2013-03-14 10:08:20 UTC
I'm just sooo embarrassed.


For years (literally) I have tried to convince a colleague and friend of mine to install Gentoo on one of his private computers.

A week ago he did. I know he did, since he called me yesterday evening to tell me about it. The essence of what he told me was: "So, I installed Your Gentoo Linux on this computer I recently bought. Everything went fine until I tried to upgrade the system to the latest packages, as you had told me to do. I upgraded to the latest kernel, which took me a while. Then X didn't start any more. Reading the messages on my screen, I came to the conclusion that I needed to rebuild the video driver for my nvidia card. But it fails to compile. What is this piece of junk? Why do you want me to loose my time with this <beep>?"


I had a very tough time to try to explain to him what was up. I know I never got it through, though.




One future Gentoo user lost. But that's not the whole problem. The main problem is that this guy is now telling the world about it. Don't know how many people he tells the story to, but at least I keep very discrete about my own Gentoo preferences right now. And probably for a good while to come.


'xcuse me, I'll have to crawl back into my hideout.
Comment 103 C. Wijtmans 2013-03-14 11:14:38 UTC
why not mask the kernel that doesnt work with nvidia-drivers on stable?
Comment 104 Jeroen Roovers (RETIRED) gentoo-dev 2013-03-14 15:17:44 UTC
*** Bug 461266 has been marked as a duplicate of this bug. ***
Comment 105 Chris Stankevitz 2013-03-14 20:38:27 UTC
> I'm just sooo embarrassed.

Is the goal of Gentoo to make it easy for your friend to update his system?  Is it the goal of Gentoo to hide Nvidia's ineptitude?

If this is the goal, then gentoo has failed in refusing to slop a hack together to work around this issue.

But this might not be the point of gentoo.  Perhaps the gentoo directors want users to "get their hands dirty" and understand the difficult position Nvidia has placed them in.

To get the answer I turn to Gentoo's philosophy:
http://www.gentoo.org/main/en/philosophy.xml

"The goal of Gentoo is to design tools and systems that allow a user to do that work as pleasantly and efficiently as possible, as they see fit."
Comment 106 Oliver Schwabedissen 2013-03-15 20:14:51 UTC
(In reply to comment #105)

> "The goal of Gentoo is to design tools and systems that allow a user to do
> that work as pleasantly and efficiently as possible, as they see fit."

While I understand that it doesn't make sense to mask a new kernel just because one proprietary kernel module will not compile with the new kernel I don't understand why it was not possible to inform users about this before the new kernel was stabilized.

There's "eselect news" which looks perfect for this to me. For eample it was used last year to inform postfix users that starting with postfix-2.9 the daemons are stored in a different location and that one has to run etc-update or dispatch-conf after emerging the new postfix version. Something emerge usually tells the user after emerging a package that contains modified config files.

So why was a decision made to not inform users of Nvidia cards about the conflict with the new kernel? I guess everybody who was involved in the stablization of vanilla-/gentoo-sources knew that kernel 3.7 would brake all stable nvidia drivers, leaving a lot of people in text mode only after booting the new kernel and trying to compile the driver that worked perfectly up to that point. Lynx is nice, but using it to search forums and bugzilla is a pain.

Personally I masked >=gentoo-sources-3.7 and will stay at kernel 3.6 until there's a stable nvidia driver supporting the than stable kernel.
Comment 107 Jeroen Roovers (RETIRED) gentoo-dev 2013-03-26 15:50:09 UTC
*** Bug 463228 has been marked as a duplicate of this bug. ***
Comment 108 Jeroen Roovers (RETIRED) gentoo-dev 2013-04-04 15:39:10 UTC
*** Bug 454560 has been marked as a duplicate of this bug. ***
Comment 109 Tom Wijsman (TomWij) (RETIRED) gentoo-dev 2013-07-01 07:42:19 UTC
*** Bug 475382 has been marked as a duplicate of this bug. ***
Comment 110 Tom Wijsman (TomWij) (RETIRED) gentoo-dev 2013-07-01 10:28:06 UTC
*** Bug 475396 has been marked as a duplicate of this bug. ***
Comment 111 Jeroen Roovers (RETIRED) gentoo-dev 2013-07-01 14:23:27 UTC
*** Bug 475406 has been marked as a duplicate of this bug. ***
Comment 112 Tom Wijsman (TomWij) (RETIRED) gentoo-dev 2013-07-01 23:51:33 UTC
*** Bug 475466 has been marked as a duplicate of this bug. ***
Comment 113 Pavel Volkov 2013-07-02 11:03:31 UTC
Why is there no check for current kernel version? (kernel 3.10, nvidia 319.32 at the moment).
I think that portage should output an incompatibility warning. Now people just see compilation errors and keep reporting bugs.
Comment 114 C. Wijtmans 2013-07-02 12:34:17 UTC
how about making the nvidia-drivers block whatever vanilla-sources is not supported yet. for ex we make the new drivers support 3.10 we block anything higher than 3.10
Comment 115 Vasilis Lourdas 2013-07-02 13:08:33 UTC
(In reply to Paul Volkov from comment #113)
> Why is there no check for current kernel version? (kernel 3.10, nvidia
> 319.32 at the moment).
> I think that portage should output an incompatibility warning. Now people
> just see compilation errors and keep reporting bugs.

It does report a warning:

Gentoo supports kernels which are supported by NVIDIA
which are limited to the following kernels:
<sys-kernel/gentoo-sources-3.10
<sys-kernel/vanilla-sources-3.10

You are free to utilize epatch_user to provide whatever
support you feel is appropriate, but will not receive 
support as a result of those changes.
Comment 116 boxcars 2013-07-02 20:35:04 UTC
(In reply to Vasileios Lourdas from comment #115)

> It does report a warning:

ISTM it would save bug wranglers time if the warning told people not to file a new bug and pointed them here to this bug entry.
Comment 117 Jeroen Roovers (RETIRED) gentoo-dev 2013-07-03 14:43:00 UTC
(In reply to boxcars from comment #116)
> (In reply to Vasileios Lourdas from comment #115)
> 
> > It does report a warning:
> 
> ISTM it would save bug wranglers time if the warning told people not to file
> a new bug

Done.

> and pointed them here to this bug entry.

I'd rather not have any more comments here.
Comment 118 Vasilis Lourdas 2013-07-03 17:20:27 UTC
Nvidia released beta drivers, v.325.08: https://devtalk.nvidia.com/default/topic/549155/unix-graphics-announcements-and-news/linux-solaris-and-freebsd-driver-325-08-beta-/

Although the release notes do not seem to say anything about kernel 3.10, I suppose they support it...
Comment 119 Kacper Kowalik (Xarthisius) (RETIRED) gentoo-dev 2013-07-04 06:45:31 UTC
*** Bug 475694 has been marked as a duplicate of this bug. ***
Comment 120 Kacper Kowalik (Xarthisius) (RETIRED) gentoo-dev 2013-07-04 07:49:18 UTC
*** Bug 475700 has been marked as a duplicate of this bug. ***
Comment 121 Kacper Kowalik (Xarthisius) (RETIRED) gentoo-dev 2013-07-04 07:49:44 UTC
*** Bug 475698 has been marked as a duplicate of this bug. ***
Comment 122 Stephan Kupfer 2013-07-04 07:51:50 UTC
Created attachment 352578 [details, diff]
nvidia-drivers-linux-3.10.patch.txt

Add patch for x11-drivers/nvidia-drivers-325.08 and kernel 3.10
Comment 123 Jeroen Roovers (RETIRED) gentoo-dev 2013-07-04 13:38:10 UTC
Comment on attachment 352578 [details, diff]
nvidia-drivers-linux-3.10.patch.txt

Please stop wasting your time on this. Everybody knows where to find these unofficial patches and we're not going to commit them to the tree.

Use epatch_user if you absolutely must risk data loss and hardware failure.
Comment 124 Florian Manschwetus 2013-07-05 10:55:43 UTC
I just like to add that I tested yesterday the 325.8 with 3.10.0 and ran into issues with opencl and hw-accel video decoding => programs entered uninterruptible sleep during to some kernel issues "unable to handle kernel paging request at"...
Back to 3.9.9 all is fine again.
Comment 125 Tom Wijsman (TomWij) (RETIRED) gentoo-dev 2013-07-06 21:26:22 UTC
*** Bug 475990 has been marked as a duplicate of this bug. ***
Comment 126 Tom Wijsman (TomWij) (RETIRED) gentoo-dev 2013-07-07 10:14:56 UTC
*** Bug 476046 has been marked as a duplicate of this bug. ***
Comment 127 Clemens Gruber 2013-07-09 17:17:21 UTC
Created attachment 352940 [details, diff]
Patch to fix the compilation errors on 3.10

patch -p1 < nvidia-linux-3.10.patch
Comment 128 Tom Wijsman (TomWij) (RETIRED) gentoo-dev 2013-07-09 17:21:37 UTC
*** Bug 476302 has been marked as a duplicate of this bug. ***
Comment 129 Chris Smith 2013-07-09 19:37:08 UTC
(In reply to Clemens Gruber from comment #127)
> Created attachment 352940 [details, diff] [details, diff]
> Patch to fix the compilation errors on 3.10
> 
> patch -p1 < nvidia-linux-3.10.patch

These patches allow it to compile but there are problems with using them. I suggest not to do so. After testing them I have reconciled with going back to a 3.9.9 kernel and will wait for an official nVidia beta or release that's designed to work with 3.10.0.
Comment 130 Dmitry Suloev 2013-07-09 19:39:53 UTC
>These patches allow it to compile but there are problems with using them.
Which kind of problem you mean?
Comment 131 Chris Smith 2013-07-09 19:59:11 UTC
(In reply to Suloev Dmitry from comment #130)
> >These patches allow it to compile but there are problems with using them.
> Which kind of problem you mean?

I thought these were causing my X errors, but I'm not so sure now as I went back to 3.9.9 with the 325.08 driver.

After I'm up for a while I can no longer start GUI apps:

Ex:
$ pan
No protocol specified

(pan:12332): Gtk-WARNING **: cannot open display: :0

$ firefox
No protocol specified
No protocol specified
Error: cannot open display: :0

$ dolphin
No protocol specified
dolphin: cannot connect to X server :0

$ kate
No protocol specified
kate: cannot connect to X server :0

Was almost positive it was the hacked nVidia install causing it, but with the the official Gentoo install on a supported kernel I'm still seeing this problem.

Sorry for any false alarm.
Comment 132 Lars Wendler (Polynomial-C) (RETIRED) gentoo-dev 2013-07-18 12:59:28 UTC
*** Bug 477298 has been marked as a duplicate of this bug. ***
Comment 133 Piotr Szymaniak 2013-07-19 08:01:58 UTC
*** Bug 477358 has been marked as a duplicate of this bug. ***
Comment 134 Stephan Kupfer 2013-08-05 21:02:25 UTC
325.15 is out, maybe it works now :)

https://devtalk.nvidia.com/default/topic/571558
Comment 135 Stephan Kupfer 2013-08-05 21:10:08 UTC
(In reply to Stephan Kupfer from comment #134)
> 325.15 is out, maybe it works now :)
> 
> https://devtalk.nvidia.com/default/topic/571558

Works for me with kernel 3.10.2 without extra patch.
Comment 136 Ray Griffin (rorgoroth) 2013-08-05 21:27:52 UTC
(In reply to Stephan Kupfer from comment #135)
Works here too using pf-sources 3.10.1
Comment 137 Kelly Price 2013-08-06 02:20:26 UTC
Bug #479864 has the bump request for 325.15.
Comment 138 André Terpstra 2013-08-07 05:36:39 UTC
x11-drivers/nvidia-drivers-325.15 works with sys-kernel/gentoo-sources-3.10.5 here
Comment 139 Denis M. (Phr33d0m) 2013-08-23 07:16:45 UTC
Please mark all bugs of the sort "nvidia-* + kernel-* = does not build / builds with this patch" a duplicate of this bug.

As per Jer's decision, no patches will be added to the nvidia package to make it work with unsupported (by nvidia) kernel versions. For the reason, read the comments above.
Comment 140 Denis M. (Phr33d0m) 2013-08-23 07:26:56 UTC
*** Bug 482168 has been marked as a duplicate of this bug. ***
Comment 141 Denis M. (Phr33d0m) 2013-08-23 07:31:53 UTC
*** Bug 482164 has been marked as a duplicate of this bug. ***
Comment 142 Jeroen Roovers (RETIRED) gentoo-dev 2013-08-23 15:32:50 UTC
*** Bug 482224 has been marked as a duplicate of this bug. ***
Comment 143 Boney McCracker 2013-08-24 00:38:15 UTC
There's got to be a better way to deal with this than handling all these unnecessary bug reports.

Why not change the ebuild logic that currently checks for nvidia-supported kernel version and issues a warning (a warning often ignored) to instead check for nvidia-supported kernel version, issue the warning, and abort the ebuild (unless the user has indicated they are consciously building against an unsupported kernel version)?

That user indication that they want to build an unsupported kernel version could be handled by a USE flag, or maybe it could be assumed based on detected use of epatch_user for the ebuild.

While there's a bit of work in setting this up, I think it's probably a lot less work than processing all these erroneous bug reports.  Moreover, it might save all those users a headache by more proactively making it clear what needs to be done.

The warning message itself might be improved by more explicitly suggesting the appropriate, supported action: to mask the unsupported kernel versions.
Comment 144 Jens Ott 2013-08-24 10:22:30 UTC
I'd suggest to even go one step further and add a conflict to kernel ebuilds for kernels not supported...
Comment 145 Clemens Gruber 2013-08-24 11:24:52 UTC
A warning should be enough. It is often the case that it's not listed in the supported kernel versions, but it works anyways. If it doesn't break too often, a warning should be enough,shouldn't it?
Comment 146 Jens Ott 2013-08-24 11:32:20 UTC
I would appreciate not to install/compile a kernel while it's known that a needed module for my system will fail to build later ... especially as emerge -c will cleanup my actual kernel and does not realize, that the newer one isn't actually usable for my system.
Comment 147 C. Wijtmans 2013-08-24 11:49:54 UTC
i suggested this before but it got ignored, probably because it requires extra work.

take a look at this bug https://bugs.gentoo.org/show_bug.cgi?id=479814.
Comment 148 Rick Farina (Zero_Chaos) gentoo-dev 2013-08-24 18:10:03 UTC
(In reply to Jens Ott from comment #144)
> I'd suggest to even go one step further and add a conflict to kernel ebuilds
> for kernels not supported...

It is not Gentoo (nor any other distro's) policy to block kernel stabilization or release on binary drivers we have no control over.  It works, or it doesn't.  Your choices are 1.) use the open source driver for your hardware or 2.) deal with whatever nvidia supports 3.) buy hardware from a vendor that doesn't hate you.

I don't mean to be rude, but the fact of the matter is nvidia doesn't care, and we can't typically fix issues in a closed source driver.  The last set of patches to "support" a newer kernel were causing all kinds of stability issues.  At least nouveau typically works these days.  It's hardly amazing but it works.
Comment 149 Martin Väth 2013-08-24 20:34:52 UTC
(In reply to Rick Farina (Zero_Chaos) from comment #148)
> The last set
> of patches to "support" a newer kernel were causing all kinds of stability
> issues.

It was not these patches: AFAIK also the eventually released drivers had the same issues. So IMHO this is no argument of holding back the patches for users: Bugs and undesired interference can happen in all cases. Usage is always at own risk.

> At least nouveau typically works these days.

No, it doesn't - it is not even close to usable (on several different systems for different reasons which need not be discussed here). I have only one system with nvidia cards where an open driver was ever usable, but this is deprecated nv driver.
Comment 150 7v5w7go9ub0o 2013-08-24 21:50:15 UTC
I don't do games or 3d, and want to drop nvidia-drivers.

So which would be better for, e.g., HD streaming (nouveau or plain Linux generic nvidia driver?) on my amd64, Core i7 with GeForce 9600 GT

If neither, is there a non-Nvidia card that'll work fairly well without custom firmware?

Thanks in advance.
Comment 151 Jens Ott 2013-08-24 23:45:48 UTC
Actually it IS policy on almost all distros I know that packages not working together have defined proper conflicts. So what is the problem to set "if nvidia-drivers are installed, don't install gentoo-sources version xyz"?

And unfortunately I run gentoo on Notebooks, where I can't influence the gfx-card-hardware easily and the nouveau-driver is not able to support native resolution of the monitor. :-(
Comment 152 Boney McCracker 2013-08-25 00:19:06 UTC
(In reply to Jens Ott from comment #151)
> Actually it IS policy on almost all distros I know that packages not working
> together have defined proper conflicts. So what is the problem to set "if
> nvidia-drivers are installed, don't install gentoo-sources version xyz"?
That sounds like a good solution.

It might be a better solution if there's a way for people who want to patch it to easily over-ride the kernel conflict (i.e., by way of a USE flag or something, rather than having to create a custom ebuild).
Comment 153 Chris Stankevitz 2013-08-25 00:53:42 UTC
(In reply to Rick Farina (Zero_Chaos) from comment #148)
> It is not Gentoo (nor any other distro's) policy to block kernel
> stabilization or release on binary drivers we have no control over.

From http://www.gentoo.org/main/en/philosophy.xml

The goal of Gentoo is to design tools and systems that allow a user to do that work as pleasantly and efficiently as possible, as they see fit.  Except when binary drivers are stupid, pleasantries will be sacrificed in favor of "using the latest kernel".
Comment 154 Rick Farina (Zero_Chaos) gentoo-dev 2013-08-25 02:35:17 UTC
(In reply to Chris Stankevitz from comment #153)
> (In reply to Rick Farina (Zero_Chaos) from comment #148)
> > It is not Gentoo (nor any other distro's) policy to block kernel
> > stabilization or release on binary drivers we have no control over.
> 
> From http://www.gentoo.org/main/en/philosophy.xml
> 
> The goal of Gentoo is to design tools and systems that allow a user to do
> that work as pleasantly and efficiently as possible, as they see fit. 
> Except when binary drivers are stupid, pleasantries will be sacrificed in
> favor of "using the latest kernel".

Wasn't there a bit more of that philosophy?  Oh, right:

"Our tools should be a joy to use, and should help the user to appreciate the richness of the Linux and free software community, and the flexibility of free software."

We do our best here, but there is nothing we can do to fix binary drivers.  Some users want blockers in nvidia-drivers so they can't install against an unsupported kernel.  Some users want no blockers so they can use epatch_user with some custom patches to try and make it work.  It isn't possible to please everyone, the length of this thread should make that painfully obvious.  I'm sorry we can't make nvidia release anything usable, but baring they, we take what they give us and do the best we can for our users.
Comment 155 C. Wijtmans 2013-08-25 09:39:00 UTC
Please take a look at the bug i posted, it is a very easy solution, i just need a maintainer.
Comment 156 Chris Stankevitz 2013-08-25 22:15:51 UTC
(In reply to Rick Farina (Zero_Chaos) from comment #154)
> We do our best here, but there is nothing we can do to fix binary drivers.

I think we are saying the same thing.  The philosophy is to provide both joy and flexibility.  In this case it is impossible to provide both.  So we choose flexibility over joy.
Comment 157 Jeroen Roovers (RETIRED) gentoo-dev 2013-08-27 16:06:37 UTC
*** Bug 482686 has been marked as a duplicate of this bug. ***
Comment 158 Tom Wijsman (TomWij) (RETIRED) gentoo-dev 2013-09-03 13:12:14 UTC
*** Bug 483480 has been marked as a duplicate of this bug. ***
Comment 159 Tom Wijsman (TomWij) (RETIRED) gentoo-dev 2013-09-03 23:03:22 UTC
*** Bug 483536 has been marked as a duplicate of this bug. ***
Comment 160 Tom Wijsman (TomWij) (RETIRED) gentoo-dev 2013-09-04 09:39:25 UTC
*** Bug 482168 has been marked as a duplicate of this bug. ***
Comment 161 Julian Ospald 2013-09-10 12:05:04 UTC
Most of the arguments here do not make sense to me.

It would be easy to add a flag like "vanilla" or the opposite and force/mask the crap. Alternatively it could even depend on I_KNOW_WHAT_I_AM_DOING="yes" or similar with a big fat warning.

That would save users the time to look for the patches, but in the end that is not much of an improvement.

But people should stop pretending this is some kind of gentoo policy. It is not. It's simply a maintainer decision.

Also: any dev can commit ebuilds to the tree, so in case there is a strong maintainer disagreement we are allowed to commit a forked ebuild.

But again: this is no big deal anyway.
Comment 162 Sergey Popov gentoo-dev 2013-09-11 09:21:28 UTC
(In reply to Julian Ospald (hasufell) from comment #161)
> Most of the arguments here do not make sense to me.
> 
> It would be easy to add a flag like "vanilla" or the opposite and force/mask
> the crap. Alternatively it could even depend on I_KNOW_WHAT_I_AM_DOING="yes"
> or similar with a big fat warning.
> 
> That would save users the time to look for the patches, but in the end that
> is not much of an improvement.
> 
> But people should stop pretending this is some kind of gentoo policy. It is
> not. It's simply a maintainer decision.
> 
> Also: any dev can commit ebuilds to the tree, so in case there is a strong
> maintainer disagreement we are allowed to commit a forked ebuild.
> 
> But again: this is no big deal anyway.

We talked about this earlier. I am also disagree with this way, but if you want to go other way - just become co-maintainer of this package
Comment 163 Jeroen Roovers (RETIRED) gentoo-dev 2013-09-11 13:57:54 UTC
(In reply to Sergey Popov from comment #162)
> (In reply to Julian Ospald (hasufell) from comment #161)

> We talked about this earlier. I am also disagree with this way, but if you
> want to go other way - just become co-maintainer of this package

Or just file a bug report to explain the grand new way your solution is going to work out.
Comment 164 Chris Slycord 2013-10-02 19:10:05 UTC
Created attachment 359992 [details, diff]
nvidia-drivers-num_physpages.patch

Gets rid of the "‘num_physpages’ undeclared" error when compiling for kernel 3.11.

Just uploading it here so people don't have to search everywhere for it
Comment 165 Jeroen Roovers (RETIRED) gentoo-dev 2013-10-05 16:02:52 UTC
*** Bug 487014 has been marked as a duplicate of this bug. ***
Comment 166 Jeroen Roovers (RETIRED) gentoo-dev 2013-10-08 13:29:57 UTC
*** Bug 487282 has been marked as a duplicate of this bug. ***
Comment 167 Jeroen Roovers (RETIRED) gentoo-dev 2013-10-11 14:31:25 UTC
*** Bug 487644 has been marked as a duplicate of this bug. ***
Comment 168 Jeroen Roovers (RETIRED) gentoo-dev 2013-10-13 13:11:29 UTC
*** Bug 487862 has been marked as a duplicate of this bug. ***
Comment 169 Jeroen Roovers (RETIRED) gentoo-dev 2013-10-14 12:30:36 UTC
*** Bug 487986 has been marked as a duplicate of this bug. ***
Comment 170 tman 2013-10-22 07:08:09 UTC
(In reply to Chris Slycord from comment #164)
> Created attachment 359992 [details, diff] [details, diff]
> nvidia-drivers-num_physpages.patch
> 
> Gets rid of the "‘num_physpages’ undeclared" error when compiling for kernel
> 3.11.
> 
> Just uploading it here so people don't have to search everywhere for it

 # patch nvidia-drivers-331.13.ebuild a.patch 
patching file nvidia-drivers-331.13.ebuild
Hunk #1 FAILED at 958.
1 out of 1 hunk FAILED -- saving rejects to file nvidia-drivers-331.13.ebuild.rej
Comment 171 Jeroen Roovers (RETIRED) gentoo-dev 2013-10-23 23:18:17 UTC
*** Bug 489200 has been marked as a duplicate of this bug. ***
Comment 172 Jeroen Roovers (RETIRED) gentoo-dev 2013-10-24 16:20:06 UTC
*** Bug 489164 has been marked as a duplicate of this bug. ***
Comment 173 Tom Wijsman (TomWij) (RETIRED) gentoo-dev 2013-10-26 11:43:32 UTC
*** Bug 489454 has been marked as a duplicate of this bug. ***
Comment 174 Jeroen Roovers (RETIRED) gentoo-dev 2013-10-29 17:09:01 UTC
*** Bug 489710 has been marked as a duplicate of this bug. ***
Comment 175 Ulenrich 2013-11-03 00:32:21 UTC
There are 3 better patches for each version available, thnx megaflow:
https://devtalk.nvidia.com/default/topic/628864/unix-graphics-announcements-and-news/num_physpages-and-support-for-3-11-and-later-kernels/

This patch does a lot more than just an additional alias:
get_num_physpages_325-331.patch tested with Linux-3.11.6 is fine
Comment 176 Jeroen Roovers (RETIRED) gentoo-dev 2013-11-05 15:52:11 UTC
*** Bug 490346 has been marked as a duplicate of this bug. ***
Comment 177 Jeroen Roovers (RETIRED) gentoo-dev 2013-11-07 00:43:52 UTC
*** Bug 490606 has been marked as a duplicate of this bug. ***
Comment 178 Jeroen Roovers (RETIRED) gentoo-dev 2014-01-21 20:55:55 UTC
*** Bug 498846 has been marked as a duplicate of this bug. ***
Comment 179 Jeroen Roovers (RETIRED) gentoo-dev 2014-01-22 14:01:55 UTC
*** Bug 498892 has been marked as a duplicate of this bug. ***
Comment 180 Jeroen Roovers (RETIRED) gentoo-dev 2014-01-24 05:04:34 UTC
*** Bug 499092 has been marked as a duplicate of this bug. ***
Comment 181 Jeroen Roovers (RETIRED) gentoo-dev 2014-04-01 19:10:14 UTC
*** Bug 506466 has been marked as a duplicate of this bug. ***
Comment 182 Jeroen Roovers (RETIRED) gentoo-dev 2014-05-11 15:36:36 UTC
*** Bug 510020 has been marked as a duplicate of this bug. ***