355 branched and committed to SVN

[Luca Boccassi]

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.

Kind regards,
Luca Boccassi