| 1 |
On Sun, 25 Aug 2013 18:18:09 +0200 |
| 2 |
Alan McKinnon <alan.mckinnon@×××××.com> wrote: |
| 3 |
|
| 4 |
> On 25/08/2013 02:45, »Q« wrote: |
| 5 |
> > On Sat, 24 Aug 2013 09:49:43 +0200 |
| 6 |
> > Alan McKinnon <alan.mckinnon@×××××.com> wrote: |
| 7 |
> > |
| 8 |
> >> On 24/08/2013 06:26, Chris Stankevitz wrote: |
| 9 |
> >>> On Fri, Aug 23, 2013 at 9:12 PM, »Q« <boxcars@×××.net> wrote: |
| 10 |
> >>>> It looks like maybe the best way to tell which ebuilds support |
| 11 |
> >>>> which kernels is to read the conditional for the ewarn message in |
| 12 |
> >>>> each ebuild. |
| 13 |
> >>> |
| 14 |
> >>> If this sort of problem spreads it might be good to build into |
| 15 |
> >>> portage some kind of blocker/keyword mechanism so that users need |
| 16 |
> >>> not deal with this.... not that I have any appreciation for the |
| 17 |
> >>> work involved. |
| 18 |
> >> |
| 19 |
> >> Those tools already exist. |
| 20 |
> >> |
| 21 |
> >> Blockers, which do not really apply here; |
| 22 |
> > |
| 23 |
> > In a comment on the bug (which is full of bugspam), someone |
| 24 |
> > suggested blocking kernels which are incompatible with the |
| 25 |
> > currently-installed nvidia-drivers. I'm glad that idea was |
| 26 |
> > dismissed. |
| 27 |
> > |
| 28 |
> >> elog messages |
| 29 |
> > |
| 30 |
> > Those elog messages are presented after compiling a new kernel and |
| 31 |
> > then trying and failing to compile nvidia-drivers. So now I grep |
| 32 |
> > the nvidia-drivers ebuilds for the messages before I compile a new |
| 33 |
> > kernel. |
| 34 |
> > |
| 35 |
> > A wiki page with info about which nvidia-drivers will build against |
| 36 |
> > which kernels would be a nice thing to have. |
| 37 |
> |
| 38 |
> Your reply demonstrates nicely the true nature of the problem: |
| 39 |
> |
| 40 |
> With nvidia-drivers, sometimes things break and there's nothing sane |
| 41 |
> that portage and the devs can do to help you. You can't check the |
| 42 |
> configured kernels as they may not be running. You can't check the |
| 43 |
> installed sources as they may not be in use. You can't even try |
| 44 |
> identify the sources symlinked by /usr/src/linux as they may have |
| 45 |
> been patched, tweaked or modified and nvidia-drivers may well build |
| 46 |
> whereas against stock sources they don't. |
| 47 |
> |
| 48 |
> The entire problem is completely due to how nVidia chose to do things, |
| 49 |
> it's their business decision. Now, if they were to get their shim code |
| 50 |
> into mainline, most of this nonsense would not happen anymore. |
| 51 |
> |
| 52 |
> The only thing left for Portage and the devs to do is to provide the |
| 53 |
> ebuild and ask you to run it. If it doesn't compile, then don't run |
| 54 |
> that kernel. |
| 55 |
> |
| 56 |
> I doubt your wiki page idea will work, it will be just accurate enough |
| 57 |
> to look like it might work and just inaccurate enough to be useless. |
| 58 |
> Which brings you back to the previous paragraph - try emerge |
| 59 |
> nvidia-drivers and if it fails then don't use that kernel. |
| 60 |
|
| 61 |
I was unclear to the point of being misleading. I'm sorry. |
| 62 |
|
| 63 |
The wiki idea is only for a page which tells which |
| 64 |
kernel/nvidia-drivers combinations the Gentoo nvidia-drivers |
| 65 |
maintainers support. And by "support", I mean they'll look into bugs |
| 66 |
and fix build problems if they're able to. This is exactly the info I'm |
| 67 |
grepping out of ewarn messages in their ebuilds now. |
Archives