PPA package builds based on nvidia-cg-toolkit fail to build

[Jeff Buchbinder]

In building a package (dolphin-emu) which has build dependencies on nvidia-cg-toolkit, the automated PPA builds gave this error:

Setting up nvidia-cg-toolkit (2.1.0017.deb1) ...
Downloading http://developer.download.nvidia.com/cg/Cg_2.1/2.1.0017/Cg-2.1_February2009_x86_64.tgz on the amd64 architecture.
Failed to download NVIDIA Cg Toolkit.
500 Can't connect to developer.download.nvidia.com:80 (Bad hostname 'developer.download.nvidia.com')

Is there a known issue with dependencies on packages which need to retrieve third party components to run?

[Jeff Buchbinder (rufustfirefly)]

Full build log reporting this is available here:

http://launchpadlibrarian.net/36592135/buildlog_ubuntu-karmic-amd64.dolphin-emu_0.0svn4658-0ubuntu3_FAILEDTOBUILD.txt.gz

[Michael Bienia (geser)]

The buildds have no internet access, so you can't use installer packages (packages which need to download the undistributable archive from the official location) on buildds (e.g. as build dependencies).

Note: This also applies to any other downloads which might happen during package building.

[Julian Edwards (julian-edwards)]

As Michael says, you can't connect outwards from the builders during a build.

[Jeff Buchbinder (rufustfirefly)]

On Thu, Dec 31, 2009 at 5:38 AM, Julian Edwards
<email address hidden> wrote:
> As Michael says, you can't connect outwards from the builders during a
> build.
>
> ** Changed in: soyuz
>       Status: New => Invalid

With respect, I call bull on your status change.

If that's the issue, I think it would make more sense to either:

a) provide packages that don't require downloading other things,
especially when they are required to build pieces of software

b) whitelist servers hosting said pieces of software

c) host them locally and set up aliases in /etc/hosts to deal with the
name lookup issue

d) (least favorite) allow binary package uploads so I don't have to
build using your build system to host packages in a PPA

It's not valid to simply mark something as "invalid" because you don't
particularly *like* that some packages require things like the nvidia
toolkit. I'm not really thrilled with it either, but I would suggest
some sort of triage, since the bug *is* valid, and does exist within
the build system. I've just given you three possible solutions, which
are far more productive than simply closing a bug because you don't
feel like dealing with the issue.

All this does is keep people from using Launchpad to build valid
packages and decrease the level of community involvement in Ubuntu by
the people who would be responsible for building those packages. I'm
thankful for getting to use Ubuntu, but if you guys don't feel like
allowing me to contribute packages back simply because your build
system can't accommodate anything that requires nvidia-cg-toolkit,
I'll take my packaging efforts elsewhere, and I'm sure others will as
well.

Jeff

[Michael Bienia (geser)]

Regarding a) installer packages are usually used when it's not allowed to redistribute a software (e.g. having a copy in the Debian or Ubuntu archive). It also applies to any build debs (as it would be redistributing). The same applies to d) as that would be redistributing too (unless we have the right to do it in which case we wouldn't be in this situation).
I'm not a lawyer but I have doubts that c) would be legal in such a situation.

The reason behind the "no net access" rule it to make sure that a build doesn't need any external files or services during build which might vanish tomorrow (or in the future) and you can't build the package anymore after that day (perhaps even without noticing it). So I doubt that there will be exceptions granted to this rule. I want to be able to build the package in one year (or even two years or even more) too.

This is not about liking a package or not, the reason behind using an installer package are its license terms. Or do you believe that the Debian maintainer of that package want to be lazy and only provide an installer package instead of a proper one? Did you check why there is only an installer package before starting complaining about the shortcomings of the build system?

[William Grant (wgrant)]

See http://bugs.debian.org/502457. The license no longer forbids redistribution, so the package could be altered to not download the binaries at install time.

[Julian Edwards (julian-edwards)]

Jeff, you are using somewhat inflammatory language there. We don't do things because we don't feel like it, there is a good reason as Michael has explained. I'll also add that connecting out to the internet at large is a security risk for the packages as the build can be easily compromised that way.

This is why the *Soyuz* bug task was marked invalid because this policy is not going to change. I apologise for not making that clearer in my original comment.

You first suggestion is the bug that this one is now a duplicate of.

[Andrew Fenn (andrewfenn)]

I'd also like to point out that I seems that this bug is being dealt with already. Your best bet to fix this is to take a look at #284750 and also on debian.. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=502457

Once Debian has built a package for it Ubuntu will most likely auto include it in whatever next release gets it pulled in. My suggestion is that you attempt to get it included faster there so it can be included in ubuntu quicker.