Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 128108 - KDE broken after expat upgrade and revdep-rebuild
Summary: KDE broken after expat upgrade and revdep-rebuild
Status: RESOLVED FIXED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Tools (show other bugs)
Hardware: All Other
: High normal (vote)
Assignee: Portage Tools Team
URL:
Whiteboard:
Keywords: InVCS
: 130116 (view as bug list)
Depends on: 128085
Blocks:
  Show dependency tree
 
Reported: 2006-03-30 07:03 UTC by Cristiano Chiucchiolo
Modified: 2006-09-11 06:32 UTC (History)
17 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Cristiano Chiucchiolo 2006-03-30 07:03:58 UTC
After upgrading expat to version 2.0.0 I run revdep-rebuild, which re-emerged the whole KDE.

Now when I login I see the splashscreen, but after that I only have the blue background, with no icon and no possibility to click anywhere.

I tried to run revdep-rebuild once again and I noticed that various KDE binaries and libraries were still marked as broken (needing libexpat.so.0), but at the end of the check no package was emerged.
Comment 1 Jakub Moc (RETIRED) gentoo-dev 2006-03-30 07:06:48 UTC
Please, see Bug 128085 if it describes the issue you have w/ revdep-rebuild. If so, note here, if not, note here anyway and reopen. ;)
Comment 2 Cristiano Chiucchiolo 2006-03-30 07:15:38 UTC
Well, I don't think it's the same issue...
The first time I run revdep-rebuild --library libexpat.so.0 and everything worked correctly (or at least so it seemed) and all KDE was re-emerged.
The problem is that after re-emerging KDE still seemed to be broken, as I described above.
At this point I tried to just run revdep-rebuild once again and I had the problem decribed in bug #128108

Maybe the two issues are linked, but I don't know exactly.

Comment 3 Jakub Moc (RETIRED) gentoo-dev 2006-03-30 07:20:07 UTC
(In reply to comment #2)
> At this point I tried to just run revdep-rebuild once again and I had the
> problem decribed in bug #128108
> 
> Maybe the two issues are linked, but I don't know exactly.

Well, if revdep-rebuild finds broken stuff, it should assign it to ebuilds and re-emerge them. Doesn't happen here, so it's IMHO a duplicate, but leaving this up to maintainer. 
Comment 4 Paul Taylor 2006-03-30 10:12:43 UTC
Confirmed.  revdep-rebuild found and rebuilt the affected packages (about 74 in my case), and running it again found no more packages to rebuild.

My .xsession-errors file reports that various KDE libraries are still trying to access libexpat.so.0; manually rebuilding those packages (kdesktop, kicker, kcontrol etc.) didn't fix the problem.  This may indicate there is a deeper dependency on libexpat.so.0 that revdep-rebuild missed, though I'm not sure how to find it.
Comment 5 Cristiano Chiucchiolo 2006-03-30 11:19:19 UTC
The worst thing is that I can't even downgrade to expat 1.9.5, because revdep-rebuild doesn't rebuild anything after this. What can I do?
Comment 6 Joe Wells 2006-03-30 13:41:24 UTC
See also bug 127470 and bug 128065.
Comment 7 Jakub Moc (RETIRED) gentoo-dev 2006-03-30 13:51:36 UTC
(In reply to comment #5)
> The worst thing is that I can't even downgrade to expat 1.9.5, because
> revdep-rebuild doesn't rebuild anything after this. What can I do?

You sure can downgrade just fine, that's unrelated to revdep-rebuild. You also won't need to run revdep-rebuild at all unless you've already re-emerged some of the apps against the new expat version.

Comment 8 Paul Taylor 2006-03-30 14:43:15 UTC
A quick and dirty way to find the libraries that need rebuilding (which revdep-rebuild missed) is to run:
   find /usr/kde/3.5/lib -type f -exec fgrep -l libexpat.so.0 {} \;
(There's probably a more elegant way to do this, but it worked for me.)

Use "equery belongs ..." to identify the owning packages and manually re-emerge them.
Comment 9 Nicholas Doyle 2006-03-30 15:46:53 UTC
I'm having the same problem.
revdep-rebuild didn't fix it for me, nor did downgrading expat.
Comment 10 younker 2006-03-30 15:51:00 UTC
you can try to rebuild fontconfig, this will solve most problems. 
Comment 11 Nicholas Doyle 2006-03-30 15:55:32 UTC
Already tried rebuilding fontconfig. No dice. For now I have made the a symlink to libexpat.so.1.5.0 to satisfy the need for libexpat.so.0. I have absolutely no idea if it is supposed to work but my apps are at least starting now.
Comment 12 manolis 2006-03-31 10:43:22 UTC
I made a symlink to libexpat.so.1 too, to load my kde desktop... 
This is not a solution, but as a workaround there are no issues for now...
Comment 13 Shaw 2006-03-31 10:51:45 UTC
I'm experiencing the same problem as Cristiano.  The first revdep-rebuild worked fine and rebuilt a ton of stuff (all of kde).  After a reboot I was unable to get farther than the kde splash screen after entering my login.  The .xsession_errors file in my home directory has all sorts of errors about libexpat and it being the wrong type- ELF32, I'm doing the compile on AMD64.  revdep-rebuild reports a ton of broken packages, but it doesn't want to fix any of it, except for the binary openoffice package.  From reading the other bugs, I understand revdep-rebuild is hosed because of the libexpat upgrade.  Doing an equery belongs on all the broken packages will take all weekend, and with no guarantee of it working (ie, revdep-rebuild did rebuild all the broken packages before with the new version of libexpat), it doesn't seem quite worth it.  But I'm out of other ideas as rebuilding fontconfig and XML::Parser didn't help.

I'm happy to test any ideas anyone has.  Will have to wait until tomorrow to test, as I'm at work now.
Comment 14 Shaw 2006-03-31 10:52:32 UTC
(In reply to comment #12)
> I made a symlink to libexpat.so.1 too, to load my kde desktop... 
> This is not a solution, but as a workaround there are no issues for now...
> 

From where to where?
Comment 15 manolis 2006-03-31 10:55:00 UTC
(In reply to comment #14)
> (In reply to comment #12)
> > I made a symlink to libexpat.so.1 too, to load my kde desktop... 
> > This is not a solution, but as a workaround there are no issues for now...
> > 
> 
> From where to where?
> 

ln -s /usr/lib/libexpat.so.1 /usr/lib/libexpat.so.0
Comment 16 Howard B. Golden 2006-03-31 20:51:24 UTC
Question: Why can't the slot on expat-2.0 be changed to 1? Then libexpat-so.0 will stay around.

I've re-emerged expat-1.95.8 and then emerged expat-2.0 with the ebuild modified to be slot 1. Isn't this situation what slots are for, or am I missing something?
Comment 17 Shaw 2006-03-31 21:59:50 UTC
Howard-- if you had the problem documented here and were able to fix it using slots, please give steps to fix, or a url explaining slots for the less fortunate.
Thanks.
Comment 18 Howard B. Golden 2006-03-31 23:12:56 UTC
(In reply to comment #17) Shaw, I edited the expat-2.0 ebuild. There is a line:
  SLOT="0"
I changed it to:
  SLOT="1"
Then I re-emerged expat-1.95.8. This brought back libexpat.so.0.
When I emerged expat-2.0 (using the modified ebuild), it didn't remove libexpat.so.0. The new libexpat.so.1 was created. Now I have both libraries. Old compilations will still use libexpat.so.0 and new ones will use libexpat.so.1.

I think the above works. It certainly fixes all the problems caused by removing libexpat.so.0.

I was asking the question about whether this is the solution. I'm not sure, and I hope someone who understands slots better will comment.

You can read about slots at http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1

Hope this helps.

Howard
Comment 19 Jakub Moc (RETIRED) gentoo-dev 2006-04-01 00:33:04 UTC
(In reply to comment #16)
> Question: Why can't the slot on expat-2.0 be changed to 1? Then libexpat-so.0
> will stay around.
> 
> I've re-emerged expat-1.95.8 and then emerged expat-2.0 with the ebuild
> modified to be slot 1. Isn't this situation what slots are for, or am I missing
> something?

See Bug 127470, Comment #16  

Comment 20 Howard B. Golden 2006-04-01 01:18:49 UTC
(In reply to comment #19)

> See Bug 127470, Comment #16  
 
Jakub, with all due respect, I don't find the _possibility_ of confusion caused by multiple versions of libexpat to be as important as the _certainty_ of system breakage caused by removing libexpat.so.0. The approach referred to in Bug 127470, Comment #15 of keeping the old library around until the revdep-rebuild is finished sounds safer to me.

You say that "we've" discussed this already. Please provide a link so I can read the discussion. Thanks.

Respectfully,

Howard
Comment 21 Cristiano Chiucchiolo 2006-04-01 01:24:41 UTC
I solved the problem by emerging manually the packages that revdep-rebuild doesn't emerge.

I used "equery belongs" to see which packages contained the broken binaries and libraries and then I emerged those packages.
Comment 22 Jakub Moc (RETIRED) gentoo-dev 2006-04-01 01:31:22 UTC
(In reply to comment #20)
> (In reply to comment #19)
> 
> > See Bug 127470, Comment #16  
> 
> Jakub, with all due respect, I don't find the _possibility_ of confusion caused
> by multiple versions of libexpat to be as important as the _certainty_ of
> system breakage caused by removing libexpat.so.0. The approach referred to in
> Bug 127470, Comment #15 of keeping the old library around until the
> revdep-rebuild is finished sounds safer to me.

No... see, most of the affected applications do not depend on expat at all. They just link against it unless you use something like --as-needed in LDFLAGS.  There's no predictible way to say that they won't get linked against both versions once they are installed, which would result in much more cryptic bugs. 

This problem is expected, can be easily diagnosed and fixed by re-emerging the affected ebuilds against the new expat version. Not so for the cases mentioned above.

> You say that "we've" discussed this already. Please provide a link so I can
> read the discussion. Thanks.

This has been discussed among the developers on IRC and decision has been made that this cannot be safely slotted.
Comment 23 moesasji 2006-04-01 05:23:04 UTC
> This problem is expected, can be easily diagnosed and fixed by re-emerging the
> affected ebuilds against the new expat version. Not so for the cases mentioned
> above.

Apparantly this problem was expected by the devs...but I failed to see the warnings. Running a testing branch borking my system can happen, I accept that. 

However I have to say that I really don't like it that it becomes nearly impossible to use my system for something that looks like a minor upgrade. 
(I never heard of "expat" and as such didn't expect so much problems)

Yes it is probably fixed after running a revdep-rebuild. But in my case recompiling 56 packages including things like kdelibs, ooffice, and the like takes a lot of time, probably a day or more. As such please make sure that users get properly informed before this is going to hit the stable branch. 

My personal recommendation would be to find a work-around so that libexpat.so.0 remains on the system until revdep-rebuild is finished so that people in stable-branch don't get bitten as bad as I was. If I would run stable this would have been unacceptable. 
Comment 24 Jakub Moc (RETIRED) gentoo-dev 2006-04-01 05:26:36 UTC
OK, everyone who has nothing *on-topic* to say, please don't comment at all. This bug is not here to moan.

(In reply to comment #23)
> My personal recommendation would be to find a work-around so that libexpat.so.0
> remains on the system until revdep-rebuild is finished so that people in
> stable-branch don't get bitten as bad as I was. If I would run stable this
> would have been unacceptable. 

I've already explained above why this won't be done, read the bug. 
Comment 25 Skander Morgenthaler 2006-04-01 07:48:02 UTC
(In reply to comment #22)

> This problem is expected, can be easily diagnosed and fixed by re-emerging the
> affected ebuilds against the new expat version. Not so for the cases mentioned
> above.

Alas, at least for me is not true in the case of kde. Anything else just runs fine after re-emerging the suggested packages, but most kde (3.5.2) packages link against libexpat.so.0 even if it is not present. This includes essential packages of kde as kicker (resultung in missing taskbar, menues etc.) and often used packages like konqueror or kmail. Emerging knode-3.5.2 (and most other kde programms) displays messages like "libexpat.so.0: Kann die Shared-Object-Datei nicht 
Comment 26 Skander Morgenthaler 2006-04-01 07:48:02 UTC
(In reply to comment #22)

> This problem is expected, can be easily diagnosed and fixed by re-emerging the
> affected ebuilds against the new expat version. Not so for the cases mentioned
> above.

Alas, at least for me is not true in the case of kde. Anything else just runs fine after re-emerging the suggested packages, but most kde (3.5.2) packages link against libexpat.so.0 even if it is not present. This includes essential packages of kde as kicker (resultung in missing taskbar, menues etc.) and often used packages like konqueror or kmail. Emerging knode-3.5.2 (and most other kde programms) displays messages like "libexpat.so.0: Kann die Shared-Object-Datei nicht öffnen: Datei oder Verzeichnis nicht gefunden" (cannot open the shared object file, not found) but they nevertheless compile without an error. 

When starting those applications, they exit with the following error: "knode: error while loading shared libraries: libexpat.so.0: cannot open shared object file: No such file or directory".

No, there was no link from libexpat.so.0 to libexpat.so.1 present at compile time, and while that link does make kde (and applications) run, it seems not as stable on my system, as many applications seem to run significantly slower. I am on amd64 btw.

revdep-rebuild as noted by the original reporter showed a complete list of kde the first time, and after re-emerging those packages still showed many broken libraries but does not want to re-emerge anything besides openoffice. But recompiling them again seems a waste of time anyway...
Comment 27 genbug 2006-04-01 09:49:20 UTC
>> OK, everyone who has nothing *on-topic* to say, please don't comment at all.
>> This bug is not here to moan.

I dont see any moaning . What I see and second is a request (ie a positive suggestion to improve gentoo) that this problem be properly flagged.

Clearly is was an expected issue yet this bug was allowed to propagate without even a warning being emmitted at the end of the ebuild.

This means users have to wait until they try to update some other package , get a cryptic message and then start search the forums and bugzilla.

Wouldn't it save everybody's time, including those having to deal with the bug reports , if a simple message was added to the ebuild?

Had this been thought though and a clear message output this bug report would not even exist. 

I cant see that suggestion as anything but *on topic*.

Please could something like that be implemented.

regards.
Comment 28 Jakub Moc (RETIRED) gentoo-dev 2006-04-01 09:59:45 UTC
(In reply to comment #26)
> Clearly is was an expected issue yet this bug was allowed to propagate without
> even a warning being emmitted at the end of the ebuild.

Maybe you need to read better?

<snip>
pkg_postinst() {
        ewarn "Please note that the soname of the library changed!"
        ewarn "If you are upgrading from a previous version you need"
        ewarn "to fix dynamic linking inconsistencies by executing:"
        ewarn "revdep-rebuild --library libexpat.so.0"
}
<snip>

> Wouldn't it save everybody's time, including those having to deal with the bug
> reports , if a simple message was added to the ebuild?

See above.

> Had this been thought though and a clear message output this bug report would
> not even exist. 

See above.

> I cant see that suggestion as anything but *on topic*.
> 
> Please could something like that be implemented.

See above.

Now - everyone please stop making useless noise on this bug? This bug is about KDE breakage after expat upgrade that isn't fixed by revdep-rebuild *ONLY*. Everything else goes to /dev/null, seriously.
Comment 29 Alec Warner archtester Gentoo Infrastructure gentoo-dev Security 2006-04-01 10:27:40 UTC
> See above.
> 
> Now - everyone please stop making useless noise on this bug? This bug is about
> KDE breakage after expat upgrade that isn't fixed by revdep-rebuild *ONLY*.
> Everything else goes to /dev/null, seriously.
> 

If by /dev/null you mean the relevant mailing list ( either gentoo-user or gentoo-dev ) then I would agree.  An expat upgrade guide may need to be created, however it's part of an issue when you run a source based distro.  I'm sorry it sucks, but thems the breaks.  The package will not be slotted, we have developers looking at alternatives ( making sure portage doesn't unmerge libraries that we know things link against, for example, which would prevent this breakage ).  However our job is not to add hacks to prevent breakage, but instead to inform you of it and give you the tools to fix/get through it.  However this is not stable; ~arch breakage is to be expected, even if for X amount of time it worked fine for you.
Comment 30 Shaw 2006-04-01 11:19:08 UTC
In response to Jakob's comment #27.  Does the warning message you quote cause the upgrade to stop after it is displayed?  If I do an emerge -Du world, will the message be displayed and continue, or will the upgrade stop?  I don't remember it stopping, and I certainly wasn't watching the screen the whole time during the compilation of kde and other tools.  But, maybe it did stop, and I missed it?

In any event, the behavior is unacceptable.  If an upgrade breaks something, and revdep --rebuild must be performed, it should be done so _automatically_, not with a warning message and certainly not with a warning message that allows the system to complete the upgrade, if that is indeed the case.  Those of us here arguing against this type of breakage are spending valuable time trying to make gentoo better and greatly appreciate the work of the developers that do the real work.  

Gentoo users may be smarter than the average bear, but we're still users who expect our software to behave reasonably.  An upgrade that breaks unsere boxen is hardly reasonable.
Comment 31 giggles1 2006-04-01 11:24:09 UTC
"Now - everyone please stop making useless noise on this bug? This bug is about
KDE breakage after expat upgrade that isn't fixed by revdep-rebuild *ONLY*.
Everything else goes to /dev/null, seriously."

Well then let me add some more. I cannot rebuild any of the KDE stuff after an expat upgrade. The configures fail, complaining that kde-config needs expat. So I thought, I'll re-emerge kdelibs by hand first (why didn't revdep-reuild want to do this??) but this fails as well. Fixing the problem is not "as simple as a revdep-rebuild" when things won't built at all after an expat upgrade.  In the mean time I have downgraded expat and rebuilt everything against the old version. I am floored that upgrading this nothing library can be such a disaster... 

Comment 32 Jakub Moc (RETIRED) gentoo-dev 2006-04-01 11:40:50 UTC
(In reply to comment #29)
> In response to Jakob's comment #27.  Does the warning message you quote cause
> the upgrade to stop after it is displayed?  If I do an emerge -Du world, will
> the message be displayed and continue, or will the upgrade stop?  I don't
> remember it stopping, and I certainly wasn't watching the screen the whole time
> during the compilation of kde and other tools.  But, maybe it did stop, and I
> missed it?

No, it doesn't stop and it won't stop in future, ever. That breaks compile chain for no reason and is completely inacceptable. Please, stop suggesting irrelevant solutions here, this bug is NOT about such stuff. Even if you aren't watching the screen, you still have the option of using ELOG features in portage 2.1 or a third-party tool like enotice for portage 2.0.

> In any event, the behavior is unacceptable.  If an upgrade breaks something,
> and revdep --rebuild must be performed, it should be done so _automatically_,
> not with a warning message and certainly not with a warning message that allows
> the system to complete the upgrade, if that is indeed the case.  

No, we won't be running revdep-rebuild from within ebuilds, and see above.

> Gentoo users may be smarter than the average bear, but we're still users who
> expect our software to behave reasonably.  An upgrade that breaks unsere boxen
> is hardly reasonable.

Don't run ~arch if you cannot stand such breakage. And honestly, as this happens all the time with source-based distros when ABI of a widely used package changes, you probably are better off looking for some alternatives if you find this completely unacceptable.

Last time - everyone who feels the urge to post off-topic comments, move your debate to appropriate mailing list/forums (or /dev/null if you wish) and stop poluting this bug. 95% of comments starting from Comment #15 are irrelevant wrt this bug. This is NOT a discussion forum.
Comment 33 Jakub Moc (RETIRED) gentoo-dev 2006-04-01 11:53:47 UTC
(In reply to comment #30)
> Well then let me add some more. I cannot rebuild any of the KDE stuff after an
> expat upgrade. The configures fail, complaining that kde-config needs expat. So
> I thought, I'll re-emerge kdelibs by hand first (why didn't revdep-reuild want
> to do this??) but this fails as well. Fixing the problem is not "as simple as a
> revdep-rebuild" when things won't built at all after an expat upgrade. 

I just tried here and it did rebuild kdelibs just fine. If you have problems, start w/ re-emerging fontconfig (which revdep-rebuild emerged as the first one here anyway, so again, not enough information provided). 

We also cannot fix the issue you've just described above unless you give us necessary information, like the order of packages that revdep-rebuild produced.
Comment 34 manolis 2006-04-01 12:08:03 UTC
don;t blame revdep-rebuild without research first. Obviously it is not a revdep-rebuild problem  that ALL kde packages are hard coded with the libexpat.so.0 dependency...
Comment 35 Will Briggs 2006-04-02 15:14:51 UTC
(In reply to comment #33)
> don;t blame revdep-rebuild without research first. Obviously it is not a
> revdep-rebuild problem  that ALL kde packages are hard coded with the
> libexpat.so.0 dependency...
> 

Comments in https://bugs.gentoo.org/show_bug.cgi?id=128442 concur with you.
(And there seems to be a lot of duplication between this bug and that)
Comment 36 Skander Morgenthaler 2006-04-03 03:36:35 UTC
(In reply to comment #34)

> Comments in https://bugs.gentoo.org/show_bug.cgi?id=128442 concur with you.
> (And there seems to be a lot of duplication between this bug and that)

Thanks for pointing to that bug. By looking at the output of revdep-rebuild with double slashes, finding and re-emerging the corresponding packages, I got my whole kde working again.
Comment 37 Jakub Moc (RETIRED) gentoo-dev 2006-04-03 14:06:07 UTC
 03 Apr 2006; Paul Varner <fuzzyray@gentoo.org>
  +gentoolkit-0.2.2_pre4.ebuild:
  Updated revdep-rebuild with fixes for bugs exposed by expat ABI change.

Everyone here, please emerge --sync and test gentoolkit-0.2.2_pre4 - should fix this issue.
Comment 38 Carsten Lohrke (RETIRED) gentoo-dev 2006-04-16 08:06:29 UTC
*** Bug 130116 has been marked as a duplicate of this bug. ***
Comment 39 James Laver 2006-05-11 15:30:22 UTC
I've been having the same problem, but with some additional revdep-rebuild problems

revdep-rebuild --library=libexpat.so.0

I get an error about an invalid package atom. Turns out it was creating an atom like this in the middle of the list of things it sent to emerge

=kde-base/kdelibs-3.5.2-r4USE="-legacyssl%"

Obviously the error stands out to me as easy to correct. but if you don't have a working installation with X on another partition and you aren't adept at using screen, then frankly you're buggered as far as c/ping the broken emerge over and adding a single space is concerned.
Comment 40 Jakub Moc (RETIRED) gentoo-dev 2006-05-11 15:36:03 UTC
(In reply to comment #38)
> I get an error about an invalid package atom. Turns out it was creating an atom
> like this in the middle of the list of things it sent to emerge
> 
> =kde-base/kdelibs-3.5.2-r4USE="-legacyssl%"

Completely unrelated, don't mix stable gentoolkit and unstable portage.
Comment 41 Paul Varner (RETIRED) gentoo-dev 2006-06-19 20:33:16 UTC
Released in gentoolkit-0.2.2
Comment 42 k.s.matheussen 2006-07-31 04:47:05 UTC
Here is what happened to me:

kdebase reemerged: Not working
kdelibs reemerged: Not working
kdebase reemerged (once more): Working