[gentoo-amd64] Re: revdep broken x11-drivers/ati-drivers net-nds/openldap

[Duncan <1i5t5.duncan@cox.net>]

"Daiajo Tibdixious" <daiajo@gmail.com> 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 <pkg> 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