updating nvidia-cudnn?

[Andreas Beckmann]

On 29/09/2022 18.15, M. Zhou wrote:
> Hi Andreas,
> 
> I can deal with the update later. Generally it is as easy as bumping
> a version number as well as a checksum in the code.
> 
> On Thu, 2022-09-29 at 15:46 +0200, Andreas Beckmann wrote:
>> Hi lumin,
>>
>> nvidia-cudnn is currently at version 8.2.4.15~cuda11.4 while
>> nvidia-cuda-toolkit 11.5.2 recently made into sid.
>> Does nvidia-cudnn need to be updated for the newer cuda toolkit? What
>> signficance does the enbedded version number have?
> 
> I will handle the update later.

I'll probably switch to cuda 11.6 in sid soon ...

>> (Since there is no build dependency on nvidia-cuda-toolkit, cudnn falls
>> through my regular testing raster.)
>>
>> Is there anything we could do to have some minimal superficial
>> autopkgtest for nvidia-cudnn (runnable on a host without nvidia gpu or
>> driver available)? E.g. compile something ...
> 
> Compilation will not detect problems. The real problems (e.g. library
> incompatibility will be raised at runtime as cuda device error or something
> alike. So I don't think there is any way to add a sensible test for a
> builder without nvidia gpu.

OK.

I don't know how tightly cudnn is coupled to cuda, maybe it should have 
a versioned constraint on nvidia-cuda-toolkit?

>> Since nvidia-cudnn is an downloader package and does not contain any
>> non-free bits (at least I assume that it only depends on them),
>> shouldn't that be rather in contrib instead of non-free?
> 
> In this sense it does not make much difference. In my fuzzy memory
> the flashplayer plugin package (maybe ten years ago) was already
> a downloader in non-free.

flashplayer is a really bad example package ;-)
In contrib you have autobuilding and can do source only uploads (unless 
you have non-free build-depends).

Andreas