On 2019/06/12 14:23, Andreas Beckmann wrote:
> Nice. I'll look into this next month (after buster was released).
I was keen to try the new version to see if it solved a problem with
p2pBandwidthLatencyTest locking up on a machine with two TITAN X GPUs,
so I went ahead and pushed a 10.1update1-ginggs branch  to git. The
problem ended up being with the 418 driver, and upgrading to 430 seems
to have solved it.
As of now, my packaging attempt builds on amd64 and ppc64el, and I'll be
running some tests on it next week.
There are still some Lintian warnings and errors, and I'd like some
suggestions on which should be fixed and which can be overridden, please.
On 14/06/2019 17.36, Graham Inggs wrote:
> Hi all
> On 2019/06/12 14:23, Andreas Beckmann wrote:
>> Nice. I'll look into this next month (after buster was released).
I think I'll upload 10.1 to sid first, do the transition there (do you
remember any problems from Ubuntu?) and look at 10.1u1 afterwards (is
there anything needing NEW?).
That way we should quickly have 10.1 in buster-backports.
From looking at the diff some time ago I remember you added a new
variable for the driver version. Why?
On 07/07/2019 11.38, Graham Inggs wrote:
>> From looking at the diff some time ago I remember you added a new
>> variable for the driver version. Why?
> The minimum driver version and the version included in the download
> filename are now different .
Wouldn't it be sufficient if we relax the driver version in the
dependencies to the mayor driver version (no digits) instead of tracking
Thay may permit to use certain outdated driver beta versions (that were
probably never uploaded to Debian/non-free), a combination not supported
upstream, but which will probably still work.
On Sun, 7 Jul 2019 at 12:26, Andreas Beckmann <[hidden email]> wrote:
> Wouldn't it be sufficient if we relax the driver version in the
> dependencies to the mayor driver version (no digits) instead of tracking
> two versions?
I don't know. From the bits I've read, it sounds like Nvidia want to
release the CDUA toolkit more frequently, and improve compatibility.
So it wouldn't surprise me, if in the next update, the minimum version
remained 418.39 , but included a 430 series driver.
I haven't got my brain around the CUDA Compatiblity section yet, but
the CUDA Application Compatibility Support Matrix  seems to
indicate drivers >= 396.26 and >= 384.111 will be compatible with CUDA
10.1. So perhaps we will need to reconsider how the dependencies in
our packages are expressed.