http://bugzilla.rpmfusion.org/show_bug.cgi?id=459 --- Comment #2 from Milos Jakubicek <xjakub(a)fi.muni.cz&gt; 2009-03-22 15:42:12 --- True, thanks. I remember the thread, but forgot to consider this:( https://fedoraproject.org/wiki/Packaging/Guidelines#Trademarks_in_Summary... I'll remove them in next release. -- Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. You are the assignee for the bug.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=459 NicolasChauvet <kwizart(a)gmail.com&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED --- Comment #4 from NicolasChauvet <kwizart(a)gmail.com&gt; 2009-03-24 17:05:46 --- 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/SD... 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) -- Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=459 --- Comment #6 from NicolasChauvet <kwizart(a)gmail.com&gt; 2009-04-15 12:09:33 --- 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. -- Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=459 Milos Jakubicek <xjakub(a)fi.muni.cz&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|kwizart(a)gmail.com |rpmfusion-package- | |review(a)rpmfusion.org Status|ASSIGNED |NEW --- Comment #8 from Milos Jakubicek <xjakub(a)fi.muni.cz&gt; 2009-04-18 01:34:12 --- (In reply to comment #6) 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. Done. Done, sorry, I thought there is no direct link, but finally I found one indeed. Done. Done. Done too, hope in the right way. Done. 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 -- Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. You are the assignee for the bug.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=459 Milos Jakubicek <xjakub(a)fi.muni.cz&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED -- Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=459 --- Comment #11 from Milos Jakubicek <xjakub(a)fi.muni.cz&gt; 2009-05-31 23:01:33 --- Nicolas, thank you for your considerations very much: (In reply to comment #10) hence I'd rather avoid such solutions. Ehm...I'm afraid I probably didn't understand the question, but imo the libraries should be just in %{_libdir}. Could you submit the SPEC file so that we can move forward with this? -- Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=459 Duncan Innes <duncan(a)innes.net&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |duncan(a)innes.net --- Comment #13 from Duncan Innes <duncan(a)innes.net&gt; 2009-08-06 17:04:33 --- 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. -- Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=459 --- Comment #15 from Duncan Innes <duncan(a)innes.net&gt; 2009-08-25 10:42:28 --- 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. -- Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=459 --- Comment #17 from Milos Jakubicek <xjakub(a)fi.muni.cz&gt; 2010-02-08 22:26:20 --- *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). -- Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=459 Michal Ambroz <rebus(a)seznam.cz&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rebus(a)seznam.cz --- Comment #19 from Michal Ambroz <rebus(a)seznam.cz&gt; 2010-03-29 00:15:37 --- 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 -- Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=459 --- Comment #21 from Michal Ambroz <rebus(a)seznam.cz&gt; 2010-03-29 02:28:29 --- 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. -- Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=459 --- Comment #23 from Neal Becker <ndbecker2(a)gmail.com&gt; 2010-09-26 17:10:19 --- 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. -- Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=459 Pete Stieber <developer(a)toyon.com&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |developer(a)toyon.com --- Comment #25 from Pete Stieber <developer(a)toyon.com&gt; 2011-03-31 00:06:14 --- 3.2 is the latest. http://developer.nvidia.com/object/cuda_3_2_downloads.html#Linux Has this been dropped? -- Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=459 --- Comment #27 from NicolasChauvet <kwizart(a)gmail.com&gt; 2011-04-05 11:03:42 --- (In reply to comment #26) 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 -- Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=459 --- Comment #29 from NicolasChauvet <kwizart(a)gmail.com&gt; 2011-04-12 23:24:49 --- 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 ? -- Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.