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

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

[Daiajo Tibdixious]

revdep-rebuild keeps throwing up these 2 as rebuild targets, yet
rebuilding them has no effect whatsoever. This is my final 'problem'
after emerge --depclean. Its a theoretical problem because I rebooted,
restarted X/KDE, and no problems whatsoever, so I can probably just
ignore this situation, but it offends my sensibilities. I've expanded
the revdep-rebuild output with qfile information.

x11-drivers/ati-drivers
    usr/lib32/xorg/modules/dri/atiogl_a_dri.so
    /usr/lib32/xorg/modules/dri/fglrx_dri.so
        media-libs/mesa (/usr/lib64/opengl/xorg-x11/lib/libGL.so.1)
        x11-drivers/ati-drivers (/usr/lib32/opengl/ati/lib/libGL.so.1)
        x11-drivers/ati-drivers (/usr/lib64/opengl/ati/lib/libGL.so.1)
        x11-libs/libX11 (/usr/lib64/libX11.so.6)
        x11-libs/libXext (/usr/lib64/libXext.so.6)
        sys-libs/libstdc++-v3 (/usr/lib64/libstdc++-v3/libstdc++.so.5)
net-nds/openldap-2.3
    /usr/lib64/libldap-2.2.so.7 net-nds/openldap-2.2-28-r7? liblber-2.2.so.7)
    /usr/lib64/libldap.so.2.0.130 net-nds/openldap-2.2-28-r7? liblber.so.2)
    /usr/lib64/libldap_r-2.2.so.7 net-nds/openldap-2.2-28-r7? liblber-2.2.so.7)
    /usr/lib64/libldap_r.so.2.0.130 net-nds/openldap-2.2-28-r7? liblber.so.2)

Firstly ati-drivers shows 2 broken .so's. I can't tell if libGL.so.1
is the mesa one or the ati-drivers one, both are present. libX11,
libXext, libstdc++-v3 are all present, so I don't know why
revdep-rebuild is showing a breakage.

If ati-drivers was broken, why is my graphics working?

Secondly openldap is referencing liblber 2.2 which is NOT present.
'equery f openldap' shows it is actually part of openldap, which I
have rebuilt about 7 times to no avail.
Actually the liblber files in openldap are 2.3 versions, not 2.2.
libldap has both 2.2 and 2.3 versions, so I guess I'm running on 2.3,
and the 2.2 are just there to cause me a headache. The installed
version is 2.3.30-r2 so I don't know why it would contain 2.2 files.

openldap is required by KDE multimedia, I'm not sure if I am actually
exercising it.

Any hints?
-- 
gentoo-amd64@gentoo.org mailing list

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

[Harm Geerts]

On Tue, January 30, 2007 13:43, Daiajo Tibdixious wrote:
> revdep-rebuild keeps throwing up these 2 as rebuild targets, yet
> rebuilding them has no effect whatsoever. This is my final 'problem'
> after emerge --depclean. Its a theoretical problem because I rebooted,
> restarted X/KDE, and no problems whatsoever, so I can probably just
> ignore this situation, but it offends my sensibilities. I've expanded
> the revdep-rebuild output with qfile information.
>
> x11-drivers/ati-drivers
>     usr/lib32/xorg/modules/dri/atiogl_a_dri.so
>     /usr/lib32/xorg/modules/dri/fglrx_dri.so
>         media-libs/mesa (/usr/lib64/opengl/xorg-x11/lib/libGL.so.1)
>         x11-drivers/ati-drivers (/usr/lib32/opengl/ati/lib/libGL.so.1)
>         x11-drivers/ati-drivers (/usr/lib64/opengl/ati/lib/libGL.so.1)
>         x11-libs/libX11 (/usr/lib64/libX11.so.6)
>         x11-libs/libXext (/usr/lib64/libXext.so.6)
>         sys-libs/libstdc++-v3 (/usr/lib64/libstdc++-v3/libstdc++.so.5)
> net-nds/openldap-2.3
>     /usr/lib64/libldap-2.2.so.7 net-nds/openldap-2.2-28-r7?
> liblber-2.2.so.7)
>     /usr/lib64/libldap.so.2.0.130 net-nds/openldap-2.2-28-r7?
> liblber.so.2)
>     /usr/lib64/libldap_r-2.2.so.7 net-nds/openldap-2.2-28-r7?
> liblber-2.2.so.7)
>     /usr/lib64/libldap_r.so.2.0.130 net-nds/openldap-2.2-28-r7?
> liblber.so.2)
>
> Firstly ati-drivers shows 2 broken .so's. I can't tell if libGL.so.1
> is the mesa one or the ati-drivers one, both are present. libX11,
> libXext, libstdc++-v3 are all present, so I don't know why
> revdep-rebuild is showing a breakage.
>
> If ati-drivers was broken, why is my graphics working?
>
> Secondly openldap is referencing liblber 2.2 which is NOT present.
> 'equery f openldap' shows it is actually part of openldap, which I
> have rebuilt about 7 times to no avail.
> Actually the liblber files in openldap are 2.3 versions, not 2.2.
> libldap has both 2.2 and 2.3 versions, so I guess I'm running on 2.3,
> and the 2.2 are just there to cause me a headache. The installed
> version is 2.3.30-r2 so I don't know why it would contain 2.2 files.

The ebuild copies the old libraries from a 2.2 install to the image of a
2.3 install in order to avoid distaster on systems that use ldap for
authentication. The postinst tells you to rebuild everything that depends
on these libraries and remove them once that's done.

Over time you have rebuild everything against the newest version, but
never removed the old libraries, this has to be done manually!

-- 
gentoo-amd64@gentoo.org mailing list

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

[Harm Geerts]

On Tue, January 30, 2007 13:43, Daiajo Tibdixious wrote:
> revdep-rebuild keeps throwing up these 2 as rebuild targets, yet
> rebuilding them has no effect whatsoever. This is my final 'problem'
> after emerge --depclean. Its a theoretical problem because I rebooted,
> restarted X/KDE, and no problems whatsoever, so I can probably just
> ignore this situation, but it offends my sensibilities. I've expanded
> the revdep-rebuild output with qfile information.
>
> x11-drivers/ati-drivers
>     usr/lib32/xorg/modules/dri/atiogl_a_dri.so
>     /usr/lib32/xorg/modules/dri/fglrx_dri.so
>         media-libs/mesa (/usr/lib64/opengl/xorg-x11/lib/libGL.so.1)
>         x11-drivers/ati-drivers (/usr/lib32/opengl/ati/lib/libGL.so.1)
>         x11-drivers/ati-drivers (/usr/lib64/opengl/ati/lib/libGL.so.1)
>         x11-libs/libX11 (/usr/lib64/libX11.so.6)
>         x11-libs/libXext (/usr/lib64/libXext.so.6)
>         sys-libs/libstdc++-v3 (/usr/lib64/libstdc++-v3/libstdc++.so.5)
> net-nds/openldap-2.3
>     /usr/lib64/libldap-2.2.so.7 net-nds/openldap-2.2-28-r7?
> liblber-2.2.so.7)
>     /usr/lib64/libldap.so.2.0.130 net-nds/openldap-2.2-28-r7?
> liblber.so.2)
>     /usr/lib64/libldap_r-2.2.so.7 net-nds/openldap-2.2-28-r7?
> liblber-2.2.so.7)
>     /usr/lib64/libldap_r.so.2.0.130 net-nds/openldap-2.2-28-r7?
> liblber.so.2)
>
> Firstly ati-drivers shows 2 broken .so's. I can't tell if libGL.so.1
> is the mesa one or the ati-drivers one, both are present. libX11,
> libXext, libstdc++-v3 are all present, so I don't know why
> revdep-rebuild is showing a breakage.
>
> If ati-drivers was broken, why is my graphics working?
>
> Secondly openldap is referencing liblber 2.2 which is NOT present.
> 'equery f openldap' shows it is actually part of openldap, which I
> have rebuilt about 7 times to no avail.
> Actually the liblber files in openldap are 2.3 versions, not 2.2.
> libldap has both 2.2 and 2.3 versions, so I guess I'm running on 2.3,
> and the 2.2 are just there to cause me a headache. The installed
> version is 2.3.30-r2 so I don't know why it would contain 2.2 files.

The ebuild copies the old libraries from a 2.2 install to the image of a
2.3 install in order to avoid distaster on systems that use ldap for
authentication. The postinst tells you to rebuild everything that depends
on these libraries and remove them once that's done.

Over time you have rebuild everything against the newest version, but
never removed the old libraries, this has to be done manually!

> openldap is required by KDE multimedia, I'm not sure if I am actually
> exercising it.

If you're not sure then you probably aren't.
-- 
gentoo-amd64@gentoo.org mailing list

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

[Duncan]

"Daiajo Tibdixious" <daiajo@gmail.com> posted
a4a9bfcb0701300443jc3ada1m5d15277d8bc0b5f3@mail.gmail.com, excerpted
below, on  Tue, 30 Jan 2007 23:43:05 +1100:

> I've expanded
> the revdep-rebuild output with qfile information.
> 
> x11-drivers/ati-drivers
>     usr/lib32/xorg/modules/dri/atiogl_a_dri.so
>     /usr/lib32/xorg/modules/dri/fglrx_dri.so
>         media-libs/mesa (/usr/lib64/opengl/xorg-x11/lib/libGL.so.1)
>         x11-drivers/ati-drivers (/usr/lib32/opengl/ati/lib/libGL.so.1)
>         x11-drivers/ati-drivers (/usr/lib64/opengl/ati/lib/libGL.so.1)
>         x11-libs/libX11 (/usr/lib64/libX11.so.6)
>         x11-libs/libXext (/usr/lib64/libXext.so.6)
>         sys-libs/libstdc++-v3 (/usr/lib64/libstdc++-v3/libstdc++.so.5)
> net-nds/openldap-2.3
>     /usr/lib64/libldap-2.2.so.7 net-nds/openldap-2.2-28-r7? liblber-2.2.so.7)
>     /usr/lib64/libldap.so.2.0.130 net-nds/openldap-2.2-28-r7? liblber.so.2)
>     /usr/lib64/libldap_r-2.2.so.7 net-nds/openldap-2.2-28-r7? liblber-2.2.so.7)
>     /usr/lib64/libldap_r.so.2.0.130 net-nds/openldap-2.2-28-r7? liblber.so.2)
> 
> Firstly ati-drivers shows 2 broken .so's. I can't tell if libGL.so.1
> is the mesa one or the ati-drivers one, both are present. libX11,
> libXext, libstdc++-v3 are all present, so I don't know why
> revdep-rebuild is showing a breakage.
> 
> If ati-drivers was broken, why is my graphics working?

Why is it working?  Because the part that's broken is 32-bit (if it's the
stuff in lib32, anyway), and the main system is 64-bit, which isn't
broken.  As long as you aren't trying to run any 32-bit games that use
the broken bit or something, you're probably fine.  Also note that even if
it's the 64-bit stuff, it's likely the 3D/OpenGL stuff, which most stuff
won't be using.  It'd only be used for 3D games, OpenGL screensavers, and
anything else OpenGL based you may be running.

This case is probably an example of one of the issues with
revdep-rebuild, or more precisely with binary-only packages you may
choose to run. Revdep-rebuild sees and scans the shared libraries, and
doesn't know when they are part of a binary-only package. Naturally, you
can remerge the binary-only package all day and if it was built against a
library not on your system, it's not going to help one bit.

Newer revdep-rebuild versions have a way to configure it to ignore certain
packages. If you have the /etc/revdep-rebuild/ dir with 99revdep-rebuild
inside, take a look at the comments in that file, and if you wish, you can
either modify it or create your own file in the dir with an appropriate
entry masking the problem dirs or individual libraries as necessary.  If
you don't have that dir, you probably need a newer (and possibly still
~arch, I've not checked) revdep-rebuild.  Of course this gets
revdep-rebuild to ignore the problem, it doesn't fix it, but there's not
much more that you can do with binary-only packages, unfortunately, except
choose not to use them or buy hardware that requires them.  (Insert
standard gripe about slaveryware here, but it's your system, not mine, so
you get to choose what you run and I'd not deny you that right, regardless
of how much I gripe.)  

> Secondly openldap is referencing liblber 2.2 which is NOT present.
> 'equery f openldap' shows it is actually part of openldap, which I
> have rebuilt about 7 times to no avail.
> Actually the liblber files in openldap are 2.3 versions, not 2.2.
> libldap has both 2.2 and 2.3 versions, so I guess I'm running on 2.3,
> and the 2.2 are just there to cause me a headache. The installed
> version is 2.3.30-r2 so I don't know why it would contain 2.2 files.
> 
> openldap is required by KDE multimedia, I'm not sure if I am actually
> exercising it.

Did you try rebuilding kdemultimedia, and/or anything else that might
require openldap?  Something's apparently still built against the old
version.  Either that or you have an orphan file that's built against the
old version that's still on your system for some reason, and need to find
and consider removing it.

BTW, if revdep-rebuild isn't providing you enough info about exactly what
it's finding and why, try running it with the --vv flag.  That's supposed
to make it extra verbose, and may provide further hints about what
it's finding that's causing it to want to rebuild whatever.  Then you can
use that to figure out what that's from.  -i is also useful, telling it to
ignore previous runs from the same day if you used --pretend on them, so
it doesn't use stale info if you've emerged stuff to fix it (or updated
the revdep config) by hand in the mean time.

BTW2, I'm a KDE guy myself but have (some of) the split packages merged,
not monolithic (as I think I mentioned before).  However, at least with
kde 3.5.6 (~arch), a pretend-merge of kde-meta doesn't grep up anything
ldap in either USE flags or packages, so either that dependency is gone in
newer KDE, or it's coming from an indirect dependency due to a USE flag
you have on that I have off.  You don't happen to have the the ldap USE
flag on, do you?  It doesn't sound like you'd be using it.  It's off here.

-- 
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

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

[Daiajo Tibdixious]

On 1/31/07, Duncan <1i5t5.duncan@cox.net> wrote:
> "Daiajo Tibdixious" <daiajo@gmail.com> posted
> below, on  Tue, 30 Jan 2007 23:43:05 +1100:
> > x11-drivers/ati-drivers
> >     usr/lib32/xorg/modules/dri/atiogl_a_dri.so
> >     /usr/lib32/xorg/modules/dri/fglrx_dri.so
> >         media-libs/mesa (/usr/lib64/opengl/xorg-x11/lib/libGL.so.1)
> >         x11-drivers/ati-drivers (/usr/lib32/opengl/ati/lib/libGL.so.1)
> >         x11-drivers/ati-drivers (/usr/lib64/opengl/ati/lib/libGL.so.1)
> >         x11-libs/libX11 (/usr/lib64/libX11.so.6)
> >         x11-libs/libXext (/usr/lib64/libXext.so.6)
> >         sys-libs/libstdc++-v3 (/usr/lib64/libstdc++-v3/libstdc++.so.5)
> > net-nds/openldap-2.3
> >     /usr/lib64/libldap-2.2.so.7 net-nds/openldap-2.2-28-r7?
> liblber-2.2.so.7)
> >     /usr/lib64/libldap.so.2.0.130 net-nds/openldap-2.2-28-r7?
> liblber.so.2)
> >     /usr/lib64/libldap_r-2.2.so.7 net-nds/openldap-2.2-28-r7?
> liblber-2.2.so.7)
> >     /usr/lib64/libldap_r.so.2.0.130 net-nds/openldap-2.2-28-r7?
> liblber.so.2)
> > 
> > If ati-drivers was broken, why is my graphics working?
> 
>> Why is it working?  Because the part that's broken is 32-bit (if it's the
>> stuff in lib32, anyway), and the main system is 64-bit, which isn't
>> broken.

Doh. It was a long day.

> As long as you aren't trying to run any 32-bit games that use
> the broken bit or something, you're probably fine.  Also note that even if
> it's the 64-bit stuff, it's likely the 3D/OpenGL stuff, which most stuff
> won't be using.  It'd only be used for 3D games, OpenGL screensavers, and
> anything else OpenGL based you may be running.

Ah, no nothing that I know of.

>> This case is probably an example of one of the issues with
>> revdep-rebuild, or more precisely with binary-only packages you may
>> choose to run.

I know it freaks on firefox-bin. I resent that "choose" to run, as its only ignorance at work here, are you saying openldap is binary? AFAIK I don't have any binary packages any more.

> Revdep-rebuild sees and scans the shared libraries, and
> doesn't know when they are part of a binary-only package. Naturally, you
> can remerge the binary-only package all day and if it was built against a
> library not on your system, it's not going to help one bit.

Yeah, I figured that out with firefox-bin, how does it apply here?

>> Newer revdep-rebuild versions have a way to configure it to ignore certain
>> packages.

I'm used to ignoring revdep-rebuild. :) Especially I ignore the packages to be rebuilt, its great for detecting broken linkage but lousy (in my limited experience) at fixing them.

>> standard gripe about slaveryware here, but it's your system, not mine, so
>> you get to choose what you run and I'd not deny you that right, regardless
>> of how much I gripe.)  

I'd rather not have slaveryware either. My son has a Win XP Home which I use for that. :(

>> > openldap is required by KDE multimedia, I'm not sure if I am actually
>> > exercising it.
> 
>> Did you try rebuilding kdemultimedia, and/or anything else that might

I removed it, put it back by --usepkg and rebuild, several times. kdebase is pulling it in, amoung other things:
# equery depends -d openldap
[ Searching for packages depending on openldap... ]
dev-libs/cyrus-sasl-2.1.22-r1
app-crypt/gnupg-1.4.6
app-crypt/gnupg-1.9.21
net-misc/curl-7.15.1-r1
net-misc/openssh-4.5_p1
kde-base/kdebase-3.5.5-r1

hmm, made a lier out of myself. I haven't rebuilt any of these.

>> BTW, if revdep-rebuild isn't providing you enough info about exactly what
>> it's finding and why, try running it with the --vv flag.  That's supposed

-vv didn't help, the extra info is environmental information, the broken messages are the same.

> BTW2, I'm a KDE guy myself but have (some of) the split packages merged,
> not monolithic (as I think I mentioned before).

I've wondered about that, going split sound like it might be less trouble,
I'll look into it.

> you have on that I have off.  You don't happen to have the the ldap USE
> flag on, do you?  It doesn't sound like you'd be using it.  It's off here.

Its not present.

Anyway, I'm happy now, I'll just ignore the broken links, since I'm not using them.
I'll put up with it & hope the next version of openldap is more consistent.

I've put up a bug on openldap: http://bugs.gentoo.org/show_bug.cgi?id=164626
as it should supply the old liblber 2.2 library as well (relating to Harm's comment).
-- 
gentoo-amd64@gentoo.org mailing list

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

[Duncan]

"Daiajo Tibdixious" <daiajo@gmail.com> posted
a4a9bfcb0701301537h3bf84b89wbea47bf769e793ce@mail.gmail.com, excerpted
below, on  Wed, 31 Jan 2007 10:37:05 +1100:

>>> This case is probably an example of one of the issues with
>>> revdep-rebuild, or more precisely with binary-only packages you may
>>> choose to run.
> 
> I know it freaks on firefox-bin. I resent that "choose" to run, as its
> only ignorance at work here, are you saying openldap is binary? AFAIK I
> don't have any binary packages any more.

No.  I was still talking about the ATI video drivers still.  As with
Nvidia, the driver has some open code but some closed binary-only code as
well.  I dealt with openldap (to the limited degree I could) further down,
below where I quoted your mention of it.

>> Revdep-rebuild sees and scans the shared libraries, and doesn't know
>> when they are part of a binary-only package. Naturally, you can remerge
>> the binary-only package all day and if it was built against a library
>> not on your system, it's not going to help one bit.
> 
> Yeah, I figured that out with firefox-bin, how does it apply here?

I'm assuming some of the binary-only ATI video driver shared libraries are
linked against something you don't have on the system.  If so, it'll be
difficult to fix since you can't just recompile them, the ebuild just
remerges the same binary stuff each time so it doesn't help.

>>> Newer revdep-rebuild versions have a way to configure it to ignore
>>> certain packages.
> 
> I'm used to ignoring revdep-rebuild. :) Especially I ignore the packages
> to be rebuilt, its great for detecting broken linkage but lousy (in my
> limited experience) at fixing them.

I've had better luck with it, but that may be simply due to the fact that
I keep up pretty closely with ~arch, updating twice a week to daily,
keep the system generally cruft free, don't run anything binary-only (with
a single exception, the close to a decade and a half old now 1993 original
Master of Orion, tho at least I run it on from-source DOSBOX)

>>> standard gripe about slaveryware here, but it's your system, not mine,
>>> so you get to choose what you run and I'd not deny you that right,
>>> regardless of how much I gripe.)
> 
> I'd rather not have slaveryware either. My son has a Win XP Home which I
> use for that. :(

If I were to be a gamer, I expect I'd run a Wii for my proprietary/gaming
stuff and still wouldn't install anything binary-only on my computer.

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.  It doesn't run the newest
chips, but it does thru the ATI r300 series chips now in 3D and beyond
that in 2D, I believe. Again, it's your system, and I'd not tell you what
you had to run even if I could, but if the native will work for what you
do with the system, it's /definitely/ less hassle.  I know I got /so/
tired of dealing with Nvidia's drivers (which I had to use at the time, as
the native ones didn't handle the second video output on the card and I
was multi-monitor, before I actually switched to Linux, when I got the
card, I knew enough to ensure twinview worked in Linux, which I planned
to switch to, but didn't realize there were closed drivers at the time,
so made a purchase decision I regretted badly after I actually switched
to Linux and learned the hassle it meant) and was /so/ glad to get off it
and get an ATI Radeon with full native support.  

>>> > openldap 
>> 
>>> Did you try rebuilding [] anything else that might
> 
> I removed it, put it back by --usepkg and rebuild, several times.
> kdebase is pulling it in, amoung other things: # equery depends -d
> openldap [ Searching for packages depending on openldap... ]
> dev-libs/cyrus-sasl-2.1.22-r1
> app-crypt/gnupg-1.4.6
> app-crypt/gnupg-1.9.21
> net-misc/curl-7.15.1-r1
> net-misc/openssh-4.5_p1
> kde-base/kdebase-3.5.5-r1
> 
> hmm, made a lier out of myself. I haven't rebuilt any of these.

One of those apparently still depends on the old ldap library.

>> BTW2, I'm a KDE guy myself but have (some of) the split packages
>> merged, not monolithic (as I think I mentioned before).
> 
> I've wondered about that, going split sound like it might be less
> trouble, I'll look into it.

I do it for a couple reasons. 

1) When there's a security update or the like, as long as it's not kdelibs
(where the monolithic package is used in both cases), it's usually just
one or two packages out of the big monolithic package I'd otherwise have
to rebuild, so those sorts of between-KDE version upgrades go MUCH faster, 

2) It allows me to pick and choose the packages I actually use.  For
instance, I don't have a handheld, so I don't need all those packages out
of kdepim, but I DO run kmail, so I have it and its support merged --
but without the handheld junk I'd be spending all that time compiling for
nothing if I ran the monolithic package.  Of course, that means that
security updates or the like for packages I don't have merged don't
force a recompile of the whole big thing either -- I don't have to worry
about them since I don't have them merged! =8^)

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. 
If you just merge kde now, and do the exact parallel with kde-meta, thus
merging /all/ the packages in the monolithic, it takes much longer to do
full KDE version upgrades, because of all that duplicated ./configure work.
Thus, unless you know there are a number of packages you definitely don't
use and can therefore skip merging, it may be best to stick with the
monolithics.  

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
security or admin issues if they aren't there!), so the extra time spent
in the duplicated ./configure steps during the merge is more or less
canceled out by the number of packages I don't merge at all, and it takes
about the same time for the full KDE version upgrades, while taking much
less time for security updates and the like, AND avoiding all that extra
cruft on the system, so the split packages are a definite net positive
for me even with that negative.  As I said, tho, it wouldn't be nearly as
clear-cut for those simply merging kde-meta instead of kde, and I'm not
sure I'd recommend it unless you DO plan on using the splits to skip a
number of individual packages you aren't interested in.

>> you have on that I have off.  You don't happen to have the the ldap USE
>> flag on, do you?  It doesn't sound like you'd be using it.  It's off
>> here.
>>
> Its not present.

I just checked... the kdebase monolithic package does indeed have an ldap
USE flag.  It looks like the split package that pulls it in is
kdebase-kioslaves, which has the flag as well.  Looking at the ebuild, the
openldap dependency is indeed conditional on the ldap flag.  Since I have
-ldap, I skipped that dependency.

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.

If you don't need ldap, which you probably don't unless you are part of a
corporate network that uses it or deliberately set it up on your home
network, I'd suggest setting -ldap in make.conf, thus overriding the
profile.  An emerge -N world should then remerge anything that uses that
USE flag, and hopefully kill all your dependencies on it, allowing you to
unmerge it and not worry about it any more.  A quick check on the packages
you listed says they all have the ldap USE flag, so indeed, one presumes
toggling it off and remerging them will remove that dependency.

> Anyway, I'm happy now, I'll just ignore the broken links, since I'm not
> using them. I'll put up with it & hope the next version of openldap is
> more consistent.

I don't like ignoring such things if I don't have to, and it shouldn't be
necessary except on binary packages.  If you're not using openldap anyway,
the above should remove it as a dependency, after which you can unmerge it
and cure the problem. =8^)

-- 
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

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

[Daiajo Tibdixious]

On 1/31/07, Duncan <1i5t5.duncan@cox.net> wrote:
> "Daiajo Tibdixious" <daiajo@gmail.com> posted
> below, on  Wed, 31 Jan 2007 10:37:05 +1100:
>
> No.  I was still talking about the ATI video drivers still.  As with
> Nvidia, the driver has some open code but some closed binary-only code as
> well.  I dealt with openldap (to the limited degree I could) further down,
> below where I quoted your mention of it.

Oh, I didn't realise.

> I've had better luck with it, but that may be simply due to the fact that
> I keep up pretty closely with ~arch, updating twice a week to daily,
> keep the system generally cruft free, don't run anything binary-only (with
> a single exception, the close to a decade and a half old now 1993 original
> Master of Orion, tho at least I run it on from-source DOSBOX)

Wow.

> 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?

> > dev-libs/cyrus-sasl-2.1.22-r1
> > app-crypt/gnupg-1.9.21
> > net-misc/curl-7.15.1-r1
> > net-misc/openssh-4.5_p1
> > kde-base/kdebase-3.5.5-r1
> >
> 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.

> 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?

> 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.

> network, I'd suggest setting -ldap in make.conf, thus overriding the
> profile.  An emerge -N world should then remerge anything that uses that
> USE flag, and hopefully kill all your dependencies on it, allowing you to

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.

> unmerge it and not worry about it any more.  A quick check on the packages
> you listed says they all have the ldap USE flag, so indeed, one presumes
> toggling it off and remerging them will remove that dependency.

openssh (e.g.) also shows -ldap in eix, but still a dependent of
openldap in equery depends.

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.

> I don't like ignoring such things if I don't have to, and it shouldn't be
> necessary except on binary packages.  If you're not using openldap anyway,
> the above should remove it as a dependency, after which you can unmerge it
> and cure the problem. =8^)

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.
-- 
gentoo-amd64@gentoo.org mailing list

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

[Duncan]

"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

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

[Daiajo Tibdixious]

On 2/2/07, Duncan <1i5t5.duncan@cox.net> wrote:
> "Daiajo Tibdixious" <daiajo@gmail.com> posted below, on  Thu, 01 Feb 2007 21:39:08 +1100:
> > 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.

openldap was in world. Such a stupid, blindingly obvious thing we
never thought of it!

So that bit is fine, I removed it from world and depclean unmerged it.

(I appreciate everything else you said, I just havn't got around to it.)
-- 
gentoo-amd64@gentoo.org mailing list

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

[Harm Geerts]

On Tue, January 30, 2007 13:43, Daiajo Tibdixious wrote:
> revdep-rebuild keeps throwing up these 2 as rebuild targets, yet
> rebuilding them has no effect whatsoever. This is my final 'problem'
> after emerge --depclean. Its a theoretical problem because I rebooted,
> restarted X/KDE, and no problems whatsoever, so I can probably just
> ignore this situation, but it offends my sensibilities. I've expanded
> the revdep-rebuild output with qfile information.
>
> x11-drivers/ati-drivers
>     usr/lib32/xorg/modules/dri/atiogl_a_dri.so
>     /usr/lib32/xorg/modules/dri/fglrx_dri.so
>         media-libs/mesa (/usr/lib64/opengl/xorg-x11/lib/libGL.so.1)
>         x11-drivers/ati-drivers (/usr/lib32/opengl/ati/lib/libGL.so.1)
>         x11-drivers/ati-drivers (/usr/lib64/opengl/ati/lib/libGL.so.1)
>         x11-libs/libX11 (/usr/lib64/libX11.so.6)
>         x11-libs/libXext (/usr/lib64/libXext.so.6)
>         sys-libs/libstdc++-v3 (/usr/lib64/libstdc++-v3/libstdc++.so.5)
> net-nds/openldap-2.3
>     /usr/lib64/libldap-2.2.so.7 net-nds/openldap-2.2-28-r7?
> liblber-2.2.so.7)
>     /usr/lib64/libldap.so.2.0.130 net-nds/openldap-2.2-28-r7?
> liblber.so.2)
>     /usr/lib64/libldap_r-2.2.so.7 net-nds/openldap-2.2-28-r7?
> liblber-2.2.so.7)
>     /usr/lib64/libldap_r.so.2.0.130 net-nds/openldap-2.2-28-r7?
> liblber.so.2)
>
> Firstly ati-drivers shows 2 broken .so's. I can't tell if libGL.so.1
> is the mesa one or the ati-drivers one, both are present. libX11,
> libXext, libstdc++-v3 are all present, so I don't know why
> revdep-rebuild is showing a breakage.
>
> If ati-drivers was broken, why is my graphics working?
>
> Secondly openldap is referencing liblber 2.2 which is NOT present.
> 'equery f openldap' shows it is actually part of openldap, which I
> have rebuilt about 7 times to no avail.
> Actually the liblber files in openldap are 2.3 versions, not 2.2.
> libldap has both 2.2 and 2.3 versions, so I guess I'm running on 2.3,
> and the 2.2 are just there to cause me a headache. The installed
> version is 2.3.30-r2 so I don't know why it would contain 2.2 files.

The ebuild copies the old libraries from a 2.2 install to the image of a
2.3 install in order to avoid distaster on systems that use ldap for
authentication. The postinst tells you to rebuild everything that depends
on these libraries and remove them once that's done.

Over time you have rebuild everything against the newest version, but
never removed the old libraries, this has to be done manually!

> openldap is required by KDE multimedia, I'm not sure if I am actually
> exercising it.

If you're not sure, then you probably aren't.
-- 
gentoo-amd64@gentoo.org mailing list

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

[Harm Geerts]

On Tue, January 30, 2007 13:43, Daiajo Tibdixious wrote:
> revdep-rebuild keeps throwing up these 2 as rebuild targets, yet
> rebuilding them has no effect whatsoever. This is my final 'problem'
> after emerge --depclean. Its a theoretical problem because I rebooted,
> restarted X/KDE, and no problems whatsoever, so I can probably just
> ignore this situation, but it offends my sensibilities. I've expanded
> the revdep-rebuild output with qfile information.
>
> x11-drivers/ati-drivers
>     usr/lib32/xorg/modules/dri/atiogl_a_dri.so
>     /usr/lib32/xorg/modules/dri/fglrx_dri.so
>         media-libs/mesa (/usr/lib64/opengl/xorg-x11/lib/libGL.so.1)
>         x11-drivers/ati-drivers (/usr/lib32/opengl/ati/lib/libGL.so.1)
>         x11-drivers/ati-drivers (/usr/lib64/opengl/ati/lib/libGL.so.1)
>         x11-libs/libX11 (/usr/lib64/libX11.so.6)
>         x11-libs/libXext (/usr/lib64/libXext.so.6)
>         sys-libs/libstdc++-v3 (/usr/lib64/libstdc++-v3/libstdc++.so.5)
> net-nds/openldap-2.3
>     /usr/lib64/libldap-2.2.so.7 net-nds/openldap-2.2-28-r7?
> liblber-2.2.so.7)
>     /usr/lib64/libldap.so.2.0.130 net-nds/openldap-2.2-28-r7?
> liblber.so.2)
>     /usr/lib64/libldap_r-2.2.so.7 net-nds/openldap-2.2-28-r7?
> liblber-2.2.so.7)
>     /usr/lib64/libldap_r.so.2.0.130 net-nds/openldap-2.2-28-r7?
> liblber.so.2)
>
> Firstly ati-drivers shows 2 broken .so's. I can't tell if libGL.so.1
> is the mesa one or the ati-drivers one, both are present. libX11,
> libXext, libstdc++-v3 are all present, so I don't know why
> revdep-rebuild is showing a breakage.
>
> If ati-drivers was broken, why is my graphics working?
>
> Secondly openldap is referencing liblber 2.2 which is NOT present.
> 'equery f openldap' shows it is actually part of openldap, which I
> have rebuilt about 7 times to no avail.
> Actually the liblber files in openldap are 2.3 versions, not 2.2.
> libldap has both 2.2 and 2.3 versions, so I guess I'm running on 2.3,
> and the 2.2 are just there to cause me a headache. The installed
> version is 2.3.30-r2 so I don't know why it would contain 2.2 files.

The ebuild copies the old libraries from a 2.2 install to the image of a
2.3 install in order to avoid distaster on systems that use ldap for
authentication. The postinst tells you to rebuild everything that depends
on these libraries and remove them once that's done.

Over time you have rebuild everything against the newest version, but
never removed the old libraries, this has to be done manually!

> openldap is required by KDE multimedia, I'm not sure if I am actually
> exercising it.

If you're not sure, then you probably aren't.
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Duplicate replies (was Re: revdep broken x11-drivers/ati-drivers net-nds/openldap)

[Harm Geerts]

Sorry, for the duplicate emails.
I've had a little trouble with my local mailsystem, it won't happen again.
-- 
gentoo-amd64@gentoo.org mailing list