355 branched and committed to SVN

[Luca Boccassi]

On Sun, 2015-10-18 at 23:31 +0100, Luca Boccassi wrote:
> On 18 October 2015 at 13:08, Luca Boccassi <luca.boccassi at gmail.com> wrote:
> > On Sat, 2015-10-17 at 19:02 +0100, Luca Boccassi wrote:
> >> On 17 October 2015 at 18:37, Andreas Beckmann <anbe at debian.org> wrote:
> >> > On 2015-10-17 18:40, Luca Boccassi wrote:
> >> >> I am sorry for this merry-go-round, I should have noticed immediately
> >> >> when I did the upgrade.
> >> >
> >> > If all things would be obvious, we would have noticed the device
> >> > permission problem a year ago :-)
> >> >
> >> > Previously nvidia's conftest.sh script would not run at all with Debian
> >> > packaged kernel headers, but maybe this has changed now. At least I saw
> >> > something like enumerating all the tests when building 358.xx modules.
> >> > So maybe we can stop maintaining out own conftest.h in the 355+ future.
> >> > But also here it would be important to delegate compiler and options
> >> > selection to kbuild. Checkin for header existence should be via
> >> > compiling stuff, not test -f (the kernel source layout must be opaque).
> >>
> >> A patch is missing for the new kernel module, I'll add it tomorrow.
> >> Due to the new architecture it's not trivial to simply remove the
> >> script as before, since the makefiles would need a lot of patching. I
> >> found much easier to simply remove the dependency in the makefiles so
> >> that it's not ran, but it needs to be done per-module and the new
> >> nvidia-modeset doesn't have it yet. Once it's there, it won't run
> >> anymore.
> >
> > Tested and committed to branches/358.
> >
> > These per-module one-line patches are the best I could come up with to
> > deal with this. Maintenance should be low enough, given that adding new
> > kernel modules should be a rare enough event, and it would require other
> > changes on our side anyway. But if there's a better way please let's go
> > for it :-)
> >
> > It certainly would be nice to be able to use upstream's conftest.sh and
> > not have to maintain our own static header, but patching the script not
> > to test for the path would probably result in its own maintenance
> > overhead. Certainly worth considering and looking into though.
> 
> Also there's one standing issue with 358, in modprobe file this won't
> do anymore:
> 
> #HAS_UVM#remove nvidia modprobe -r -i nvidia-uvm nvidia-modeset nvidia
> 
> Since modeset is always present we need the line in, so HAS_UVM won't
> cut it anymore I think. Should we do a "sed" in debian/rules?

Hi Andreas,

I have now committed a fix for both the modeset problem and the VLC
regression (libEGL crash).

For the latter, the problem was that the new libEGL.so library needs the
old libEGL_nvidia.so present, even though they are not linked! I checked
what the upstream installer was doing, and it's adding both, and doing
so fixes the crash.

For the former, I have a tentative and not-very-nice fix which involves
a new #HAS_UVM_MODPROBE# macro. The problem is that in the modprobe
removal rule, "nvidia" has to come last, so the normal #HAS_UVM# won't
do as it will simply be changed with a "#" if uvm is not present. It's
not nice at all, but it works. Suggestions for better solutions are very
welcome :-)

I have ran the usual battery of tests (desktop and optimus, cuda,
opencl, 2d/3d, vdpau) and as far as I can tell 358.16 is ready for
experimental, I don't see any outstanding issues.

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/20151201/4e6f716e/attachment.sig>