subject:"Re\: upgrading in sid"


I missed this message until just now, thanks so much for all the info I snipped 
out, I'm going to try to understand it now.


aptitude-create-state-bundle  doesn't apparently exist on my system -- was this a relatively recent addition to aptitude?  (it may 
have been a year or slightly longer since I've upgraded aptitude)





  Actually, if you have a way to post large files on the internet, it
would be interesting if you could run
aptitude-create-state-bundle snapshot.tar.bz2 and then let me know how
to get access to it; then I might be able to reproduce your problems
here and find out exactly what's happening.

  Daniel





--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: upgrading in sid


Daniel Burrows wrote:

On Mon, Dec 31, 2007 at 03:59:16PM -0500, charlie derr [EMAIL PROTECTED] was 
heard to say:

Daniel Burrows wrote:

  It would be interesting to know what ldd /usr/lib/libxml2.so.2 says.

[EMAIL PROTECTED]:/var/cache/apt$ ldd /usr/lib/libxml2.so.2
linux-gate.so.1 =  (0xb7fb7000)
libdl.so.2 = /lib/i686/cmov/libdl.so.2 (0xb7e7e000)
libz.so.1 = /usr/local/lib/libz.so.1 (0xb7e6a000)

  ^^

  You may not know it's there, but you have a local version of libz.so.1
that isn't binary-compatible with the Debian-supplied libz.  You're
probably better off just deleting this (or moving it to some other name,
like was-libz.1); as it is, you risk random breakage and security holes
(because you probably aren't getting security updates for your local
version of the library).

  You may want to check if anything else has been placed in
/usr/local/bin or /usr/local/lib, and what the timestamps are (run
ls -l /usr/local/bin /usr/local/lib), as any other files in there
will override the system libraries.




Thanks so very much to you and Florian both being patient with me and explaining in this sort of detail.  The timestamp on the 
problematic libz.so.1.2.3 (where libz.so.1 was linked to told me that I'd installed it on 11-16-2006 which was long enough ago 
that I can understand forgetting that I'd done it (and also at a period of time, that I might very well have been trying to 
install new software (some of which I might not have been able to find in debian)).


  


  Erk.  That means something is hosed in your apt cache.  I would guess
this isn't related to your earlier problems, but it would be interesting
to know whether running aptitude update fixes this problem, 

it hasn't yet (subsequent upgrades/removals won't all succeed (all of the gnome 
related stuff is foobared)) -- this is why i've


  Huh, interesting.


delete:~# apt-cache showpkg desktop-base shared-mime-info
Package: desktop-base
Versions:
4.0.4(/var/lib/apt/lists/ftp.us.debian.org_debian_dists_unstable_main_binary-i386_Packages)
4.0.3(/var/lib/dpkg/status)


  OK, apt believes that version 4.0.4 is available from unstable.  But
when it goes to actually install that version, it apparently blows up,
complaining that no file in the archive actually provides version 4.0.4.
At least, that's how I interpret that message
(pkgAcqArchive::pkgAcqArchive generates it if QueueNext
fails)...although from the source it looks like there are a few other
things it could be caused by, such as unusual trust errors.  You didn't
mention trust problems, though, so I assume that's not what's happening.

  I wonder what these commands will show:

grep -A 1000 ^Package: desktop-base$ 
/var/lib/apt/lists/ftp.us.debian.org_debian_dists_unstable_main_binary-i386_Packages | 
sed '/^$/,$d'

apt-cache policy desktop-base

apt-get -s install desktop-base

apt-get -s install desktop-base=4.0.4

aptitude -s install desktop-base=4.0.4

aptitude - show desktop-base

  Actually, if you have a way to post large files on the internet, it
would be interesting if you could run
aptitude-create-state-bundle snapshot.tar.bz2 and then let me know how
to get access to it; then I might be able to reproduce your problems
here and find out exactly what's happening.

  Daniel





With the removal of the problematic libz stuff, aptitude is humming along just fine.  I now understand (I think) completely what 
the sequence of events was.


In trying my upgrade the other day, there was a problem with 5 packages:
desktop-base gnome-session  libgnome2-common libgnomevfs2-common 
shared-mime-info

It was the gzopen64 error, but not understanding it, my first thought was that perhaps the downloaded files were maybe corrupted 
(I'd seen what I'd thought was a similar error in the past and forcing a redownload had apparently fixed it), so I deleted the 
.deb files out of /var/cache/apt/archives --- this part didn't go as well as I'd hoped because there was no immediate attempt to 
redownload anything (I just got the same error), and this is when I tried apt-get -f install which may or may not have screwed 
up the state of those 5 packages.



thanks again to everyone for the assistance, you're all great,
~c


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: upgrading in sid

2008-01-02 Thread Daniel Burrows

On Wed, Jan 02, 2008 at 09:09:53AM -0500, charlie derr [EMAIL PROTECTED] was 
heard to say:
 aptitude-create-state-bundle  doesn't apparently exist on my system -- was 
 this a relatively recent addition to aptitude?  (it may have been a year or 
 slightly longer since I've upgraded aptitude)

  Yes, it was added in version 0.4.6.  All it really does is make a
compressed archive of the following files/directories:

  /var/lib/aptitude
  /var/lib/apt
  /var/cache/apt/pkgcache.bin
  /var/cache/apt/srcpkgcache.bin
  /etc/apt
  /var/lib/dpkg/status

  ...but I find it's easier to tell people to run it than to tell them
to make a compressed archive of a half-dozen cryptically named items. :)

  Daniel


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: upgrading in sid


Thanks again for explaining everything.

After continuing through a few more upgrades (actually, I got the word that I should now be using safe-upgrade, so was using 
that when I remembered), I'm now almost fully up to date (kde wants to uninstall itself when I try to upgrade kdebase, so I'm 
putting that off for a week or so to see if it works better after available packages are built on the other end).  I really 
appreciate all the assistance,


~c




Daniel Burrows wrote:

On Wed, Jan 02, 2008 at 09:09:53AM -0500, charlie derr [EMAIL PROTECTED] was 
heard to say:
aptitude-create-state-bundle  doesn't apparently exist on my system -- was 
this a relatively recent addition to aptitude?  (it may have been a year or 
slightly longer since I've upgraded aptitude)


  Yes, it was added in version 0.4.6.  All it really does is make a
compressed archive of the following files/directories:

  /var/lib/aptitude
  /var/lib/apt
  /var/cache/apt/pkgcache.bin
  /var/cache/apt/srcpkgcache.bin
  /etc/apt
  /var/lib/dpkg/status

  ...but I find it's easier to tell people to run it than to tell them
to make a compressed archive of a half-dozen cryptically named items. :)

  Daniel





--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: upgrading in sid

2008-01-02 Thread Sven Joachim

On 2008-01-02 17:42 +0100, charlie derr wrote:

 After continuing through a few more upgrades (actually, I got the word
 that I should now be using safe-upgrade, so was using that when I
 remembered), I'm now almost fully up to date (kde wants to uninstall
 itself when I try to upgrade kdebase, so I'm putting that off for a
 week or so to see if it works better after available packages are
 built on the other end).

That might take a while.  Apparently the i386 buildd has been down for
ten days at least, and the whole KDE team is running amd64. :-(

I'd put testing in my sources.list and install kdebase from there.

Sven


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: upgrading in sid


Sven Joachim wrote:

On 2008-01-02 17:42 +0100, charlie derr wrote:


After continuing through a few more upgrades (actually, I got the word
that I should now be using safe-upgrade, so was using that when I
remembered), I'm now almost fully up to date (kde wants to uninstall
itself when I try to upgrade kdebase, so I'm putting that off for a
week or so to see if it works better after available packages are
built on the other end).


That might take a while.  Apparently the i386 buildd has been down for
ten days at least, and the whole KDE team is running amd64. :-(



maybe I should attempt an amd64 install again (I do have an alternate / partition on this machine where I attempted to do this 
when it was new (over a year ago) -- I got it mostly working but the mouse was wonky (it almost worked, but it was very hard to 
successfully select text) and the clock ran twice as fast as it was supposed to and I gave up trying to research the answers to 
those two issues -- maybe they're fixed by now and simply booting back to that partition and upgrading everything will work).



I'd put testing in my sources.list and install kdebase from there.


i don't think i'll do that -- there's no new feature that I'm missing, so I'll 
probably just wait


thanks in any event for the info,
~c



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: gnome won't uninstall because I messed up dpkg by mixing and matching apt-get and aptitude incorrectly (used to be Re: upgrading in sid)

Ron Johnson wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/31/07 15:48, charlie derr wrote:
[snip]

Of course, I would do all this from the (real) console, not a GNOME
terminal window.

you're just chicken :-]

Real Men use the console. I'm not sure what Real Women use.

Yeah, I used to think that way too. But I find that a full-featured X environment is definitely preferrable to the command-line
when I have an option (yeah I *can* do everything from a single console if I have to (as long as screen and emacs are installed),
but I'm a lot more efficient with a mouse and graphics, etc...). I'm at the point where I really don't believe that very many
folks are actually browsing the internet regularly with a text-only browser from a command line. But who knows, maybe there're
more Real Men out there than I'm guessing...

(i'm still in the same original openbox session I started in a couple
days ago (my one concession was to not do this from my usual busy
(50-100 application windows spread across 4 desktops) KDE session))

i did take the extra step of doing my upgrade from within a screen
session (inside konsole, not gnome-terminal)

Lastly, I'd *never* use aptitude.

It appears (to me at least) that that's an irrational bias you have
there.

Irrational? I was last irrational in... in... well, it's been a
*long* time since I've been irrational.

aptitude (and wajig) likes to be more than slightly aggressive in
what else it wants to remove when you remove a top level (not
meta-) package.

ahh, right, I do remember that argument being used (in favor of refusing to switch out apt-get for aptitude in general), but I
never really bought it -- first of all, I found it helpful to have packages pruned out when I probably never used them, and for
the odd case where something I wanted was removed, I never minded simply reinstalling once I realized it was missing -- also, my
understanding is that this is a configurable option that can be set in some config file to act any way one wants (the problem was
the people were complaining about aptitude's default setting being problematic -- seemed like a really nitpicky complaint to me if
it's actually a tuneable parameter and not hard-coded to lock one in to that behavior)

Recent versions of apt-get strike a nice balance by listing the
packages that become orphanable by a remove, and helpfully
suggests running apt-get autoremove. And just install the ones
you want to keep, so that apt-get stops pestering/reminding you to
autoremove them.

Do you really feel like apt-get is fully supported? The last things I remember seeing from developers on the lists (not even
very recently) seemed to indicate that use of apt-get is now (and has been for some time) deprecated. Of course, if you're not
running sid/unstable, that might not yet be true for the version you're using, but...

be well,
~c

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: gnome won't uninstall because I messed up dpkg by mixing and matching apt-get and aptitude incorrectly (used to be Re: upgrading in sid)

2008-01-02 Thread Ron Johnson

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/02/08 11:23, charlie derr wrote:
 Ron Johnson wrote:

 On 12/31/07 15:48, charlie derr wrote:
 [snip]
 Of course, I would do all this from the (real) console, not a GNOME
 terminal window.
 you're just chicken :-]

 Real Men use the console.  I'm not sure what Real Women use.

 
 Yeah, I used to think that way too.   But I find that a full-featured X
 environment is definitely preferrable to the command-line when I have an

X is great for allowing you to have lots of xterms.  Esspecially
when 24x80 isn't optimal.

Proportional fonts and icons are also *sometimes* useful.  Mainly to
be able to cram more information onto the screen.  But that's about it.

Oh yeah, and colors.  ANSI colors don't look very good on a white
background.  (I prefer black on white for the same reason newpapers
and books have black ink on white paper.  Can you imagine trying to
read a black newspaper with white ink?  Yech.  Of course, I know
that I'm in the significant minority.)

 option (yeah I *can* do everything from a single console if I have to

Yech.  That's what VTs are for...

 (as long as screen and emacs are installed), but I'm a lot more
 efficient with a mouse and graphics, etc...).   I'm at the point where I
 really don't believe that very many folks are actually browsing the
 internet regularly with a text-only browser from a command line.   But
 who knows, maybe there're more Real Men out there than I'm guessing...

Because most Web Designers are not Real Mean, and thus pollute web
pages with too much graphical whooey.

 (i'm still in the same original openbox session I started in a couple
 days ago (my one concession was to not do this from my usual busy
 (50-100 application windows spread across 4 desktops) KDE session))

 i did take the extra step of doing my upgrade from within a screen
 session (inside konsole, not gnome-terminal)

 Lastly, I'd *never* use aptitude.
 It appears (to me at least) that that's an irrational bias you have
 there.

 Irrational?  I was last irrational in... in... well, it's been a
 *long* time since I've been irrational.

 aptitude (and wajig) likes to be more than slightly aggressive in
 what else it wants to remove when you remove a top level (not
 meta-) package.
 
 ahh, right, I do remember that argument being used (in favor of refusing
 to switch out apt-get for aptitude in general), but I never really
 bought it -- first of all, I found it helpful to have packages pruned
 out when I probably never used them,

Doing what the app wants, without asking the user, is the Microsoft Way.

   and for the odd case where
 something I wanted was removed, I never minded simply reinstalling once
 I realized it was missing -- also, my understanding is that this is a
 configurable option that can be set in some config file to act any way
 one wants (the problem was the people were complaining about aptitude's
 default setting being problematic -- seemed like a really nitpicky
 complaint to me if it's actually a tuneable parameter and not hard-coded
 to lock one in to that behavior)

If you're going to write an app which is named like the original
app, and has command options like the original app, so that users of
the original app will use the new app, doesn't it sound reasonable
that the new app have defaults similar to the old app?

 Recent versions of apt-get strike a nice balance by listing the
 packages that become orphanable by a remove, and helpfully
 suggests running apt-get autoremove.  And just install the ones
 you want to keep, so that apt-get stops pestering/reminding you to
 autoremove them.

 
 Do you really feel like apt-get is fully supported?

If it wasn't, then auto-remove wouldn't have been added.

 The last things I
 remember seeing from developers on the lists (not even very recently)
 seemed to indicate that use of apt-get is now (and has been for some
 time) deprecated.  Of course, if you're not running sid/unstable, that
 might not yet be true for the version you're using, but...

Been running Sid for years.  apt-get has never let me down.

- --
Ron Johnson, Jr.
Jefferson LA  USA

I'm not a vegetarian because I love animals, I'm a vegetarian
because I hate vegetables!
unknown
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHe+EWS9HxQb37XmcRAu1MAJwPGr8pTXfQ5DsOjZ/0KhSYTn2sUwCdF3EY
VBHjMcR0gHUMnhIzg0LXqK8=
=FB8n
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: upgrading in sid

2008-01-02 Thread David Fox

On 12/31/07, charlie derr [EMAIL PROTECTED] wrote:

snip some stuff


 I'm not aware of ever intentionally doing anything to install any 64bit
 libs.  My whole system is running as 32-bit.

MIne too (I don't do AMD64 because I don't have an AMD64, sniff).

But I also see 64 bit stuff in /lib64. And I don't think they are for
64bit file position related stuff
because if I disassemble one representative file I see 64 bit instructions.

As these will likely never get used until or unless I get a 64bit
machine, how do I remove them? I don't think I ever explicitly told
aptitude to install these libraries.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: upgrading in sid

2008-01-02 Thread Daniel Burrows

On Wed, Jan 02, 2008 at 07:26:18PM -0800, David Fox [EMAIL PROTECTED] was 
heard to say:
 On 12/31/07, charlie derr [EMAIL PROTECTED] wrote:
 
 snip some stuff
 
 
  I'm not aware of ever intentionally doing anything to install any 64bit
  libs.  My whole system is running as 32-bit.
 
 MIne too (I don't do AMD64 because I don't have an AMD64, sniff).
 
 But I also see 64 bit stuff in /lib64. And I don't think they are for
 64bit file position related stuff
 because if I disassemble one representative file I see 64 bit instructions.
 
 As these will likely never get used until or unless I get a 64bit
 machine, how do I remove them? I don't think I ever explicitly told
 aptitude to install these libraries.

  You didn't say what libraries they are or what packages they come from
(use dpkg -S to find the latter out).  But on my system the only 64-bit
libraries are in /usr/lib64/fakeroot.  I assume it includes them so that
it can run programs that are themselves 64-bit.

  Other 64-bit libraries are in these packages (according to apt-file):

* amd64-libs, support software for running 64-bit programs in a
  32-bit environment (AIUI).  Required by amd64-libs-dev.

* lib64gcc1, required by various 64-bit libraries.

* lib64ncurses5, also required by various 64-bit libraries.

* lib64readline5, required by gdb64.

* libc6-amd64, required by gdb64 and various 64-bit libraries,
  along with libc6-dev-amd64.

  Daniel


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: upgrading in sid

2008-01-01 Thread Hugo Vanwoerkom


Florian Kulzer wrote:

On Mon, Dec 31, 2007 at 18:34:55 -0500, charlie derr wrote:

[...]


[EMAIL PROTECTED]:~$ /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
[EMAIL PROTECTED]:~$

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.

[...]


[EMAIL PROTECTED]:~$ 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 [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: gnome won't uninstall because I messed up dpkg by mixing and matching apt-get and aptitude incorrectly (used to be Re: upgrading in sid)

2008-01-01 Thread Hugo Vanwoerkom


Ron Johnson wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/31/07 15:48, charlie derr wrote:
[snip]

Of course, I would do all this from the (real) console, not a GNOME
terminal window.

you're just chicken :-]


Real Men use the console.  I'm not sure what Real Women use.


(i'm still in the same original openbox session I started in a couple
days ago (my one concession was to not do this from my usual busy
(50-100 application windows spread across 4 desktops) KDE session))

i did take the extra step of doing my upgrade from within a screen
session (inside konsole, not gnome-terminal)


Lastly, I'd *never* use aptitude.

It appears (to me at least) that that's an irrational bias you have
there.


Irrational?  I was last irrational in... in... well, it's been a
*long* time since I've been irrational.



T'was *at least* a year ago. Happy new year.



aptitude (and wajig) likes to be more than slightly aggressive in
what else it wants to remove when you remove a top level (not
meta-) package.

Recent versions of apt-get strike a nice balance by listing the
packages that become orphanable by a remove, and helpfully
suggests running apt-get autoremove.  And just install the ones
you want to keep, so that apt-get stops pestering/reminding you to
autoremove them.


   I'm going with the debian/GNU party line which says aptitude is
superior to apt-get in some way (though I still don't think there's a
drop-in replacement for apt-get source functionality to make aptitude
do the right thing, so I would still use apt-get there, but now that i
know aptitude install -f is the equivalent of apt-get -f install, I
really use apt-get for nothing except downloading source packages,
aptitude happily works just fine (until this event, and I think it was
really the number of upgradeable packages I was trying to do at once,
and the unfortunate circumstance of not reading the apt-listbugs output
closely enough to catch that this libxml2 problem was gonna bite me)) --
i'm confident it'll get solved though (and if not, a reinstall isn't a
huge burden for me).





--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: upgrading in sid

2007-12-31 Thread Florian Kulzer

On Sun, Dec 30, 2007 at 20:29:09 -0500, charlie derr wrote:
 charlie derr wrote:

[...]

 delete:~# dpkg -l libxml2 gconf2 | awk '/^[^D|+]/{print $1,$2,$3}'
 ii gconf2 2.20.1-2
 ii libxml2 2.6.30.dfsg-3

[...]

 delete:~# /usr/bin/python -V
 Python 2.4.4

That looks OK to me; I have the same versions and I can run
update-gconf-defaults without problems.

 after much fussing (all with aptitude now -- i'm not mixing in any apt-get 
 commands),

Just to clarify this once more: Your main problem is the gconftool-2
issue, which seems to break all package scripts which call this tool.
Using apt-get in between only caused a minor temporary problem with
aptitude's database, from which aptitude recovered on its own AFAICT.

I've managed to successfully remove a lot of gnome stuff, but 
 not enough to completely succeed.  I've snipped lots of output above this 
 (and in my mind, the gzopen64 thing seems to be key -- it's certainly 
 repeated once for each of these packages that are now still failing)

Yes, this seems to be the root of all evil at the moment.

 Processing was halted because there were too many errors.
 E: Sub-process /usr/bin/dpkg returned an error code (1)
 A package failed to install.  Trying to recover:
 Setting up dia-common (0.96.1-6) ...
 gconftool-2: symbol lookup error: /usr/lib/libxml2.so.2: undefined symbol: 
 gzopen64
 dpkg: error processing dia-common (--configure):
  subprocess post-installation script returned error exit status 127

[...]

gzopen64 should be defined in /usr/lib/libz.so.1; something is wrong
with this on your system. Post the output of the following commands:

dpkg -l zlib1g

ldd /usr/bin/gconftool-2 | grep libz

ldd /usr/lib/libxml2.so.2 | grep libz

nm -D /usr/lib/libz.so.1 | grep gzopen64

-- 
Regards,| http://users.icfo.es/Florian.Kulzer
  Florian   |


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

gnome won't uninstall because I messed up dpkg by mixing and matching apt-get and aptitude incorrectly (used to be Re: upgrading in sid)


http://www.assembla.com/wiki/show/door/SidGnomeRefusingToDie


It seemed like there was too much output there to want to burden the list with it all (but I thought someone clueful might still 
possibly catch something I haven't)


my working assumption at this point is that last night either manually deleting the deb files for 5 packages (from the 
/var/cache/apt/archives directory) and/or the fact that immediately after trying that I then tried running apt-get -f install 
(when I'd only been using aptitude previously) created the problem  -- but i'm not sure I care all that much about how I mucked 
things up, it's rather getting things straightened out that's important -- so does anyone have any tricks they'd suggest for how I 
get all of these uninstalls to complete despite the fact that gconftool-2 is very unhappy and barfs complaining about a lib 
mismatch problem with gzopen64 (the root of the problem is with libxml2.so.2, so perhaps the package .   But at this point I'd 
rather that I accept that all gnome stuff will be forever broken on this box than have aptitude continue to be borked.  If someone 
has an elegant solution, of course I'm happy to consider that too, but I'd appreciate any thoughts (no matter how 
outrageous/potentially-destructive).




here's a small snip for those who don't want to follow the link at the top:


gconftool-2: symbol lookup error: /usr/lib/libxml2.so.2: undefined symbol: 
gzopen64
dpkg: error processing capplets-data (--remove):
 subprocess pre-removal script returned error exit status 127
dpkg: error processing desktop-base (--remove):
 Package is in a very bad inconsistent state - you should
 reinstall it before attempting a removal.


and as I pasted this I realized I ought to see where that file comes from and 
the package is libxml2

if I try to do aptitude remove libxml2 the first couple dozen choices to resolve dependencies leave it at its current version 
(and I'm unsure whether aptitude might actually give me a better choice if i keep clicking n -- it does seem to be able to 
indefinitely suggest new solutions)


if I try to upgrade libxml2 I get this (desktop-base (along with shared-mime-info is one of those 5 packages I talked about above 
(that I incorrectly removed the .deb files from my archives directory) :



Resolving dependencies...
E: I wasn't able to locate file for the desktop-base package. This might mean 
you need to manually fix this package.
The following actions will resolve these dependencies:

Remove the following packages:
deskbar-applet
epiphany-extensions
evince
evolution
evolution-common
evolution-data-server
evolution-exchange
gnome-mount
gnome-power-manager
gnome-screensaver
gnome-volume-manager
nautilus-cd-burner
rhythmbox
sound-juicer
sun-java5-jre
yelp

Install the following packages:
bittorrent [3.4.2-11 (unstable, now)]
fam [2.7.0-13 (unstable)]
gnome-mime-data [2.18.0-1 (unstable, now)]
libavahi-glib1 [0.6.21-4 (unstable, now)]
libbonobo2-0 [2.20.2-1 (unstable, now)]
libbonobo2-common [2.20.2-1 (unstable, now)]
libbonoboui2-0 [2.20.0-1 (unstable, now)]
libbonoboui2-common [2.20.0-1 (unstable)]
libcamel1.2-10 [1.12.2-1 (unstable, now)]
libebook1.2-9 [1.12.2-1 (unstable, now)]
libecal1.2-7 [1.12.2-1 (unstable, now)]
libedataserver1.2-9 [1.12.2-1 (unstable, now)]
libgnome-desktop-2 [2.20.2-1 (unstable, now)]
libgnome2-0 [2.20.1.1-1 (unstable, now)]
libgnomeui-0 [2.20.1.1-1 (unstable, now)]
libgnomeui-common [2.20.1.1-1 (unstable)]
libgnomevfs2-0 [1:2.20.1-1 (unstable, now)]
libgnomevfs2-extra [1:2.20.1-1 (unstable, now)]
libgtkhtml3.14-19 [3.16.1-1 (unstable)]
libnotify1 [0.4.4-3 (unstable, now)]
libpanel-applet2-0 [2.20.2-2 (unstable, now)]
libsoup2.2-8 [2.2.104-1 (unstable, now)]
libwnck-common [2.20.2-1 (unstable)]
libwnck22 [2.20.2-1 (unstable)]
libxres1 [2:1.0.3-1 (unstable, now)]
python-gnome2 [2.20.1-1 (unstable)]
rdesktop [1.5.0-3+cvs20071006 (unstable)]

Upgrade the following packages:
gtkhtml3.14 [3.14.2-1 (now) - 3.16.1-1 (unstable)]
libgnome2-common [2.18.0-4 (now) - 2.20.1.1-1 (unstable)]
libgnomevfs2-common [1:2.18.1-2 (now) - 1:2.20.1-1 (unstable)]
notification-daemon [0.3.7-1 (now) - 0.3.7-1+b1 (unstable)]

Leave the following dependencies unresolved:
libgnomevfs2-0 recommends gnome-mount
meld recommends yelp
Score is -4309






thanks much in advance for any that are still tuned in -- it's a bit of 
a muddle,
~c



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: upgrading in sid

On Sun, Dec 30, 2007 at 05:28:48PM -0500, charlie derr [EMAIL PROTECTED] was 
heard to say:
 It's been a while, but I just attempted a massive upgrade (executing 
 aptitude upgrade) and ended up with:

 Errors were encountered while processing:

  The interesting thing is why these packages failed, which would be in
the output preceding the list of failed packages.

 Unpacking replacement desktop-base ...
 gconftool-2: symbol lookup error: /usr/lib/libxml2.so.2: undefined symbol: 
 gzopen64
 dpkg: warning - old post-removal script returned error exit status 127
 dpkg - trying script from the new package instead ...
 gconftool-2: symbol lookup error: /usr/lib/libxml2.so.2: undefined symbol: 
 gzopen64
 dpkg: error processing /var/cache/apt/archives/desktop-base_4.0.4_all.deb 
 (--unpack):

  It's pretty clear from that that your problem is that your version of
libxml2 is failing to load because it doesn't contain gzopen64.

  It would be interesting to know what ldd /usr/lib/libxml2.so.2 says.
Some hits on Google suggest that people get this problem when they have
another version of libz hanging out in $LD_LIBRARY_PATH (e.g., in
/usr/local/lib or /lib).

 The above is in response to   apt-get -f install (what used to work in the 
 past for fixing issues, maybe that's my mistake?)

  That ought to work fine.

 If I try to upgrade one of those packages individually with   aptitude 
 install shared-mime-info then the below happens:

 The following packages will be upgraded:
   gnome-session libgnome2-common libgnomevfs2-common shared-mime-info
 4 packages upgraded, 0 newly installed, 0 to remove and 795 not upgraded.
 Need to get 0B/2706kB of archives. After unpacking 1461kB will be used.
 Do you want to continue? [Y/n/?] y
 Writing extended state information... Error!
 E: I wasn't able to locate file for the desktop-base package. This might mean 
 you need to manually fix this package.
 E: Couldn't lock list directory..are you root?

  Erk.  That means something is hosed in your apt cache.  I would guess
this isn't related to your earlier problems, but it would be interesting
to know whether running aptitude update fixes this problem, and to see
the output of apt-cache showpkg desktop-base.

  Daniel


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: upgrading in sid

On Sun, Dec 30, 2007 at 08:01:32PM -0500, charlie derr [EMAIL PROTECTED] was 
heard to say:
 The following packages will be upgraded:
   gnome-session libgnome2-common libgnomevfs2-common shared-mime-info
 4 packages upgraded, 0 newly installed, 0 to remove and 795 not upgraded.
 Need to get 0B/2706kB of archives. After unpacking 1461kB will be used.
 Do you want to continue? [Y/n/?] y
 Writing extended state information... Error!
 E: I wasn't able to locate file for the desktop-base package. This might 
 mean you need to manually fix this package.
 E: Couldn't lock list directory..are you root?

 You used apt-get to break the desktop-base package behind aptitude's
 back and that seems to have confused aptitude. I would hope that this
 problem goes away once you have fixed the desktop-base package.


 Thanks again for letting me know that it was my mixing apt-get and aptitude 
 that probably screwed me up.

  I don't know any reason that mixing apt-get and aptitude should cause
problems, particularly this problem.  This is usually a symptom of your
package lists being out of sync in a weird way: it means that apt
thought it could download this package, but when it went to actually
download it no source was providing it.  I expect you would get the same
error with apt-get as with aptitude.

  Daniel


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: gnome won't uninstall because I messed up dpkg by mixing and matching apt-get and aptitude incorrectly (used to be Re: upgrading in sid)

2007-12-31 Thread Ron Johnson

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/31/07 09:15, charlie derr wrote:
 http://www.assembla.com/wiki/show/door/SidGnomeRefusingToDie
 
 
 It seemed like there was too much output there to want to burden the
 list with it all (but I thought someone clueful might still possibly
 catch something I haven't)
 
 my working assumption at this point is that last night either manually
 deleting the deb files for 5 packages (from the /var/cache/apt/archives
 directory) and/or the fact that immediately after trying that I then
 tried running apt-get -f install (when I'd only been using aptitude
 previously) created the problem  -- but i'm not sure I care all that
 much about how I mucked things up, it's rather getting things
 straightened out that's important -- so does anyone have any tricks
 they'd suggest for how I get all of these uninstalls to complete despite
 the fact that gconftool-2 is very unhappy and barfs complaining about a
 lib mismatch problem with gzopen64 (the root of the problem is with
 libxml2.so.2, so perhaps the package .   But at this point I'd rather
 that I accept that all gnome stuff will be forever broken on this box
 than have aptitude continue to be borked.  If someone has an elegant
 solution, of course I'm happy to consider that too, but I'd appreciate
 any thoughts (no matter how outrageous/potentially-destructive).
 
 
 
 here's a small snip for those who don't want to follow the link at the top:
 
 
 gconftool-2: symbol lookup error: /usr/lib/libxml2.so.2: undefined
 symbol: gzopen64
 dpkg: error processing capplets-data (--remove):
  subprocess pre-removal script returned error exit status 127
 dpkg: error processing desktop-base (--remove):
  Package is in a very bad inconsistent state - you should
  reinstall it before attempting a removal.
 
 
 and as I pasted this I realized I ought to see where that file comes
 from and the package is libxml2
 
 if I try to do aptitude remove libxml2 the first couple dozen choices
 to resolve dependencies leave it at its current version (and I'm unsure
 whether aptitude might actually give me a better choice if i keep
 clicking n -- it does seem to be able to indefinitely suggest new
 solutions)
 
 if I try to upgrade libxml2 I get this (desktop-base (along with
 shared-mime-info is one of those 5 packages I talked about above (that I
 incorrectly removed the .deb files from my archives directory) :
 
 
 Resolving dependencies...
 E: I wasn't able to locate file for the desktop-base package. This might
 mean you need to manually fix this package.
 The following actions will resolve these dependencies:
 
 Remove the following packages:
 deskbar-applet
 epiphany-extensions
 evince
 evolution
 evolution-common
 evolution-data-server
 evolution-exchange
 gnome-mount
 gnome-power-manager
 gnome-screensaver
 gnome-volume-manager
 nautilus-cd-burner
 rhythmbox
 sound-juicer
 sun-java5-jre
 yelp
 
 Install the following packages:
 bittorrent [3.4.2-11 (unstable, now)]
 fam [2.7.0-13 (unstable)]
 gnome-mime-data [2.18.0-1 (unstable, now)]
 libavahi-glib1 [0.6.21-4 (unstable, now)]
 libbonobo2-0 [2.20.2-1 (unstable, now)]
 libbonobo2-common [2.20.2-1 (unstable, now)]
 libbonoboui2-0 [2.20.0-1 (unstable, now)]
 libbonoboui2-common [2.20.0-1 (unstable)]
 libcamel1.2-10 [1.12.2-1 (unstable, now)]
 libebook1.2-9 [1.12.2-1 (unstable, now)]
 libecal1.2-7 [1.12.2-1 (unstable, now)]
 libedataserver1.2-9 [1.12.2-1 (unstable, now)]
 libgnome-desktop-2 [2.20.2-1 (unstable, now)]
 libgnome2-0 [2.20.1.1-1 (unstable, now)]
 libgnomeui-0 [2.20.1.1-1 (unstable, now)]
 libgnomeui-common [2.20.1.1-1 (unstable)]
 libgnomevfs2-0 [1:2.20.1-1 (unstable, now)]
 libgnomevfs2-extra [1:2.20.1-1 (unstable, now)]
 libgtkhtml3.14-19 [3.16.1-1 (unstable)]
 libnotify1 [0.4.4-3 (unstable, now)]
 libpanel-applet2-0 [2.20.2-2 (unstable, now)]
 libsoup2.2-8 [2.2.104-1 (unstable, now)]
 libwnck-common [2.20.2-1 (unstable)]
 libwnck22 [2.20.2-1 (unstable)]
 libxres1 [2:1.0.3-1 (unstable, now)]
 python-gnome2 [2.20.1-1 (unstable)]
 rdesktop [1.5.0-3+cvs20071006 (unstable)]
 
 Upgrade the following packages:
 gtkhtml3.14 [3.14.2-1 (now) - 3.16.1-1 (unstable)]
 libgnome2-common [2.18.0-4 (now) - 2.20.1.1-1 (unstable)]
 libgnomevfs2-common [1:2.18.1-2 (now) - 1:2.20.1-1 (unstable)]
 notification-daemon [0.3.7-1 (now) - 0.3.7-1+b1 (unstable)]
 
 Leave the following dependencies unresolved:
 libgnomevfs2-0 recommends gnome-mount
 meld recommends yelp
 Score is -4309

Charlie,

In this kind of situation, I would # apt-get --purge remove the
problematic package(s), then # apt-get update and try again.

Of course, I would do all this from the (real) console, not a GNOME
terminal window.

Lastly, I'd *never* use aptitude.

- --
Ron Johnson, Jr.
Jefferson LA  USA

Your mistletoe is no match for my TOW missile.  Santa-bot
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHeS3hS9HxQb37XmcRAjIwAKCW/iF3tZTyruZNQMGV+KPMl2s6YQCfcMI7
tnS6ijJWcztotu27wfMOfRY=
=R6GD

Re: upgrading in sid

2007-12-31 Thread Ron Johnson

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/31/07 11:42, Daniel Burrows wrote:
 On Sun, Dec 30, 2007 at 08:01:32PM -0500, charlie derr [EMAIL PROTECTED] 
 was heard to say:
 The following packages will be upgraded:
   gnome-session libgnome2-common libgnomevfs2-common shared-mime-info
 4 packages upgraded, 0 newly installed, 0 to remove and 795 not upgraded.
 Need to get 0B/2706kB of archives. After unpacking 1461kB will be used.
 Do you want to continue? [Y/n/?] y
 Writing extended state information... Error!
 E: I wasn't able to locate file for the desktop-base package. This might 
 mean you need to manually fix this package.
 E: Couldn't lock list directory..are you root?
 You used apt-get to break the desktop-base package behind aptitude's
 back and that seems to have confused aptitude. I would hope that this
 problem goes away once you have fixed the desktop-base package.

 Thanks again for letting me know that it was my mixing apt-get and aptitude 
 that probably screwed me up.
 
   I don't know any reason that mixing apt-get and aptitude should cause
 problems, particularly this problem.

Don't apt-{get,cache} and aptitude track dependencies in different
manners, using different data stores?

   This is usually a symptom of your
 package lists being out of sync in a weird way: it means that apt
 thought it could download this package, but when it went to actually
 download it no source was providing it.  I expect you would get the same
 error with apt-get as with aptitude.

- --
Ron Johnson, Jr.
Jefferson LA  USA

Your mistletoe is no match for my TOW missile.  Santa-bot
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHeS5KS9HxQb37XmcRAuc1AKDANaBqJ+WliveeawOD38LyLTjKfgCeIN7Y
4C39SnLc8kuETyvsdk9euFE=
=TXyq
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: upgrading in sid

On Mon, Dec 31, 2007 at 12:00:42PM -0600, Ron Johnson [EMAIL PROTECTED] was 
heard to say:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On 12/31/07 11:42, Daniel Burrows wrote:
I don't know any reason that mixing apt-get and aptitude should cause
  problems, particularly this problem.
 
 Don't apt-{get,cache} and aptitude track dependencies in different
 manners, using different data stores?

  No.  Only some aptitude-specific features (like saving your planned
actions and tracking new packages) are tracked outside the apt cache.
In etch this also includes remembering which packages are automatically
installed.

  Daniel


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: upgrading in sid


Daniel Burrows wrote:

On Sun, Dec 30, 2007 at 05:28:48PM -0500, charlie derr [EMAIL PROTECTED] was 
heard to say:

It's been a while, but I just attempted a massive upgrade (executing aptitude 
upgrade) and ended up with:

Errors were encountered while processing:


  The interesting thing is why these packages failed, which would be in
the output preceding the list of failed packages.


i did it in a screen session (which i still have access to).   I'll put that info up somewhere (again there's a ton of output) if 
it's truly important.  For the moment I'm going to concentrate on answering accurately all of your below queries.  And thanks :-]





Unpacking replacement desktop-base ...
gconftool-2: symbol lookup error: /usr/lib/libxml2.so.2: undefined symbol: 
gzopen64
dpkg: warning - old post-removal script returned error exit status 127
dpkg - trying script from the new package instead ...
gconftool-2: symbol lookup error: /usr/lib/libxml2.so.2: undefined symbol: 
gzopen64
dpkg: error processing /var/cache/apt/archives/desktop-base_4.0.4_all.deb 
(--unpack):


  It's pretty clear from that that your problem is that your version of
libxml2 is failing to load because it doesn't contain gzopen64.


yeah, i understood that intuitively, but you rephrased it better than i could


  It would be interesting to know what ldd /usr/lib/libxml2.so.2 says.


[EMAIL PROTECTED]:/var/cache/apt$ ldd /usr/lib/libxml2.so.2
linux-gate.so.1 =  (0xb7fb7000)
libdl.so.2 = /lib/i686/cmov/libdl.so.2 (0xb7e7e000)
libz.so.1 = /usr/local/lib/libz.so.1 (0xb7e6a000)
libm.so.6 = /lib/i686/cmov/libm.so.6 (0xb7e44000)
libc.so.6 = /lib/i686/cmov/libc.so.6 (0xb7cf7000)
/lib/ld-linux.so.2 (0x8000)
[EMAIL PROTECTED]:/var/cache/apt$



Some hits on Google suggest that people get this problem when they have
another version of libz hanging out in $LD_LIBRARY_PATH (e.g., in
/usr/local/lib or /lib).


I didn't intentionally install anything in addition to anything debian did (I definitely didn't recompile my own version of glibc 
or anything else on this box, it's all deb binaries loaded from sid repositories).


echo $LD_LIBRARY_PATH

gets me nothing (both as root and as ni)




The above is in response to   apt-get -f install (what used to work in the past 
for fixing issues, maybe that's my mistake?)


  That ought to work fine.


If I try to upgrade one of those packages individually with   aptitude install 
shared-mime-info then the below happens:

The following packages will be upgraded:
  gnome-session libgnome2-common libgnomevfs2-common shared-mime-info
4 packages upgraded, 0 newly installed, 0 to remove and 795 not upgraded.
Need to get 0B/2706kB of archives. After unpacking 1461kB will be used.
Do you want to continue? [Y/n/?] y
Writing extended state information... Error!
E: I wasn't able to locate file for the desktop-base package. This might mean 
you need to manually fix this package.
E: Couldn't lock list directory..are you root?


  Erk.  That means something is hosed in your apt cache.  I would guess
this isn't related to your earlier problems, but it would be interesting
to know whether running aptitude update fixes this problem, 


it hasn't yet (subsequent upgrades/removals won't all succeed (all of the gnome 
related stuff is foobared)) -- this is why i've


and to see

the output of apt-cache showpkg desktop-base.



i included shared-mime-info as it's also messed up (along with 3 additional gnome packages) and part of the logjam -- and thanks 
very much for helping, this is all greek to me at this point, but it's fun to try to follow along:




delete:~# apt-cache showpkg desktop-base shared-mime-info
Package: desktop-base
Versions:
4.0.4(/var/lib/apt/lists/ftp.us.debian.org_debian_dists_unstable_main_binary-i386_Packages)
4.0.3(/var/lib/dpkg/status)

Reverse Depends:
  nautilus,desktop-base 0.2
  gnome-session,desktop-base
  libgnome2-common,desktop-base 0.3.16
  xfce4-session,desktop-base 0.3.20
  xfce4,desktop-base
  nautilus,desktop-base 0.2
  libgnome2-common,desktop-base 0.3.16
  gnome-session,desktop-base
  gnome-desktop-environment,desktop-base
  gdm-themes,desktop-base 0.3.15
Dependencies:
4.0.4 - librsvg2-common (0 (null)) gnome (16 (null)) kde (16 (null)) xfce4 (16 
(null)) wmaker (0 (null))
4.0.3 - librsvg2-common (0 (null)) gnome (16 (null)) kde (16 (null)) xfce4 (16 
(null)) wmaker (0 (null))
Provides:
4.0.4 -
4.0.3 -
Reverse Provides:
Package: shared-mime-info
Versions:
0.22-2(/var/lib/apt/lists/ftp.us.debian.org_debian_dists_unstable_main_binary-i386_Packages)
0.21-2(/var/lib/dpkg/status)

Reverse Depends:
  nautilus,shared-mime-info
  xdg-utils,shared-mime-info
  libgnomevfs2-common,shared-mime-info
  xlog,shared-mime-info
  xdg-utils,shared-mime-info
  tracker,shared-mime-info
  thunar,shared-mime-info
  rox-filer,shared-mime-info 0.16
  revelation,shared-mime-info
  planner,shared-mime-info
  pcmanfm-nohal,shared-mime-info
  pcmanfm,shared-mime-info

Re: upgrading in sid


Thanks much for the help.


gzopen64 should be defined in /usr/lib/libz.so.1; something is wrong
with this on your system. Post the output of the following commands:

dpkg -l zlib1g

ldd /usr/bin/gconftool-2 | grep libz

ldd /usr/lib/libxml2.so.2 | grep libz

nm -D /usr/lib/libz.so.1 | grep gzopen64


[EMAIL PROTECTED]:/var/cache/apt$ dpkg -l zlib1g
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name  Version   Description
+++-=-=-==
ii  zlib1g1:1.2.3.3.dfsg-8  compression library - runtime
[EMAIL PROTECTED]:/var/cache/apt$
[EMAIL PROTECTED]:/var/cache/apt$ ldd /usr/bin/gconftool-2 | grep libz
libz.so.1 = /usr/local/lib/libz.so.1 (0xb7be)
[EMAIL PROTECTED]:/var/cache/apt$
[EMAIL PROTECTED]:/var/cache/apt$ ldd /usr/lib/libxml2.so.2 | grep libz
libz.so.1 = /usr/local/lib/libz.so.1 (0xb7dc)
[EMAIL PROTECTED]:/var/cache/apt$
[EMAIL PROTECTED]:/var/cache/apt$ nm -D /usr/lib/libz.so.1 | grep gzopen64
3f80 T gzopen64
[EMAIL PROTECTED]:/var/cache/apt$


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: gnome won't uninstall because I messed up dpkg by mixing and matching apt-get and aptitude incorrectly (used to be Re: upgrading in sid)




Charlie,

In this kind of situation, I would # apt-get --purge remove the
problematic package(s), then # apt-get update and try again.



as Daniel and Florian have pointed out elsewhere in this thread, my problem is with libxml2 being completely borken at the moment 
(I think) and aptitude is just showing me the manifestation (because of all the calls to gconftool-2 in postinstall scripts for 
gnome apps and libs).



Of course, I would do all this from the (real) console, not a GNOME
terminal window.


you're just chicken :-]

(i'm still in the same original openbox session I started in a couple days ago (my one concession was to not do this from my usual 
busy (50-100 application windows spread across 4 desktops) KDE session))


i did take the extra step of doing my upgrade from within a screen session 
(inside konsole, not gnome-terminal)



Lastly, I'd *never* use aptitude.


It appears (to me at least) that that's an irrational bias you have there.   I'm going with the debian/GNU party line which says 
aptitude is superior to apt-get in some way (though I still don't think there's a drop-in replacement for apt-get source 
functionality to make aptitude do the right thing, so I would still use apt-get there, but now that i know aptitude install -f 
is the equivalent of apt-get -f install, I really use apt-get for nothing except downloading source packages, aptitude happily 
works just fine (until this event, and I think it was really the number of upgradeable packages I was trying to do at once, and 
the unfortunate circumstance of not reading the apt-listbugs output closely enough to catch that this libxml2 problem was gonna 
bite me)) -- i'm confident it'll get solved though (and if not, a reinstall isn't a huge burden for me).




- --
Ron Johnson, Jr.
Jefferson LA  USA



thanks,
~c


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: upgrading in sid

2007-12-31 Thread Florian Kulzer

On Mon, Dec 31, 2007 at 16:31:37 -0500, charlie derr wrote:
 Thanks much for the help.

 gzopen64 should be defined in /usr/lib/libz.so.1; something is wrong
 with this on your system. Post the output of the following commands:

[...]

 [EMAIL PROTECTED]:/var/cache/apt$ dpkg -l zlib1g

[...]

 ii  zlib1g1:1.2.3.3.dfsg-8  compression library - runtime
 [EMAIL PROTECTED]:/var/cache/apt$
 [EMAIL PROTECTED]:/var/cache/apt$ ldd /usr/bin/gconftool-2 | grep libz
 libz.so.1 = /usr/local/lib/libz.so.1 (0xb7be)
 [EMAIL PROTECTED]:/var/cache/apt$
 [EMAIL PROTECTED]:/var/cache/apt$ ldd /usr/lib/libxml2.so.2 | grep libz
 libz.so.1 = /usr/local/lib/libz.so.1 (0xb7dc)
 [EMAIL PROTECTED]:/var/cache/apt$
 [EMAIL PROTECTED]:/var/cache/apt$ nm -D /usr/lib/libz.so.1 | grep gzopen64
 3f80 T gzopen64

You have the latest version of the zlib1g package, but you also have a
non-Debian libz.so.1 in /usr/local/lib/ (probably an older version
installed together with some non-Debian software). Until September 2007
the default behavior would have been to use the Debian library in
/usr/lib/ (therefore you might not have noticed this problem earlier),
but now the default is for /usr/local/lib/ to take precedence. You have
to get your system to use the proper file when libz.so.1 is needed. 

The most straightforward approach is to delete or to rename
/usr/local/lib/libz.so.1 and to run ldconfig (without arguments as
root). Afterwards you should see something like this:

$ ldconfig -pNX | grep 'libz\.so'
libz.so.1 (libc6,x86-64) = /usr/lib64/libz.so.1
libz.so.1 (libc6) = /usr/lib/libz.so.1
libz.so (libc6) = /usr/lib/libz.so
$ ldd /usr/lib/libxml2.so.2 | grep libz
libz.so.1 = /usr/lib/libz.so.1 (0xb7e43000)

This tells you that /usr/lib/libz.so.1 will be used from now on, and we
already verified that this one has gzopen64 defined (the nm ...
command above). This should allow you to (un)install all the currently
broken packages.

If you need to keep /usr/local/lib/libz.so.1 then you have to set
LD_LIBRARY_PATH to make sure that /usr/lib/ has a higher priority than
/usr/local/lib/. I would advise not to keep alternate versions of
Debian-provided libraries around, at least not if they have the same
soname. If you want to check which other local libraries might cause
problems in the future, you can run:

ldconfig -pNX | grep local

-- 
Regards,| http://users.icfo.es/Florian.Kulzer
  Florian   |


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: upgrading in sid




ii  zlib1g1:1.2.3.3.dfsg-8  compression library - runtime
[EMAIL PROTECTED]:/var/cache/apt$
[EMAIL PROTECTED]:/var/cache/apt$ ldd /usr/bin/gconftool-2 | grep libz
libz.so.1 = /usr/local/lib/libz.so.1 (0xb7be)
[EMAIL PROTECTED]:/var/cache/apt$
[EMAIL PROTECTED]:/var/cache/apt$ ldd /usr/lib/libxml2.so.2 | grep libz
libz.so.1 = /usr/local/lib/libz.so.1 (0xb7dc)
[EMAIL PROTECTED]:/var/cache/apt$
[EMAIL PROTECTED]:/var/cache/apt$ nm -D /usr/lib/libz.so.1 | grep gzopen64
3f80 T gzopen64


You have the latest version of the zlib1g package, but you also have a
non-Debian libz.so.1 in /usr/local/lib/ (probably an older version
installed together with some non-Debian software). Until September 2007
the default behavior would have been to use the Debian library in
/usr/lib/ (therefore you might not have noticed this problem earlier),
but now the default is for /usr/local/lib/ to take precedence. You have
to get your system to use the proper file when libz.so.1 is needed. 


The most straightforward approach is to delete or to rename
/usr/local/lib/libz.so.1 and to run ldconfig (without arguments as
root). Afterwards you should see something like this:

$ ldconfig -pNX | grep 'libz\.so'
libz.so.1 (libc6,x86-64) = /usr/lib64/libz.so.1
libz.so.1 (libc6) = /usr/lib/libz.so.1
libz.so (libc6) = /usr/lib/libz.so



[EMAIL PROTECTED]:~$ /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
[EMAIL PROTECTED]:~$

I'm not aware of ever intentionally doing anything to install any 64bit libs.  
My whole system is running as 32-bit.



$ ldd /usr/lib/libxml2.so.2 | grep libz
libz.so.1 = /usr/lib/libz.so.1 (0xb7e43000)



[EMAIL PROTECTED]:~$ ldd /usr/lib/libxml2.so.2 | grep libz
libz.so.1 = /usr/local/lib/libz.so.1 (0xb7e83000)





This tells you that /usr/lib/libz.so.1 will be used from now on, and we
already verified that this one has gzopen64 defined (the nm ...
command above). This should allow you to (un)install all the currently
broken packages.


I think I'd like to understand why this first attempt didn't work.


aptitude is still very broken, full output here at 
http://www.assembla.com/wiki/show/door/AptitudeUpgradeStillFailing






If you need to keep /usr/local/lib/libz.so.1 then you have to set
LD_LIBRARY_PATH to make sure that /usr/lib/ has a higher priority than
/usr/local/lib/. I would advise not to keep alternate versions of
Debian-provided libraries around, at least not if they have the same
soname. If you want to check which other local libraries might cause
problems in the future, you can run:

ldconfig -pNX | grep local



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?

thanks again,
~c





--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: upgrading in sid

On Mon, Dec 31, 2007 at 03:59:16PM -0500, charlie derr [EMAIL PROTECTED] was 
heard to say:
 Daniel Burrows wrote:
   It would be interesting to know what ldd /usr/lib/libxml2.so.2 says.

 [EMAIL PROTECTED]:/var/cache/apt$ ldd /usr/lib/libxml2.so.2
 linux-gate.so.1 =  (0xb7fb7000)
 libdl.so.2 = /lib/i686/cmov/libdl.so.2 (0xb7e7e000)
 libz.so.1 = /usr/local/lib/libz.so.1 (0xb7e6a000)
  ^^

  You may not know it's there, but you have a local version of libz.so.1
that isn't binary-compatible with the Debian-supplied libz.  You're
probably better off just deleting this (or moving it to some other name,
like was-libz.1); as it is, you risk random breakage and security holes
(because you probably aren't getting security updates for your local
version of the library).

  You may want to check if anything else has been placed in
/usr/local/bin or /usr/local/lib, and what the timestamps are (run
ls -l /usr/local/bin /usr/local/lib), as any other files in there
will override the system libraries.

  

   Erk.  That means something is hosed in your apt cache.  I would guess
 this isn't related to your earlier problems, but it would be interesting
 to know whether running aptitude update fixes this problem, 

 it hasn't yet (subsequent upgrades/removals won't all succeed (all of the 
 gnome related stuff is foobared)) -- this is why i've

  Huh, interesting.

 delete:~# apt-cache showpkg desktop-base shared-mime-info
 Package: desktop-base
 Versions:
 4.0.4(/var/lib/apt/lists/ftp.us.debian.org_debian_dists_unstable_main_binary-i386_Packages)
 4.0.3(/var/lib/dpkg/status)

  OK, apt believes that version 4.0.4 is available from unstable.  But
when it goes to actually install that version, it apparently blows up,
complaining that no file in the archive actually provides version 4.0.4.
At least, that's how I interpret that message
(pkgAcqArchive::pkgAcqArchive generates it if QueueNext
fails)...although from the source it looks like there are a few other
things it could be caused by, such as unusual trust errors.  You didn't
mention trust problems, though, so I assume that's not what's happening.

  I wonder what these commands will show:

grep -A 1000 ^Package: desktop-base$ 
/var/lib/apt/lists/ftp.us.debian.org_debian_dists_unstable_main_binary-i386_Packages
 | sed '/^$/,$d'

apt-cache policy desktop-base

apt-get -s install desktop-base

apt-get -s install desktop-base=4.0.4

aptitude -s install desktop-base=4.0.4

aptitude - show desktop-base

  Actually, if you have a way to post large files on the internet, it
would be interesting if you could run
aptitude-create-state-bundle snapshot.tar.bz2 and then let me know how
to get access to it; then I might be able to reproduce your problems
here and find out exactly what's happening.

  Daniel


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: upgrading in sid

On Mon, Dec 31, 2007 at 04:02:01PM -0800, Daniel Burrows [EMAIL PROTECTED] 
was heard to say:
   You may want to check if anything else has been placed in
 /usr/local/bin or /usr/local/lib, and what the timestamps are (run
 ls -l /usr/local/bin /usr/local/lib), as any other files in there
 will override the system libraries.

  Just to clarify, the reason for checking the timestamps is that it
might give you a notion of when and why the files were created.

  Daniel


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: upgrading in sid

2007-12-31 Thread Florian Kulzer

On Mon, Dec 31, 2007 at 18:34:55 -0500, charlie derr wrote:

[...]

 [EMAIL PROTECTED]:~$ /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
 [EMAIL PROTECTED]:~$

 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.

[...]

 [EMAIL PROTECTED]:~$ 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. 

-- 
Regards,| http://users.icfo.es/Florian.Kulzer
  Florian   |


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: upgrading in sid