Gnome 2.18 - stable, the next few days

Leio · Posted: Mon Aug 13, 2007 11:22 am Post subject:

To summarize it once again:

If you do not use revdep-rebuild -X you are going to get a lot more trouble than by using it.
And we mean that when we say that in all kinds of ewarn's, forum posts, upgrade guides...
The -X will allow revdep-rebuild to upgrade while rebuilding a package, not just rebuilding the old package and then you have to also upgrade later - this is a waste of time, use -X.
Secondly, -X allows revdep-rebuild to do a better ordering, because when it passes the list to emerge, emerge will see the upgrade instead of a specific old version, and be able to order it better due to that. Which means all this pango and whatever problem hopefully wouldn't happen because pango will be rebuilt AND upgraded much earlier in the list as without -X.
Also, http://www.gentoo.org/proj/en/desktop/gnome/howtos/gnome-2.18-upgrade.xml now contains information about this.
Furthermore, you might want to use revdep-rebuild -X without the --library argument after upgrading curl too. That has some ABI breakage as well. So upgrade expat AND curl and then "revdep-rebuild -X", thank you for reading this and sorry for the pain, but you really want a new expat for all the coolness (and performance/memory fixes) in it

Update: So a perfect way to handle this could be the following:

xavier10 · Posted: Mon Aug 13, 2007 11:23 am Post subject:

maxheadroom · n00b Joined: 17 Feb 2004 Posts: 20

xavier10 · Posted: Mon Aug 13, 2007 12:19 pm Post subject:

xavier10 · Posted: Mon Aug 13, 2007 12:27 pm Post subject:

Herr_Wan · n00b Joined: 03 Jun 2007 Posts: 1

Just for info, I had to recompile heliodor on amd64 because it was not working anymore :

heliodor[6381]: segfault at 0000000000000000 rip 0000000000000000 rsp 00007fffcd49e710 error 14

emerge -C heliodor && emerge heliodor

Cheers
r1
_________________
http://thiscow.eu

iandoug · Posted: Mon Aug 13, 2007 2:13 pm Post subject:

roderick · Posted: Mon Aug 13, 2007 3:36 pm Post subject:

This topic spells it all out clearly on what needs to be done:

http://forums.gentoo.org/viewtopic-t-575655.html

Most of the issues are around the following packages:

gettext, XML-Parser, fontconfig, pango, gtk+

Basically, you need to emerge the expat update first, then those packages above and then do the revdep-rebuild -X.
_________________
If God were a pickle, I'd still say "no pickle on my burger".
http://roderick-greening.blogspot.com/

iandoug · Posted: Tue Aug 14, 2007 2:39 am Post subject:

juniper · l33t Joined: 21 Oct 2004 Posts: 655 Location: EU

I just had a minor ordeal with this as well, however it all seems good.

basically, after reading all this I had to do a series of revdep-rebuild, revdep-rebuild -X, etc etc

juniper · l33t Joined: 21 Oct 2004 Posts: 655 Location: EU

actually, i do have a problem now. my wireless card doesn't work!!! Argh!!! how did this happen!!!

i have a ipw2200 and if i modprobe it takes about 5 seconds, exits and nothing happens. the output of dmesg is

mdmnchr · n00b Joined: 05 Jun 2003 Posts: 51

xavier10 · Posted: Wed Aug 15, 2007 3:56 am Post subject:

Trying again to emerge random stuff taken in the result of 'revdep-rebuild -pX' did not fix it for me. Most ebuilds would fail to emerge due to 'libexpat.0.so missing'. Now this raises a question for me: what does it mean that libexpat.0.so is missing, when I see that other people can get the same package to build ? I mean: if I see that pango does not build for me but builds for someone else, it means that the dependence on libexpat.0.so can only be indirect, right ?
Now, if I try to build all the packages pango does depend on, with no problem, then it should prove that there is no indirect dependence ? Or what ? would it mean a there is a deeper dependences that is not satisfied ? but then, should it not be among the direct dependences of pango ?

Well, anyway, I am ashamed to admit it: I did do the symbolic link fix, that I agree nobody should even think about doing. But at least, now some of my applications seem to work. (Nota bene: I am developping some stuff with lablgtk, and was not even able to run my own software due to the breakage of gtk; now, at least I can use my computer to actually work).

I want to limit the consequences of that regretable decision, so I guess I should remove the symbolic link when I do emerge packages (rarely now, since I got badly burnt this week) and re create it when I switch to "now I use my computer mode". Oh yes, and I will not complain when applications that were broken to libexpat now fail, since that will likely be the source of the problem. Does this seem reasonable ?

(I know this should not be done, but I see it as my last hope to resume work now)

Henno · n00b Joined: 14 Nov 2002 Posts: 29 Location: Germany

xavier10 · Posted: Wed Aug 15, 2007 7:50 am Post subject:

iandoug · Posted: Wed Aug 15, 2007 8:01 am Post subject:

BoneKracker · Guru Joined: 14 Mar 2006 Posts: 585

I guess I got lucky. I was able to upgrade an x86 and a ppc without major issues. As best I can recall...

emerge -uavDN world first broke saying it needed the XML-parser perl module. So I emerged (oneshot) it.
Then it broke saying it needed a related module, so I emerged (oneshot) it.

emerge -uavDN world then broke on something linking to expat. Seeing that was one of the packages to be upgraded (but that it was later in the order) I separately emerged it. It provided the instruction to revdep-rebuild -X --library (etc.), so I did that.

Then I resumed the -uavDN world, which completed fine. Normal cleanup caught a few more things.

I do agree with xavier10 that better communication about this would have helped.

When I saw all the 2.18 packages show up in my updates, I decided to wait 2-3 days (just from experience that there are always a couple housekeeping glitches and these get cleaned up in the first days).

Then, I checked for upgrade guides, saw the Gnome 2.18 one (which was frigging useless) and went ahead blindly. That document is where information should have been laid out in detail about how to proceed. Don't blame, the devs, though -- that could have been done by anybody (preferably someone just undertaking the task for the first time on a stable-branch machine).

meron · n00b Joined: 16 Mar 2004 Posts: 46 Location: Nijmegen, NL

I agree with BoneKracker. After noticing emerge broke on almost everything after expat, the log was clear on XML-parser being the problem. After emering XML-parser, some thinking and revdep-rebuild, I was able to emerge & compile everything correctly. So yeah, some more info would have been nice, but the problem was not that big (if I can solve it, it can't be a major problem).
So hereby: thanks to the devellopers for all their work.

Lasker · Guru Joined: 17 Jul 2002 Posts: 445

What I still blame the developers for is that they could and did foresee all the mess.
Also, several warnings about it at "various" places is not the right way to do, cause
that would demand us to frequently read many forum topics. Devs may have the
time to do that, users usually have a life.

My suggestion: create a new and closed forum "Emergency Room" with things you
really don't want to miss.

roderick · Posted: Thu Aug 16, 2007 12:24 pm Post subject:

jonnevers · Posted: Thu Aug 16, 2007 1:12 pm Post subject:

Lasker · Guru Joined: 17 Jul 2002 Posts: 445

roderick · Posted: Thu Aug 16, 2007 4:20 pm Post subject:

It's a source based distro. Some care must always be taken when performing updates. Afterall, you as the user here are like a package maintainer, unlike other distros where an actual package maintainer does the hard work for us.

For such a source based distro, it is quite incumbent upon the user to read the forums, GLSA announcements, and GWN to keep up to date on changes.

This is quite different from Ubuntu, Red Hat, Suse, etc, as they release pre-built sets and already do all the hard work for you.
_________________
If God were a pickle, I'd still say "no pickle on my burger".
http://roderick-greening.blogspot.com/

Lasker · Guru Joined: 17 Jul 2002 Posts: 445

Ok, that was standard phrase No.2 (No.1 would be "make it better"). :roll:

I'm always open to arguments, but please try don't being a phrase monger.
Admittedly, my suggestion with the ebuild-based, forced user intervention might be too expensive. But what does it cost to place a good visible warning (as I suggested before) as part of the topic sentence, at least in cases like this? 5 seconds or maybe 10 of your precious time? Can you imagine how much time it did cost to me and who knows how many other users? Where is the relation? Where is the rule that states source based distros have to be inconvenient for their users? Even in cases where it'd be so easy to prevent? And yes, I do know (and appreciate!) the difference to binary based distros. What do you think why I'm still a gentoo user (for many years now) and was (long time ago) a user of your three examples above and a few more?

This was my last attempt to convince you. If unsuccessful, we'll have to live with it. Better give ground before debating starts wasting more time than fixing problems further ignorance will cause. Ah - and I hope I didn't sound too unpolite. If so I do apologize (please keep in mind I'm not a native speaker).
Have a nice day!

xavier10 · Posted: Fri Aug 17, 2007 7:51 am Post subject:

Ok, I have fixed my situation.

What I did was:

1) remove the symbolic link that I had temporarily added so that I could do some work with the damaged system, cuz I had to). I was SCARED about emerging anything with an unsafe symbolic link active (am I correct to suspect this may generate further breakage in the system ?).

2) focus on pango, which seemed to be the first package that would break on any emerge path. I decided to re-emerge anything it would depend on. Therefore I did emerge --emptytree -avD pango.

3) do revdep-rebuild -X (well, in fact it was -p -X, and copy of the emerge command).
Some packages would fail, but most would emerge safely. That fixed part of kde, gnome.

4) emerge -auvD world for the remaining packages.

5) individual emerges when binaries fail and complain about libexpat.0.so

A few notes: I have noticed that some packages that revdep-rebuild -p wants to re-emerge are simply ignored by revdep-rebuild -p -X. That is the reason why I found that individual emerges were necessary for some remaining packages. Note that step 4 did already part of the work in fixing kde individual builds that had not been fixed by the revdep-rebuild -X stage.

Regarding to the update strategy, now. When I installed gentoo for the first time, I did not notice any kind of warning that I remember of inviting evrybody to read the forums whenever updating any single package. Over years using gentoo, I came across very important upgrades, that involved temporarily breaking the system and these were typically highlighed with blocker packages, and I liked that approach. I consider that a blocker package was a very nice warning that some update may not work well at first and would require the user to go look for more information. I did not notice that for expat, and think it might have helped me avoiding or foreseeing the mess. Not sure if the blocker thing is the best way to warn users against a steep udpate. Though I would still like a distinction be made between the updates that maintain all interfaces (99% of them, I expect) and the 1% potentially problematic ones.