Nvidia Packaging

[Andreas Beckmann]

On 2014-09-08 16:13, Graham Inggs wrote:
> On 08/09/2014 14:01, Andreas Beckmann wrote:
>> For cuda 6.0/6.5 a DD will need to do the first upload, since that will

That already went through NEW :-)

> I do have 6.0 mostly packaged already, it's available in my Ubuntu PPA:
> https://launchpad.net/~ginggs/+archive/ubuntu/testing
> I must still update the Build-Depends to libcuda1 | libcuda-5.5-1, but
> haven't yet because I wanted to test building it on the PPA builders and
> the current nvidia drivers in Ubuntu don't yet provide libcuda-6.0-1
> (but Alberto knows about this and I expect it very soon).

They can provide several libcuda-X.Y-1 not only the latest.

Note to self (or Vincent): n-g-d: libcuda1 add Provides libcuda-6.0-1
(and maybe libcuda-6.5-1). This is not urgent since nothing in Debian
should rely on this and therefore it is for documentation only.

> I'd like to do 6.0 first as it may still be possible to include it in
> Ubuntu Utopic (which doesn't have new enough drivers for 6.5).

That would be 2014/10? (Or however Ubuntu numbers this.)

> I have a Jetson board that I think will be useful for testing arm
> support for 6.5.

Sounds good. Let's try to get this done for jessie.

> Once I've uploaded 5.5, shall I just continue with 6.0 in SVN in trunk,
> or should I create a branch, or what?

Now we already have a 6.0 branch :-). This should be merged into trunk
once you are going to upload to unstable. Luckily there are no more
renames needed in d/ when bumping the major version :-)

Apropos branches: if you need to make Ubuntu-specific uploads you are
welcome to put the respective branches/tags in the Debian SVN
repository, too. Use codenames and branch them off a tag.

> Please let me know if you want to make any other changes, otherwise I am
> going to update d/control and d/changelog and then upload.

That has been done inbetween :-)

Just some general side notes about "my style" and workflow:

I usually keep trailing commas in Depends/Recommends/... as well as
putting each (new) entry on its own line. That usually allows for
minimal diffs (and helpful blames), e.g. just one line being
added/deleted without modifying anything "unrelated" nearby.

Graham, please tag your upload in SVN. I use svn-buildpackage, so it's
just "svn-buildpackage ... --svn-tag" for the build (and --svn-tag-only
for doing it after the build).
Vincent, Graham, after doing the final commit, but before tagging (and
uploading) please run "svn update". This ensures that your working copy
is up-to-date (otherwise everything not touched in the last commit will
be at an "older" revision) and the tag will be on that last commit -
otherwise you'll do a mixed-version commit as in e.g. r4869

> New Revision: 4869
> [svn-buildpackage] Tagging nvidia-xconfig 340.32-1
> 
> Added:
>     packages/nvidia-xconfig/tags/340.32-1/
>       - copied from r4866, packages/nvidia-xconfig/trunk/
>     packages/nvidia-xconfig/tags/340.32-1/debian/changelog
>       - copied unchanged from r4868, packages/nvidia-xconfig/trunk/debian/changelog

compared to e.g. r4888

> New Revision: 4888
> [svn-buildpackage] Tagging nvidia-cuda-toolkit 6.0.37-1
> 
> Added:
>     packages/nvidia-cuda-toolkit/tags/6.0.37-1/
>       - copied from r4887, packages/nvidia-cuda-toolkit/branches/6.0/


Notes regarding nvidia-modprobe: since the code does not seem to change
too often, I don't think it is necccessary to keep it in sync with the
nvidia-graphics-driver version (i.e. do version-bump only uploads). It
is not something anyone would use directly. (The no-code-change argument
would hold for nvidia-xconfig, too, but at least this is a program
called by the users, and according to the bug logs still quite
frequently being used, so I usually uploaded it at least once for each
new major upstream version going to unstable).

Notes regarding conftest.h:
The conftest.sh script does not work reliably/at all with Debian
kernels, so it had been reimplemented long ago (even before I got into
n-g-d stuff) as a .h. This needs to be updated whenever the conftest.sh
changes. Also this is a union over all current and legacy drivers, so be
careful deleting "unused" stuff. (Having unused defines does not hurt.)

I have a git repository where I imported the nvidia kernel source trees
(excluding the blobs) from the beginning of time. That usually helped me
digging out these changes (and the changelog deltas, too). I should
probably push this somewhere ...

In case I write some "wisdom" that is entirely clear to me, but not to
someone else working on n-g-d and friends, feel free to polish it up and
put it into a README.source as you see it fit.


OK, short review of Graham's ppa branch, too:
* does xz compression really help? we are just bundling compressed
files, so xz should take a lot of time for a small size gain over gzip
* stupid libcuinjXX conflicts: yes, we need them :-( (but put them on
their own lines and add trailing commas)
* everything else should be covered in my upload

Please take a look at the lintian warnings. There are a lot of privacy
breach warnings (experimental tags) in the documentation.
Missing manpages could be written if you really want, but should *not*
get lintian overrides.


And now back to the beach before the sun gets too hot :-)

Greetings from Crete


Andreas

PS: I think we can move discussion back to the list, I've fixed my
subscription :-)