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.
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.
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.
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.
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. ***
*** Bug 450952 has been marked as a duplicate of this bug. ***
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.
Just confirming the behavior indicated by Martin with respect to out-of-source builds. The version.h symlink workaround works for me.
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).
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.
(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.
Added to bleeding-edge overlay: nvidia-drivers-173.14.36 patched for 3.7, thanks to Martin Väth! (bug 447566)
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?
*** Bug 455496 has been marked as a duplicate of this bug. ***
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!
*** Bug 455942 has been marked as a duplicate of this bug. ***
*** Bug 455940 has been marked as a duplicate of this bug. ***
*** Bug 455918 has been marked as a duplicate of this bug. ***
*** Bug 455974 has been marked as a duplicate of this bug. ***
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
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.
(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.
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
(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.
I confirm problem here. No compiling against kernel 3.7.6
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.
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.
*** Bug 456226 has been marked as a duplicate of this bug. ***
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
(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.
(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.
The patches for 313.18 work against vanilla-sources and allow me to compile the drivers. BTW, thanks Everet for that tip with patches!
Commit message: Fix building against linux-3.7+ http://sources.gentoo.org/x11-drivers/nvidia-drivers/files/nvidia-drivers-313.18-linux-3.7+.patch?rev=1.1 http://sources.gentoo.org/x11-drivers/nvidia-drivers/nvidia-drivers-313.18.ebuild?r1=1.2&r2=1.3
Looks like same problem for linux 3.8.0
*** Bug 458246 has been marked as a duplicate of this bug. ***
(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.
(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
*** Bug 458382 has been marked as a duplicate of this bug. ***
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
(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.
can we have this now in portage?
(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!
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.
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
*** Bug 458738 has been marked as a duplicate of this bug. ***
*** Bug 458850 has been marked as a duplicate of this bug. ***
*** Bug 459036 has been marked as a duplicate of this bug. ***
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.
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)
A patch is also needed for x11-drivers/nvidia-drivers-310.32 because it was stabilized yesterday.
*** Bug 459468 has been marked as a duplicate of this bug. ***
*** Bug 459488 has been marked as a duplicate of this bug. ***
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.
*** Bug 459786 has been marked as a duplicate of this bug. ***
No need for new patches, nvidia-drivers-313.18-linux-3.7+.patch from FILESDIR already does the job.
(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.
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.
(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 >>
(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.
*** Bug 460014 has been marked as a duplicate of this bug. ***
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
(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.
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?
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
(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.
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
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?
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
*** Bug 460104 has been marked as a duplicate of this bug. ***
(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.
(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.
(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
(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.
(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.
(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.
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.
(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.
(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.
(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.
Partially upstreamed to nVidia's Linux driver dev forum: https://devtalk.nvidia.com/default/topic/528786/linux/linux-3-8-incompatibility/1
After using the patch in
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.
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?
Complaints -> nvidia.
(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
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.
(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.
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.
(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.
Thanks @maintainer for all your good work. Everyone else, use epatch_user and use your energy to do something productive.
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?
(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.
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.
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).
(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.
trying again to take it, failed earlier due to mid air collision
(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}.
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
> 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.
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
(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
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.
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.
why not mask the kernel that doesnt work with nvidia-drivers on stable?
*** Bug 461266 has been marked as a duplicate of this bug. ***
> 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."
(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.
*** Bug 463228 has been marked as a duplicate of this bug. ***
*** Bug 454560 has been marked as a duplicate of this bug. ***
*** Bug 475382 has been marked as a duplicate of this bug. ***
*** Bug 475396 has been marked as a duplicate of this bug. ***
*** Bug 475406 has been marked as a duplicate of this bug. ***
*** Bug 475466 has been marked as a duplicate of this bug. ***
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.
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
(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.
(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.
(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.
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...
*** Bug 475694 has been marked as a duplicate of this bug. ***
*** Bug 475700 has been marked as a duplicate of this bug. ***
*** Bug 475698 has been marked as a duplicate of this bug. ***
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 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.
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.
*** Bug 475990 has been marked as a duplicate of this bug. ***
*** Bug 476046 has been marked as a duplicate of this bug. ***
Created attachment 352940 [details, diff] Patch to fix the compilation errors on 3.10 patch -p1 < nvidia-linux-3.10.patch
*** Bug 476302 has been marked as a duplicate of this bug. ***
(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.
>These patches allow it to compile but there are problems with using them. Which kind of problem you mean?
(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.
*** Bug 477298 has been marked as a duplicate of this bug. ***
*** Bug 477358 has been marked as a duplicate of this bug. ***
325.15 is out, maybe it works now :) https://devtalk.nvidia.com/default/topic/571558
(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.
(In reply to Stephan Kupfer from comment #135) Works here too using pf-sources 3.10.1
Bug #479864 has the bump request for 325.15.
x11-drivers/nvidia-drivers-325.15 works with sys-kernel/gentoo-sources-3.10.5 here
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.
*** Bug 482168 has been marked as a duplicate of this bug. ***
*** Bug 482164 has been marked as a duplicate of this bug. ***
*** Bug 482224 has been marked as a duplicate of this bug. ***
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.
I'd suggest to even go one step further and add a conflict to kernel ebuilds for kernels not supported...
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?
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.
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.
(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.
(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.
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.
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. :-(
(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).
(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".
(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.
Please take a look at the bug i posted, it is a very easy solution, i just need a maintainer.
(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.
*** Bug 482686 has been marked as a duplicate of this bug. ***
*** Bug 483480 has been marked as a duplicate of this bug. ***
*** Bug 483536 has been marked as a duplicate of this bug. ***
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.
(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
(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.
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
*** Bug 487014 has been marked as a duplicate of this bug. ***
*** Bug 487282 has been marked as a duplicate of this bug. ***
*** Bug 487644 has been marked as a duplicate of this bug. ***
*** Bug 487862 has been marked as a duplicate of this bug. ***
*** Bug 487986 has been marked as a duplicate of this bug. ***
(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
*** Bug 489200 has been marked as a duplicate of this bug. ***
*** Bug 489164 has been marked as a duplicate of this bug. ***
*** Bug 489454 has been marked as a duplicate of this bug. ***
*** Bug 489710 has been marked as a duplicate of this bug. ***
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
*** Bug 490346 has been marked as a duplicate of this bug. ***
*** Bug 490606 has been marked as a duplicate of this bug. ***
*** Bug 498846 has been marked as a duplicate of this bug. ***
*** Bug 498892 has been marked as a duplicate of this bug. ***
*** Bug 499092 has been marked as a duplicate of this bug. ***
*** Bug 506466 has been marked as a duplicate of this bug. ***
*** Bug 510020 has been marked as a duplicate of this bug. ***