post-352 drivers

[Andreas Beckmann]

On 2016-02-17 13:04, Luca Boccassi wrote:
> 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.

thanks, and see below

>> 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.

only do this where a specific glvnd stub first occurred (355/358/361),
simplifies propagating via merge
keep the old package names in d/control (maybe with Architecture: none)
for now, even if they are currently unused (but existed in the archive
before)

the -glvnd-nvidia suffix is only for libgl1-*-glx, libegl1-*, libgles[12]-*
i.e. where we currently have multiple vendor implementations and where
we will soon have another "vendor" implementation: the glvnd stub
where the "official" package names are unclear so far, maybe dropping
the suffix completely :-)

> 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.

Yes. The interesting package names are libglx0, libgldispatch0, libopengl0.
Our packages ...
* should use the same with a -nvidia suffix (not -glvnd-nvidia)
* drop, breaks, replaces the current libglvnd-nvidia
* install directly in the system lib directory
* Breaks+Replaces the official ones (use (<< 1:) to silence lintian)
* should not depend on anything from src:nvidia*- if possible
* whereever we add a dependency on libGLVND0-nvidia, express this as
  libGLVND0 | libGLVND0  (without any versioning)
* maybe sync the package description with the "free" ones
Let me see how this looks in 355.

>> 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?

I just grepped for ptxjitcompiler to find potential dlopen(), but there
is only circular referencing with fatbinaryloader. So let's just ignore
both for now. If something needs them, they are there.

>> 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.

Oh, that looks messy. So far the module up to 358.16 built against grsec
(didn't test it beyond building), that why I expected a less intrusive
change. Maybe better ignore this for now.

Andreas