Bug 459

In Fedora it is afaik recommended to not use (R) or (TM) in package descriptions. Iirc wrote Tom Spot something about this recently on fedora-devel.

True, thanks. I remember the thread, but forgot to consider this:(

https://fedoraproject.org/wiki/Packaging/Guidelines#Trademarks_in_Summary_or_Description

I'll remove them in next release.

We would be always late with this package, according to this post, Fedora 10 is unsupported:
http://forums.nvidia.com/index.php?s=40b321e20c43adeeb3fd07d9ea2454fe&showtopic=92353

You have packaged cuda like if it was a library, but it is a more a compiler than a library. I don't think using a -devel will make sense.

Usually, Fedora guideline are pretty clear on the name of the package, it need to be the name of the "source tarball". In this case, it should be cudatoolkit. I would agree to use only cuda (which is the kown product name), but having the package named cudatoolkit and eventually provides cuda seems the prefered way.
I'm aware that historically, the package name has changed. (and may change with newer version also).

- Does the package need to be (can be) multilib compliant or multiarch compliant. At this time it is neither mutlilibs nor multiarches compliant.
(it may not be relevant)

- There is also a cuda-sdk (cuda-devel ?)
http://www.nvidia.com/object/thankyou_linux.html?url=/compute/cuda/2_1/SDK/cuda-sdk-linux-2.10.1215.2015-3233425.run
Is it needed along with cuda ?

* - Development/Languages seems more accurate to describe the rpm Group.

* - Does Cg is needed (bundled within) for this package ? 
  And which version it might work best with ?

* - The package are binary only, but nvidia currently only certify it on F-9 and EL-5. Also with the rpm strongerHash feature, rpm built on F-10 and beyond could not be compatible with older distro. Thus I think the disttag must be re-enabled.


* For the debuginfo, You can have a look on the rar review at rpmfusion to see how debuginfo can be disabled without touching binaries, or with xorg-x11-drv-nvidia\* to override the build id while extracting debuginfo.

* please use %{version} for the Source0/1.

* Please use install with -p whenever it is possible to prevent timestamp change. (for example, when installing the initscript or when you convert the doc in utf8). That will avoid.


* scriplets need to end with || : to avoid rpm transaction to be canceled if something went wrong for any reason. (i don't know why an initscript would be needed - will check later)

Sorry for the delay,

(In reply to comment #4)
> You have packaged cuda like if it was a library, but it is a more a compiler
> than a library. I don't think using a -devel will make sense.

Yes, I was unsure about this, I've removed the -devel subpackage now.

> Usually, Fedora guideline are pretty clear on the name of the package, it need
> to be the name of the "source tarball". In this case, it should be cudatoolkit.
> I would agree to use only cuda (which is the kown product name), but having the
> package named cudatoolkit and eventually provides cuda seems the prefered way.
> I'm aware that historically, the package name has changed. (and may change with
> newer version also).

Done, although I'd note that the general rule is "tarball name OR project name".
 
> - Does the package need to be (can be) multilib compliant or multiarch
> compliant. At this time it is neither mutlilibs nor multiarches compliant.
> (it may not be relevant)

I've split the libraries into a -libs subpackage, so this is now multilib. Multiarch doesn't make sense IMO.

> - There is also a cuda-sdk (cuda-devel ?)
> http://www.nvidia.com/object/thankyou_linux.html?url=/compute/cuda/2_1/SDK/cuda-sdk-linux-2.10.1215.2015-3233425.run
> Is it needed along with cuda ?

No, it isn't, it contains mostly code samples. I do not find it worth packaging now.

> * - Development/Languages seems more accurate to describe the rpm Group.

Done

> * - Does Cg is needed (bundled within) for this package ? 
>   And which version it might work best with ?

Where do you see it bundled? Maybe I just misunderstood the question...

> * - The package are binary only, but nvidia currently only certify it on F-9
> and EL-5. Also with the rpm strongerHash feature, rpm built on F-10 and beyond
> could not be compatible with older distro. Thus I think the disttag must be
> re-enabled.

Of course, just didn't notice it is missing. Added, thanks.
> 
> * For the debuginfo, You can have a look on the rar review at rpmfusion to see
> how debuginfo can be disabled without touching binaries, or with
> xorg-x11-drv-nvidia\* to override the build id while extracting debuginfo.
>

Thanks for hint, used the method from xorg...nvidia.

> * please use %{version} for the Source0/1.

Done.

> * Please use install with -p whenever it is possible to prevent timestamp
> change. (for example, when installing the initscript or when you convert the
> doc in utf8). That will avoid.

Done, converting has been already done by touch -r.

> * scriplets need to end with || : to avoid rpm transaction to be canceled if
> something went wrong for any reason. (i don't know why an initscript would be
> needed - will check later)
> 

Fixed, there were also others like "mv" which must be appended with ||: so as not to fail on 32bit (moving into same dir).

See the new SPEC file and SRPM in http://mjakubicek.fedorapeople.org/nvidia-cuda-toolkit/

I don't know where you got the cudatoolkit initscript but it is totally undeed.
Once the nvidia driver is loaded, the /dev/nvidia? and /dev/nvidiactl are automatically created. Furthermore this script assume the module name to be hardcoded to nvidia.ko which won't be garanted in the near future for all nvidia driver branches (even only cuda capables branches).

Once the initscript is removed, please only update the spec file as the src.rpm is quite big.

- License:
The License is nVidia proprietary, and can be redistributed according to :
quoting EULA.txt
"2.1.2 Linux/FreeBSD Exception. Notwithstanding the foregoing terms of Section 2.1.1, SOFTWARE designed exclusively for use on the Linux or FreeBSD operating systems, or other operating systems derived from the source code to these operating systems, may be copied and redistributed, provided that the binary files thereof are not modified in any way (except for unzipping of compressed files). "
So this pretty well fit with our:
Redistributable, no modification permitted

- You need a ExclusiveArch since cudatoolkit is only provided as i386 i586 x86_64
That will lead to have:
%if 0%{?fedora} > 10
ExclusiveArch:  i586 x86_64
%else
ExclusiveArch:  i386 x86_64
%endif

- Please use the full source url when possible for SOURCE0/1

- cuda virtual provides can probably be versioned (version-release.)


- Post scripts, since libraries are provided by the -libs sub-package, you need to have:
%postun libs -p /sbin/ldconfig

- According to the cuda download page. The cudatoolkit highly depend on a certified nvidia driver version. (specially for EL-5, where they are multiple version). I can bump the nvidia driver to that version, but i guess that once cuda 2.2 will be here, It will be possible to have two differents certified cuda version on a Fedora 9 plateform. 
That will lead to work with alternative, so different version of the cudatoolkit can co-exist. (like there is with different version of the jdk compiler).
(I don't like to use version in the name of the package )

- It would be better to fix the package in %prep (iconv, sed, etc)
and then to cp -pR the whole directories to a versioned prefix in %install
(like /usr/lib/cudatoolkit-%{version}-%{_target_cpu} which is the best suitable for compiler according to the FHS )

Then everything could be versioned as appropriate using alternative in %post %postun .

But this probably needs more experiments (what is the default installation prefix btw ?)



Whatever the decision to use a better prefix, I don't like cuda headers to be available in the standard include path. This could be tweaked from /usr/bin/nvcc.profile.
On the other side, I will probably introduce pkg-config support for cudart.pc provided within the nvidia driver.

updated package - summary

(In reply to comment #6)
> I don't know where you got the cudatoolkit initscript but it is totally undeed.
> Once the nvidia driver is loaded, the /dev/nvidia? and /dev/nvidiactl are
> automatically created. Furthermore this script assume the module name to be
> hardcoded to nvidia.ko which won't be garanted in the near future for all
> nvidia driver branches (even only cuda capables branches).

Well, I found the info about it on NVidia website ("might be necessary") and it was present in the Mandriva package. Unfortunately I don't have any CUDA-enabled GPU card available (...in fact, I've no Nvidia around at all, just realizing:), hence I'm sorry but I couldn't test. I have one tester among Fedoras BOINC users who however is not able to find out such things of course.

> 
> - You need a ExclusiveArch since cudatoolkit is only provided as i386 i586
> x86_64
> That will lead to have:
> %if 0%{?fedora} > 10
> ExclusiveArch:  i586 x86_64
> %else
> ExclusiveArch:  i386 x86_64
> %endif

Done.
 
> - Please use the full source url when possible for SOURCE0/1

Done, sorry, I thought there is no direct link, but finally I found one indeed.
 
> - cuda virtual provides can probably be versioned (version-release.)

Done.

> - Post scripts, since libraries are provided by the -libs sub-package, you need
> to have:
> %postun libs -p /sbin/ldconfig

Done.
 
> - According to the cuda download page. The cudatoolkit highly depend on a
> certified nvidia driver version. (specially for EL-5, where they are multiple
> version). I can bump the nvidia driver to that version, but i guess that once
> cuda 2.2 will be here, It will be possible to have two differents certified
> cuda version on a Fedora 9 plateform. 
> That will lead to work with alternative, so different version of the
> cudatoolkit can co-exist. (like there is with different version of the jdk
> compiler).
> (I don't like to use version in the name of the package )

Done too, hope in the right way.
 
> - It would be better to fix the package in %prep (iconv, sed, etc)
> and then to cp -pR the whole directories to a versioned prefix in %install
> (like /usr/lib/cudatoolkit-%{version}-%{_target_cpu} which is the best suitable
> for compiler according to the FHS )

Done.

> But this probably needs more experiments (what is the default installation
> prefix btw ?)

> Whatever the decision to use a better prefix, I don't like cuda headers to be
> available in the standard include path. This could be tweaked from
> /usr/bin/nvcc.profile.

I used %{_includedir}/cudart which is one of the upstream solutions. 

Updated SPEC file as previously on:
http://mjakubicek.fedorapeople.org/nvidia-cuda-toolkit/cudatoolkit.spec

Ops, sorry...somehow I managed to de-assign the bugreport.

Packaging a compiler isn't as trivial as any other packages.
I think it would be fine to have a project using the cuda compiler packaged as an experiment. Do you have some candidate for this?
(I may have two cases, schroedinger-nonfree and nvidia-texture-tools).
Then I have few questions...

I have improved the spec file, but it remains two ways of improvements with some related questions:
- Does binaries/libraries compiled with cuda 1.1 works with cuda 2.1 (2.2)
- Does the packaging scheme will work also for cuda 1.1 (which may remains suitable for older systems/drivers), and forthcoming 2.2 (in other words, shall we have version in the name, the same as java-1.6.0-{openjdk,sun} are versionned).
- How the cuda compiler should works with the nvidia drivers Requirements. (buildtime/runtime). That will make the cuda enabled libraries/(binaries?) to be enabled once the driver support cuda with an additional sub-directory (the same as glibc use dso from _libdir/sse2 when cpu support this feature). So either this sub-directory need to be versioned (sugegstion: _libdir/cudart-2.1) either we do not need that, (_libdir/cuda). 

In Any case, produced libraries/binaries seems to be linked with the cudart library from the cuda compiler, so this last needs to be splitted from the compiler package to be installed independently.(as multilibs).
Produced binaries/libraries seems also to use symbols from the libcuda library (provided from the nvidia driver) but aren't using -lcuda at link time, so there are a lot of undefined-non-weak-symbol.

Then there is a need to mind the pkg-config buildtime behaviour along the WIP improvements about nvidia drivers packaging.

(I will submit a new spec soon).

Nicolas, thank you for your considerations very much:

(In reply to comment #10)
> I have improved the spec file, but it remains two ways of improvements with
> some related questions:
> - Does binaries/libraries compiled with cuda 1.1 works with cuda 2.1 (2.2)
> - Does the packaging scheme will work also for cuda 1.1 (which may remains
> suitable for older systems/drivers), and forthcoming 2.2 (in other words, shall
> we have version in the name, the same as java-1.6.0-{openjdk,sun} are
> versionned).

From what I have found in forums, backward compatibility should be preserved, hence I'd rather avoid such solutions.

> - How the cuda compiler should works with the nvidia drivers Requirements.
> (buildtime/runtime). That will make the cuda enabled libraries/(binaries?) to
> be enabled once the driver support cuda with an additional sub-directory (the
> same as glibc use dso from _libdir/sse2 when cpu support this feature). So
> either this sub-directory need to be versioned (sugegstion: _libdir/cudart-2.1)
> either we do not need that, (_libdir/cuda). 

Ehm...I'm afraid I probably didn't understand the question, but imo the libraries should be just in %{_libdir}.

> 
> (I will submit a new spec soon).
> 

Could you submit the SPEC file so that we can move forward with this?

ping again

Just to register interest in this work.  Have systems fully ready to test CUDA rpm's when necessary.

Running Fedora 11 x86_64 with Cuda capable card

Currently running Cuda drivers, toolkit and SDK downloaded from nvidia and installed manually - so I know what works and kind of how it works.  Am using Cuda 2.3 though which currently require the nvidia beta 190.18 driver.

Also interested in running on RHEL5 x86_64 if that's an option at all.

(In reply to comment #11)
> Nicolas, thank you for your considerations very much:
...
> 
> Could you submit the SPEC file so that we can move forward with this?
> 
Sorry for been that late, the general idea was to move the prefix from /usr to /usr/lib/nvidia-cuda-%{version}-$(uname -m) so that we can respect the FHS WRT packaging compiler.
There is a need to take a look how it is done for java (openjdk/sun) for some example.

You shouldn't wait for my spec anymore as I tend to have explored more than necessary (mulitple cuda toolkit installed).

I think the spec should be cuda.spec, because we didn't use the toolkit keyword for Cg either.

@Duncan, thx for you interest. One way to have usefull info is to package an application using the cuda compiler. But other infor about the matching drivers and other testing are very valuable feedbacks.

My current testing has shown the following:

We're running CUDA 2.3 at the request of our developers, so we are currently having to use Nvidia beta drivers 190.18

I've not managed to get CUDA working at all on my workstation if I install any of the nvidia-beta RPMs.  Not been able to nail this down, but if I install the binary driver downloaded from nvidia things run OK.  This is confusing as I thought the RPM builds were a complete version of the official nvidia binary install?

The server attached to the Tesla box is installed with the cudadriver_2.3_linux_64_190.18.run and cudatoolkit_2.3_linux_64_rhel5.3.run binaries from Nvidia.

The CUDA 2.3 SDK is installed on some systems at the moment, but not all.

Our developers are writing test apps to push to the Tesla boxes & suitable workstations.  I will update with more information about that when it's available.

My RPM building skills are somewhat limited, but I'd like to help if I can.

Hi Nicolas,

(In reply to comment #14)
> (In reply to comment #11)
> > Nicolas, thank you for your considerations very much:
> ...
> > 
> > Could you submit the SPEC file so that we can move forward with this?
> > 
> Sorry for been that late, the general idea was to move the prefix from /usr to
> /usr/lib/nvidia-cuda-%{version}-$(uname -m) so that we can respect the FHS WRT
> packaging compiler.
> There is a need to take a look how it is done for java (openjdk/sun) for some
> example.

I have spent some time considering all these multi*install issues and came to these conclusions:

We have to distinguish between the cuda compiler and the libraries. While the compiled should and could go into the location compliant with FHS (will modify so), the libraries need more adjustment:

I'm currently really not sure whether it is worth making multiple CUDA version parallel installable -- I've found an official nvidia document stating that CUDA *is* backward compatible [1], so we could just keep shipping the highest CUDA version that will run with the nvidia driver present in current rpmfusions repositories (currently, we could ship cuda 2.2).

The other (much more complicated and imo not worth doing it) choice is:
Ship all or almost all cuda versions from the same package (named "cuda-[version]"), the highest one compliant with current rpmfusions nvidia driver could have "Provides: cuda". Using alternatives is not enough, we have to ensure that the libraries will be found by the linker, so the proper solution would be to use environmental modules [2].

What is your opinion about this? Do you find it worth shipping more cuda versions or not? (actually, in case we'd support the multiple versions, I'd ship all of them then).

[1] http://developer.download.nvidia.com/compute/cuda/2_3/toolkit/docs/NVIDIA_CUDA_BestPracticesGuide_2.3.pdf

[2] https://fedoraproject.org/wiki/PackagingDrafts/EnvironmentModules

*PING*

I'd like to finish this review finally, even if we would now have the CUDA library in RPMFusion (that's actually the only thing I'm really interested in).

*PING2*

Hello
would it make sense to update the package to the current version (3.0) 
of the upstream package?
http://developer.nvidia.com/object/cuda_3_0_downloads.html
Best regards
Michal Ambroz

Created attachment 397 [details]
rpmlint for cuda toolkit

rpmlint cudatoolkit-2.1-3.fc12.src.rpm cudatoolkit-2.1-3.fc12.i586.rpm cudatoolkit-libs-2.1-3.fc12.i586.rpm cudatoolkit-debuginfo-2.1-3.fc12.i586.rpm

Hello, 
I have tried to do the formal review of the current src.rpm and spec file
an here are the results.


Key:
- = not applicable
x = Check
! = Problem
? = Not evaluated

=== REQUIRED ITEMS ===
[X]  Package is named according to the Package Naming Guidelines.
Name coresponds to the upstream tarball name

[X]  Spec file name must match the base package %{name}, in the format
%{name}.spec.
[!]  Package meets the Packaging Guidelines.
- rpmlint suggests not mixing spaces and tabs for indentation
- second copy of man pages copied to the doc
- documents have got 8MB - it would be worth of thinking about the doc package
- include files in /usr/include/cudart should probably be in separate -headers package (precedens could be for example stdio.h which is in package glibc-headers) 
- a lot of cuda tools is not packaged (nvcc, preprocessors, tpx assembler etc.), just binaries from open64 project are in the package so the installation of this package will be much different in comparision of installaton of the upstream package.


[X]  Package successfully compiles and builds into binary rpms on at least one
supported architecture.
Tested on: FC12

[!]  Rpmlint output: attached
- some formal minor issues with the spec file found, duplicit man pages

[X]  Buildroot is correct
[!]  Package licensed - free to distribute if binaries are not modified
Binaries are stripped during build of the package - this is not permitted by the license.

[X]  License field in the package spec file matches the actual license.
[X]  If (and only if) the source package includes the text of the license(s) in
its own file, then that file, containing the text of the license(s) for the
package is included in %doc.
[X]  Spec file is legible and written in American English.
[X]  Sources used to build the package matches the upstream source, as provided
in the spec URL.
[X]  Package is not known to require ExcludeArch, OR:
Arches excluded: all but i685 and x86_64 (resp. i386 and x86_64 for <FC10)
Why: binary distribution from nvidia

[X]  All build dependencies are listed in BuildRequires, except for any that
are listed in the exceptions section of Packaging Guidelines.
[-]  The spec file handles locales properly.
[X]  ldconfig called in %post and %postun if required.
[X]  Package must own all directories that it creates.
[-]  Package requires other packages for directories it uses.
[!]  Package does not contain duplicates in %files.
man pages are packed twice

[X]  Permissions on files are set properly.
[X]  Package has a %clean section, which contains rm -rf %{buildroot} (or
$RPM_BUILD_ROOT).
[X]  Package consistently uses macros, however as there are used $RPM_BUILD_ROOT and path macros like %{_bindir} on the same line, I would recommend rather using %{buildroot} instead

[!]  Package contains code, or permissable content.
Binaries are stripped during build of the package - this is not permitted by the license. I would recommend to do not strip or ask upstream for permission to do that.

[!]  Large documentation files are in a -doc subpackage, if required.
- documentation is huge - 8.5MB and should be in separate -doc subpackage

[X]  Package uses nothing in %doc for runtime.
[!]  Header files in -devel subpackage, if present.
- header files are not, but shuold be in separate -devel package

[-]  Static libraries in -devel subpackage, if present.
[-]  Package requires pkgconfig, if .pc files are present.
[-]  Development .so files in -devel subpackage, if present.
[?]  Fully versioned dependency in subpackages, if present.
[X]  Package does not contain any libtool archives (.la).
[-]  Package contains a properly installed %{name}.desktop file if it is a GUI
application.
[-]  Package does not own files or directories owned by other packages.

=== SUGGESTED ITEMS ===
[!]  Latest version is packaged.
- latest version is 3.0, however it could still have got sense to have package of the older version of the compiler for compatibility reasons. 

[X]  Package does not include license text files separate from upstream.
[-]  Description and summary sections in the package spec file contains
translations for supported Non-English languages, if available.
[?]  Reviewer should test that the package builds in mock.
[?]  Package should compile and build into binary rpms on all supported
architectures.
tested only on i686 (building for i586)

[X]  Package functions as described.
[X]  Scriptlets must be sane, if used.
[-]  The placement of pkgconfig(.pc) files are correct.
[X]  File based requires are sane.

Created attachment 494 [details]
Nvidia cuda spec update to version 3.2RC

It includes a spec files that is update to the lates version of cuda which is compatible with Fedora13.

Are you sure you want to go with RC?  I wanted to install cuda + pycuda.  When I tried the RC I got compile errors, but using the current release built all successfully.

Created attachment 500 [details]
Nvidia cuda spec update to version 3.1

Nvidia cuda spec update to version 3.1

3.2 is the latest.

http://developer.nvidia.com/object/cuda_3_2_downloads.html#Linux

Has this been dropped?

This is the spec I'm using these days:

http://www.cora.nwra.com/~orion/fedora/cudatoolkit.spec

Sorry, no changelog entries :(

(In reply to comment #26)
> This is the spec I'm using these days:
> 
> http://www.cora.nwra.com/~orion/fedora/cudatoolkit.spec
There are two major issues with this spec:
- /usr/share/cuda is all wrong for binary content. It should be /usr/lib/cuda instead (no matter of the library architecture givent that's a compiler and see next issue).
- Removing alternative library architecture is wrong, it is expectable to build native x86_32 code on a x86_64 OS. gcc can do that, same for the cuda compiler.
And givent that the package will not be multilib 'naturally' because it doesn't have a -devel subpacakge, I expect it will be easier to have a compat32 subpackage instead.

Eventually,
-There there is a need to have a look on how to package additional cuda libraries (either compiled with this toolkit, or pre-built for a given version of cuda).
-rpm macros should allow to ease integration with the cuda

Alright, here's another attempt.

http://www.cora.nwra.com/~orion/fedora/cudatoolkit.spec

* Thu Apr 7 2011 Orion Poplawski <orion@cora.nwra.com> - 4.0.13-1
- Update to 4.0.13 (RC2)
- Install primarily to %%{_libdir}cuda
- Add computeprof subpackage
- Add libs-32bit package on x86_64 for 32-bit libraries
- Moves documentation to doc subpackage

Probably should also ship a .desktop file for computeprof.


One fun thing:

make[2]: Entering directory `/export/home/orion/NVIDIA_GPU_Computing_SDK/C/src/oceanFFT'
oceanFFT.cpp:630:6: warning: unused parameter ‘value’
In file included from /usr/lib/cuda/include/cuda_runtime.h:59:0,
                 from <command-line>:0:
/usr/lib/cuda/include/host_config.h:82:2: error: #error -- unsupported GNU version! gcc 4.5 and up are not supported!

Given this last problem with the version of the compiler, we would start working on cuda 4.0 even if it's at -RC2 stage.
I'm preparing an update of the related driver at 270xx from at least F-14 and later.

I would prefer using /usr/lib/cuda even for lib64 arch given that the compiler can produce x86_32 code, once the required libraries are present.

That been said, we might need other tweak. IIRC, there is a configuration file the compiler checks for the internal headers and library path. Is it there still ?

Hi,

I found this announce: http://developer.nvidia.com/content/cuda-platform-source-release
Will it help adding the cuda implementation within the repositories?

PS: this is also to bump to know if updates are available...

My attempt at an update is here:

http://www.cora.nwra.com/~orion/fedora/cudatoolkit.spec

* Fri Dec 9 2011 Orion Poplawski <orion@cora.nwra.com> - 4.1.21-1
- Update to 4.1.21 (RC2)

I have to install the resulting package with --nodeps because of missing libcuda.so.1.  See bug 2083.

There is a new Cuda 5 on the horizon that is compatible with Fedora 16.

Created attachment 924 [details]
cudatoolkit spec 5.0.7

Haven't really tested this out yet.

http://www.cora.nwra.com/~orion/fedora/cudatoolkit.spec

This is now version 5.0.35 update 1.

I'm closing this review since nvidia is providing it's own repository:
https://developer.nvidia.com/cuda-downloads

Please avoid mindlessly producing conflicting packages with this "upstream" repository. Or at least engage with nvidia on their forum if you beleive there is a need for packaging fix.