post-352 drivers

[Luca Boccassi]

On Wed, 2016-02-17 at 14:46 +0100, Andreas Beckmann wrote:
> 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.

Ran a bit late so only had time to do 355. Committed to SVN, please have
a look when you have time.

Did a quick test on my laptop, installing all the 355.11-3 packages over
355.11-2 (with dpkg --auto-deconfigure to do what apt does) and
everything went smooth.

If it looks ok to you, tomorrow I'll do 358 and 361 too.

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

ACK.

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

ACK. We can look again if we get requests from users.

Kind regards,
Luca Boccassi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-nvidia-devel/attachments/20160218/798b6d60/attachment.sig>