[gentoo-user] Applying patches without needing overlays and modifying ebuilds
Does anyone think that a mechanism of applying patches to a package without the need to modify the ebuild of that package would be a useful feature? There are cases of useful patches that are not accepted by the maintainers of the ebuild (because they have not been accepted upstream or other reasons), forcing users to copy ebuilds in their overlay and modifying the ebuild there. This turns out to be a hassle every time the package receives an update. What if we could just specify patches to be applied in, say, /etc/portage/packages.patch with something like: media-video/smplayer j-random-hack.patch and portage would apply that patch automatically? That way, the hassle of updating the ebuild of a package in which I use custom patches would go away. The patches could be searched for in a designated directory, in this example maybe /var/portage/patches/media-video/smplayer (or something else entirely.) Can someone think of a way to set up something like this?
Re: [gentoo-user] Applying patches without needing overlays and modifying ebuilds
Nikos Chantziaras wrote: Does anyone think that a mechanism of applying patches to a package without the need to modify the ebuild of that package would be a useful feature? There are cases of useful patches that are not accepted by the maintainers of the ebuild (because they have not been accepted upstream or other reasons), forcing users to copy ebuilds in their overlay and modifying the ebuild there. This turns out to be a hassle every time the package receives an update. What if we could just specify patches to be applied in, say, /etc/portage/packages.patch with something like: media-video/smplayer j-random-hack.patch and portage would apply that patch automatically? That way, the hassle of updating the ebuild of a package in which I use custom patches would go away. The patches could be searched for in a designated directory, in this example maybe /var/portage/patches/media-video/smplayer (or something else entirely.) Can someone think of a way to set up something like this? Patches are already stored in a files directory. For instance, it would be /var/portage/media-video/smplayer/files in your example. Maybe I'm missing some point you were trying to make.
Re: [gentoo-user] /dev/sr0 has disappeared: solved
090516 Dirk Heinrichs wrote: Am Samstag, 16. Mai 2009 11:55:18 schrieb Philip Webb: I have got 2.6.25 to work again after enabling 'evdev' evdev is completely unrelated to CD writing. Yes, I know that: it was necessary in order to resurrect 2.6.25 after the big change in Xorg recently: I mentioned it in my OP. OK, let's look at the interesting parts: 03:00.0 IDE interface: JMicron Technologies, Inc. JMB368 IDE controller Kernel driver in use: pata_jmicron For this you need CONFIG_PATA_JMICRON=y, which you don't have. Aha ! -- it was present for 2.6.25 , so what happened to it ... ? Let's go through the kernel config: # CONFIG_PCIEPORTBUS is not set You really need to enable this (that is a PCI-Express machine, isn't it?). I didn't have in in 2.6.25 it doesn't seem to do anything I want: do you have suggestions what it might help with ? CONFIG_BLK_DEV_FD=y Do you have a floppy drive, still? Yes lots of diskettes too (they ceased to be floppy long ago: grin)). I use one for quick back-ups of files I'm working on. CONFIG_HAVE_IDE=y Useless. Hmm, seems to be selected automatically, thus not that useless ;) However, I can't even find it in menuconfig. # CONFIG_CHR_DEV_SG is not set As written before: No SG, no write (to CD). No, I didn't have it in 2.6.25 have just blanked a CD without it. The kernel help recommends 'No' unless you have a special reason. # CONFIG_ATA_SFF is not set You need to enable this to make CONFIG_PATA_JMICRON visible. ... THAT's what happened to it !! This is the change in 2.6.29 (it could have been in 2.6.26-8 , which I didn't install). So having enabled these two options, I now get /dev/sr0 can read write (at least blank) a CD again. This is another trap in configuring a new kernel, ie some needed option is moved /or needs another enabled to see it. Another trap I ran into briefly was a field needing a string, which looks as if all it needs is 'y/n' (also in 2.6.29). Thanks for the careful analysis. I will post a msg to the Forum, as there have been several inquiries there which seemed unresolved. -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
[gentoo-user] Re: Applying patches without needing overlays and modifying ebuilds
Saphirus Sage wrote: Nikos Chantziaras wrote: Does anyone think that a mechanism of applying patches to a package without the need to modify the ebuild of that package would be a useful feature? There are cases of useful patches that are not accepted by the maintainers of the ebuild (because they have not been accepted upstream or other reasons), forcing users to copy ebuilds in their overlay and modifying the ebuild there. This turns out to be a hassle every time the package receives an update. What if we could just specify patches to be applied in, say, /etc/portage/packages.patch with something like: media-video/smplayer j-random-hack.patch and portage would apply that patch automatically? That way, the hassle of updating the ebuild of a package in which I use custom patches would go away. The patches could be searched for in a designated directory, in this example maybe /var/portage/patches/media-video/smplayer (or something else entirely.) Can someone think of a way to set up something like this? Patches are already stored in a files directory. For instance, it would be /var/portage/media-video/smplayer/files in your example. Maybe I'm missing some point you were trying to make. The point I'm trying to make is applying patches without even touching the ebuild.
Re: [gentoo-user] /dev/sr0 has disappeared: solved
Am Sonntag, 17. Mai 2009 09:18:52 schrieb Philip Webb: However, I can't even find it in menuconfig. # CONFIG_CHR_DEV_SG is not set As written before: No SG, no write (to CD). No, I didn't have it in 2.6.25 have just blanked a CD without it. The kernel help recommends 'No' unless you have a special reason. With the special reasons listet in the very first lines: If you want to use SCSI scanners, synthesizers or CD-writers or just about anything having SCSI in its name other than hard disks, CD-ROMs or tapes, say Y here. Bye... Dirk signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: Applying patches without needing overlays and modifying ebuilds
On Sun, 17 May 2009 10:20:33 +0300
Nikos Chantziaras rea...@arcor.de wrote:
What if we could just specify patches to be applied in, say,
/etc/portage/packages.patch with something like:
media-video/smplayer j-random-hack.patch
...
Can someone think of a way to set up something like this?
I'd suggest passing the list of patches thru the environment - it
should be much easier to implement than commandline. Like this:
MY_PATCHES='j-random-hack.patch' emerge media-video/smplayer
Then you can edit /usr/portage/eclass/base.eclass, adding processing of
this var and all the patching you need to base_src_util function,
right after unpack ${A}.
In fact, I think I've seen such thing already implemented somewhere,
but prehaps it's just a by-product of my imagination.
--
Mike Kazantsev // fraggod.net
signature.asc
Description: PGP signature
Re: [gentoo-user] Applying patches without needing overlays and modifying ebuilds
Nikos Chantziaras rea...@arcor.de writes: What if we could just specify patches to be applied in, say, /etc/portage/packages.patch with something like: media-video/smplayer j-random-hack.patch and portage would apply that patch automatically? That way, the hassle of updating the ebuild of a package in which I use custom patches would go away. One problem here is the order of patches. Often the order that the patches need to be applied is important, and your mechanism does not allow you to specify the order with respect to those patches in the ebuild. Another problem is that when a package is upgraded, the patches required can change. The patch that worked with version X might have to be changed for version X+1 or may not be needed any more. So it is necessary to do some work anyway when upgrading packages.
Re: [gentoo-user] Applying patches without needing overlays and modifying ebuilds
On Sun, 17 May 2009 09:44:19 +0300, Nikos Chantziaras wrote:
Does anyone think that a mechanism of applying patches to a package
without the need to modify the ebuild of that package would be a useful
feature? There are cases of useful patches that are not accepted by
the maintainers of the ebuild (because they have not been accepted
upstream or other reasons), forcing users to copy ebuilds in their
overlay and modifying the ebuild there. This turns out to be a hassle
every time the package receives an update.
I think you can redefine ebuild functions in /etc/portage/env/cat/pkg, so
you could out a custom src_unpack() in there. It should work if the ebuild
has no src_unoack, so you could do something like
src_unpack() {
unpack ${A}
epatch mypatch
}
I don't know how this would work with an existing src_unpack in the
ebuild, if you copied the existing function and added your patch.
--
Neil Bothwick
i *DId* rEaD tHE DoCS; ThaT'S WHy I'm conFuSeD!
signature.asc
Description: PGP signature
Re: [gentoo-user] Re: New xorg.conf with x11-base/xorg-server-1.5.3-r5
On Sunday 17 May 2009 03:33:22 pk wrote: Alan McKinnon wrote: As I see it, at the bottom of the stack you have a kernel and at the top a user space app (the X server will do for an example). Plug in a USB device that the app can use, and the kernel needs to make a node in /dev for it if it's not already there. The kernel should not be interrogating the device for all possible info - that is expensive - and doesn't need to. It only needs enough info to know what driver, major and minor numbers to use. X OTOH, can I couldn't agree more. And this is what Udev, as a user space app, does. The only thing it doesn't handle is communicating with other user space apps; this is currently Hals job. the current model uses udev as the interface to the kernel's nodes and HAL as the interface to exactly what hardware you have. Seems pretty sane for the most usual use case. At some point in the stack you will need the OS-dependant part, my guess is the best place is between hal and udev. Only Linux uses Well, as I understand it this is what it looks like today: kernel - udev (or equivalent for non-linux kernel/OS) - hal - dbus - user apps To me that seems a bit redundant... No, there's nothing redundant in that. udev talks kernel-speak, hal talks userspace-speak. Hal could be distro-agnostic, udev can't be (not in a sane environment) and dbus is simply a transport layer for messages. That's five different functions going on, and none of them logically belong with any other in the same layer. What I would like to see: kernel - udev - user apps Then X must talk to udev directly. Two problems: - only Linux has udev. Other OSes may not need, want or be willing to touch udev with a bargepole. - X is multi-platform. Good luck getting Keith to agree to make it essentially Linux only :-) Or at the most: kernel - udev - daemon - user apps. But you have that in the current setup. Hal (for better or worse) is the daemon. dbus is simply a message transport and can be omitted from the conceptual diagram udev, but all OSes use something in that spot. And if not, they have static nodes. Yes, but if the developers could agree on a common API for the udev daemon and it's equivalents on other platforms (what does BSD use?)... Or if they could agree on using Hal v2 (rewritten from scratch with no or a minimum of dependencies). I don't think that's feasible. Easiest would be the bottom layer of hal has OS-specific code to talk to udev (or it's equivalent in other OSes). Or perhaps a plugin/module type system. Meanwhile we have an acknowledged problem with hal - it's too complex, too many things have been shoved into it that were never catered for in the design, configuration is horrific - and the devs are having their usual spirited debate about how best to approach a solution. This is perfectly normal and perfectly healthy Yes, I guess so. Since I'm (currently) not in the position to help out I'll have to live with whatever they come up with. But sometimes it's a bit frustrating... Sorry for the ranting. Hey, it could be worse. You could be forced to use Windows... -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Applying patches without needing overlays and modifying ebuilds
On Sun, 17 May 2009 09:42:20 +0100
Neil Bothwick n...@digimed.co.uk wrote:
I think you can redefine ebuild functions
in /etc/portage/env/cat/pkg, so you could out a custom src_unpack()
in there. It should work if the ebuild has no src_unoack, so you
could do something like
src_unpack() {
unpack ${A}
epatch mypatch
}
I don't know how this would work with an existing src_unpack in the
ebuild, if you copied the existing function and added your patch.
I use /etc/portage/bashrc for the same purpose. For instance, this is a
patch I'm tacking onto portage ATM:
if [[ ${CATEGORY}/${PN} == sys-apps/portage ]]
then
post_src_unpack() {
cd ${S}/bin
epatch /etc/portage/patches/misc-functions.patch
}
fi
As you can see, there are post_ and pre_ phases for all phase functions
which can be used to do fancy stuff like this.
I prefer /etc/portage/bashrc for this, since these hacks are usually
only needed for a short time, so having them all in one place for an
easy overview helps to keep the cruft down.
/loki_val
[gentoo-user] Re: Applying patches without needing overlays and modifying ebuilds
Peter Alfredsen wrote:
On Sun, 17 May 2009 09:42:20 +0100
Neil Bothwick n...@digimed.co.uk wrote:
I think you can redefine ebuild functions
in /etc/portage/env/cat/pkg, so you could out a custom src_unpack()
in there. It should work if the ebuild has no src_unoack, so you
could do something like
src_unpack() {
unpack ${A}
epatch mypatch
}
I don't know how this would work with an existing src_unpack in the
ebuild, if you copied the existing function and added your patch.
I use /etc/portage/bashrc for the same purpose. For instance, this is a
patch I'm tacking onto portage ATM:
if [[ ${CATEGORY}/${PN} == sys-apps/portage ]]
then
post_src_unpack() {
cd ${S}/bin
epatch /etc/portage/patches/misc-functions.patch
}
fi
As you can see, there are post_ and pre_ phases for all phase functions
which can be used to do fancy stuff like this.
I prefer /etc/portage/bashrc for this, since these hacks are usually
only needed for a short time, so having them all in one place for an
easy overview helps to keep the cruft down.
Thanks. I already have a /etc/portage/bashrc in place, which pulls
packages out of /etc/portage/package.icc to be compiled with Intel C++.
I'll try to use the same mechanism to pull patches from
/etc/portage/package.patch for packages listed there.
Re: [gentoo-user] How to IPSEC M$oft VPN client setup
On Sunday 17 May 2009, Mick wrote: Thanks Graham, On Saturday 16 May 2009, Graham Murray wrote: Here are some samples. /etc/racoon/racoon.conf /etc/racoon/psk.txt /etc/ipsec.conf Do I need a /etc/setkey.conf file? How do I create it? When I run '/etc/init.d/racoon start' this is what I get: === # /etc/init.d/racoon --verbose restart * Loading ipsec policies from /etc/ipsec.conf. * Starting racoon ... /usr/sbin/racoon: invalid option -- '4' usage: racoon [-BdFv] [-a (port)] [-f (file)] [-l (file)] [-p (port)] -B: install SA to the kernel from the file specified by the configuration file. -d: debug level, more -d will generate more debug message. -C: dump parsed config file. -L: include location in debug messages -F: run in foreground, do not become daemon. -v: be more verbose -a: port number for admin port. -f: pathname for configuration file. -l: pathname for log file. -p: port number for isakmp (default: 500). -P: port number for NAT-T (default: 4500). [ !! ] === I am not sure I do this right. The remote router's LAN is 10.10.10.0/24. This is the same like my local LAN's subnet. My local LAN ip is 10.10.10.5. The remote router is giving (or is it expecting?) addresses for clients in the 172.16.1.0/24 subnet. How should I configure the /etc/ipsec.conf file? The more I try to use VPN the more I love SSH! http://bugs.gentoo.org/87920 -- Regards, Mick signature.asc Description: This is a digitally signed message part.
[gentoo-user] Re: Problem with compiling kernel
Mick schrieb: Last time this happened to me (more than once), it was because I had selected something in the kernel that I shouldn't have. I had to retrace my steps, removed the offending module and then it compiled and installed fine. I think you are right. Yesterday I had some time to look more closely into this and came to the same conclusion. I will first try to build an external initrd, which will be loaded during boot. Perhaps I will later switch back to include the initrd inside the kernel. Thanks for your help. Marc
Re: [gentoo-user] Re: New xorg.conf with x11-base/xorg-server-1.5.3-r5
Alan McKinnon wrote: - only Linux has udev. Other OSes may not need, want or be willing to touch udev with a bargepole. Yes, udev is linux only. Replace udev with whatever is available on other platforms in that diagram. I just used linux as an example... Sorry for not making it clear. But you have that in the current setup. Hal (for better or worse) is the daemon. dbus is simply a message transport and can be omitted from the conceptual diagram Why is dbus needed? Why can't the user space apps talk to the user space daemon directly? To me it's just another unnecessary layer, each layer needs some kind of translation and thus resources. To me hal or whatever may replace it should have a minimalist approach. You could be forced to use Windows... Well, the way I see it, some people/projects are aiming to create a new Windows. But I'm doing a don Quijote here... Best regards Peter K
Re: [gentoo-user] Re: Copying encrypted files from a DVD
There are still a lot of DVD-Video media that don't use CSS. I have certainly cloned region-protected DVDs on a number of occasions using `dd`. These disks have given no read errors, and the subsequent encrypted .iso image has produced perfectly fine rips. Most video DVDs are dual layer how did you write them? You can play the dvd.iso using mplayer - it will decrypt on the fly - or you decrypt them some other method before re-authoring. Usually I just convert them to mp4 using mplayer / mencoder. If you like to write it to DVD in a way that allows standalone players to read it, you need to retain the layer break. You read it out with cdrecord and you set it with cdrecord driveropts=layerbreak=# Jörg dvdstyler is good for turning an mp4 (for example) into a DVD that can be read by a standalone player. Dual layer is handled transparently. - Grant
Re: [gentoo-user] Re: New xorg.conf with x11-base/xorg-server-1.5.3-r5
On Sunday 17 May 2009 14:15:31 pk wrote: But you have that in the current setup. Hal (for better or worse) is the daemon. dbus is simply a message transport and can be omitted from the conceptual diagram Why is dbus needed? Why can't the user space apps talk to the user space daemon directly? To me it's just another unnecessary layer, each layer needs some kind of translation and thus resources. To me hal or whatever may replace it should have a minimalist approach. Because the methodology is not that user-space apps talk to hal, but that hal sends events to user space apps that are listening. And hal does not and should not know anything about those apps. Polling vs events is a problem that was solved a very long time ago. For a dynamically changing system, events wins hands down almost always (one major exception - real time OSes). It's asynchronous, easier to program and both hal and the user space app talk to one and only one well defined API, and just forget all about timing issues. From an engineering point of view, a message bus is an excellent idea. -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] upgrading from kernel 2.6.24-rc6 to latest kernel
bn ha scritto: 2) What are the caveats and pitfalls I should be aware of when upgrading to latest kernel? I confess that reading CHANGELOGs didn't help me too much, quite confusing. I resume this thread because I read ofthings like that (/dev/sr0 has disappeared thread): You need to enable this to make CONFIG_PATA_JMICRON visible. ... THAT's what happened to it !! This is the change in 2.6.29 (it could have been in 2.6.26-8 , which I didn't install). So having enabled these two options, I now get /dev/sr0 can read write (at least blank) a CD again. This is another trap in configuring a new kernel, ie some needed option is moved /or needs another enabled to see it. Another trap I ran into briefly was a field needing a string, which looks as if all it needs is 'y/n' (also in 2.6.29). So, what kind of traps like that should I expect? cheers, m.
Re: [gentoo-user] upgrading from kernel 2.6.24-rc6 to latest kernel
On Sun, 2009-05-17 at 16:46 +0100, bn wrote: So, what kind of traps like that should I expect? I expect things like that to have potentially changed with every point release of the 2.6 kernel, since the numbering scheme is practically useless now. Every 2.6.XX release has the potential for major changes. Typically I will run a make oldconfig and then walk through the menuconfig options. I don't consider it a pleasant exercise, but since I don't upgrade the kernel very much it's not so terrible. -Sean
Re: [gentoo-user] upgrading from kernel 2.6.24-rc6 to latest kernel
090517 bn wrote: What are the caveats and pitfalls I should be aware of when upgrading to latest kernel? I resume this thread because I read of things like /dev/sr0 has disappeared You need to enable this to make CONFIG_PATA_JMICRON visible. ... THAT's what happened to it !! This is the change in 2.6.29 (it could have been in 2.6.26-8 , which I didn't install). So having enabled these two options, I now get /dev/sr0 can read write (at least blank) a CD again. This is another trap in configuring a new kernel, ie some needed option is moved /or needs another enabled to see it. Another trap I ran into briefly was a field needing a string, which looks as if all it needs is 'y/n' (also in 2.6.29). So, what kind of traps like that should I expect? That's part of the fun: you don't know what will hit you till it does ! As the OP of the above quote, my own resolution is to upgrade more often. 'make oldconfig' is the usual recommendation, but there's no help: it's just a list of Do you want to ... ? which you can't save easily. I upgraded from 2.6.25 that was the only real problem, which was caused by a change in 'make menuconfig' layout, so I'ld say go ahead, but step cautiously thro' the configuration, then test everything afterwards (I didn't find out re CDs till just now). Each new kernel sb accompanied by a list of changes in configuration with a short help paragraph for each: at present, that's missing. Something to for Gentoo devs to nag upstream to get improved (smile). -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-user] Re: New xorg.conf with x11-base/xorg-server-1.5.3-r5
Dale ha scritto: I hope someone wins the debate soon and gets this to work and be user friendly. I'm about to make a fresh backup and try this again. I have upgraded my kernel to a really new version, 2.6.25. Sorry, nvidia won't compile with anything newer that I have tried. Uh? last nvidia-drivers needs 2.6.25 kernel? m.
Re: [gentoo-user] Applying patches without needing overlays and modifying ebuilds
On Sun, 17 May 2009 12:13:27 +0200, Peter Alfredsen wrote:
As you can see, there are post_ and pre_ phases for all phase functions
which can be used to do fancy stuff like this.
Neat!
I prefer /etc/portage/bashrc for this, since these hacks are usually
only needed for a short time, so having them all in one place for an
easy overview helps to keep the cruft down.
Each to his own. I prefer a separate file for each program (or set of
programs), as it makes the function, and continued need, of each one
obvious. The same with /etc/portage/packages.{use,unmask,etc}.
--
Neil Bothwick
I've got a mind like a... a... what's that thing called?
signature.asc
Description: PGP signature
Re: [gentoo-user] upgrading from kernel 2.6.24-rc6 to latest kernel
On Sun, 17 May 2009 12:18:14 -0400, Philip Webb wrote: 'make oldconfig' is the usual recommendation, but there's no help: it's just a list of Do you want to ... ? which you can't save easily. Of course there;s help. Most options give a choice of y/n/m/?. Guess what happens when you press? -- Neil Bothwick WinErr 001: Windows loaded - System in danger signature.asc Description: PGP signature
Re: [gentoo-user] Re: New xorg.conf with x11-base/xorg-server-1.5.3-r5
On Sunday 17 May 2009 19:10:05 bn wrote: Dale ha scritto: I hope someone wins the debate soon and gets this to work and be user friendly. I'm about to make a fresh backup and try this again. I have upgraded my kernel to a really new version, 2.6.25. Sorry, nvidia won't compile with anything newer that I have tried. Uh? last nvidia-drivers needs 2.6.25 kernel? Dale has an old video card and needs one of the nvidia legacy driver releases. He finds that that release doesn't work with kernels after .25 -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Re: New xorg.conf with x11-base/xorg-server-1.5.3-r5
Alan McKinnon ha scritto: On Sunday 17 May 2009 19:10:05 bn wrote: Dale ha scritto: I hope someone wins the debate soon and gets this to work and be user friendly. I'm about to make a fresh backup and try this again. I have upgraded my kernel to a really new version, 2.6.25. Sorry, nvidia won't compile with anything newer that I have tried. Uh? last nvidia-drivers needs 2.6.25 kernel? Dale has an old video card and needs one of the nvidia legacy driver releases. He finds that that release doesn't work with kernels after .25 Uh, I see. I was worried, sorry. m.
Re: [gentoo-user] Re: New xorg.conf with x11-base/xorg-server-1.5.3-r5
On Sun, May 17, 2009 at 11:00 AM, Alan McKinnon alan.mckin...@gmail.com wrote: On Sunday 17 May 2009 19:10:05 bn wrote: Dale ha scritto: I hope someone wins the debate soon and gets this to work and be user friendly. I'm about to make a fresh backup and try this again. I have upgraded my kernel to a really new version, 2.6.25. Sorry, nvidia won't compile with anything newer that I have tried. Uh? last nvidia-drivers needs 2.6.25 kernel? Dale has an old video card and needs one of the nvidia legacy driver releases. He finds that that release doesn't work with kernels after .25 Hummnow I'm getting interested. I just did an emerge -DuN world to my dad's machine in Southern California last night. He's got a 6 year old machine with an old nvidia card that's no longer supported by the newest drivers so the emerge messages tell me that I have to use an older legacy version of the driver. Thing is I have him on gentoo-sources-2.6.29-r4 using nvidia-drivers-96.43.09. Everything seems to be working from here. I see the driver in memory. I Can run X apps remotely. gandalf ~ # uname -a Linux gandalf 2.6.29-gentoo-r4 #3 PREEMPT Sun May 17 06:58:58 PDT 2009 i686 AMD Athlon(tm) XP 2500+ AuthenticAMD GNU/Linux gandalf ~ # gandalf ~ # emerge -pv nvidia-drivers These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] x11-drivers/nvidia-drivers-96.43.09 USE=acpi gtk -custom-cflags (-multilib) 0 kB Total: 1 package (1 reinstall), Size of downloads: 0 kB gandalf ~ # I guess my question is whether he's going to have issues. He's really bad about reporting this stuff to me and I'm not there to see the screen or use the system. I don't see much in /var/log/Xorg.0.log other than a complaint about GLX and freetype. freetype I can fix. GLX I haven't looked into. Any problems? Thanks, Mark
Re: [gentoo-user] upgrading from kernel 2.6.24-rc6 to latest kernel
Neil Bothwick wrote: On Sun, 17 May 2009 12:18:14 -0400, Philip Webb wrote: 'make oldconfig' is the usual recommendation, but there's no help: it's just a list of Do you want to ... ? which you can't save easily. Of course there;s help. Most options give a choice of y/n/m/?. Guess what happens when you press? Usually something that doesn't make much sense. Happens here all the time. Same as a man page. I just need a brighter light bulb I guess. ;-) Dale :-) :-)
Re: [gentoo-user] Re: New xorg.conf with x11-base/xorg-server-1.5.3-r5
bn wrote: Dale ha scritto: I hope someone wins the debate soon and gets this to work and be user friendly. I'm about to make a fresh backup and try this again. I have upgraded my kernel to a really new version, 2.6.25. Sorry, nvidia won't compile with anything newer that I have tried. Uh? last nvidia-drivers needs 2.6.25 kernel? m. Well, I have a old card so I have to use a old driver but I can't get any of the 2.6.29 kernels to get along with nvidia at all. It barely does even try to compile. It's not just me this time either. Google reports that others are having the same issue. I did get my 2.6.25 kernel to work and nvidia to compile. Now to try out this xorg upgrade. Got to update my backups first tho. Not in no real big hurry either. I suspect it won't be any better than the last time. :/ Dale :-) :-)
Re: [gentoo-user] Re: New xorg.conf with x11-base/xorg-server-1.5.3-r5
Mark Knecht wrote: On Sun, May 17, 2009 at 11:00 AM, Alan McKinnon alan.mckin...@gmail.com wrote: On Sunday 17 May 2009 19:10:05 bn wrote: Dale ha scritto: I hope someone wins the debate soon and gets this to work and be user friendly. I'm about to make a fresh backup and try this again. I have upgraded my kernel to a really new version, 2.6.25. Sorry, nvidia won't compile with anything newer that I have tried. Uh? last nvidia-drivers needs 2.6.25 kernel? Dale has an old video card and needs one of the nvidia legacy driver releases. He finds that that release doesn't work with kernels after .25 Hummnow I'm getting interested. I just did an emerge -DuN world to my dad's machine in Southern California last night. He's got a 6 year old machine with an old nvidia card that's no longer supported by the newest drivers so the emerge messages tell me that I have to use an older legacy version of the driver. Thing is I have him on gentoo-sources-2.6.29-r4 using nvidia-drivers-96.43.09. Everything seems to be working from here. I see the driver in memory. I Can run X apps remotely. gandalf ~ # uname -a Linux gandalf 2.6.29-gentoo-r4 #3 PREEMPT Sun May 17 06:58:58 PDT 2009 i686 AMD Athlon(tm) XP 2500+ AuthenticAMD GNU/Linux gandalf ~ # gandalf ~ # emerge -pv nvidia-drivers These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] x11-drivers/nvidia-drivers-96.43.09 USE=acpi gtk -custom-cflags (-multilib) 0 kB Total: 1 package (1 reinstall), Size of downloads: 0 kB gandalf ~ # I guess my question is whether he's going to have issues. He's really bad about reporting this stuff to me and I'm not there to see the screen or use the system. I don't see much in /var/log/Xorg.0.log other than a complaint about GLX and freetype. freetype I can fix. GLX I haven't looked into. Any problems? Thanks, Mark Hey, we got a pretty similar rig here. I have a FX5200, made by Chaintech I think. Info alert: r...@smoker / # uname -a Linux smoker 2.6.25-gentoo-r9 #3 PREEMPT Sat May 16 12:06:51 CDT 2009 i686 AMD Athlon(tm) XP 2500+ AuthenticAMD GNU/Linux r...@smoker / # emerge -pv nvidia-drivers These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] x11-drivers/nvidia-drivers-173.14.09 USE=acpi gtk -custom-cflags (-multilib) 0 kB Total: 1 package (1 reinstall), Size of downloads: 0 kB r...@smoker / # lspci | grep VGA 02:00.0 VGA compatible controller: nVidia Corporation NV34 [GeForce FX 5200] (rev a1) r...@smoker / # My drivers appears to be a little newer but you may have a older card than me. If so, my sympathies. ;-) There is a newer version of the 173.* series but it wouldn't compile either. I think this is the only version that works. That goodness it does a good job. Dale :-) :-)
Re: [gentoo-user] Re: New xorg.conf with x11-base/xorg-server-1.5.3-r5
On Sun, May 17, 2009 at 12:12 PM, Dale rdalek1...@gmail.com wrote: Mark Knecht wrote: On Sun, May 17, 2009 at 11:00 AM, Alan McKinnon alan.mckin...@gmail.com wrote: On Sunday 17 May 2009 19:10:05 bn wrote: Dale ha scritto: I hope someone wins the debate soon and gets this to work and be user friendly. I'm about to make a fresh backup and try this again. I have upgraded my kernel to a really new version, 2.6.25. Sorry, nvidia won't compile with anything newer that I have tried. Uh? last nvidia-drivers needs 2.6.25 kernel? Dale has an old video card and needs one of the nvidia legacy driver releases. He finds that that release doesn't work with kernels after .25 Hummnow I'm getting interested. I just did an emerge -DuN world to my dad's machine in Southern California last night. He's got a 6 year old machine with an old nvidia card that's no longer supported by the newest drivers so the emerge messages tell me that I have to use an older legacy version of the driver. Thing is I have him on gentoo-sources-2.6.29-r4 using nvidia-drivers-96.43.09. Everything seems to be working from here. I see the driver in memory. I Can run X apps remotely. gandalf ~ # uname -a Linux gandalf 2.6.29-gentoo-r4 #3 PREEMPT Sun May 17 06:58:58 PDT 2009 i686 AMD Athlon(tm) XP 2500+ AuthenticAMD GNU/Linux gandalf ~ # gandalf ~ # emerge -pv nvidia-drivers These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] x11-drivers/nvidia-drivers-96.43.09 USE=acpi gtk -custom-cflags (-multilib) 0 kB Total: 1 package (1 reinstall), Size of downloads: 0 kB gandalf ~ # I guess my question is whether he's going to have issues. He's really bad about reporting this stuff to me and I'm not there to see the screen or use the system. I don't see much in /var/log/Xorg.0.log other than a complaint about GLX and freetype. freetype I can fix. GLX I haven't looked into. Any problems? Thanks, Mark Hey, we got a pretty similar rig here. I have a FX5200, made by Chaintech I think. Info alert: r...@smoker / # uname -a Linux smoker 2.6.25-gentoo-r9 #3 PREEMPT Sat May 16 12:06:51 CDT 2009 i686 AMD Athlon(tm) XP 2500+ AuthenticAMD GNU/Linux r...@smoker / # emerge -pv nvidia-drivers These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] x11-drivers/nvidia-drivers-173.14.09 USE=acpi gtk -custom-cflags (-multilib) 0 kB Total: 1 package (1 reinstall), Size of downloads: 0 kB r...@smoker / # lspci | grep VGA 02:00.0 VGA compatible controller: nVidia Corporation NV34 [GeForce FX 5200] (rev a1) r...@smoker / # My drivers appears to be a little newer but you may have a older card than me. If so, my sympathies. ;-) There is a newer version of the 173.* series but it wouldn't compile either. I think this is the only version that works. That goodness it does a good job. Dale Dale, As far as I can tell I'm not having any problems. This machine was using a 2.6.28 kernel up until yesterday when I updated to 2.6.29-r4. The point I'm trying to make is that this old driver and all the kernels I have used up to now have all worked. I noticed that the machine does have the older C compile 4.1.2 on it and that's what most of the machine has been built with. I'm just starting to switch over to 4.3.2 which is why it's selected. This kernel and the version of nvidia-drivers I listed earlier compile on both for me. The one I used for this kernel/driver combo was 4.3.2/ gandalf ~ # gcc-config -l [1] i686-pc-linux-gnu-4.1.2 [2] i686-pc-linux-gnu-4.3.2 * gandalf ~ # The VGA is older I think. 440 series. I suspect it's the one I put in 5-6 years ago. I don't remember whether we ever updated it: gandalf ~ # lspci | grep VGA 03:00.0 VGA compatible controller: nVidia Corporation NV18 [GeForce4 MX 440 AGP 8x] (rev a2) gandalf ~ # In my case attempting to install anything newer results in a big emerge message telling me not to and suggesting this specific nvdia driver. gandalf ~ # lsmod Module Size Used by usblp 10140 0 uhci_hcd 18980 0 sbp2 19184 1 usbhid 21468 2 nvidia 4699324 0 i2c_nforce2 5828 0 ohci_hcd 20080 0 snd_intel8x0 25784 0 nvidia_agp 5704 1 snd_ac97_codec 90232 1 snd_intel8x0 ac97_bus1316 1 snd_ac97_codec agpgart25748 2 nvidia,nvidia_agp i2c_core 17564 2 nvidia,i2c_nforce2 ohci1394 25664 1 ehci_hcd 29380 0 ieee1394 66064 2 sbp2,ohci1394 gandalf ~ # gandalf ~ # modinfo nvidia filename: /lib/modules/2.6.29-gentoo-r4/video/nvidia.ko license:NVIDIA alias: char-major-195-* alias: pci:v10DEd*sv*sd*bc03sc02i00* alias: pci:v10DEd*sv*sd*bc03sc00i00* depends:
Re: [gentoo-user] Re: New xorg.conf with x11-base/xorg-server-1.5.3-r5
Mark Knecht wrote: Dale, As far as I can tell I'm not having any problems. This machine was using a 2.6.28 kernel up until yesterday when I updated to 2.6.29-r4. The point I'm trying to make is that this old driver and all the kernels I have used up to now have all worked. I noticed that the machine does have the older C compile 4.1.2 on it and that's what most of the machine has been built with. I'm just starting to switch over to 4.3.2 which is why it's selected. This kernel and the version of nvidia-drivers I listed earlier compile on both for me. The one I used for this kernel/driver combo was 4.3.2/ gandalf ~ # gcc-config -l [1] i686-pc-linux-gnu-4.1.2 [2] i686-pc-linux-gnu-4.3.2 * gandalf ~ # The VGA is older I think. 440 series. I suspect it's the one I put in 5-6 years ago. I don't remember whether we ever updated it: gandalf ~ # lspci | grep VGA 03:00.0 VGA compatible controller: nVidia Corporation NV18 [GeForce4 MX 440 AGP 8x] (rev a2) gandalf ~ # In my case attempting to install anything newer results in a big emerge message telling me not to and suggesting this specific nvdia driver. gandalf ~ # lsmod Module Size Used by usblp 10140 0 uhci_hcd 18980 0 sbp2 19184 1 usbhid 21468 2 nvidia 4699324 0 i2c_nforce2 5828 0 ohci_hcd 20080 0 snd_intel8x0 25784 0 nvidia_agp 5704 1 snd_ac97_codec 90232 1 snd_intel8x0 ac97_bus1316 1 snd_ac97_codec agpgart25748 2 nvidia,nvidia_agp i2c_core 17564 2 nvidia,i2c_nforce2 ohci1394 25664 1 ehci_hcd 29380 0 ieee1394 66064 2 sbp2,ohci1394 gandalf ~ # gandalf ~ # modinfo nvidia filename: /lib/modules/2.6.29-gentoo-r4/video/nvidia.ko license:NVIDIA alias: char-major-195-* alias: pci:v10DEd*sv*sd*bc03sc02i00* alias: pci:v10DEd*sv*sd*bc03sc00i00* depends:agpgart,i2c-core vermagic: 2.6.29-gentoo-r4 preempt mod_unload K7 parm: NVreg_VideoMemoryTypeOverride:int parm: NVreg_EnableVia4x:int parm: NVreg_EnableALiAGP:int parm: NVreg_ReqAGPRate:int parm: NVreg_NvAGP:int parm: NVreg_EnableAGPSBA:int parm: NVreg_EnableAGPFW:int parm: NVreg_SoftEDIDs:int parm: NVreg_Mobile:int parm: NVreg_ModifyDeviceFiles:int parm: NVreg_DeviceFileUID:int parm: NVreg_DeviceFileGID:int parm: NVreg_DeviceFileMode:int parm: NVreg_ResmanDebugLevel:int parm: NVreg_FlatPanelMode:int parm: NVreg_DevicesConnected:int parm: NVreg_RmLogonRC:int parm: NVreg_RemapLimit:int parm: NVreg_UpdateMemoryTypes:int parm: NVreg_DetectPrimaryVga:int parm: NVreg_RegistryDwords:charp parm: NVreg_VbiosFromROM:int parm: NVreg_EnableBrightnessControl:int parm: NVreg_PanelPWMFrequency:int parm: NVreg_PanelBrightnessLimits:int parm: NVreg_RMEdgeIntrCheck:int parm: NVreg_UsePageAttributeTable:int parm: NVreg_MapRegistersEarly:int gandalf ~ # - Mark I suspect that this is a difference between our drivers. Yours will build with the newer kernels where mine doesn't for some reason. I did google the error and it is reported by a lot of others as well. I can't recall the exact error at the moment but it couldn't find something to do with the kernel. What I read was that something moved that nvidia looks for during the install. Now that I have upgraded a bit, I may give some other versions a try again. I'm going to try the ones I already have downloaded tho. It takes hours to download anything on dial-up. Dale :-) :-)
Re: [gentoo-user] Re: New xorg.conf with x11-base/xorg-server-1.5.3-r5
On Sonntag 17 Mai 2009, Alan McKinnon wrote: On Sunday 17 May 2009 03:33:22 pk wrote: Alan McKinnon wrote: As I see it, at the bottom of the stack you have a kernel and at the top a user space app (the X server will do for an example). Plug in a USB device that the app can use, and the kernel needs to make a node in /dev for it if it's not already there. The kernel should not be interrogating the device for all possible info - that is expensive - and doesn't need to. It only needs enough info to know what driver, major and minor numbers to use. X OTOH, can I couldn't agree more. And this is what Udev, as a user space app, does. The only thing it doesn't handle is communicating with other user space apps; this is currently Hals job. the current model uses udev as the interface to the kernel's nodes and HAL as the interface to exactly what hardware you have. Seems pretty sane for the most usual use case. At some point in the stack you will need the OS-dependant part, my guess is the best place is between hal and udev. Only Linux uses Well, as I understand it this is what it looks like today: kernel - udev (or equivalent for non-linux kernel/OS) - hal - dbus - user apps To me that seems a bit redundant... No, there's nothing redundant in that. udev talks kernel-speak, hal talks userspace-speak. Hal could be distro-agnostic, udev can't be (not in a sane environment) and dbus is simply a transport layer for messages. That's five different functions going on, and none of them logically belong with any other in the same layer. What I would like to see: kernel - udev - user apps Then X must talk to udev directly. Two problems: - only Linux has udev. Other OSes may not need, want or be willing to touch udev with a bargepole. - X is multi-platform. Good luck getting Keith to agree to make it essentially Linux only :-) which is not a problem at all. udev only creates device nodes. There is no need to 'talk udev' or do special crap for udev. Yes, but if the developers could agree on a common API for the udev daemon and it's equivalents on other platforms (what does BSD use?)... and there already is one. It is called '/dev'
[gentoo-user] portage bug?
Hi, Would anybody, please, confirm the following behavior before I file a report with B.G.O? % emerge -C dev-perl/yaml % emerge --depclean -p [-snip-] Calculating dependencies... done! * Dependencies could not be completely resolved due to * the following required packages not being installed: * * dev-perl/yaml pulled in by: * perl-core/Module-Build-0.28.08 * * Have you forgotten to run `emerge --update --newuse --deep world` prior * to depclean? It may be necessary to manually uninstall packages that no longer * exist in the portage tree since it may not be possible to satisfy their * dependencies. Also, be aware of the --with-bdeps option that is documented * in `man emerge`. % emerge --update --newuse --deep world Calculating dependencies... done! Auto-cleaning packages... No outdated packages were found on your system. -- Best regards, Daniel
Re: [gentoo-user] portage bug?
Daniel Iliev schrieb am 18.05.2009 00:16: Hi, Would anybody, please, confirm the following behavior before I file a report with B.G.O? % emerge -C dev-perl/yaml % emerge --depclean -p [-snip-] Calculating dependencies... done! * Dependencies could not be completely resolved due to * the following required packages not being installed: * * dev-perl/yaml pulled in by: * perl-core/Module-Build-0.28.08 * * Have you forgotten to run `emerge --update --newuse --deep world` prior * to depclean? It may be necessary to manually uninstall packages that no longer * exist in the portage tree since it may not be possible to satisfy their * dependencies. Also, be aware of the --with-bdeps option that is documented * in `man emerge`. % emerge --update --newuse --deep world Calculating dependencies... done! Auto-cleaning packages... No outdated packages were found on your system. What is the problem with this behavior. You unmerge yaml but it is needed by Module-Build. What do you expect --depclean to do? If you run emerge --update --newuse --deep world yaml would be pulled in again as it is needed by Module-Build. --depclean only removes packages that have now reverse dependencies which is not the case here. -- Daniel Pielmeier signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] portage bug?
From what I see, update newuse deep world is NOT pulling it back in. That's the bug. On May 17, 2009 6:26 PM, Daniel Pielmeier daniel.pielme...@googlemail.com wrote: Daniel Iliev schrieb am 18.05.2009 00:16: Hi,Would anybody, please, confirm the following behavior before I file a report with B What is the problem with this behavior. You unmerge yaml but it is needed by Module-Build. What do you expect --depclean to do? If you run emerge --update --newuse --deep world yaml would be pulled in again as it is needed by Module-Build. --depclean only removes packages that have now reverse dependencies which is not the case here. -- Daniel Pielmeier
Re: [gentoo-user] portage bug?
On Mon, 18 May 2009 01:16:24 +0300 Daniel Iliev daniel.il...@gmail.com wrote: Hi, Would anybody, please, confirm the following behavior before I file a report with B.G.O? % emerge -C dev-perl/yaml [...] % emerge --update --newuse --deep world Calculating dependencies... done! Auto-cleaning packages... No outdated packages were found on your system. Try to add --with-bdeps=y and I think you'll find the expected behavior.
Re: [gentoo-user] portage bug?
Jason Weisberger schrieb am 18.05.2009 00:30: From what I see, update newuse deep world is NOT pulling it back in. That's the bug. Okay i should read more carefully. Tried the --with-bdeps option? -- Daniel Pielmeier signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] portage bug?
On Sun, 17 May 2009 18:30:47 -0400 Jason Weisberger jbdu...@gmail.com wrote: From what I see, update newuse deep world is NOT pulling it back in. That's the bug. Exactly. -- Best regards, Daniel
Re: [gentoo-user] portage bug?
Daniel Iliev wrote: Hi, Would anybody, please, confirm the following behavior before I file a report with B.G.O? % emerge -C dev-perl/yaml % emerge --depclean -p [-snip-] Calculating dependencies... done! * Dependencies could not be completely resolved due to * the following required packages not being installed: * * dev-perl/yaml pulled in by: * perl-core/Module-Build-0.28.08 * * Have you forgotten to run `emerge --update --newuse --deep world` prior * to depclean? It may be necessary to manually uninstall packages that no longer * exist in the portage tree since it may not be possible to satisfy their * dependencies. Also, be aware of the --with-bdeps option that is documented * in `man emerge`. % emerge --update --newuse --deep world Calculating dependencies... done! Auto-cleaning packages... No outdated packages were found on your system. It's not a bug, it's counterintuitive expected behavior. The pointer to the answer is buried in the error message: Also, be aware of the --with-bdeps option that is documented in `man emerge` In summary, dev-perl/yaml is a build dependency of Module-Build, and therefore not strictly required. By default, to be safe, depclean expects it to be there. Since Module-Build is already installed, however, by default emerge won't pull it in, because it shouldn't be necessary. Hence, the behavior you observe. You can file a bug if you wish, but make sure to do a full search, as there are misunderstandings of depclean all over b.g.o. Nick
Re: [gentoo-user] [solved] portage bug?
On Mon, 18 May 2009 00:36:56 +0200 Peter Alfredsen loki_...@gentoo.org wrote: On Mon, 18 May 2009 01:16:24 +0300 Daniel Iliev daniel.il...@gmail.com wrote: Hi, Would anybody, please, confirm the following behavior before I file a report with B.G.O? % emerge -C dev-perl/yaml [...] % emerge --update --newuse --deep world Calculating dependencies... done! Auto-cleaning packages... No outdated packages were found on your system. Try to add --with-bdeps=y and I think you'll find the expected behavior. Yes, that's it. Strange, I was under the impression that bdeps was yes by default. Thanks, guys, and sorry for the noise. -- Best regards, Daniel
Re: [gentoo-user] [solved] portage bug?
Daniel Iliev wrote: On Mon, 18 May 2009 00:36:56 +0200 Peter Alfredsen loki_...@gentoo.org wrote: On Mon, 18 May 2009 01:16:24 +0300 Daniel Iliev daniel.il...@gmail.com wrote: Hi, Would anybody, please, confirm the following behavior before I file a report with B.G.O? % emerge -C dev-perl/yaml [...] % emerge --update --newuse --deep world Calculating dependencies... done! Auto-cleaning packages... No outdated packages were found on your system. Try to add --with-bdeps=y and I think you'll find the expected behavior. Yes, that's it. Strange, I was under the impression that bdeps was yes by default. Thanks, guys, and sorry for the noise. It is if you add it to make.conf. I added the line to mine a long time ago. Something like this: # EMERGE_DEFAULT_OPTS allows emerge to act as if certain options are # specified on every run. Useful options include --ask, --verbose, # --usepkg and many others. Options that are not useful, such as --help, # are not filtered. EMERGE_DEFAULT_OPTS=--with-bdeps y Hope that saves you some typing. Dale :-) :-)
Re: [gentoo-user] [SOLVED] portage bug?
My mistake, not a bug. I'm glad I asked here before wasting devs' time with invalid reports. Thanks, guys! :) -- Best regards, Daniel
Re: [gentoo-user] [solved] portage bug?
On Mon, 18 May 2009 01:49:54 +0300, Daniel Iliev wrote: Yes, that's it. Strange, I was under the impression that bdeps was yes by default. Only when using --depclean. -- Neil Bothwick To boldly go where I surely don't belong. signature.asc Description: PGP signature
was [gentoo-user] Re: New xorg.conf with x11-base/xorg-server-1.5.3-r5 now old nvidia drivers
For you guys with older hardware/drivers, have you tried turning on CONFIG_UNUSED_SYMBOLS and recompiling the kernel to see if its helps? (Kernel hacking - Enable unused/obsolete exported symbols). I use it to support vmware server 1.x and ati flgrx drivers (with 2.6.26 or later kernels). IIRC my home machine is an IGP 440 MX running 2.6.28 (not sure of driver version off the top of my head, maybe masked to ?97?) but its working fine.
Re: was [gentoo-user] Re: New xorg.conf with x11-base/xorg-server-1.5.3-r5 now old nvidia drivers
Adam Carter wrote: For you guys with older hardware/drivers, have you tried turning on CONFIG_UNUSED_SYMBOLS and recompiling the kernel to see if its helps? (Kernel hacking - Enable unused/obsolete exported symbols). I use it to support vmware server 1.x and ati flgrx drivers (with 2.6.26 or later kernels). IIRC my home machine is an IGP 440 MX running 2.6.28 (not sure of driver version off the top of my head, maybe masked to ?97?) but its working fine. That is a good find. I can't say that it is the problem but it was not enabled on my kernel but it is now. I'll try to test this later on as well. This sounds like what the error was reporting it couldn't find. This could work. Thanks. Dale :-) :-)
RE: was [gentoo-user] Re: New xorg.conf with x11-base/xorg-server-1.5.3-r5 now old nvidia drivers
For you guys with older hardware/drivers, have you tried turning on CONFIG_UNUSED_SYMBOLS and recompiling the kernel to see if its helps? (Kernel hacking - Enable unused/obsolete exported symbols). snip That is a good find. I can't say that it is the problem but it was not enabled on my kernel but it is now. I'll try to test this later on as well. This sounds like what the error was reporting it couldn't find. This could work. If it does work it would be worth a bug report to get the nvidia ebuild(s) updated similar to the ati ones; # grep -i symbol ati-drivers-8.593.ebuild if kernel_is ge 2 6 26 ! linux_chkconfig_present UNUSED_SYMBOLS; then ewarn You have to Enable unused/obsolete exported symbols in Kernel hacking section of kernel config for fglrx to load
