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.
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. ;)
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.
(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.
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.
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?
See also bug 127470 and bug 128065.
(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.
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.
I'm having the same problem. revdep-rebuild didn't fix it for me, nor did downgrading expat.
you can try to rebuild fontconfig, this will solve most problems.
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.
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...
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.
(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?
(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
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?
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.
(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
(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
(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
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.
(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.
> 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.
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.
(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
(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...
>> 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.
(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.
> 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.
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.
"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...
(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.
(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.
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...
(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)
(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.
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.
*** Bug 130116 has been marked as a duplicate of this bug. ***
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.
(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.
Released in gentoolkit-0.2.2
Here is what happened to me: kdebase reemerged: Not working kdelibs reemerged: Not working kdebase reemerged (once more): Working
