From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.62) (envelope-from ) id 1HChge-0004im-MS for garchives@archives.gentoo.org; Thu, 01 Feb 2007 19:33:37 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.8/8.13.8) with SMTP id l11JVlF5028394; Thu, 1 Feb 2007 19:31:47 GMT Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by robin.gentoo.org (8.13.8/8.13.8) with ESMTP id l11JVlOo028389 for ; Thu, 1 Feb 2007 19:31:47 GMT Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HCheo-0000W3-Uf for gentoo-amd64@lists.gentoo.org; Thu, 01 Feb 2007 20:31:42 +0100 Received: from ip68-231-13-122.ph.ph.cox.net ([68.231.13.122]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 01 Feb 2007 20:31:42 +0100 Received: from 1i5t5.duncan by ip68-231-13-122.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 01 Feb 2007 20:31:42 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-amd64@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-amd64] Re: revdep broken x11-drivers/ati-drivers net-nds/openldap Date: Thu, 1 Feb 2007 19:31:30 +0000 (UTC) Message-ID: References: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-amd64@gentoo.org Reply-to: gentoo-amd64@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-13-122.ph.ph.cox.net User-Agent: pan 0.121 (Dortmunder) Sender: news X-Archives-Salt: 04b972d6-6b49-416b-8689-12dc80511869 X-Archives-Hash: ea41a9182f580fbac10f3acdcec614f2 "Daiajo Tibdixious" posted a4a9bfcb0702010239k27520bf1ve6a54a3e235f580d@mail.gmail.com, excerpted below, on Thu, 01 Feb 2007 21:39:08 +1100: >> If you aren't using the 3D stuff on your video card anyway, you may wish >> to see if the native xorg driver will run it. > > What do I have to do to run it? The first step is to see for sure what the status is with your video card. You mentioned ATI, but didn't mention what, tho I did get the impression it wasn't one of the latest generation cards, which AFAIK isn't supported at all yet, by the native xorg drivers. FWIW, here's an abridged list from the radeon manpage (from the native driver, which I run, version 6.6.3 here, on a 9200se/rv280, if your card is a radeon below radeon 9250, it'll work too, in 3D even, but I cut that out): RS400 Radeon XPRESS 200/200M IGP R300 Radeon 9700PRO/9700/9500PRO/9500/9600TX, FireGL X1/Z1 (2D only) R350 Radeon 9800PRO/9800SE/9800, FireGL X2 (2D only) R360 Radeon 9800XT (2d only) RV350 Radeon 9600PRO/9600SE/9600, M10/M11, FireGL T2 (2D only) RV360 Radeon 9600XT (2d only) RV370 Radeon X300, M22 (2d only) RV380 Radeon X600, M24 (2d only) RV410 Radeon X700, M26 PCIE (2d only) R420 Radeon X800 AGP (2d only) R423/R430 Radeon X800, M28 PCIE (2d only) R480/R481 Radeon X850 PCIE/AGP (2d only) There is experimental 3D support for some of that, I think thru the rv3xx series, so anything below the x700, m26 pcie, but I'm not positive of where the cutoff is or the exact status, and it's still fairly new so if you /do/ want 3D support on it, you'd want to run ~arch xorg, xf86-video-ati (that's the video package you'd want for native ATI incl. Radeon), and related packages (the rest of the drivers, extensions, protocols, etc, that make up modular-x). To get the driver, simply set VIDEO_CARDS="radeon" in your make.conf, and remerge xorg-server and mesa. They should pull in the new driver. If you want 3D (and the driver has support for it), you'll also need to ensure the proper kernel drivers are enabled and rebuild it. Under Device Drivers > Character devices, ensure /dev/agpgart is enabled (certain other things hard-enable it in which case it's displayed with --- instead of the usual option), that DRM is built-in or modularized (built-in here), and that the ATI Radeon DRM support is likewise built-in or modularized (modularized here). Of course if you change the built-ins, you'll need to reboot and run the new kernel to get them. Otherwise, you can probably simply modprobe them. Note that you can also get DRI/DRM separately, and might want to for newer cards, but I've always used the kernel built-in, so I can't get into many specifics on that except that I know it's possible and often recommended for cards where the 3D support isn't fully stable yet. Then, you'll want to change your driver in xorg.conf, from frglx or whatever the proprietary one is, to radeon (Driver "radeon" in Section "Device"). Depending on what driver specific settings you have if any, and how complicated your video setup is, that might be all you have to do, or you may have to do some additional configuration. Here, I run two monitors attached to the same card, in merged framebuffer mode, thus avoiding having to run the xinerama extension, and I have a rather complex setup with some driver specific settings . However, for a single monitor and no special settings, you may not have anything else to worry about. Try it and see, I'd say, then see what the log says if you don't like it and either man radeon and go from there or ask for further help. I'm not sure if ATI has its own eselect opengl setting or not, but if it does and you were using it, you'll want to switch back to xorg-x11 there, too. AFAIK, you should even be able to keep both setups merged on your system, and switch between them as desired. In any event, I'd suggest simply commenting out any frglx settings in xorg.conf instead of deleting them, at least at first, making it easy to go back if you decide you want to. >> All that said, there's one negative as well. When the packages are >> split, that means most of what was the single ./configure step in the >> monolithic package now gets run many times, once for each of the split >> packages. > > Wouldn't a configure cache work in this case? I haven't actually tried one > myself > (due to all the warnings), however within a KDE merge it should always be > the same. Um... yes. However, while I use it, it's not really supported by Gentoo if you run into trouble with it, which does happen occasionally, so I didn't mention it. Basically, certain apps apparently poison its cache, making trouble not for themselves, but for whatever tries to use the portion of the cache that was poisoned, later. The problem is therefore extremely hard to find since the package that fails might be the next one merged or might be 10 or 100 packages down the line -- and of course the bug ends up getting reported against the wrong package, the one that failed due to the invalid cached config, not the one that made the config invalid in the first place. You can see why certain developers, that happen to be the maintainers of the packages most frequently targeted by confcache issues not from that package, but from something else an unknown number of packages earlier, would begin to /hate/ the very idea of confcache, after they get say 20 bugs on it, when it's not their package at fault! So anyway, what I do is any time I get a failure, the first thing I try is blowing away the cached config, so confcache has to start from scratch. If it's a confcache issue, that /usually/ solves it, altho I've seen a couple packages that won't merge with confcache on at all, so I had to FEATURES=-confcache emerge to get them to emerge. Fortunately, I've not had any devs complaining about it in my FEATURES when I bug something with FEATURES=confcache in my emerge --info output, but since that's the first thing I try killing when an emerge doesn't work, I'd not be filing the bug if it was confcache related FWIW there is apparently at least one KDE specific package that poisons the confcache for expat, which is used by something later in the kde upgrade process. I know this as I've triggered the thing several times on a kde upgrade -- and I have /tmp and thus /tmp/confcache on a tmpfs, so it's always clear after a reboot, and sometimes the kde upgrade has been the first set of emerges I've done! Still, I tend to watch my merges fairly closely (a dual Opteron and enough memory to have PORTAGE_TMPDIR on tmpfs means I can do merges in the background without too much trouble, as long as I've set PORTAGE_NICENESS), and find it's still worth the trouble of having to merge an individual package here and there after blowing away the confcache, before resuming the regular merge sequence. Those who have a slower system and find it preferable to set portage to do its merges while they are away or asleep, however, would likely find it pretty frustrating, since it would have triggered an emerge abort, less than half-way thru that long kde upgrade. >> In my case, there are whole swatches of several of the monolithics that >> I don't use at all and would prefer not to have on the system (can't >> cause > > Do you mind sharing the list of kde packates that you DO use? $grep kde-base /var/lib/portage/world kde-base/ksig kde-base/kdeartwork-kworldclock kde-base/kcalc kde-base/kaddressbook-plugins kde-base/kstart kde-base/kgpg kde-base/kmix kde-base/kview kde-base/kicker-applets kde-base/secpolicy kde-base/kdcop kde-base/kdict kde-base/kooka kde-base/kpager kde-base/kdf kde-base/ksystraycmd kde-base/kscreensaver kde-base/kate-plugins kde-base/kpat kde-base/kdepasswd kde-base/kppp kde-base/kfloppy kde-base/artsplugin-audiofile kde-base/knetattach kde-base/khexedit kde-base/kdeadmin-kfile-plugins kde-base/ksnapshot kde-base/kmenuedit kde-base/ksysguard kde-base/kdeaddons-kfile-plugins kde-base/kuser kde-base/kolourpaint kde-base/knewsticker-scripts kde-base/kaudiocreator kde-base/renamedlg-images kde-base/kmid kde-base/kcron kde-base/klipper kde-base/kdemultimedia-kfile-plugins kde-base/kcoloredit kde-base/kwalletmanager kde-base/kdeartwork-emoticons kde-base/kdeartwork-sounds kde-base/kdeartwork-wallpapers kde-base/kteatime kde-base/kcharselect kde-base/kdegraphics-kfile-plugins kde-base/kdebase-startkde kde-base/ksvg kde-base/konsole kde-base/kiconedit kde-base/kget kde-base/renamedlg-audio kde-base/kdeartwork-iconthemes kde-base/kdenetwork-kfile-plugins kde-base/kmail kde-base/kdeartwork-kwin-styles kde-base/kdvi kde-base/kdemultimedia-kappfinder-data kde-base/ark kde-base/kruler kde-base/kode kde-base/kdeartwork-styles kde-base/kpdf kde-base/artsplugin-xine kde-base/kregexpeditor kde-base/konq-plugins kde-base/kdemultimedia-arts kde-base/kgamma kde-base/kweather kde-base/konqueror-akregator There are of course others, dependencies of the packages listed in world. >> If you don't have -ldap, the profile is probably setting +ldap for you. >> Yes, I just checked, it's turned on by default in >> $PORTDIR/profiles/default-linux/amd64/2006.1/desktop in any case, so >> probably is in other similar profiles as well. > > I'm using that profile. I'll try to remember to check the profile as well > as make.conf, > I'd didn't realise I would have to minus some USE flags, rather than just > omit them. I always use the output from emerge --info when I'm checking USE flag status, since that way portage folds in all the ones turned on by the cascading profiles. With the cascading profiles, you'd otherwise have to check several files, not only the profile itself, but its parents, in this case not only desktop, but 2006.1, and amd64, and default-linux, and profiles/base, as well. By using emerge --info, you get what portage would use in general, regardless of what file it's in (with the exception of the package specific package.use), and if you don't like it, you can set your make.conf accordingly, without having to worry about where in the cascading profiles the setting is otherwise coming from. Additionally, I ALWAYS use either emerge --ask --verbose (which I've aliased to ea) or emerge --pretend --verbose (ep) previous to emerging or updating anything, and check either changed USE flags (for updates) or all USE flags (for new packages) before I merge the package, verifying whether it is indeed going to use the USE flags I'd prefer. That is in fact one of the big reasons I like Gentoo -- I like having that control and make use if it. Thus, knowing I have no use for LDAP, I'd have turned that off either when I initially went thru USE flags when I setup the system, or soon thereafter, when I found something trying to merge with USE=ldap. > I added -ldap to my make.conf and did a full rebuild --newuse, which took > most of the day. Now, despite eix showing -ldap on kde-base/dedbase, > 'equery depends' still shows the same list (less the older version of > gnupg) as above. depclean did remove 2 more packages, but not openldap. Hmm... that's weird. I'd probably be investigating further, but it's not something I could really explain how to do remotely. It's one of those things I'd try one thing, then try something else depending on the results I got, until I either got tired of it and gave up or resolved the issue to my satisfaction. > openssh (e.g.) also shows -ldap in eix, but still a dependent of openldap > in equery depends. Remember when I said I like the control Gentoo gives me? Well, I'm not sure why openssh is in the system dependencies, but having no remote computer, I have no intention of logging on remotely to other computers nor of letting anyone logon remotely to this one. In fact, just the /idea/ of the software existing on my computer disturbs me, given there's no legitimate reason I know of for it to be there, so it's not, despite the system dependency! It's in my /etc/portage/profile/package.provided file at a high enough version I shouldn't have to worry about it for awhile! That makes portage act as if it's merged when it's not, and as long as nothing else actually has to depend on it, I should be fine. I've been fine so far! Naturally, however, I'm not going to recommend this to anyone else, as I imagine there's gotta be SOME sane reason it's in system. I figure if whatever it is ever gets me and crashes the system, I'm a decent enough troubleshooter I should hope I figure it out. Meanwhile, I personally rest WAY better knowing its not on my system at all, so couldn't POSSIBLY be used to remotely login or somehow otherwise compromise my system. If it's not there to compromise, it can't be compromised, and I want it not there, so with Gentoo, I make sure it IS "not there"! So anyway, no openssl here, so regardless of the ldap USE flag setting, LDAP won't be a problem for openssl for me here! =8^) > It looks to me like 'equery depends' is broken. > > app-crypt/gnupg is an example of something that still has the ldap USE > flag enabled, > I've noticed some packages just blatantly ignore make.conf, and always > have certain USE enabled, which I don't understand. Does it have the USE flag enabled when you try an emerge --pretend? Maybe it's listed in /etc/portage/package.use? (Tho why it would be there if you didn't put it there is an even weirder question, but that's one explanation for individual packages diverging from the general make.conf setting.) If it doesn't have the USE flag enabled, but it's still depending on it, it can be due to a bug in the ebuild. On most (non-Gentoo) systems, configure scripts normally automatically detect optional packages and link against them if they find them. Usually, there's a configure option to specifically turn on or off the linking, and the ebuild can set that in addition to telling portage whether the package should be installed first as a dependency or not. However, sometimes an ebuild won't set the configure option to specifically turn it on or off, or sometimes the option won't work as intended or isn't there. In those cases, it's an ebuild bug, and should probably be filed as such, so the ebuild maintainer can figure out the problem and either enable the configure option or create a suitable patch and apply it as well as filing a bug upstream to try and get the bug fixed there as well. (Of course, do a bug search to see if anyone else has filed the bug before you file it yourself. Handling dups takes time that could otherwise be spent fixing bugs.) I'd guess gnupg may be one of these bugged packages. Since the file was installed, the configure script found and built against it, even tho the USE flag was off, so it would have no longer pulled in the dependency if the file wasn't there already, to be detected. If you can indeed confirm that case, I would suggest checking for a bug filed on it and filing one if you can't find one. > After learning more about "provide_old_libs" from the bug, and > /var/log/portage/elog, I just deleted all of broken .so files, as they > were supposed to have been. revdep-rebuild is now clean. Sometimes that's the easiest, particularly if you have binary-packages ready to replace things if you decide you made a mistake and it's needed after all. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- gentoo-amd64@gentoo.org mailing list