RFS: nvidia-cg-toolkit (updated package)

Tue May 3 12:08:21 UTC 2011

Hi all:

Since I received 3 email within the last 24 hours I will try to answer
all the question here.

I started this package over a year ago and made packages for 6-7
nvidia toolkit releases while merging the changelog so I might not
remember all the reasons I did things like that since I never made a
local git for it. I only uploaded the last 2 releases to Debian
Mentors. All the specific answers are below:

On Sun, May 1, 2011 at 10:19 AM, Michael Tautschnig <mt at debian.org> wrote:
> You seem to be putting lots of energy in this package. Yet your changes go far
> beyond what an ordinary NMU should be like. As there has been a sequence of NMUs
> already probably it would be best if you took over the package. Yet you will
> have to follow proper procedures to do so. Have you gotten in touch with the
> current official maintainer(s)? Looking at your changelog you seem to have
> spoken to at least one of them. Please provide some information about this
> process (here, not in the package) and please perform the proper procedure to
> take over the package, if you intend to do so in long term. If all you want to
> do is an NMU, then please make sure you keep the changes to a minimum.
>
> Best regards,
> Michael

Yeah I realize the changes are way over a standard NMU. My original
plan was to email the original maintainers the changes so they could
incorporate them. I sent a few email and finally opened a bug report
since I never got a reply. Since the package is not officially
orphaned and I'm not a DD/DM I was waiting to see if it got orphaned
and then was planning on contacting the nvidia devel list to see if
they wanted to include it under their team umbrella.

On Mon, May 2, 2011 at 11:32 PM, Russ Allbery <rra at debian.org> wrote:
> Also, if you're interested in maintaining packages of this sort in
> general, you may want to consider joining the NVIDIA packaging team by
> subscribing to the pkg-nvidia-devel mailing list on
> lists.alioth.debian.org.  We're currently maintaining the CUDA packages as
> well as the NVIDIA graphics drivers and libraries, and while I don't have
> any time to work on NVIDIA packaging myself, I'm happy to do uploads for
> others and some package review.  Other people on the team may also be
> willing to help.
>
> --
> Russ Allbery (rra at debian.org)               <http://www.eyrie.org/~eagle/>

As I mentioned above I was considering this but I was waiting to hear
from the maintainers since I did not want to hijack or do anything
that may have been perceived as rude by them.

On Tue, May 3, 2011 at 5:59 AM, Andreas Beckmann <debian at abeckmann.de> wrote:

> I just had a brief look over the package.
> What's curious is that you need a login at nvidia to download the
> software, but the license explicitely allows redistribution.

Yes this started within the last week or so since I try to check every
1-2 weeks for a new version and I first saw this 3-4 days ago.

> * as Andres Mejia has resigned, you should also drop the
>    DM-Upload-Allowed: yes
>  from debian/control as there are no non-DD uploaders left

Seems that I missed it when I removed Andres Mejia name.

> * the debian/watch file can be generated with a single sed call with
>  two -e '...' -e '...' parameters
> * the watch file is not useful since it points to a page that requires
>  a login :-(

Yeah, when I noticed this 3-4 days ago  I knew the watch file /
get-orig-source routine became obsolete.

> * why do we need override_dh_gencontrol: and override_dh_builddeb:? dh
> should work fine without

This is for compatibility with ubuntu lucid or to be more
correct/precise with debhelper 7 or at least some versions of it. I
compile these on my ppa and from what I remember the i386 version
tried to run those 2 commands for the ia32 package which is amd64
only. I never saw this error on my local machine on Debian since it
had debhelper 8 and compiling in maverick also worked fine without
those overrides. I used to bump the debhelper dependency to > 8 but
decided to use this method since it worked in debhelper 7/8.

> * the doc package should only Recommends/Suggests: the toolkit (if you
> add a dependency at all), otherwise you have an Arch: all package that's
> uninstallable everywhere except on i386/amd64. But why shouldn't you
> read the docs on a different arch or without installing the toolkit?

The -doc package contains several example programs that would require
the toolkit to compile. To ensure that those program compiled I made
it depend on the same source version to avoid compatibility issues. To
be honest I thought I had it as a Recommends but thanks for pointing
it out. Also I was thinking of splitting the package since the
documentation is truly an arch:all package but the examples are really
an arch: i386 amd64 package but never got around to it.

> * use Suggests: nvidia-cg-toolkit-doc (= ${source:Version}) as this is
> an arch:all package that does not get binNMUed. See deb-substvars(5)

True.

> * the runtime libraries should probably be split to a separate package,
> I assume that binaries created with the cg toolkit will be linked
> against them and this shouldn't pull in the toolkit. But that's not for
> this new upstream NMU. A single package for both libs should be OK to
> avoid mixing different versions as there seems to be no proper
> SONAME/SOVERSION being used :-(

When I thought about this, I  reached a similar conclusion :-(.

> * why do we need post{inst,rm} scripts that manually call ldconfig?

That was my interpretation of:
http://www.debian.org/doc/debian-policy/ch-sharedlibs.html
Section 8.1.1

> * eventually override the Informational and eXperimental lintian tags,
> too (spelling-error-in-binary, binary-has-unneeded-section,
> shlib-calls-exit). Have a look at the nvidia-graphics-drivers package
> how we did this there, e.g. copy the comments why we added these overrides

Oh I had these override before but I took them out since I did not
want to go too override happy. I can add them back and check the
graphic package for the comment.

> * since source code seems to be available, can you rebuild the cgfxcat
> and cginfo binaries? These rebuilds could be stripped :-)

I did not know the source code was available. I will try searching for
it and see.

> * debhelper 8, standards 3.9.2

Yeah I was waiting for the next version to update the package and this
was in the TODO list.

I will incorporate some of these changes in the local version I have
and wait till confirmation for the others. If there is any interest I
can re-upload it to debian.mentors or wait and see if it gets
incorporated under the nvidia umbrella and then do them.

Thanks for the interest,
Miguel