Stefan Dirsch wrote:
On Sat, Jun 23, 2001 at 02:59:12AM +0200, Ralf Corsepius wrote:
Ben Rosenberg wrote:
* Ralf Corsepius (corsepiu@faw.uni-ulm.de) [010622 15:51]: ->StarTux wrote: ->> ->> About the Nvidia...Got it running, but its non--smp. ->> ->> Maybe get the .src.rpm and do a rebuild? ->Please do! -> ->rpm --rebuild NVIDIA_GLX-1.0-1251.suse72.src.rpm -> ->But be warned! It is missing files, requires you to have both ->SuSE-kernels installed and it will destroy your kernel's config. If ->using it on SuSE installations older than 7.2 it will erase your ->kernel sources. -> -><rant> ->This src.rpm is one of the most stupid things I've ever seen. -></rant>
Why not get the tar.gz files of the GLX and Kernel module..untar them and build those. I guess I am getting old and don't understand the aversion to tarballs that people seem to have.
Get the tarballs..an make them. They work. :)
<*g*> They lack the SuSE-7.2 specifics. Instead, I hacked that nvidia_glx.spec :)
1) For SuSE-7.2, SuSE has repackaged the original NVIDIA_GLX package, is installing to different locations than NVidia, added their switch2_nvglx script and changed several details => SuSE's NVIDIA_GLX is incompatible the NVIDIA's generic NVIDIA_GLX ;)
Just to make this clear. SuSE's NVIDIA_GLX has the same GL/GLcore libs and glx extension as any other NVIDIA_GLX RPM. Yes, we use other locations for them as we provide 3D support also for other boards and make this with 'tricky' symbolic links. Therefore we use this switch2nvidia_glx script.
Well, actually I've never understood this logic.On one machine, all you need is one libGL, not several ones. An actual problem however exists in with libGLcore, as compiling GL-apps with NVidia's GLX will add a linker dependency to libGLcore, which does not exist if using MesaGL[X]. Your approach does not help wrt. this. The only benefit of using switch2*-scripts, I see, is potentially being able to switch between MesaGL[X] and NVidia-GL[X] at run-time (I think rpm-dependencies prevent this, however I haven't checked for this).
2) With SuSE-7.2, SuSE now provides a dummy NVIDIA_GLX package whose version number does not match with the actual NVIDIA_GLX (the dummy's version is greater than NVidia's) => Many beginners will not notice that they do not run NVidia's drivers.
We use this dummy package, because we can't provide the official NVIDIA_GLX RPM (license issues) and want to provide an easy update without having to change anything in the configuration for 3D. That the dummy's version is higher than Nvidia's is an error on SuSE 7.2 (will be 0.8 on SuSE 7.3). The user gets a warning during installation that these are dummy packages and he has to update with YOU (YaST Online update) the packages NVIDIA_GLX + NVIDIA_kernel, if he wants real 3D. root gets an email with the same content. And if you execute '3Ddiag' you will get the waring that you only had installed the dummy packages with the notice to update them with YOU. I know (I saw this warning), but referring to YOU is another dark chapter.
For some strange reason, I haven't been able YOU working since it exists. Probably because of me being behind a very restrictive firewall/proxy.
3) Wrt. to the NVIDIA_kernel modules, NVidia's site provides UP-rpms, but does not provide modules for the SuSE-kernel variants coming on CD.
You can find on nVidia's website NVIDIA_kernel RPMs for SuSE 7.0/7.1/7.2 containing NVdriver kernel modules for all preinstalled SuSE kernels. Where? I can only see UP-NVIDIA_kernel-RPMS ons http://www.nvidia.com.
I know ftp1.detonator.nvidia.com had had them for other SuSE versions, but somehow I don't seem to be able to reach this site anymore. Wrt. "all preinstalled kernels": SuSE-7.2 provides a precompiled 2.4.4-4GB-SMP kernel, but your nvidia_glx.spec does not support it. => AFAIS, you do not provide precompiled modules for all precompiled kernels!
These RPMs also include the 'sources' with installation instructions, if you have self-compiled your kernel. NVidia's SRPMS do not contain your scripts and also do not consider your symlinks and /usr/lib/GL subdirectory. I.e. though they work,
4) The src.rpm mentioned above comes with preconfigured kernel .config's. To build the kernel module rpms they at first rm -rf /usr/src/linux, then simply copy these preconfigured .configs into the kernel sources (== overwrite) the actual kernel .config and run make oldconfig (== reconfigure the kernel with defaults). If one of the kernel source trees is not present, rpm simply aborts.
=> This src.rpm may be suiteable for building binary rpms internally at SuSE, but it is not acceptable to be put on a public site.
I sent this src.rpm to nVidia only for information and told them not to distribute it. But nVidia does not all we tell them. :-( At least there is a README.SuSE which tells the people only to install the i386.rpm packages. Something to communicate to NVidia for you, I'd say ;)
I don't understand why SuSE doesn't simply put a nosrc.rpm on their site and tells people to d/l the tarball.
I don't understand, what you want to tell me with this sentence ...
Write an ordinary rpm.spec like you would do if you could distribute the sources, but then add NoSource-Rpm-Tags to your rpm.specs: .. Source0: ftp://ftp.nvidia.com/<actual-path>/NVIDIA_kernel-1.0-1251.tar.gz NoSource: 0 .. rpm -bs nvidia_glx.spec then will generate a <package>.nosrc.rpm which would not contain the copyrighted sources, i.e. you could put this *.nosrc.rpm on your ftp-site without legal concerns. Then tell people to download the tarball from NVidia and to run: rpm --rebuild nvidia_glx.spec Ralf