|
|
| Applications |
| Mailing Lists |
| Miscellaneous |
| Operating Systems |
| Programming |
Re: upgrading in sid
From: Hugo Vanwoerkom <hvw59601(at)care2.com>
Date: Tue Jan 01 2008 - 07:06:03 EST
>
> Your system is OK, except for the fact that there is a non-Debian
> libz.so.1 in /usr/local/lib/. Wherever this file came from, it does not
> implement the gzopen64 function which is needed by gconftool-2. Your
> problem will persist as long as the linker gives precedence to
> /usr/local/lib/libz.so.1.
>
> [...]
>
>
> Same as above: You need to see /usr/lib/libz.so.1 here (no "/local/").
>
>
> I don't think you did anything so far. ("/sbin/ldconfig -pNX" is a
> diagnostic command; I was trying to tell you how to check which
> locations are known for the libz library.)
>
>
> The main issue seems to be the gconftool-2 problem. Whenever you call
> aptitude it will first try to fix the broken packages and it will
> continue to fail until the libz.so.1 issue is addressed.
>
>
> AFAICT, your only two problems are /usr/local/lib/libz.so.1 and
> /usr/local/lib/libz.so. My problem is that I don't know why these files
> are on your system, therefore I am hesitant to tell you to delete or
> rename them, because this might break other things.
>
> In my opinion you have three options:
>
> 1) Tells us exactly how and why these /usr/local/lib/ files got on your
> system. We might be able to figure out what the safest approach is if
> we know that.
>
> 2) Read up on the basics of linking and shared libraries, then make an
> informed decision yourself after you fully understand the present
> problem.
>
> 3) Remove or rename the /usr/local/lib/libz.so* files, run "ldconfig"
> (as root, without any arguments or options), make sure that "ldd
> /usr/lib/libxml2.so.2 | grep libz" shows /usr/lib/libz.so.1 will be
> used, and run "aptitude install -f".
>
Date: Tue Jan 01 2008 - 07:06:03 EST
Florian Kulzer wrote:
> On Mon, Dec 31, 2007 at 18:34:55 -0500, charlie derr wrote:
>
> [...]
>
>> ni@delete:~$ /sbin/ldconfig -pNX | grep 'libz\.so' >> libz.so.1 (libc6) => /usr/local/lib/libz.so.1 >> libz.so.1 (libc6) => /usr/lib/libz.so.1 >> libz.so (libc6) => /usr/local/lib/libz.so >> libz.so (libc6) => /usr/lib/libz.so >> ni@delete:~$ >> >> I'm not aware of ever intentionally doing anything to install any >> 64bit libs. My whole system is running as 32-bit.
>
> Your system is OK, except for the fact that there is a non-Debian
> libz.so.1 in /usr/local/lib/. Wherever this file came from, it does not
> implement the gzopen64 function which is needed by gconftool-2. Your
> problem will persist as long as the linker gives precedence to
> /usr/local/lib/libz.so.1.
>
> [...]
>
>> ni@delete:~$ ldd /usr/lib/libxml2.so.2 | grep libz >> libz.so.1 => /usr/local/lib/libz.so.1 (0xb7e83000)
>
> Same as above: You need to see /usr/lib/libz.so.1 here (no "/local/").
>
>> I think I'd like to understand why this first attempt didn't work.
>
> I don't think you did anything so far. ("/sbin/ldconfig -pNX" is a
> diagnostic command; I was trying to tell you how to check which
> locations are known for the libz library.)
>
>> aptitude is still very broken, full output here at >> http://www.assembla.com/wiki/show/door/AptitudeUpgradeStillFailing
>
> The main issue seems to be the gconftool-2 problem. Whenever you call
> aptitude it will first try to fix the broken packages and it will
> continue to fail until the libz.so.1 issue is addressed.
>
>> i'm totally lost by now (but eagerly trying to keep up), here's the output from that one: >> >> $ /sbin/ldconfig -pNX | grep local >> libz.so.1 (libc6) => /usr/local/lib/libz.so.1 >> libz.so (libc6) => /usr/local/lib/libz.so >> libsvn_ra_local-1.so.1 (libc6) => /usr/lib/libsvn_ra_local-1.so.1 >> liblocalkonnector.so (libc6) => /usr/lib/liblocalkonnector.so >> >> so should i get rid of all those (or rename them) and see if that helps?
>
> AFAICT, your only two problems are /usr/local/lib/libz.so.1 and
> /usr/local/lib/libz.so. My problem is that I don't know why these files
> are on your system, therefore I am hesitant to tell you to delete or
> rename them, because this might break other things.
>
> In my opinion you have three options:
>
> 1) Tells us exactly how and why these /usr/local/lib/ files got on your
> system. We might be able to figure out what the safest approach is if
> we know that.
>
> 2) Read up on the basics of linking and shared libraries, then make an
> informed decision yourself after you fully understand the present
> problem.
>
> 3) Remove or rename the /usr/local/lib/libz.so* files, run "ldconfig"
> (as root, without any arguments or options), make sure that "ldd
> /usr/lib/libxml2.so.2 | grep libz" shows /usr/lib/libz.so.1 will be
> used, and run "aptitude install -f".
>
Good show Florian! I got stuck in a similar situation a year or so ago. Happened through the installation of an RPM package that I alien'd. Happy new year.
Hugo
-- To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.orgReceived on Tue Jan 1 07:07:52 2008
This archive was generated by hypermail 2.1.8 : Fri Feb 29 2008 - 16:53:50 EST
|
Contact Us Legal Notices Order Services Online Pantek Home Privacy Policy IT news Site Map Pantek Library |