Re: [gentoo-user] Re: The NVIDIA/Kernel fiasco -- is it safe to sync yet?
On 27/08/2013 04:06, »Q« wrote: On Mon, 26 Aug 2013 08:02:32 +0200 Alan McKinnon alan.mckin...@gmail.com wrote: On 26/08/2013 03:52, »Q« wrote: I doubt your wiki page idea will work, it will be just accurate enough to look like it might work and just inaccurate enough to be useless. Which brings you back to the previous paragraph - try emerge nvidia-drivers and if it fails then don't use that kernel. I was unclear to the point of being misleading. I'm sorry. The wiki idea is only for a page which tells which kernel/nvidia-drivers combinations the Gentoo nvidia-drivers maintainers support. And by support, I mean they'll look into bugs and fix build problems if they're able to. This is exactly the info I'm grepping out of ewarn messages in their ebuilds now. That list is the list of kernels that nVidia supports, which is easy to find. Where? AIUI from reading various threads about this, sometimes that info can be found in nVidia's developer web forum, but I've never been able to find it there. nVidia's READMEs give a minimum kernel version, but no max. So ask nVidia to clearly and unambiguously state in an easily found place what kernels *they* support. Look, all issues with building the driver shim are directly the responsibility of nVidia themselves, a result of *their* business decisions. The correct thing to do is to make it nVidia's problem and not force the community to jump through hoops trying to track down what does and does not work today. Or, you could do the heavy lifting yourself. You test all current drivers with all recent kernels and maintain a gentoo wiki page that lists the info you want. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: The NVIDIA/Kernel fiasco -- is it safe to sync yet?
On Tue, Aug 27, 2013 at 12:57 PM, Alan McKinnon alan.mckin...@gmail.com wrote: On 27/08/2013 04:06, »Q« wrote: On Mon, 26 Aug 2013 08:02:32 +0200 Alan McKinnon alan.mckin...@gmail.com wrote: On 26/08/2013 03:52, »Q« wrote: I doubt your wiki page idea will work, it will be just accurate enough to look like it might work and just inaccurate enough to be useless. Which brings you back to the previous paragraph - try emerge nvidia-drivers and if it fails then don't use that kernel. I was unclear to the point of being misleading. I'm sorry. The wiki idea is only for a page which tells which kernel/nvidia-drivers combinations the Gentoo nvidia-drivers maintainers support. And by support, I mean they'll look into bugs and fix build problems if they're able to. This is exactly the info I'm grepping out of ewarn messages in their ebuilds now. That list is the list of kernels that nVidia supports, which is easy to find. Where? AIUI from reading various threads about this, sometimes that info can be found in nVidia's developer web forum, but I've never been able to find it there. nVidia's READMEs give a minimum kernel version, but no max. So ask nVidia to clearly and unambiguously state in an easily found place what kernels *they* support. Look, all issues with building the driver shim are directly the responsibility of nVidia themselves, a result of *their* business decisions. The correct thing to do is to make it nVidia's problem and not force the community to jump through hoops trying to track down what does and does not work today. Or, you could do the heavy lifting yourself. You test all current drivers with all recent kernels and maintain a gentoo wiki page that lists the info you want. Hmm... reading this thread makes me understand why Linus gave nVidia 'the bird'. Rgds, -- FdS Pandu E Poluan ~ IT Optimizer ~
Re: [gentoo-user] Re: The NVIDIA/Kernel fiasco -- is it safe to sync yet?
On 27/08/2013 09:14, Pandu Poluan wrote: That list is the list of kernels that nVidia supports, which is easy to find. Where? AIUI from reading various threads about this, sometimes that info can be found in nVidia's developer web forum, but I've never been able to find it there. nVidia's READMEs give a minimum kernel version, but no max. So ask nVidia to clearly and unambiguously state in an easily found place what kernels *they* support. Look, all issues with building the driver shim are directly the responsibility of nVidia themselves, a result of *their* business decisions. The correct thing to do is to make it nVidia's problem and not force the community to jump through hoops trying to track down what does and does not work today. Or, you could do the heavy lifting yourself. You test all current drivers with all recent kernels and maintain a gentoo wiki page that lists the info you want. Hmm... reading this thread makes me understand why Linus gave nVidia 'the bird'. I'm not so sure. I can understand nVidia's position. They make and sell hardware. They want their stuff to run on as many things as possible. They also have a huge codebase driven mostly by the primary OS of their users - Windows. Maintaining that is a large job so they'd like to re-use the bulk of it across all OSes. Business-wise this does make sense. But it does mean that they have to drop support for much built-in goodness on Linux (KMS, shipped OpenGL and more) and provide that bit themselves. No biggy - they have it all already for Windows. The kernel shim module is GPL'ed, but not in mainline, and there's this little thing about the Linux kernel - the famous stable api nonsense. So they are forever playing catch-up, and the kernel DOES rip out huge chunks of the api as and when needed. So what's nVidia to do? By and large their support for X11 is pretty good, and I've seen much worse. Yes, they are behind current kernel releases. No, they are not years behind. For the most part their code keeps up with the major binary distros. To those users who want to run whatever kernel Linux shipped today and expect nVidia to always keep up, I have an answer: get real people. nvidia support Linux, they never promised to keep up with Linus. Why do users think they have a right to demand something from a vendor that the vendor never promised to do? Why do some users think it correct and proper to demand the Gentoo maintainers jump through hoops to provide functionality that nVidia never promised, for versions they do not support *yet*? Seriously, to all the nVidia dumpers (not you Pandu), get a life people and get real. You bought hardware knowing full well what the conditions for drivers were going to be. The vendor does an OK job in the market place and if you don't like that, well that's tough. Buy different hardware. But don't expect entities to do stuff they never agreed to do. To Gentoo users who dump on this matter, when you installed Gentoo you implicitly agreed to be your own packager. There is no PPA or Yum repo and there's no paid staff member building packages. The work the packager does for Ubuntu and RedHat is now you now have to do yourself, and part of that is dealing with the times when shit don't work. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: The NVIDIA/Kernel fiasco -- is it safe to sync yet?
On 26/08/2013 03:52, »Q« wrote: I doubt your wiki page idea will work, it will be just accurate enough to look like it might work and just inaccurate enough to be useless. Which brings you back to the previous paragraph - try emerge nvidia-drivers and if it fails then don't use that kernel. I was unclear to the point of being misleading. I'm sorry. The wiki idea is only for a page which tells which kernel/nvidia-drivers combinations the Gentoo nvidia-drivers maintainers support. And by support, I mean they'll look into bugs and fix build problems if they're able to. This is exactly the info I'm grepping out of ewarn messages in their ebuilds now. That list is the list of kernels that nVidia supports, which is easy to find. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: The NVIDIA/Kernel fiasco -- is it safe to sync yet?
On 25/08/2013 02:45, »Q« wrote: On Sat, 24 Aug 2013 09:49:43 +0200 Alan McKinnon alan.mckin...@gmail.com wrote: On 24/08/2013 06:26, Chris Stankevitz wrote: On Fri, Aug 23, 2013 at 9:12 PM, »Q« boxc...@gmx.net wrote: It looks like maybe the best way to tell which ebuilds support which kernels is to read the conditional for the ewarn message in each ebuild. If this sort of problem spreads it might be good to build into portage some kind of blocker/keyword mechanism so that users need not deal with this not that I have any appreciation for the work involved. Those tools already exist. Blockers, which do not really apply here; In a comment on the bug (which is full of bugspam), someone suggested blocking kernels which are incompatible with the currently-installed nvidia-drivers. I'm glad that idea was dismissed. elog messages Those elog messages are presented after compiling a new kernel and then trying and failing to compile nvidia-drivers. So now I grep the nvidia-drivers ebuilds for the messages before I compile a new kernel. A wiki page with info about which nvidia-drivers will build against which kernels would be a nice thing to have. Your reply demonstrates nicely the true nature of the problem: With nvidia-drivers, sometimes things break and there's nothing sane that portage and the devs can do to help you. You can't check the configured kernels as they may not be running. You can't check the installed sources as they may not be in use. You can't even try identify the sources symlinked by /usr/src/linux as they may have been patched, tweaked or modified and nvidia-drivers may well build whereas against stock sources they don't. The entire problem is completely due to how nVidia chose to do things, it's their business decision. Now, if they were to get their shim code into mainline, most of this nonsense would not happen anymore. The only thing left for Portage and the devs to do is to provide the ebuild and ask you to run it. If it doesn't compile, then don't run that kernel. I doubt your wiki page idea will work, it will be just accurate enough to look like it might work and just inaccurate enough to be useless. Which brings you back to the previous paragraph - try emerge nvidia-drivers and if it fails then don't use that kernel. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: The NVIDIA/Kernel fiasco -- is it safe to sync yet?
On Sunday 25 Aug 2013 17:18:09 Alan McKinnon wrote: On 25/08/2013 02:45, »Q« wrote: On Sat, 24 Aug 2013 09:49:43 +0200 Alan McKinnon alan.mckin...@gmail.com wrote: On 24/08/2013 06:26, Chris Stankevitz wrote: On Fri, Aug 23, 2013 at 9:12 PM, »Q« boxc...@gmx.net wrote: It looks like maybe the best way to tell which ebuilds support which kernels is to read the conditional for the ewarn message in each ebuild. If this sort of problem spreads it might be good to build into portage some kind of blocker/keyword mechanism so that users need not deal with this not that I have any appreciation for the work involved. Those tools already exist. Blockers, which do not really apply here; In a comment on the bug (which is full of bugspam), someone suggested blocking kernels which are incompatible with the currently-installed nvidia-drivers. I'm glad that idea was dismissed. elog messages Those elog messages are presented after compiling a new kernel and then trying and failing to compile nvidia-drivers. So now I grep the nvidia-drivers ebuilds for the messages before I compile a new kernel. A wiki page with info about which nvidia-drivers will build against which kernels would be a nice thing to have. Your reply demonstrates nicely the true nature of the problem: With nvidia-drivers, sometimes things break and there's nothing sane that portage and the devs can do to help you. You can't check the configured kernels as they may not be running. You can't check the installed sources as they may not be in use. You can't even try identify the sources symlinked by /usr/src/linux as they may have been patched, tweaked or modified and nvidia-drivers may well build whereas against stock sources they don't. The entire problem is completely due to how nVidia chose to do things, it's their business decision. Now, if they were to get their shim code into mainline, most of this nonsense would not happen anymore. The only thing left for Portage and the devs to do is to provide the ebuild and ask you to run it. If it doesn't compile, then don't run that kernel. I doubt your wiki page idea will work, it will be just accurate enough to look like it might work and just inaccurate enough to be useless. Which brings you back to the previous paragraph - try emerge nvidia-drivers and if it fails then don't use that kernel. I've been always running ATI Radeon cards, by accident rather than design. I was thinking of moving to NVidia on a new box to be built soon, because of the many accolades that I have read on the Internet, but reports of problems like this make me pause for thought. Sure it's not major borkage, but it is an inconvenience. How do NVidia users manage such problems? Trial and error? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: The NVIDIA/Kernel fiasco -- is it safe to sync yet?
On 08/25/2013 06:34 PM, Mick wrote: On Sunday 25 Aug 2013 17:18:09 Alan McKinnon wrote: On 25/08/2013 02:45, »Q« wrote: On Sat, 24 Aug 2013 09:49:43 +0200 Alan McKinnon alan.mckin...@gmail.com wrote: On 24/08/2013 06:26, Chris Stankevitz wrote: On Fri, Aug 23, 2013 at 9:12 PM, »Q« boxc...@gmx.net wrote: It looks like maybe the best way to tell which ebuilds support which kernels is to read the conditional for the ewarn message in each ebuild. If this sort of problem spreads it might be good to build into portage some kind of blocker/keyword mechanism so that users need not deal with this not that I have any appreciation for the work involved. Those tools already exist. Blockers, which do not really apply here; In a comment on the bug (which is full of bugspam), someone suggested blocking kernels which are incompatible with the currently-installed nvidia-drivers. I'm glad that idea was dismissed. elog messages Those elog messages are presented after compiling a new kernel and then trying and failing to compile nvidia-drivers. So now I grep the nvidia-drivers ebuilds for the messages before I compile a new kernel. A wiki page with info about which nvidia-drivers will build against which kernels would be a nice thing to have. Your reply demonstrates nicely the true nature of the problem: With nvidia-drivers, sometimes things break and there's nothing sane that portage and the devs can do to help you. You can't check the configured kernels as they may not be running. You can't check the installed sources as they may not be in use. You can't even try identify the sources symlinked by /usr/src/linux as they may have been patched, tweaked or modified and nvidia-drivers may well build whereas against stock sources they don't. The entire problem is completely due to how nVidia chose to do things, it's their business decision. Now, if they were to get their shim code into mainline, most of this nonsense would not happen anymore. The only thing left for Portage and the devs to do is to provide the ebuild and ask you to run it. If it doesn't compile, then don't run that kernel. I doubt your wiki page idea will work, it will be just accurate enough to look like it might work and just inaccurate enough to be useless. Which brings you back to the previous paragraph - try emerge nvidia-drivers and if it fails then don't use that kernel. I've been always running ATI Radeon cards, by accident rather than design. I was thinking of moving to NVidia on a new box to be built soon, because of the many accolades that I have read on the Internet, but reports of problems like this make me pause for thought. Sure it's not major borkage, but it is an inconvenience. How do NVidia users manage such problems? Trial and error? Sort of. When I hit a nice spot with a kernel/nvidia-driver combination, then I do not update both for quite a while.
Re: [gentoo-user] Re: The NVIDIA/Kernel fiasco -- is it safe to sync yet?
On 25/08/2013 18:34, Mick wrote: On Sunday 25 Aug 2013 17:18:09 Alan McKinnon wrote: On 25/08/2013 02:45, »Q« wrote: On Sat, 24 Aug 2013 09:49:43 +0200 Alan McKinnon alan.mckin...@gmail.com wrote: On 24/08/2013 06:26, Chris Stankevitz wrote: On Fri, Aug 23, 2013 at 9:12 PM, »Q« boxc...@gmx.net wrote: It looks like maybe the best way to tell which ebuilds support which kernels is to read the conditional for the ewarn message in each ebuild. If this sort of problem spreads it might be good to build into portage some kind of blocker/keyword mechanism so that users need not deal with this not that I have any appreciation for the work involved. Those tools already exist. Blockers, which do not really apply here; In a comment on the bug (which is full of bugspam), someone suggested blocking kernels which are incompatible with the currently-installed nvidia-drivers. I'm glad that idea was dismissed. elog messages Those elog messages are presented after compiling a new kernel and then trying and failing to compile nvidia-drivers. So now I grep the nvidia-drivers ebuilds for the messages before I compile a new kernel. A wiki page with info about which nvidia-drivers will build against which kernels would be a nice thing to have. Your reply demonstrates nicely the true nature of the problem: With nvidia-drivers, sometimes things break and there's nothing sane that portage and the devs can do to help you. You can't check the configured kernels as they may not be running. You can't check the installed sources as they may not be in use. You can't even try identify the sources symlinked by /usr/src/linux as they may have been patched, tweaked or modified and nvidia-drivers may well build whereas against stock sources they don't. The entire problem is completely due to how nVidia chose to do things, it's their business decision. Now, if they were to get their shim code into mainline, most of this nonsense would not happen anymore. The only thing left for Portage and the devs to do is to provide the ebuild and ask you to run it. If it doesn't compile, then don't run that kernel. I doubt your wiki page idea will work, it will be just accurate enough to look like it might work and just inaccurate enough to be useless. Which brings you back to the previous paragraph - try emerge nvidia-drivers and if it fails then don't use that kernel. I've been always running ATI Radeon cards, by accident rather than design. I was thinking of moving to NVidia on a new box to be built soon, because of the many accolades that I have read on the Internet, but reports of problems like this make me pause for thought. Sure it's not major borkage, but it is an inconvenience. How do NVidia users manage such problems? Trial and error? The second (trial and error). When you find a combination that works correctly and well, mark it in your mind as stable++ and stick with it. My current laptop has a Radeon, the three before that were nVidia. I just got used to having to use a kernel that was a few versions behind the most current one to be able to use the binary blob driver. It's really no big deal in the grand scheme of things - kernels don't change their behaviour *that* much between versions - most user-facing changes are new drivers and decent power management stuff. More often than not the user will have got along just nicely with an older kernel for a while, and that kernel will carry on doing what it always did and work. It's very rare that a user *must* have some new kernel and absolutely cannot go back to an earlier version. I satisfied myself with trying the most recent kernels once a month and seeing if the drivers built. If yes, and they worked, great. If not, oh well I would just go back to what I had before. Half the time I'd have to do that anyway due to some regression from nVidia anyway (I lost track of how often a driver update would send GPU temps through the roof and have the fan running constantly) nouveau also worked well for me. I don't need fancy 3D graphics (KDE and e17 effects is about my limit of GPU stressing) and I don't need awesome battery life, so I was willing to trade power efficiency and piece-of-mid efficiency. Your needs might be different so YMMV. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: The NVIDIA/Kernel fiasco -- is it safe to sync yet?
hasufell wrote: On 08/25/2013 06:34 PM, Mick wrote: I've been always running ATI Radeon cards, by accident rather than design. I was thinking of moving to NVidia on a new box to be built soon, because of the many accolades that I have read on the Internet, but reports of problems like this make me pause for thought. Sure it's not major borkage, but it is an inconvenience. How do NVidia users manage such problems? Trial and error? Sort of. When I hit a nice spot with a kernel/nvidia-driver combination, then I do not update both for quite a while. I rarely have issues with them installing. I may find some odd bug but not a clash with kernel and driver. Then again, I don't update my kernel very often either. I did make it to 3.9.5 a little while back. I do recall reading about issues with the 3.10.* kernels tho. I think something moved or something and Nvidia needed to update the drivers. I would usually say I am lucky but folks that know me know better than that. lol Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] Re: The NVIDIA/Kernel fiasco -- is it safe to sync yet?
On 24/08/2013 06:26, Chris Stankevitz wrote: On Fri, Aug 23, 2013 at 9:12 PM, »Q« boxc...@gmx.net wrote: It looks like maybe the best way to tell which ebuilds support which kernels is to read the conditional for the ewarn message in each ebuild. If this sort of problem spreads it might be good to build into portage some kind of blocker/keyword mechanism so that users need not deal with this not that I have any appreciation for the work involved. Those tools already exist. Blockers, which do not really apply here; elog messages 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. 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. Kind of funny... Gentoo's mandate is sort of at odds with itself. A joy to use while simultaneously giving full flexibility. Chris -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: The NVIDIA/Kernel fiasco -- is it safe to sync yet?
On Fri, Aug 23, 2013 at 9:12 PM, »Q« boxc...@gmx.net wrote: It looks like maybe the best way to tell which ebuilds support which kernels is to read the conditional for the ewarn message in each ebuild. If this sort of problem spreads it might be good to build into portage some kind of blocker/keyword mechanism so that users need not deal with this not that I have any appreciation for the work involved. 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. 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. Kind of funny... Gentoo's mandate is sort of at odds with itself. A joy to use while simultaneously giving full flexibility. Chris
