This ebuild is a first attempt at consolidating nvidia-kernel/glx/settings and adds the yet to be ported xconfig programs. It copies large parts of the two main existing ebuilds, but removes some cruft such as x86-fbsd use variable which keeps showing QA warnings. All changes are commented with a # PAH: so you can see what I did and hopefully why! Another major change was to download the pkg0 file which excludes the precompiled binaries. Since I run x86, I keyworded the ebuild -* ~x86 for now. I did make some changes to account for amd64 such as downloading it from ftp and some nomenclature consolidation. I still feel there is a lot of unnecessary hacking going on in this ebuild, but did not want to remove anything until the primary maintainers have at it. For now, you will need to copy the files/ directory from the nvidia-kernel portage directory since some of the patches are needed. No other module's patch files are required. Installation tips. 1) unmerge nvidia-kernel/glx/settings. Emerge nvdia. NOTE: I have found at least one application which needed recompilation since it had trouble with the glx libraries. I DON'T KNOW WHY! Otherwise, everything seems to work as expected. Please consider this experimental. But I _DO_ think it very worthwhile.
Created attachment 75137 [details] media-video/nvidia/nvidia-1.0.8174.ebuild
You will note that the install routines have been modularized to a large degree, so hopefully debugging is easier. Also, the only drawback is that the nvidia-settings and xconfig programs are version independent from the main ebuild. However, I don't see this as a major issue since I don't expect those programs to change often or significantly. Lastly, the maintainers may wish to work on some of the user notifications and perhaps add some additional explanations. Maybe even there is a need for revdep-rebuild? Good luck. hope this leads to something good. BTW, total time to emerge (not including download) 1min 10seconds. This, on an Athlon XP2500 oc'ed to 2800.
(In reply to comment #0) > removes some cruft such as x86-fbsd use variable > which keeps showing QA warnings. The QA warnings are completely invalid (see Bug 70648).
In case anyone wants to resurrect free bsd support, the download is available via ftp at ftp://download.nvidia.com/freebsd/${NV_V}/${X86_NV_PACKAGE}-${PKG_V}.tar.gz
I found several open gl apps that were "lost" as a result of the upgrade. A solution so far is to rerun eselect opengl nvidia after installing this new ebuild. Seems to repair the damage as opposed to recompiling all dependent applications.
Note to those waiting on this: I should be able to get this into CVS tonight. I'll post here once I have something.
Uploading tar file with new ebuild for testing. - Place the contents of this tar file in the x11-drivers directory. - emerge unmerge nvidia-settings nvidia-glx nvidia-kernel - emerge nvidia-drivers Please let me know how it works before I commit it. Thanks to Peter for his first version which I based this off of. Changes from Peter's: - Removed Peter's comments to clean things up a bit. - Added FreeBSD support back. - AMD64 support. - AMD64 needs pkg2 for 32-bit libs. - Added back many patches. - The "--use-old" flag on eselect doesn't appear to work and I couldn't find any docs on it. Removed flag for now.
Created attachment 75278 [details] Tar File of new x11-drivers/nvidia-drivers ebuild
comments. compiles and installs on x86 same as my prototye ebuild. Thx for adding back x64. notes: 1) if you are going to use free bsd, consider putting x86-fbsd in IUSE to avoid those silly QA warnings. 2) compiling the nvidia-settings component yields small warnings: * making nvidia settings * Building libXNVCtrl... imake -DUseInstalled -I/usr/lib/X11/config In file included from /usr/lib/X11/config/Imake.tmpl:105, from Imakefile.c:35: /usr/lib/X11/config/linux.cf:371: warning: "BuildLibGlxWithoutPIC" redefined In file included from /usr/lib/X11/config/site.def:44, from /usr/lib/X11/config/Imake.tmpl:46, from Imakefile.c:35: /usr/lib/X11/config/host.def:63: warning: this is the location of the previous definition This is not new, but since we're cleaning up, may as well investigate. 3) eselect now works and properly sets nvidia as the default x driver (this eliminates the issue I found in comment 0 and 2 where glx was not working. Duh, it wasn't working because nvidia's glx wasn't there. 4) I would suggest we look at adding some checks in the preamble to the ebuild which checks if any of the nvidia ebuilds is installed. If they are installed, a fatal error should be reported that the user MUST uninstall all prior nvidia ebuilds. 5) From a cosmetic point of view, the file is still messy. Too much old stuff still commented out, and I would consider moving the pkg_ functions higher in the file. This would keep all the glx private functions in one place and keep the core ebuild functions together. JM2C. Glad we're moving forward with this.
Here's the current function list as I think it should be organized. #All the standard functions together pkg_setup() { src_unpack() { src_compile() { src_install() { pkg_preinst() { pkg_postinst() { pkg_postrm() { #Setup and check functions # include future is_nvidia_installed check in this space mtrr_check() { check_xfree() { check_multilib() { #Install functions install_kernel_modules() { install_nvidia_settings() { install_nvidia_xconfig() { #All glx modules install_glx_modules() { donvidia() { src_install-libs() { want_tls() { This will make future maintenance easier and improve greatly on readability.
Attaching new ebuild. Comments on comment 9: 1) I don't know if doing that is acceptable. I don't think that's the way it's suppose to be handled. I'm going to look into this. 2) I don't get those on my machine. Maybe this is an x86 or your version of X problem. 3) Excellent. 4) I've added RDEPEND checks to the new ebuild. 5) I've done as you've suggested in comment 10. I don't htink there's much clean-up left. Every line in the file seems to have a purpose now. (All but a few.) Give the new ebuild a shot.
Created attachment 75284 [details] nvidia-drivers-1.0.8174.ebuild (LATEST)
Checking now. Only thing is that you left the block between lines 418 and 431 commented out. In the glx ebuild, these were NOT commented out. However, I could see no function. I think they can be excluded still. It looks much better. Only other suggestion on appearance would be to add a comment line or block above the group of glx-related functions so a reader could easily tell what the heck all that code is for! :) ### The following group of functions are related ### ### to the GLX module installation and are called ### ### by the install_glx_modules function ### I would add this just above the install_glx_modules function at line 314 or thereabouts. As for your comment about the IUSE="x86-fbsd" I can't see why it's wrong since it's just a declaration, isn't it? And, when used stops those QA warnings about x86-fbsd not being in IUSE. Your call. Finally,
* Installing nvidia module QA Notice: USE Flag 'x86-fbsd' not in IUSE for 11-drivers/nvidia-drivers-1.0.8174 QA Notice: USE Flag 'x86-fbsd' not in IUSE for 11-drivers/nvidia-drivers-1.0.8174 QA Notice: USE Flag 'x86-fbsd' not in IUSE for 11-drivers/nvidia-drivers-1.0.8174 This is why I suggest using IUSE="x86-fbsd..." unless portage is missing that x86-fbsd is a keyworded arch! Is that a separate bug? I know you should not put arches in IUSE. Anyway ebuild seems solid at least for me. Still think we need to broaden the test base.
bug #101896 may explain what happened to the x86-fbsd arch. Seems that it has been shelved while amd64-fbsd is developed. Not sure what the impact on this project is, but seems that regardless which way we handle the use variable, it matters little.
I don't feel that including tarballs that are independently packaged by upstream into a single ebuild is correct. What will you do when a single one of them has a new release? Revision bump? If that feels like a hack, it should. ftp://download.nvidia.com/XFree86/${NVS}/${NVS}-${NVS_V}.tar.gz ftp://download.nvidia.com/XFree86/${NVX}/${NVX}-${NVX_V}.tar.gz
(In reply to comment #16) > I don't feel that including tarballs that are independently packaged by > upstream into a single ebuild is correct. What will you do when a single one of > them has a new release? Revision bump? If that feels like a hack, it should. > No argument. It certainly is a hack. However, the prepackaged nvidia .run files contain binaries of both settings and config. So, while it is possible that one or both utility programs may be independently bumped, it is unlikely absent a driver bump too. xconfig is married to current driver capabilities and so is settings. I did write to upstream to ask them to package the utility sources too. Don't know how n will receive that suggestion though. It's easy enough to _not_ include the utility programs. However, I believe there is a compelling reason to include them. That's why we're having this thread afterall. See if having one ebuild is better than four.
There should be some note in the ebuild that the user may have to add some options to their xorg.conf file or there desktop may be messed up. I found my fonts very small (resolution: defaulted to 75x75 dpi) and desktop dimensions defaulted to 1280x1024. Since I have mine set to use 1024x768 first, the screen was very large and fonts very small. Had to remerge the previous nvidia-kernel and run: 'xdpyinfo | grep -B1 dot' to see what my previous resolution was set to: 81x81 Then add options to the xorg.conf file: Option "UseEdidFreqs" "false" Option "UseEdidDpi" "FALSE" Option "DPI" "81 x 81" That worked and got my screen back to 1024x768 and fonts correct size. Tried the option of making 1280x1024 the first mode to use and that works, but don't like using that dimension: Modes "1280x1024" "1024x768" "800x600" "640x480" so went back to: Modes "1024x768" "800x600" "640x480" "1280x1024" Starting to see forum post on this problem. Asked a friend, but he had his default set to 1280x1024 so didn't notice anything. But anyone that doesn't and will see the problem if EDID info isn't avail from the display device or is wrong. Ref: /usr/share/doc/nvidia-kernel-1.0.8174-r1/README.gz (Appendix Y. Dots Per Inch)
(In reply to comment #18) snip... > I found my fonts very small (resolution: defaulted to 75x75 dpi) and desktop > dimensions defaulted to 1280x1024. > > Then add options to the xorg.conf file: > Option "UseEdidFreqs" "false" > Option "UseEdidDpi" "FALSE" > Option "DPI" "81 x 81" > Regrettably, you stumbled on a documented problem with the 8174 driver I reported. This version uses a borked method to compute the proper DPI for a given resolution. http://www.nvnews.net/vbulletin/showthread.php?t=61189 covers it all. In your example above, I suggest NOT using option DPI since by setting UseEdidDPI = false, you are forcing the driver to try and recompute which is successful in almost all cases. Unless you have a specific reason, I would not set the DPI but let the driver recompute. This should be corrected in a future version. nVidia changed the default handling for the UseEdidDPI option from false to true. The result was small chaos! However, IMHO, it's not the place of an ebuild to warn users of bugs and workarounds. The purpose of an ebuild is to install or remove an application. Every so often, a new nvidia driver causes more trouble than it resolves. 8174 may be an example. However, I have found that turning off UseEdidDPI makes a big difference. I think if you set UseEdidDPI to false you will be fine. Don't use Option DPI. Good Luck
First, thanks for the reply and info!! (In reply to comment #19) > snip... > Every so often, a new nvidia driver causes more trouble than it resolves. 8174 > may be an example. However, I have found that turning off UseEdidDPI makes a > big difference. I think if you set UseEdidDPI to false you will be fine. Don't > use Option DPI. Good Luck Yes, your correct! Don't need to set the DPI option. But do need to set the UseEdidDPI and UseEdidFreqs both to false. UseEdidDPI (false) alone still caused the same exact problem. >However, IMHO, it's not the place of an ebuild to warn users of bugs and >workarounds. The purpose of an ebuild is to install or remove an application. Ebuilds have and do contain informational snippets needed by the user to properly post configure the application. Few examples: Package: alsa-lib-1.0.10 * Please use media-sound/alsa-driver rather than in-kernel drivers as there * have been some problems recently with the in-kernel drivers. See bug #87544. Package: aspell-0.50.5-r4 * * Please re-emerge ALL your aspell-LANG dictionaries Package: crafty-20.1 * Remember, in order to play games, you have to * be in the 'games' group. Package: gentoo-sources-2.6.14-r2 * As of 2.6.13 the support for devfs has been removed. * You will be required to either manage a static /dev * or to ensure that udev is starting on boot. Not that everyone catches them there either.
Well, I understand your point and see your examples. The problem here is that we're dealing with a possible bug, and I'm not sure if it the place of an ebuild to warn about a bug or potential bug (it does not affect everyone) and suggest a kludge. That's why the 8174 drivers are still marked ~*. If they were rock solid, it would not be keyword masked. BUT, since nVidia DID change a default, a message could be added at the end similar to: ewarn "The handling of DPI detecting was changed from 1.0-7676 to 1.0-8174 such" ewarn "that "UseEdidDpi" is on by default. This may cause fonts to render at an" ewarn "unsuitably small DPI at certain resolutions." echo einfo "If you have font problems, try changing Option \"UseEdidDPI\" \"False\" in your xorg.conf file." einfo "You may also try adding Option \"DPI\" \"pixel x pixel\" to xorg.conf" echo einfo "Users may also wish to follow the nVidia Linux Drivers discussion forum" einfo "at http://www.nvnews.net/vbulletin/forumdisplay.php?s=&forumid=14" However, this message may get lost during the emerge process. And recall, this problem exists already with the 8174 drivers. Personally, I'm against having workarounds in an ebuild. Good luck
I agree with Peter across the board. - Yes, this is sort of a hack, bringing all the sources sepatarely into one ebuild. The point of this is to make it easy for the user to download the NVIDIA drivers as you would expect to get them from NVIDIA. The big difference isebuildwe build them from source though. A revision bump is exactly what I had planned for the utilities. Historically though, they only modify the utilies when they release new drivers, so I expect this to be minimal. - We cannot fix bugs in the NVIDIA drivers that they do not have patches for. If a patch is released, we're happy to add it. I think we should start RESOLVING bugs as UPSTREAM or CANTFIX for bugs that we have no control over. This would get rid of quite a few NVIDIA bugs. Donnie, are you happy with all of this? What are your thoughts? I don't want to make a decision about this on my own since this will affect many users. I've heard from only a few people and the comments have been in favor of this ebuild merge in almost all instances.
(In reply to comment #22) > - Yes, this is sort of a hack, bringing all the sources sepatarely into one > ebuild. The point of this is to make it easy for the user to download the > NVIDIA drivers as you would expect to get them from NVIDIA. The big difference > isebuildwe build them from source though. A revision bump is exactly what I > had planned for the utilities. Historically though, they only modify the > utilies when they release new drivers, so I expect this to be minimal. OK, you might want to reconsider that if they start releasing the utilities independently. > - We cannot fix bugs in the NVIDIA drivers that they do not have patches for. > If a patch is released, we're happy to add it. I think we should start > RESOLVING bugs as UPSTREAM or CANTFIX for bugs that we have no control over. > This would get rid of quite a few NVIDIA bugs. I agree, they should be UPSTREAM. But you should ensure that users actually do report them, not just mark stuff UPSTREAM and forget about it.
Thanks for the comments. I do wish we could get a little more testing before I made the switch. I think I'll let this sit here until after Christmas. Then I'll get it uploaded. Between now and then, we need to direct people to this thread for testing.
> I've heard from only a few people... Ut oh. Have you considered posting the existence of this new ebuild in development on gentoo-dev/users? Maybe even a post to alt.os.gentoo.linux? A message similar to: To all gentoo users who use the nvidia-kernel and nvidia-glx drivers. An experimental update to the way gentoo installs the nvidia drivers and utility programs is currently being tested. Prior to commit, we'd like your feedback. Essentially, we have packaged all the nVidia drivers and utility programs (nvidia-settings and nvidia-xconfig) and all documentation into one ebuild. The bug covering this is at http://bugs.gentoo.org/show_bug.cgi?id=116085. Then follow with some instructions for downloading the tarball and installing into /usr/local/portage. This should get a lot more participation. ITMT, Kris, you may want to roll another tarball of the current suite so users can easily download the latest. Let me know if you want me to help or if you want to post.
Some comments on the code: || ( virtual/x11 >=x11-base/xorg-server-0.99.1-r7 ) || ( virtual/x11 media-libs/mesa ) This is wrong, modular dependencies should be first, not last. # The X module # Since we moved away from libs in /usr/X11R6 need to check this if has_version "<x11-base/xorg-x11-6.8.0-r4" || \ has_version "x11-base/xfree86" ; then mkdir -p ${NV_D}/usr/X11R6 for dir in lib lib32 lib64 ; do [[ -d ${NV_D}/usr/${dir} ]] && mv ${NV_D}/usr/${dir} ${NV_D}/usr/X11R6 done fi Get rid of this cruft. It's more than a year gone at this point, and xfree86 wasn't even the name of the package. Same for check_xfree(). You also need to allow for different module directories -- <=6.8.99.15 are /usr/lib/modules, and modular X is /usr/lib/xorg/modules. Get rid of all references to X11R6; everything in the tree, including 6.8.2, installs to /usr.
(In reply to comment #26) > Some comments on the code: > > Get rid of this cruft. Couldn't have said it better myself. Thanks for clarifying some of the stuff I did not understand. I thought there was a lot of extra code that was superfluous. Kris, I am handing over this to your care now. Let me know if I can help in any way now or in the future.
Cleaned up suggested changes. Updated version to 8178. I will attach new tar file for testing. Please give this a shot guys. And yes, there may still be more cleanups.
Created attachment 75389 [details] nvidia-drivers-8178.tar.gz - Convenient tar file for testing.
Created attachment 75390 [details] nvidia-drivers/nvidia-drivers-1.0.8178.ebuild (Included in tar.)
Peter, Since you volunteered, will you send out some notices about this bug for testing? Thanks
I still have to add modular X support.
How is it with support for multiple kernels? Will it be possible to have different versions?
(In reply to comment #33) > How is it with support for multiple kernels? > Will it be possible to have different versions? > prior to emerge, link /usr/src/desired-kernel /usr/src/linux That should do it. Or, if not, simply boot into the desired kernel and emerge.
src_install-libs() { local pkglibdir=lib local inslibdir=$(get_libdir) if [[ ${#} -eq 2 ]] ; then pkglibdir=${1} inslibdir=${2} elif has_multilib_profile && [[ ${ABI} == "x86" ]] ; then pkglibdir=lib32 fi local usrpkglibdir=usr/${pkglibdir} local libdir=usr/${pkglibdir} X fails to load unless the local libdir=/usr/X11R6/${pkglibdir} (this was the way it existed in ALL previous ebuilds). The function donvidia links files, and X11R6 is being looked for by the driver. So, even though Gentoo does not use X11R6 for anything, this MUST be changed for now. Probably a command line switch somewhere for compiling the driver. Will look.
# libGL.la - a libtool library file # Generated by __GENERATED_BY__ (for use by libtool) # # Please DO NOT delete this file! # It is necessary for linking the library. # The name that we can dlopen(3). dlname='libGL.so' # Names of this library. library_names='libGL.so.1.0.8174 libGL.so.1 libGL.so' # Libraries that this one depends upon. dependency_libs=' -L/usr/X11R6/lib -lm -lXext -lX11 -ldl' libGL.la may be the culprit. See above...
Created attachment 75408 [details, diff] Fix to allow nvidia driver to load The removal of X11R6 from the symlinks cause problems that cause this ebuild to not work. X will abend with messages about not being able to load nvidia, glx, etc. This one line change IS necessary to get this ebuild to work as 8174 did. You don't need to apply the patch, but can edit the ebuild at line 353: local libdir=usr/X11R6/${pkglibdir} where X11R6 is added to the path. Whether this is a linking problem, a hard coded path problem, etc. remains to be seen. At least this will get the driver functioning.
I hadn't realized the tools were being built from source. We should keep anything that's being compiled in a separate package from the kernel module.
Quite apart from this being a bad idea IMHO, it doesn't fly: # emerge nvidia-drivers -v Calculating dependencies ...done! >>> emerge (1 of 1) x11-drivers/nvidia-drivers-1.0.8178 to / >>> Resuming download... >>> Downloading http://www.mirror.ac.uk/sites/www.ibiblio.org/gentoo/distfiles/nvidia-xconfig-1.0.tar.gz --21:55:38-- http://www.mirror.ac.uk/sites/www.ibiblio.org/gentoo/distfiles/nvidia-xconfig-1.0.tar.gz => `/usr/portage/distfiles/nvidia-xconfig-1.0.tar.gz' Resolving www.mirror.ac.uk... 194.80.135.25 Connecting to www.mirror.ac.uk|194.80.135.25|:80... connected. HTTP request sent, awaiting response... 404 Not Found 21:55:39 ERROR 404: Not Found. >>> Resuming download... >>> Downloading http://distfiles.gentoo.org/distfiles/nvidia-xconfig-1.0.tar.gz --21:55:39-- http://distfiles.gentoo.org/distfiles/nvidia-xconfig-1.0.tar.gz => `/usr/portage/distfiles/nvidia-xconfig-1.0.tar.gz' Resolving distfiles.gentoo.org... 64.50.238.52, 156.56.247.195, 216.165.129.135, ... Connecting to distfiles.gentoo.org|64.50.238.52|:80... connected. HTTP request sent, awaiting response... 404 Not Found 21:55:39 ERROR 404: Not Found. >>> Resuming download... >>> Downloading http://distro.ibiblio.org/pub/Linux/distributions/gentoo/distfiles/nvidia-xconfig-1.0.tar.gz --21:55:39-- http://distro.ibiblio.org/pub/Linux/distributions/gentoo/distfiles/nvidia-xconfig-1.0.tar.gz => `/usr/portage/distfiles/nvidia-xconfig-1.0.tar.gz' Resolving distro.ibiblio.org... 152.2.210.109 Connecting to distro.ibiblio.org|152.2.210.109|:80... connected. HTTP request sent, awaiting response... 404 Not Found 21:55:39 ERROR 404: Not Found. >>> Resuming download... >>> Downloading ftp://download.nvidia.com/XFree86/nvidia-xconfig/nvidia-xconfig-1.0.tar.gz --21:55:39-- ftp://download.nvidia.com/XFree86/nvidia-xconfig/nvidia-xconfig-1.0.tar.gz => `/usr/portage/distfiles/nvidia-xconfig-1.0.tar.gz' Resolving download.nvidia.com... 216.228.115.13, 216.228.121.15, 216.228.115.17 Connecting to download.nvidia.com|216.228.115.13|:21... connected. Logging in as anonymous ... Logged in! ==> SYST ... done. ==> PWD ... done. ==> TYPE I ... done. ==> CWD /XFree86/nvidia-xconfig ... done. ==> SIZE nvidia-xconfig-1.0.tar.gz ... done. ==> PASV ... done. ==> REST 86160 ... done. ==> RETR nvidia-xconfig-1.0.tar.gz ... done. Length: 86,160 (84K), 0 (0) remaining 100%[++++++++++++++++++++++++++++++++++++++++++++++++++++++] 86,160 --.--K/s 21:55:42 (0.00 B/s) - `/usr/portage/distfiles/nvidia-xconfig-1.0.tar.gz' saved [86160] !!! Couldn't download nvidia-xconfig-1.0.tar.gz. Aborting.
(In reply to comment #34) > > How is it with support for multiple kernels? > > Will it be possible to have different versions? > prior to emerge, link /usr/src/desired-kernel /usr/src/linux When emerge it for gentoo-sources-2.6.13-r5 and then for gentoo-sources-2.6.14-r5, will the whole installation be there or will we suddenly have that the emerging for gentoo-sources-2.6.13-r5 has been removed from the system? (still working with the --oneshot option?) Or what if different versions of the driver is requiered for different versions of the kernel, will this now be possible? (this ain't really the case today).
(In reply to comment #40) > When emerge it for gentoo-sources-2.6.13-r5 and then for > gentoo-sources-2.6.14-r5, will the whole installation be there or will we > suddenly have that the emerging for gentoo-sources-2.6.13-r5 has been removed > from the system? (still working with the --oneshot option?) Nothing is different in the handling of the kernel component. When /usr/src/linux is linked to a kernel, that's where emerge will put or remove files. An earlier kernel's nvidia.ko file should remain untouched. > > Or what if different versions of the driver is requiered for different versions > of the kernel, will this now be possible? (this ain't really the case today). > This circumstance would be interesting. I have not seen this. But, in theory, the old nvidia.ko driver would reside in the old kernel tree, and a new one in the then current one. There is _not_ the clear cut -K option whicn nvidia has in its run file. If your situation becomes that custom, then I would suggest abandoning ebuilds all together and use the nvidia-installer. That allows you a lot of flexibility and compile options for multiple kernels. As for your other point, the entire suite of applications would be re-emerged each time. However, absent a version bump, no further download need be done and compile time is very short. Please test and report.
(In reply to comment #39) > Quite apart from this being a bad idea IMHO, it doesn't fly: > Thank you. I don't know why that happens today and not yesterday :). I was able to duplicate your error completely. Kris, why does this work, and the existing code not anymore? if use x86; then NVDL="ftp://download.nvidia.com/XFree86/Linux-x86/${NV_V}/${X86_NV_PACKAGE}-${X86_PKG_V}.run" elif use amd64; then NVDL="ftp://download.nvidia.com/XFree86/Linux-x86_64/${NV_V}/${AMD64_NV_PACKAGE}-${AMD64_PKG_V}.run" fi NVDL="${NVDL} ftp://download.nvidia.com/XFree86/${NVS}/${NVS}-${NVS_V}.tar.gz \ ftp://download.nvidia.com/XFree86/${NVX}/${NVX}-${NVX_V}.tar.gz" echo "$NVDL" DESCRIPTION="NVIDIA Linux X11 driver, GLX libraries, and utilities" HOMEPAGE="http://www.nvidia.com/" SRC_URI=${NVDL} works fine here without the x86? and amd64?. Go figure.
Did you just upgrade to 2.1 portage, or bash 3.1?
(In reply to comment #43) > Did you just upgrade to 2.1 portage, or bash 3.1? > I did just upgrade portage to 2.0.53, but had to upgrade baselayout to 1.11.14 due to a dependency in an ~x86 package. Bash is still 3.0... Could this have something to do with this?
BTW, freebsd source download does not occur. There is a tar.gz avail at: ftp://download.nvidia.com/freebsd/1.0-8178/NVIDIA-FreeBSD-x86-1.0.8178.tar.gz Might be important to take that too. Add to the download conditional: elif use x86-fbsd; then NVDL="ftp://download.nvidia.com/freebsd/1.0-8178/NVIDIA-FreeBSD-x86-1.0.8178.tar.gz " fi Of course the QA warnings will continue to show for x86-fbsd since it's not a recognized arch at the moment. This part needs a lot of testing since I think the fbsd was pretty much hacked from the existing x86 sources.
carlo@gentoo.org posted the following on the gentoo-dev list. It is copied here with his permission. He was responding to a user's thought that a meta-type ebuild for nvidia might be a viable solution which would help both those who want module indepence, and those who want simplicity and "one stop shopping." I responded to the user that his idea was a reasonable comment. carlo replied... Not at all. "Meta ebuilds" are a provisional and fugly workaround as long as we have to wait for proper sets and only to be used for a larger set of packages. Wrapping three or four ebuilds with another one, just for the sake of lazy people having only to emerge a single ebuild is ridiculous. The only valid point in the original idea to merge the nvidia-* packages is to reduce the overall number of packages in the repository. As you heard the voices against it, ranging from none to valid reasons, everything left is to bury the idea and to close the bug. ---------------- I wanted to post these comments so they will be considered along with others we receive. All pov's should be considered.
Created attachment 75455 [details] nvidia-drivers-1.0.8178.ebuild portage > 2.0.52 killed the download capability here. This ebuild works around that by assigning NVDL to include all download sources. It also adds in the fbsd source to be downloaded. This part needs testing. Hopefully flameeyes will come over and help. To use, 1) download and replace existing ebuild in /usr/local/portage/x11-drivers/nvidia-drivers/ . 2) Run ebuild *8178.ebuild digest. 3) emerge as normal.
Created attachment 75456 [details] nvidia-drivers-1.0.8178.ebuild It would help to proof read once in a while :( fbsd download file was missing a /
A last question from me at at least. Will this unified build be replacing those old modular builds we have had this far? or will we see them side by side in the portage tree? Whats feels a bit strange IMHO is that Xorg is going modular, suddenly a driver merge together with application and becomes a kind of monolithic build instead. I hope the modular builds won't be replaced.
DEPEND="virtual/linux-sources virtual/x11 >=x11-libs/gtk+-2" This ebuild need depencies updated for modular X. See also bug #114603.
news.gmane.org gmane.linux.gentoo.devel:34284 Overwhelmingly against for a number of reasons. Some of the less contentious responses requested an option to do things like they are, so when a kernel is updated, they don't have to reinstall everything (even though it's just one minute!) Some liked the idea of a meta ebuild which would do everything AND leave users the option of updating just one module. Many complained that they don't LIKE the nvidia userland programs (or can't use them due to arch) so there is no need to package them! Personally, I think a unified approach has value, but if nothing else, at least the ebuilds got cleaned up!
So there does appear to be a lot of people against this (or at least a few people who talk loudly). What do you think if we do what ATI does? We'll split this and make an nvidia-drivers and an nvidia-extra or nvidia-utils. I like it. Then there is no recompile of anything on kernel rebuild. Only reinstall of pre-build glx files.
(In reply to comment #52) > So there does appear to be a lot of people against this (or at least a few > people who talk loudly). What do you think if we do what ATI does? We'll > split this and make an nvidia-drivers and an nvidia-extra or nvidia-utils. I > like it. Then there is no recompile of anything on kernel rebuild. Only > reinstall of pre-build glx files. > Well, even _that_ bothers people (flameeyes). I can understand people who don't want the utilities, and can visualize splitting them into one or even two pakages. But I don't understant the resistance because, as you say, this is how the ATI project is handled. Heck, you may even get flak moving the ebuilds from media-video (where they don't belong) to x11-drivers (where they do belong)! However, if you proceed, I see three alternatives based on current feedback (which I take seriously, and probably too personally): In each scenario, nvidia-settings and nvidia-xconfig will stay separated. 1) nvidia-kernel and glx combined into a single ebuid. 2) nvidia-kernel and glx remain separate and stay as they are -- maybe moving to x11 where they belong. 3) create a meta-type ebuild which would bring in both on request (this would allow the users to cherry pick if they want). Maybe even have the meta bring in the extra programs? Interestingly on the ng, even choice 3 was received in a "well, if you have to do something, do this so we can keep doing things the old way." I see logic and economy in 1) since everything comes from one package. I am amazed at the strong reaction this provoked. I always thought simplification and streamlining is better!
I don't know how to resolve this issue. What do you do in a situation where some want it and some don't? We're a community here, so do we vote? :-)
(In reply to comment #54) > I don't know how to resolve this issue. What do you do in a situation where > some want it and some don't? We're a community here, so do we vote? :-) > MYOP says the devs control things, just like when kde went split. Here's a possible solution. 1) first off, regardless of whether or not nvidia is unified, they should be moved to x11-drivers and x11-misc. media-video is really the wrong place. 2) I do see the logic of splitting off the utilities from the kernel modules. They are different and come from different places (even though nvidia packages them together). If -settings and -xconfig are split from the unified package, they should remain unique. 3) I do _NOT_ understand the resistance to including the glx driver with the kernel driver. It's no overhead and it's there already. Flameeye's complaint is not clear to me anyway. I think nvidia-drivers should contain everything needed to get an X session up and running. 4) I do _NOT_ see the benefit of creating a meta-type ebuild which has RDEPEND for kernel and glx as some had proposed. This is a hack and wasted effort. Now, if nvidia decides to package all tools together with the driver at some future point, then I say combine everything again regardless of resistance. But as long as only the ia32 binaries are included in the *.run files, take out the utils. JM2C
Created attachment 76719 [details, diff] patch to install libGL.la again Apparently some ebuilds (epsilon, for example) need libGL.la and look for it during linking. So, this code fragment from the nvidia-glx ebuild is back. Also, will need to copy over the libGL.la-r2 from media-video/nvidia-glx/files so it will install properly. Isn't this file avail in the pkg.run file? Shouldn't we use it if it is?
(In reply to comment #54) > I don't know how to resolve this issue. What do you do in a situation where > some want it and some don't? We're a community here, so do we vote? :-) > From the mailing list, not many was for this idea if I am not mistaken ... also, this will be a step backwards, as we already split it once due to user request ... I am not a fan. At most, ill go for a nvidia-driver or something that just depends on the whole bunch.
Few extra points maybe: - nvidia-kernel and nvidia-glx is split, as not the update/first_time_install time is longer/shorter, but the rebuild if just the kernel changed is longer especially on older machines. Don't as me, but it was back then the biggest reasoning for most users for the split. - not everybody want nvidia-settings and nvidia-xconfig, and USE flags will be silly for this case. - nvidia-settings for example updates only once for 3 or more nvidia-drivers updates. - not really that a big point, as it could be avoided, but leaving as is will probably result in the least amount of new bugs introduced. Which is why i think an nvidia-driver(s) that just depends on all four packages might be the better solution, as it caters for those not wanting the extra, the people with slower machines that do lot of kernel testing/updating, and should not inconvenience those with the blazing fast new machines. Just me though.
this is a blocker. Need same patch for unified drivers or else!
Created attachment 77807 [details] x11-drivers/nvidia-drivers/nvidia-drivers-1.0.8178-r2.ebuild Update to include 1/18/06 patches
Created attachment 77808 [details, diff] files/1.0.8178/NVIDIA-1.0-8178-U011806.diff patch which must go into x11-drivers/nvidia-drivers/files.
Removing depend bug since this fixes everything.
Where are we going with this? Should we just close it.
Seems like lack of interest and inertia killed this. Closing since I'm the reporter. If anyone else wants to resurrect, hey, go ahead. Augustus, your call.
Closing./
