Debian Bug report logs - #502457
Please properly package nvidia-cg-toolkit into non-free

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: "Andrew Fenn" <andrewfenn@gmail.com>

To: submit@bugs.debian.org

Subject: RFP: nvidia-cg-toolkit

Date: Fri, 17 Oct 2008 00:05:33 +0700

Tags: needs-packaging
Package: wnpp
Severity: normal

There is already an nvidia-cg-toolkit package which installs the 2004
files directly from nvidia's website but this package should be made
obsolete. At the time this package needed to download directly from
nivida's website due to copyright issues but this is no longer the
case.

If one downloads the tgz for Linux ( on this page:
http://developer.nvidia.com/object/cg_toolkit.html#downloads ) there
are multiple exemptions allowing for Debian to re-distribute the
package.

Looking at the .tgz file go to /./usr/local/Cg/docs/license.txt

"2.1.3  Linux Exception.  Notwithstanding the foregoing terms of Section
       2.1.1, SOFTWARE designed exclusively for use on the Linux operating
       system may be copied and redistributed, provided that the binary
       files thereof are not modified in any way (except for unzipping of
       compressed files)."

Message #10 received at 502457@bugs.debian.org (full text, mbox, reply):

From: Chris Taylor <chris@code-monkeys.org>

To: 502457@bugs.debian.org

Subject: Re: RFP: nvidia-cg-toolkit

Date: Thu, 16 Oct 2008 16:16:08 -0700

That clause does not change the fact that it is still not DFSG Free and
cannot be distributed in main. Because of this, the package would still
have to be a installer as it is now.


/r,
Chris

Message #15 received at 502457@bugs.debian.org (full text, mbox, reply):

From: Daniel Baumann <daniel@debian.org>

To: Chris Taylor <chris@code-monkeys.org>, 502457@bugs.debian.org

Subject: Re: Bug#502457: RFP: nvidia-cg-toolkit

Date: Fri, 17 Oct 2008 09:36:12 +0200

Chris Taylor wrote:
> That clause does not change the fact that it is still not DFSG Free and
> cannot be distributed in main.

correct, however...

> Because of this, the package would still
> have to be a installer as it is now.

we do have a non-free section for this particular case where packages
that do not comply to DFSG, but are allowed to be redistributed.

-- 
Address:        Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
Email:          daniel.baumann@panthera-systems.net
Internet:       http://people.panthera-systems.net/~daniel-baumann/

Message #20 received at 502457@bugs.debian.org (full text, mbox, reply):

From: "Andrew Fenn" <andrewfenn@gmail.com>

To: 502457@bugs.debian.org

Subject: Re: RFP: nvidia-cg-toolkit

Date: Sun, 19 Oct 2008 12:18:50 +0700

[Message part 1 (text/plain, inline)]

Note: This request is that nvidia-cg-toolkit gets properly packaged
into the non-free section. NOT main. I thought that was pretty obvious
but I guess I have to say it out loud.

By having a downloader rather then the data it presents problems for
people with personal packages archives in Ubuntu for example. These
machines can not download from the internet which means you can not
use nvidia-cg-toolkit as a dependency in your PPA. This is how I found
out about the license change.

I have made a deb already in my personal package archives (can be
downloaded here: https://launchpad.net/~andrewfenn/+archive ) and have
also attached a diff of the debian directory to this email. Please
note that this deb isn't up to debian standards so please update it if
you feel it isn't good enough.

In this package I have put common files found in both amd64 and i386
versions of the Linux distributable and placed them in a common
folder.

I hope this information helps,
Andrew

[nvidia-cg-toolkit.diff (text/x-diff, attachment)]

Message #35 received at 502457@bugs.debian.org (full text, mbox, reply):

From: Nigel Stewart <nstewart@nvidia.com>

To: 502457@bugs.debian.org

Subject: Cg 3.0 (July 2010) .deb packages available directly from Nvidia

Date: Sat, 31 Jul 2010 22:15:04 -0500

Cg now provides x86 and amd64 .deb packages, beginning with Cg 3.0 (July 2010)
The current release supersedes all previous releases and is fully backwards compatible.

It is recommended that Ubuntu incorporate or adapt these as a replacement.
http://developer.nvidia.com/object/cg_download.html

For further discussion:
http://developer.nvidia.com/forums/index.php?showforum=14

- Nigel

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------

Message #40 received at 502457@bugs.debian.org (full text, mbox, reply):

From: Stefano Rivera <stefano@rivera.za.net>

To: 502457@bugs.debian.org

Cc: Federico Di Gregorio <fog@debian.org>, Andrew Fenn <andrewfenn@gmail.com>, Nigel Stewart <nstewart@nvidia.com>

Subject: Properly packaged

Date: Sun, 12 Sep 2010 13:49:46 +0200

Hi, although I'm not a Cg user myself, I stumbled across this bug on
Launchpad, and decided to do something about it (it's causing some
FTBFSs in Ubuntu).

I have what I believe is a reasonable solution to this, which is a total
rework of the package using Nvidia's tarballs in a multiple orig.tar.gz
source format 3.0 (quilt) package.

http://people.ubuntu.com/~stefanor/tmp/nvidia-cg-toolkit_3.0.0007-0ubuntu1.dsc

Fredrico:
I'd like to be able to sync this package from Debian instead of directly
uploading to Ubuntu, but with the 10.10 release less than a month away I
probably can't wait long enough.  However, if you do have any input /
review I'd welcome it, so we can minimise future pain.

Does this look good to you?

The documentation should be split out into a -doc package, as it weighs
several MiB. However, I didn't want to do something like that in Ubuntu,
I'd rather it happened in Debian first.

Nigel:
> It is recommended that Ubuntu incorporate or adapt these as a
> replacement.

I'm afraid that [Debian and] Ubuntu can't redistribute your debs, our
infrastructure requires us to build our own debs. We can include your
pre-built binaries in them (as I'm doing), although this obviously means
the package ends up in non-free.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  H: +27 21 465 6908 C: +27 72 419 8559  UCT: x3127

Message #45 received at 502457@bugs.debian.org (full text, mbox, reply):

From: Nigel Stewart <nstewart@nvidia.com>

To: Stefano Rivera <stefano@rivera.za.net>

Cc: "502457@bugs.debian.org" <502457@bugs.debian.org>, Federico Di Gregorio <fog@debian.org>, Andrew Fenn <andrewfenn@gmail.com>

Subject: Re: Properly packaged

Date: Sun, 12 Sep 2010 12:01:47 -0500

Stefano,

From an Nvidia point of view we're mainly concerned about having
the most current release in circulation, and making it easy
to deploy Cg either via the normal packaging channel, or directly
from Nvidia, as necessary.

My main concern would be with incompatibilities or inconsistencies
in the Nvidia-packaged .debs and the Debian/Ubuntu-packaged .debs,
resulting in end-user issues and forum/blog ranting.

Would it be possible for the packages to build based on the
Nvidia .deb packages, rather than the tgz?  We've gone to some
trouble to be lintian clean, it would be a shame for there to be
a duplication of that effort, and inconsistent interpretations of
the packaging policy.

So having different packages due to "infrastructure requirements"
seems a bit unfortunate from that point of view.  I guess the
best I can do it ensure that the Debian/Ubuntu and Nvidia packaged
debs remain as interchangeable as possible.

We're open to splitting the packages into -lib, -dev and -doc
components, but have not prioritized that work internally, yet.
We do have some inertia about keeping things simple and
consistent with the way we package for other platforms.
We've been doing some work to deploy the documentation on the
web, as an alternative to locally installing it.

One nice thing would be the possibility of installing both
32-bit and 64-bit binaries on a 64-bit machine, which currently
is prevented by the documentation and headers conflicting.

Aside from that, if there is some way we can help push (backport?)
Cg 3.0 into Ubuntu 9.04, 9.10 and 10.4, (and Debian maintenance)
that's something else we'd like to see.

Best wishes for 10.10!

- Nigel

Cg Runtime Developer
NVIDIA

> Hi, although I'm not a Cg user myself, I stumbled across this bug on
> Launchpad, and decided to do something about it (it's causing some
> FTBFSs in Ubuntu).
>
> I have what I believe is a reasonable solution to this, which is a total
> rework of the package using Nvidia's tarballs in a multiple orig.tar.gz
> source format 3.0 (quilt) package.
>
> http://people.ubuntu.com/~stefanor/tmp/nvidia-cg-toolkit_3.0.0007-0ubuntu1.dsc
>
> Fredrico:
> I'd like to be able to sync this package from Debian instead of directly
> uploading to Ubuntu, but with the 10.10 release less than a month away I
> probably can't wait long enough.  However, if you do have any input /
> review I'd welcome it, so we can minimise future pain.
>
> Does this look good to you?
>
> The documentation should be split out into a -doc package, as it weighs
> several MiB. However, I didn't want to do something like that in Ubuntu,
> I'd rather it happened in Debian first.
>
> Nigel:
>> It is recommended that Ubuntu incorporate or adapt these as a
>> replacement.
>
> I'm afraid that [Debian and] Ubuntu can't redistribute your debs, our
> infrastructure requires us to build our own debs. We can include your
> pre-built binaries in them (as I'm doing), although this obviously means
> the package ends up in non-free.
>
> SR

-- 
=============================================================
GPU Technology Conference (GTC 2010)
Sept. 20-23, 2010 | San Jose, CA | www.nvidia.com/gtc
Submissions: www.nvidia.com/object/call_for_submissions.html
Exhibits and Sponsorships: www.nvidia.com/object/exhibitors
=============================================================

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------

Message #50 received at 502457@bugs.debian.org (full text, mbox, reply):

From: Stefano Rivera <stefano@rivera.za.net>

To: Nigel Stewart <nstewart@nvidia.com>

Cc: "502457@bugs.debian.org" <502457@bugs.debian.org>, Federico Di Gregorio <fog@debian.org>, Andrew Fenn <andrewfenn@gmail.com>

Subject: Re: Properly packaged

Date: Sun, 12 Sep 2010 20:16:54 +0200

Hi Nigel (2010.09.12_19:01:47_+0200)
> From an Nvidia point of view we're mainly concerned about having
> the most current release in circulation, and making it easy
> to deploy Cg either via the normal packaging channel, or directly
> from Nvidia, as necessary.

I'm sure most upstreams feel that way, however the Linux distribution's
job is do integration work and produce a cohesive, stable release. That
means we can't simply distribute the latest version of everything.

And practically speaking, most users don't need the latest versions,
they need versions that work and are well supported. That's why they
chose Debian. If your users get this package via Debian, they are
getting the version that the Debian maintainer of the package has
provided.

If you want to provide newer releases for your users, you can use the
backports process that both Debian [1] and Ubuntu [2] have.

If you want to do that outside the control of Debian/Ubuntu, you could
provide your own APT repository (or Launchpad PPA [3]), however many
users would probably stick to the distribution-provided versions.

[1]: http://backports.debian.org/Contribute/
[2]: https://help.ubuntu.com/community/UbuntuBackports
[3]: https://wiki.ubuntu.com/Upstream

> My main concern would be with incompatibilities or inconsistencies in
> the Nvidia-packaged .debs and the Debian/Ubuntu-packaged .debs,
> resulting in end-user issues and forum/blog ranting.

Yes, it would be best to minimise those.

This package is a bit of a special case in that it's proprietary,
binary-only software, so while you can build it on contemporary Debian
and Ubuntu machines, we are stuck with whatever binaries you provide.

I don't know what your build process is, but if you could use the same
source packages Debian uses (it looks like your version is a fork of
Debian's) then you should be able to achieve this.

> Would it be possible for the packages to build based on the Nvidia
> .deb packages, rather than the tgz?

Technically, yes. However Debian source packages are built from a
(*source*) tarball. The tarball could contain your two debs, but you had
two convenient tarballs, so I used them instead. They are a much better
fit with the Debian workflow (even if they are proprietary and binary).
I did look at your deb, but it didn't look like it obeyed Debian Policy
of the FHS very well, so I based by installation layout on the current
Debian package instead.

> We've gone to some trouble to be lintian clean,

Is it really lintian clean?
$ lintian Cg-3.0_July2010_x86.deb | wc -l
702
(My package still lists 22 issues, but they are upstream issues, out of
my control)

Can it handle a user upgrading to it from the current Debian version?
There are other issues, like the addition of manpage sections.

> it would be a shame for there to be a duplication of that effort, and
> inconsistent interpretations of the packaging policy.

That's something for you to coordinate with the Debian Package
maintainer rather than me. If you are interested in co-maintaining the
package with him, ask him. Having an active upstream developer who wants
to help can make Debian package maintenance much easier.

> So having different packages due to "infrastructure requirements"
> seems a bit unfortunate from that point of view.

Debian's infrastructure assumes that we are dealing with free software.
The build system and best practices are designed to ensure that we meet
the Debian Free Software Guidelines [4]. Obviously it can be bent to
build from anything we can shove inside a tarball, as I described above,
but the packages that are the easiest to work with are those that stick
to the conventions.

[4]: http://www.debian.org/social_contract

> I guess the best I can do it ensure that the Debian/Ubuntu and Nvidia
> packaged debs remain as interchangeable as possible.

Agreed. If you involve yourself in the Debian and Ubuntu maintenance of
these packages (community participation is always welcome), then you can
do this from both sides.

> We're open to splitting the packages into -lib, -dev and -doc
> components, but have not prioritized that work internally, yet.

Considering the package only has two reverse dependencies and is only
built for two architectures, this isn't a particularly urgent job.

> We do have some inertia about keeping things simple and
> consistent with the way we package for other platforms.

And we have inertia about keeping things simple and consistent with the
way we deal with other packages :)

> One nice thing would be the possibility of installing both
> 32-bit and 64-bit binaries on a 64-bit machine, which currently
> is prevented by the documentation and headers conflicting.

Debian/Ubuntu doesn't support multi-arch yet. But its coming some time
soon...

> Aside from that, if there is some way we can help push (backport?)
> Cg 3.0 into Ubuntu 9.04, 9.10 and 10.4, (and Debian maintenance)
> that's something else we'd like to see.

Yes, see [1], [2].

> Best wishes for 10.10!

Thanks. And I'm hoping for a speedy squeeze release too.

SR

BTW: Your filename version number scheme is not particularly amenable to
machine comparison. 3.0.0007 is way preferable to 3.0_July2010.

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  H: +27 21 465 6908 C: +27 72 419 8559  UCT: x3127

Message #55 received at 502457@bugs.debian.org (full text, mbox, reply):

From: Nigel Stewart <nstewart@nvidia.com>

To: Stefano Rivera <stefano@rivera.za.net>

Cc: "502457@bugs.debian.org" <502457@bugs.debian.org>, Federico Di Gregorio <fog@debian.org>, Andrew Fenn <andrewfenn@gmail.com>

Subject: Re: Properly packaged

Date: Sun, 12 Sep 2010 19:53:42 -0500

Stefano,

> That means we can't simply distribute the latest
> version of everything.

I understand that general reasoning, but when we're still seeing
significant Linux traffic for Cg 2.0 --- it means that many many
users are effectively unsupportable by both Nvidia and Debian.
There are lots of known and resolved bugs in Cg 2.0, it's obsolete.
So Nvidia could go the backports way, or simply recommend that they
install the .deb packages directly from the Cg download page.

http://developer.nvidia.com/object/cg_download.html

I'll look into backports, but from a support perspective it
seems more complicated and costly than handing out the current
.deb, as we've just stared doing.

It does seem a bit of a double standard that security updates
for open source can be cherry-picked into the mainline, whereas
closed source with security updates (and new features) can't
go out to real-world users.

> Most users don't need the latest versions

They do if they need/want security related patches.

> I don't know what your build process is, but if you could use the same
> source packages Debian uses (it looks like your version is a fork of
> Debian's) then you should be able to achieve this.

Our build directly packages .tgz, .rpm or .deb for Linux.
It was necessary to patch dpkg-deb to make this work
without fakeroot on RedHat.  We specifically want to ship
the same binaries for _all_ Linux distributions, rather than
worry about bugs that could be per-distribution, due to a compiler
bug, or whatever.

> I did look at your deb, but it didn't look like it obeyed Debian Policy
> of the FHS very well, so I based by installation layout on the current
> Debian package instead.

>> We've gone to some trouble to be lintian clean,
> Is it really lintian clean?
> $ lintian Cg-3.0_July2010_x86.deb | wc -l
> 702

$ lintian --version
Lintian v2.3.4ubuntu2

271 warnings regarding "windows-devel-file-in-package" (MS DevStudio projects)
414 warnings regarding "manpage-in-wrong-directory" (manCg, manCgFX, etc)
9   warnings regarding "image-file-in-usr-lib" (image files for examples)

...stemming from Cg being intended as an SDK....
(So I take these with a grain of salt)

W: nvidia-cg-toolkit: package-name-doesnt-match-sonames libCg libCgGL
W: nvidia-cg-toolkit: new-package-should-close-itp-bug
W: nvidia-cg-toolkit: copyright-without-copyright-notice
W: nvidia-cg-toolkit: possible-unindented-list-in-extended-description
W: nvidia-cg-toolkit: extra-license-file usr/lib/nvidia-cg-toolkit/examples/OpenGL/glew/LICENSE.txt
W: nvidia-cg-toolkit: maintainer-script-ignores-errors postinst
W: nvidia-cg-toolkit: shlib-without-versioned-soname usr/lib/libCg.so libCg.so
W: nvidia-cg-toolkit: shlib-without-versioned-soname usr/lib/libCgGL.so libCgGL.so

Looking into the implications of versioned soname is on my to-do list....

I guess it's "all good" in the sense that these new packages are being
consistent with the existing Debian ones, and we can be confident of
these being upgradable to the Nvidia ones.  But, I'll check and
keep an eye on things, anyway.

> Can it handle a user upgrading to it from the current Debian version?

Yes, the idea is if/when Debian/etc is lagging, our package will always be
installable.

> Agreed. If you involve yourself in the Debian and Ubuntu maintenance of
> these packages (community participation is always welcome), then you can
> do this from both sides.

That is something to consider, certainly.
But, I have limited discretionary cycles...

> BTW: Your filename version number scheme is not particularly amenable to
> machine comparison. 3.0.0007 is way preferable to 3.0_July2010.

Tell me about it! :-)

- Nigel

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------

Message #60 received at 502457@bugs.debian.org (full text, mbox, reply):

From: Stefano Rivera <stefano@rivera.za.net>

To: Nigel Stewart <nstewart@nvidia.com>

Cc: "502457@bugs.debian.org" <502457@bugs.debian.org>, Federico Di Gregorio <fog@debian.org>, Andrew Fenn <andrewfenn@gmail.com>

Subject: Re: Properly packaged

Date: Tue, 14 Sep 2010 16:36:51 +0200

Apologies to the rest of you, Nigel and I have kind of taken over this
bug, I think *is* relevant to the bug, so I'm continuing the discussion
here.

Hi Nigel (2010.09.13_02:53:42_+0200)
> I understand that general reasoning, but when we're still seeing
> significant Linux traffic for Cg 2.0 --- it means that many many
> users are effectively unsupportable by both Nvidia and Debian.

That is true. As a non-free package Debian can offer little support (and
makes this clear in README.Debian)

> There are lots of known and resolved bugs in Cg 2.0, it's obsolete.

I don't know how the release team usually handles binary-only packages,
with regards to freeze exceptions (squeeze is frozen) and
stable-proposed-updates (the way we get bugfixes to users). Such things
are normally reviewed by looking at the size and complexity of diffs.
Maybe someone who knows could tell you.

If the current maintainers aren't being proactive enough about these
things, (it's probably because they are too busy with other packages), I
suggest you involve you prod them or get involved yourself.

> I'll look into backports, but from a support perspective it
> seems more complicated and costly than handing out the current
> .deb, as we've just stared doing.

Yes, however Linux distribution users are more likely to install things
from their distro repositories than random websites. Something from your
distro is probably less likely to break your system and is probably
easier to get working.

Plus you get updates without having to worry. This is an important
concern, re security.

Wearing my Debian User hat, I'm always very skeptical of commercial APT
repositories / debs. I use the occasional bit of proprietary software,
but I prefer to get it via a repository I trust.

> It does seem a bit of a double standard that security updates
> for open source can be cherry-picked into the mainline, whereas
> closed source with security updates (and new features) can't
> go out to real-world users.

They (probably, I'm no expert on Debian non-free) can, someone just
needs to make it happen. In the absence of diffs, changelogs will have
to suffice.

New features are usually not desirable for security updates, but
non-free doesn't come with support, so we can take more risks. If the
only way to get a security update is to get new features too, so be it.
(Ubuntu now takes this approach with Firefox.)

As to Ubuntu, are you aware of Canonical's partner repository [1]?
Canonical allows third parties to get their proprietary applications
included in the partner repository.  I don't know how much of this is
your own personal initiative and how much is Nvidia's desire to reach
out to Linux users, but that is another possible option.

[1]: http://www.canonical.com/engineering-services/certification/application-packaging

> Our build directly packages .tgz, .rpm or .deb for Linux.
> It was necessary to patch dpkg-deb to make this work
> without fakeroot on RedHat.  We specifically want to ship
> the same binaries for _all_ Linux distributions, rather than
> worry about bugs that could be per-distribution, due to a compiler
> bug, or whatever.

Thanks for that clarification. That means that it doesn't really make
any difference whether we build from debs or tarballs, it's the same
binary objects, just rearranged differently.

> 271 warnings regarding "windows-devel-file-in-package" (MS DevStudio projects)

Yeah, I thought those weren't relevant for Debian, so I removed them
(the DirectX stuff too).

> 414 warnings regarding "manpage-in-wrong-directory" (manCg, manCgFX, etc)

Debian Policy 12.1. I moved them into man3, with named 3Cg etc.

> 9   warnings regarding "image-file-in-usr-lib" (image files for examples)

Examples should really go in /usr/share/doc/$package/examples.

> Looking into the implications of versioned soname is on my to-do list....

That definitely requires package splitting, but would probably make your
users (people who distribute Cg-linked applications) lives a little easier.

> I guess it's "all good" in the sense that these new packages are being
> consistent with the existing Debian ones, and we can be confident of
> these being upgradable to the Nvidia ones.  But, I'll check and
> keep an eye on things, anyway.

Thanks.

>> Can it handle a user upgrading to it from the current Debian version?
>
> Yes, the idea is if/when Debian/etc is lagging, our package will always be
> installable.

I meant technically. I had to add a call to get
nvidia-cg-toolkit-installer to remove any existing
non-package-maintained-stuff in preinst.

> But, I have limited discretionary cycles...

Yeah, so do we all :/ (I should really spend more cycles on working on
my MSc...)

It's great to actually see someone from a commercial player like Nvidia
engaging with Community distributions, I hope we can do something that
works well for everyone.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  H: +27 21 465 6908 C: +27 72 419 8559  UCT: x3127

Message #65 received at 502457@bugs.debian.org (full text, mbox, reply):

From: Andrew Fenn <andrewfenn@gmail.com>

To: Stefano Rivera <stefano@rivera.za.net>

Cc: Nigel Stewart <nstewart@nvidia.com>, "502457@bugs.debian.org" <502457@bugs.debian.org>, Federico Di Gregorio <fog@debian.org>

Subject: Re: Properly packaged

Date: Wed, 15 Sep 2010 19:10:17 +0700

On Tue, Sep 14, 2010 at 9:36 PM, Stefano Rivera <stefano@rivera.za.net> wrote:
> I don't know how the release team usually handles binary-only packages,
> with regards to freeze exceptions (squeeze is frozen) and
> stable-proposed-updates (the way we get bugfixes to users). Such things
> are normally reviewed by looking at the size and complexity of diffs.
> Maybe someone who knows could tell you.
>

I do not think that the CG toolkit is a dependency on any package and
considering how it has been packaged previously I doubt it would
effect anything by updating the package at the last minute. That said,
is there anyone with some authority that can chime in on this?

On Mon, Sep 13, 2010 at 12:01 AM, Nigel Stewart <nstewart@nvidia.com> wrote:
> We're open to splitting the packages into -lib, -dev and -doc
> components, but have not prioritized that work internally, yet.

Please do consider doing this. As an Ubuntu user of the CG toolkit for
many years it has been annoying to download several megabytes of
documentation and examples I am not going to look at just to use the
lib. It is not complicated to set your debian folder to make multiple
debs so you shouldn't need to worry about it complicating your build
process. :)

Message #70 received at 502457@bugs.debian.org (full text, mbox, reply):

From: Stefano Rivera <stefano@rivera.za.net>

To: Andrew Fenn <andrewfenn@gmail.com>

Cc: Nigel Stewart <nstewart@nvidia.com>, "502457@bugs.debian.org" <502457@bugs.debian.org>, Federico Di Gregorio <fog@debian.org>

Subject: Re: Properly packaged

Date: Wed, 15 Sep 2010 15:46:29 +0200

Hi Andrew (2010.09.15_14:10:17_+0200)
> I do not think that the CG toolkit is a dependency on any package and

It's a build-dep of ogre-contrib.

> considering how it has been packaged previously I doubt it would
> effect anything by updating the package at the last minute.

Yes, but when the final freeze was announced (with outdated requirements
for Universe) I uploaded it to Ubuntu. We're stuck with it for a while
now :)

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  H: +27 21 465 6908 C: +27 72 419 8559  UCT: x3127

Message #75 received at 502457@bugs.debian.org (full text, mbox, reply):

From: Nigel Stewart <nstewart@nvidia.com>

To: Andrew Fenn <andrewfenn@gmail.com>

Cc: Stefano Rivera <stefano@rivera.za.net>, "502457@bugs.debian.org" <502457@bugs.debian.org>, Federico Di Gregorio <fog@debian.org>

Subject: Re: Properly packaged

Date: Wed, 15 Sep 2010 11:51:59 -0500

>> We're open to splitting the packages into -lib, -dev and -doc
>> components, but have not prioritized that work internally, yet.
>
> Please do consider doing this. As an Ubuntu user of the CG toolkit for
> many years it has been annoying to download several megabytes of
> documentation and examples I am not going to look at just to use the
> lib. It is not complicated to set your debian folder to make multiple
> debs so you shouldn't need to worry about it complicating your build
> process. :)

Andrew, I understand that from an end-user perspective.  But our
build, test and release process is SDK-oriented, and is done on
various RedHat machines, so I _do_ worry about complicating all
of that...  As it is we need our own custom dpkg-deb binary.

It does seem like something that _could_ be done downstream...

- Nigel

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------

Message #80 received at 502457@bugs.debian.org (full text, mbox, reply):

From: Scott Howard <showard314@gmail.com>

To: Stefano Rivera <stefano@rivera.za.net>, Andrew Fenn <andrewfenn@gmail.com>, "502457@bugs.debian.org" <502457@bugs.debian.org>, Federico Di Gregorio <fog@debian.org>

Subject: Checking in regarding packaging of nvidia cg libraries

Date: Fri, 18 Feb 2011 20:39:17 -0500

Hello,

I'm doing research into the feasibility of packaging Penumbra Overture
[1] and have done a quick look into licensing [2]. The Penumbra devs
released the game GPL-3 last year, and the last of the completely
closed libraries (besides this cg toolkit) were released as zlib
license this week. The package needs libCg and libCgGL from the nvidia
cg toolkit. For Penumbra to be practical, it would have to depend on
the library binary packages (non-free) instead of an installer
downloading the entire sdk (contrib).

What are the plans for the package?

Regards,
Scott

[1] http://en.wikipedia.org/wiki/Penumbra:_Overture
[2] http://wiki.debian.org/Games/PenumbraOverture

Message #85 received at 502457@bugs.debian.org (full text, mbox, reply):

From: Andrew Fenn <andrewfenn@gmail.com>

Cc: Stefano Rivera <stefano@rivera.za.net>, "502457@bugs.debian.org" <502457@bugs.debian.org>, Federico Di Gregorio <fog@debian.org>

Subject: Re: Checking in regarding packaging of nvidia cg libraries

Date: Sat, 19 Feb 2011 10:48:24 +0700

Hi Scott,

They released the source code, not the artwork if I am correct. That
means although you could package up the game binary it would be pretty
much useless without the content to go with it.

Regards,
Andrew

On Sat, Feb 19, 2011 at 8:39 AM, Scott Howard <showard314@gmail.com> wrote:
> Hello,
>
> I'm doing research into the feasibility of packaging Penumbra Overture
> [1] and have done a quick look into licensing [2]. The Penumbra devs
> released the game GPL-3 last year, and the last of the completely
> closed libraries (besides this cg toolkit) were released as zlib
> license this week. The package needs libCg and libCgGL from the nvidia
> cg toolkit. For Penumbra to be practical, it would have to depend on
> the library binary packages (non-free) instead of an installer
> downloading the entire sdk (contrib).
>
> What are the plans for the package?
>
> Regards,
> Scott
>
> [1] http://en.wikipedia.org/wiki/Penumbra:_Overture
> [2] http://wiki.debian.org/Games/PenumbraOverture
>

Message #90 received at 502457-close@bugs.debian.org (full text, mbox, reply):

From: debian.micove@gmail.com (Miguel A. Colón Vélez)

To: 502457-close@bugs.debian.org

Subject: Bug#502457: fixed in nvidia-cg-toolkit 3.1.0013-1

Date: Fri, 25 May 2012 18:47:49 +0000

Source: nvidia-cg-toolkit
Source-Version: 3.1.0013-1

We believe that the bug you reported is fixed in the latest version of
nvidia-cg-toolkit, which is due to be installed in the Debian FTP archive:

libcg_3.1.0013-1_amd64.deb
  to non-free/n/nvidia-cg-toolkit/libcg_3.1.0013-1_amd64.deb
libcggl_3.1.0013-1_amd64.deb
  to non-free/n/nvidia-cg-toolkit/libcggl_3.1.0013-1_amd64.deb
nvidia-cg-dev_3.1.0013-1_amd64.deb
  to non-free/n/nvidia-cg-toolkit/nvidia-cg-dev_3.1.0013-1_amd64.deb
nvidia-cg-doc_3.1.0013-1_all.deb
  to non-free/n/nvidia-cg-toolkit/nvidia-cg-doc_3.1.0013-1_all.deb
nvidia-cg-toolkit_3.1.0013-1.debian.tar.gz
  to non-free/n/nvidia-cg-toolkit/nvidia-cg-toolkit_3.1.0013-1.debian.tar.gz
nvidia-cg-toolkit_3.1.0013-1.dsc
  to non-free/n/nvidia-cg-toolkit/nvidia-cg-toolkit_3.1.0013-1.dsc
nvidia-cg-toolkit_3.1.0013-1_amd64.deb
  to non-free/n/nvidia-cg-toolkit/nvidia-cg-toolkit_3.1.0013-1_amd64.deb
nvidia-cg-toolkit_3.1.0013.orig-amd64.tar.gz
  to non-free/n/nvidia-cg-toolkit/nvidia-cg-toolkit_3.1.0013.orig-amd64.tar.gz
nvidia-cg-toolkit_3.1.0013.orig-i386.tar.gz
  to non-free/n/nvidia-cg-toolkit/nvidia-cg-toolkit_3.1.0013.orig-i386.tar.gz
nvidia-cg-toolkit_3.1.0013.orig.tar.gz
  to non-free/n/nvidia-cg-toolkit/nvidia-cg-toolkit_3.1.0013.orig.tar.gz



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 502457@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Miguel A. Colón Vélez <debian.micove@gmail.com> (supplier of updated nvidia-cg-toolkit package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Thu, 24 May 2012 20:45:17 -0400
Source: nvidia-cg-toolkit
Binary: nvidia-cg-toolkit libcg libcggl nvidia-cg-dev nvidia-cg-doc
Architecture: source amd64 all
Version: 3.1.0013-1
Distribution: unstable
Urgency: low
Maintainer: Debian NVIDIA Maintainers <pkg-nvidia-devel@lists.alioth.debian.org>
Changed-By: Miguel A. Colón Vélez <debian.micove@gmail.com>
Description: 
 libcg      - Nvidia Cg core runtime library
 libcggl    - Nvidia Cg Opengl runtime library
 nvidia-cg-dev - Cg Toolkit - GPU Shader Authoring Language (headers)
 nvidia-cg-doc - Cg Toolkit - GPU Shader Authoring Language (documentation)
 nvidia-cg-toolkit - Cg Toolkit - GPU Shader Authoring Language
Closes: 502457 506494 539418 610093 639857 649514
Changes: 
 nvidia-cg-toolkit (3.1.0013-1) unstable; urgency=low
 .
   [ Andreas Beckmann ]
   * Adopt package.  (Closes: #649514)
   * New Maintainer: Debian NVIDIA Maintainers.
   * New Uploaders: Miguel A. Colón Vélez, Russ Allbery, and myself.
   * Move packaging git repository to pkg-nvidia:
     git://git.debian.org/git/pkg-nvidia/nvidia-cg-toolkit.git
   * Acknowledge l10n NMUs.  (Closes: #610093)
   * Update Lintian overrides.
   * Review, reorder, and simplify the packaging.
   * Add XS-Autobuild: yes.
   * Use Breaks/Replaces: nvidia-cg-toolkit (<< ${source:Version}) to allow
     upgrades from old monolithic packages in Ubuntu and from NVIDIA.
   * Document a possible package build workflow in README.source.
   * Error out early if the .orig-*.tar.gz are not unpacked before build.
 .
   [ Miguel A. Colón Vélez ]
   * New upstream release 3.1.0013 (April 2012).
     - Since release 2.1 the upstream license allows redistribution, so convert
       the packaging from an installer package (in contrib) to a set of
       packages: nvidia-cg-{toolkit,dev,doc}, libcg, libcggl (in non-free).
     (Closes: #506494, #539418, #502457, #639857)
   * Remove installer script, debconf translations and related dependencies.
   * nvidia-cg-toolkit.preinst: Run installer script in uninstallation mode
     before upgrade.
   * Convert package to 3.0 (quilt) format.
   * Add watch file, get-orig-source target, and README.source.
   * Use two pristine upstream tarballs (*.orig-{amd64,i386}.tar.gz) and an
     empty *.orig.tar.gz (via create-empty-orig in debian/source/options).
   * Bump Standards-Version to 3.9.3.
   * Update copyright file as per DEP-5.
   * Bump debhelper to (>= 9) and compat version to 9.
   * Simplify the rules file by using the dh helper.
   * Change Section from contrib/libs to non-free/libs.
   * Update the README.Debian file and Homepage.
   * Add build dependencies for cginfo and cgfxcat.
   * Compile cginfo and cgfxcat instead of using the prebuilt binaries.
     - Ensure the hardened LDFLAGS are used.
     - Link cginfo and cgfxcat with --as-needed to reduce library footprint.
   * Don't strip the prebuilt binaries since stripping may violate the license
     (modifies binaries).
   * Use the manpages from version 3.0.0016 for the binaries in the
     nvidia-cg-toolkit package. They got removed upstream in version 3.1.0010 but
     are still included in the Cg Reference Manual.
     - Fix a spelling error in cgc.1 (compatable -> compatible).
   * Add multiarch support.
   * Create the libcg and libcggl packages.
     - Unfortunately upstream provides libraries with an unversioned SONAME.
     - Use Multi-Arch: same.
     - Breaks/Replaces old nvidia-cg-toolkit and libcg.
     - Create the libcg.symbols and libcggl.symbols files.
     - Create *.postinst/*.postrm according to Debian policy 8.1.1.
   * Create the nvidia-cg-dev package.
     - Use Multi-Arch: same.
     - Depend on the new libcg and libcggl packages.
     - Breaks/Replaces old nvidia-cg-toolkit.
   * Create the nvidia-cg-doc package.
     - Breaks/Replaces old nvidia-cg-toolkit.
     - Don't compress the examples (Makefile, *.h, *.c, *.cpp, *.cg).
     - Don't include the license.pdf/license.txt files since a verbatim copy is
       included in the copyright file.
     - Don't include the Microsoft Visual Studio files.
     - Don't include architecture dependent files. These files can be
       recompiled by the user since the sources are included.
   * Package nvidia-cg-toolkit:
     - Change Section to non-free/devel.
     - Depend on the new libcg, libcggl and nvidia-cg-dev packages.
     - Suggest the newly created nvidia-cg-doc package.
     - Update description using the latest information from the Nvidia website.
   * {libcg,nvidia-cg-doc}.postinst: Manually remove /usr/lib/libCg.so and
     /usr/lib/libCgGL.so. Due to the removal of the /usr/lib64 symlink, the
     installer script does not remove these files.
 .
   [ Russ Allbery ]
   * Add DM-Upload-Allowed: yes.
Checksums-Sha1: 
 3991a17313d187ddfbf10f721353b119c303d619 3041 nvidia-cg-toolkit_3.1.0013-1.dsc
 7e3d70fcb2246a577654e6b7fb141db907560c53 24829131 nvidia-cg-toolkit_3.1.0013.orig-amd64.tar.gz
 b0cdbcacd85716a80a90b7c65b817b6931df9d5b 23332348 nvidia-cg-toolkit_3.1.0013.orig-i386.tar.gz
 ab3311a31e796117f6c4ab8176ac1382aef100f3 65 nvidia-cg-toolkit_3.1.0013.orig.tar.gz
 c1612af6f721f015fdf9e09d87a254cd8e842389 24600 nvidia-cg-toolkit_3.1.0013-1.debian.tar.gz
 c998e23128816a7433ee8b545db111a0cd5bab88 2176854 nvidia-cg-toolkit_3.1.0013-1_amd64.deb
 76a378a921072d34a0563ff2c95c0d22ab7b112f 3859980 libcg_3.1.0013-1_amd64.deb
 baf97c4dd2f1d7d2452396fcf57315a308b3b115 197120 libcggl_3.1.0013-1_amd64.deb
 92bbefe83b9409d3b6e17b26c8a4535c5a9b6d5d 25592 nvidia-cg-dev_3.1.0013-1_amd64.deb
 39ec74b517a3875131356da38f4b79dac067c506 12760168 nvidia-cg-doc_3.1.0013-1_all.deb
Checksums-Sha256: 
 78241b7088b78ceb05cfb3cdf01303c28e796fd175813969ecb9f9122c722d73 3041 nvidia-cg-toolkit_3.1.0013-1.dsc
 e8ff01e6cc38d1b3fd56a083f5860737dbd2f319a39037528fb1a74a89ae9878 24829131 nvidia-cg-toolkit_3.1.0013.orig-amd64.tar.gz
 cef3591e436f528852db0e8c145d3842f920e0c89bcfb219c466797cb7b18879 23332348 nvidia-cg-toolkit_3.1.0013.orig-i386.tar.gz
 cd75abc9f0dc4d5132ac6892dd023f7abc54cce38e6c825348e21585fbc67b95 65 nvidia-cg-toolkit_3.1.0013.orig.tar.gz
 6f37878bd6609bfa8a8cfc2f5f78abb1d381fff42ac73d53166e11ecf6ead8b0 24600 nvidia-cg-toolkit_3.1.0013-1.debian.tar.gz
 7e958f01af397921b0b0060186597fb0abaa972ad0eed447d9a33a1103918b0c 2176854 nvidia-cg-toolkit_3.1.0013-1_amd64.deb
 24cfc20bdb735726ef106cce3e9524178393ae21efe010b7bfe7c3913834a4b5 3859980 libcg_3.1.0013-1_amd64.deb
 6f719432c71e57a19a07d7ce512cdc6accd65e5a094c86babed5ff1340eb4845 197120 libcggl_3.1.0013-1_amd64.deb
 9905711391af60886816be3d849ea8d360d599b3c4940c5edf217ab21cee42cb 25592 nvidia-cg-dev_3.1.0013-1_amd64.deb
 701121b0f9338861b9f55f05b954270d45e535aa31302805a17e6a3c46264987 12760168 nvidia-cg-doc_3.1.0013-1_all.deb
Files: 
 9bd091fb600f40bbbfa069ec18af4ccb 3041 non-free/libs extra nvidia-cg-toolkit_3.1.0013-1.dsc
 88ba727cdbe0261fac465c4d84f44762 24829131 non-free/libs extra nvidia-cg-toolkit_3.1.0013.orig-amd64.tar.gz
 9a9fc5108154808f3b10eafa54df1c74 23332348 non-free/libs extra nvidia-cg-toolkit_3.1.0013.orig-i386.tar.gz
 723ac9cc5e07d368f65cf5b83e70f48a 65 non-free/libs extra nvidia-cg-toolkit_3.1.0013.orig.tar.gz
 82dce7cbab9ed31a67a44a4e0b9c9142 24600 non-free/libs extra nvidia-cg-toolkit_3.1.0013-1.debian.tar.gz
 fbee5d89fbeffe256663ae7051692ada 2176854 non-free/devel extra nvidia-cg-toolkit_3.1.0013-1_amd64.deb
 e527991d2b744c6ea97408faeb3e22f6 3859980 non-free/libs extra libcg_3.1.0013-1_amd64.deb
 eb359bdcbb30b52e8a67b4b2e7696e5f 197120 non-free/libs extra libcggl_3.1.0013-1_amd64.deb
 0414233205466d7ab0559629f0978b4e 25592 non-free/libdevel extra nvidia-cg-dev_3.1.0013-1_amd64.deb
 a9b9a2650bcd5315fa46720be3c918ef 12760168 non-free/doc extra nvidia-cg-doc_3.1.0013-1_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQIcBAEBCAAGBQJPv7fGAAoJEAFx4YKK4JNFgWwQAJ+b/nRjZYAFrzEKjmWD9shx
HSyQ3EEMIpncGNgZUS41RaYJ/lwXqsm6+JCvjkrpR6uxe/E4K0/FKr3izwA62RCj
UyPSBJxcVEdihZyOY/6NnsqtUateXb1aqhNSnDpSVxBYPeCusC3+DYydHFJYHf+T
BzPljhWHvBthgJAR8zU678eHr0tOOQfrAJDyeiQTNPclLuBSmaJZF/hQKDI17P5/
kikirHC3AmmQeQ212U9RAHAAJdrqSmTtILxOZdQvPKjextQK9pFvCUrQU8girzq7
rHNRNUeZNo8DLdxej7mbpm1j8MRyVX2JLO0No9zShL7yhbrZkW7R0FDlDi3nrlz1
2FtY1veWwvm10vvgx9KG7cK/9jPp1byYGxmld04rYtOx8Ui2Dn68yhXSFS7jnsEG
LyweIY871WrfM3zLDULLtig5oBClWYiGKk8gZlyqjSJDJnP7xD46GjlBb1h9swbP
Qn5Nr38Yi4eeqiZpljuH5upwZ1R2e0yp8E4qFHuvK6oMC86wGGNM1MQgga1bCqI8
7wiNmGLDSxdlqRTK0jmWA5meEuwnz73rXuwsTYmI1vSL7TLERGVKi3iyeWvbOxDF
5aVos4ROHIg1zUCd3MWa2x7LgVx8zkOfzx3eHQYSYipl6K7S0DYQ3s39xPaTAOcp
qQZmz3gXQAj53Nja89uh
=bYrO
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.