| Summary: | =x11-drivers/nvidia-drivers - Stabilize versions that compile against >=sys-kernel/*-sources-3.7. | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | dolohow |
| Component: | [OLD] Keywording and Stabilization | Assignee: | Jeroen Roovers (RETIRED) <jer> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | enhancement | CC: | nitro, xarthisius |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
dolohow
2013-03-10 14:58:30 UTC
Please be more clear about what problem you are experiencing and how a version bump would resolve this; it currently sounds more like you need to run `emerge emerge -1 @module-rebuild` on the new kernel you have downgraded or upgraded to, because most versions in the Portage tree are working fine together. (In reply to comment #0) > =x11-drivers/nvidia-drivers =x11-drivers/nvidia-drivers is not a valid package atom; did you mean all or some versions of x11-drivers/nvidia-drivers or just a specific version, which one(s)? > version bump due to masked kernel 3.5.7 How does the masking of kernel 3.5.7 affect your usage of nvidia-drivers? > lack of support for <kernel 3.7 What exactly do you mean with this? Their is support there, especially in the Long Term Support branches; you can see a list of them on kernel.org. 2.4.22 and up are supported according to http://us.download.nvidia.com/XFree86/Linux-x86/310.40/README/minimumrequirements.html so Nvidia supports them as well. I mean that =x11-drivers/nvidia-drivers-310.32 which marked as stable can't be compiled on =sys-kernel/gentoo-sources-3.7.10 which is also stable. I suggest to mark =x11-drivers/nvidia-drivers-313.26 as stable considering above. Apologies for not enough information emerge --info http://paste.kde.org/691964/62929961/ I'm afraid it is to soon to consider stabilization, let's see... Guys - I didn't come here to complain (honest!), but this is pretty irritating. This is the second kernel bump in a row that I had trouble with because the stable nvidia driver does not support the stable kernel. Shouldn't part of the release process for something like that kernel include verifying that other packages depending on it will work with the new version? I know that's how core system components such as gcc are handled, and also why it takes so darn long for a new major version to be released. Now, while gcc and the kernal obviously aren't equivalent, I don't see why the same logic shouldn't also be applied here where it makes sense. If a new kernel version is ready to be bumped, also bump the major driver packages. If those driver packages are not yet ready, then treat them as blockers and hold off on the kernel upgrade. If it's a kernel security issue, then I do understand the need for a speedy release, but can you please give some consideration to other packages that will be affected? If a new kernel version *must* be released ASAP, and a minor nvidia-drivers version bump is all that's necessary to support it, then it seems like that would be a reasonable circumstance in which the driver can/should be fast-tracked as well. Alternatively, could a patch to support the newer kernel be backported to the current stable driver? That'd also be perfectly fine. But, bumping the kernel without taking care of the drivers as well simply breaks stable users' systems. I guess you may not see this because you run unstable (or perhaps you don't use an nvidia card, in which case you simply may not care), but the whole point of running stable is for things to simply work. When I reboot after updating my stable system and my video driver is suddenly busted, that's not working. Again, I didn't come here to complain, but simply to file a bug report about this. After finding that a bug was already filed, though... the response I saw wasn't particularly encouraging. If you're not willing to do anything about it now, please at least keep this issue in mind for future bumps. (In reply to comment #4) > Guys - I didn't come here to complain (honest!), but this is pretty > irritating. This is the second kernel bump in a row that I had trouble with > because the stable nvidia driver does not support the stable kernel. > Shouldn't part of the release process for something like that kernel include > verifying that other packages depending on it will work with the new > version? I know that's how core system components such as gcc are handled, > and also why it takes so darn long for a new major version to be released. > > Now, while gcc and the kernal obviously aren't equivalent, I don't see why > the same logic shouldn't also be applied here where it makes sense. If a > new kernel version is ready to be bumped, also bump the major driver > packages. If those driver packages are not yet ready, then treat them as > blockers and hold off on the kernel upgrade. If it's a kernel security > issue, then I do understand the need for a speedy release, but can you > please give some consideration to other packages that will be affected? > > If a new kernel version *must* be released ASAP, and a minor nvidia-drivers > version bump is all that's necessary to support it, then it seems like that > would be a reasonable circumstance in which the driver can/should be > fast-tracked as well. Alternatively, could a patch to support the newer > kernel be backported to the current stable driver? That'd also be perfectly > fine. But, bumping the kernel without taking care of the drivers as well > simply breaks stable users' systems. I guess you may not see this because > you run unstable (or perhaps you don't use an nvidia card, in which case you > simply may not care), but the whole point of running stable is for things to > simply work. When I reboot after updating my stable system and my video > driver is suddenly busted, that's not working. > > Again, I didn't come here to complain, but simply to file a bug report about > this. After finding that a bug was already filed, though... the response I > saw wasn't particularly encouraging. If you're not willing to do anything > about it now, please at least keep this issue in mind for future bumps. I completely agree with this man I agree with the fact that a new kernel stabilization can't be achieved without full support for it (on a stable system). And at the same time, non nvidia-users can't wait for nvidia support for get the last kernel version. Can we use a mechanism to allow a package to mask another package? Fo example: nvidia-drivers-310.32 can mask all kernels >=3.7 avoiding nvidia-users to update to an unsupported kernel. At the same time, "other" users do not have to wait for nvidia support untill update to last stable kernel. When a new nvidia-drivers become stable (and allow kernel >=3.7), automatically kernel >=3.7 get unmasked and become stable for that users too. I think this solution will make everyone happy. (In reply to comment #6) > I agree with the fact that a new kernel stabilization can't be achieved > without full support for it (on a stable system). > And at the same time, non nvidia-users can't wait for nvidia support for get > the last kernel version. > Can we use a mechanism to allow a package to mask another package? > > Fo example: nvidia-drivers-310.32 can mask all kernels >=3.7 avoiding > nvidia-users to update to an unsupported kernel. At the same time, "other" > users do not have to wait for nvidia support untill update to last stable > kernel. > > When a new nvidia-drivers become stable (and allow kernel >=3.7), > automatically kernel >=3.7 get unmasked and become stable for that users too. > > I think this solution will make everyone happy. It's not a good idea, the better solution is one proposed by @Jared B. In this particular problem the 3.5.7 kernel should be patched with upstream. Dolohow, does stable nvidia (310.32) not build with gentoo-sources-3.6.11-r1? I find it odd you did not mention that kernel since we have been on linux 3.6 for quite a while before 3.7. I have had unstable nvidia drivers unmasked for a long time. nvidia 313.26 works fine with 3.6 kernels, but it does not work with 3.7 kernel for me. It *builds* and the nvidia module loads but X will not start. Does it work for you? I get the following error... Loading extension GLX NVIDIA: could not open the device file /dev/nvidia0 (Input/output error). Fatal server error: no screens found (EE) regarding comment 8: It is possible that your hardware is too old for the 310.x drivers (in my case they dropped support for the Geforce go 7 series chips). The solution will probably involve (eventually) stabling the 313 kernel, but also bumping a patched 304, 173 and 96 nvidia driver to satisfy people with old hardware, but with post 3.7 kernels. (In reply to comment #7) > (In reply to comment #6) > > I agree with the fact that a new kernel stabilization can't be achieved > > without full support for it (on a stable system). > > And at the same time, non nvidia-users can't wait for nvidia support for get > > the last kernel version. > > Can we use a mechanism to allow a package to mask another package? > > > > Fo example: nvidia-drivers-310.32 can mask all kernels >=3.7 avoiding > > nvidia-users to update to an unsupported kernel. At the same time, "other" > > users do not have to wait for nvidia support untill update to last stable > > kernel. > > > > When a new nvidia-drivers become stable (and allow kernel >=3.7), > > automatically kernel >=3.7 get unmasked and become stable for that users too. > > > > I think this solution will make everyone happy. > > It's not a good idea, the better solution is one proposed by @Jared B. > In this particular problem the 3.5.7 kernel should be patched with upstream. Why not? Could you explain me why it's a bad idea? Just for curiosity :) *** This bug has been marked as a duplicate of bug 461664 *** *** This bug has been marked as a duplicate of bug 447566 *** |
