post-352 drivers

[Luca Boccassi]

On 17 February 2016 at 08:39, Andreas Beckmann <anbe at debian.org> wrote:
> On 2016-02-10 01:09, Luca Boccassi wrote:
>> The stable release of 361 is here, 361.28. It's marked as a long lived
>> branch: http://www.nvidia.com/object/unix.html
>>
>> I've tested and pushed the changes to SVN. Main changes are that the ARM
>> installer does not ship the glvnd based libraries, but only the
>> proprietary stack. x86 installers ship both, and leave the choice to the
>> user about which to use, as suggested by upstream I've picked the glvnd
>> based libraries.
>
> I assume libOpenGL.so.0 is now getting used ... so we should probably
> move it to a separate package libopengl0-nvidia. Let's do so in
> branches/355, I'll merge later. Don't forget B+R.

ACK, I'll do that later tonight.

> I'm considering renaming the packages with th glvnd stubs to
> libfoogl42-glvnd-nvidia. What do you think?
> So we could additionally have libfoogl42-nvidia on x86 (but not
> coinstallable) and it would simplify the case for armhf where there is
> currently only the "classic" non-glvnd variant for some libs.

Agreed, I'll do that later tonight.

Also, what do you think about being pro-active and starting to have
C+R on Mesa's GLVND packages [1]. Even though they are not uploaded
yet, as soon as they are the installation is going to break,
especially for dual-stack users on optimus systems due to the file
path conflicts.

> Currently nothing depends/recommends/suggests the new ptxjitcompiler
> package.

Yeah I was not sure where it's needed. I can't see any specific
dependencies by ldd'ing around. Maybe libnvidia-compiler could be a
good place?

> Doesn't build against the grsec kernel, all other kernels build fine.

Yep, it looks like a _lot_ of work to support grsec kernels. A link
was posted not long ago in the mailing list, and a page that holds
patches to make the kernel module build was linked from there [2].

How could we handle it? I don't think it would be a good idea to just
drop that many patches in all module builds, it's risky.

Kind regards,
Luca Boccassi

[1] https://anonscm.debian.org/cgit/pkg-xorg/lib/libglvnd.git/tree/debian
[2] https://grsecurity.net/~paxguy1/