[gentoo-user] Going ~x86?
Alex Schuster
I am not running ~x86 at the moment. I like to stay on the safer side, and
it has not been too much trouble. Yet. There are things in have in
package.keywords, quite a lot actually.
Most packages are not a problem. Examples are games-fps/quake3, games-
fps/worldofpadman or games-strategy/widelands, which I want to use, but
they are all keyworded. Or net-misc/youtube-dl, which changes quite
frequently to adopt to youtube changes, and I want to always have the
newest version. Or firefox 3.5. which took quite a while to go stable I
think. Those are no problem.
There are other packages, which I unmask because of trouble with stable
ones. One example is sys-apps/util-linux-2.15.1, which I need in order to
make cfdisk work with large drives. Sometimes they pull in something else
I have to unmask, but it's no big problem.
Then there is KDE4. I like it, but there are still so many bugs, so I want
it to be a pretty new version from kde-testing. And I guess this is what
is responsible for most of my problems, which make the @world update
break. The current problem is with samba, apparently the monolithic
package is being replaced by split ones, like with Qt. The new version is
needed by kde-base/kdebase-kioslaves-4.3.3-r1 (4.3.3 is stable). I can
mask this, and the @world update will work, with a minor complaint about
the masked kioslaves.
I wonder if it's worth the trouble. I read here that running a full ~x86
system would probably be easier. And I'd like to try, but while going from
x86 to ~x86 is easy, the other way is quite hard, isn't it? If possible at
all.
What about stability problems? I'd expect some, as the ~x86 stuff is not
so fully tested. What are your experiences? And, do you also get blockers
from time to time that are hard to solve?
I know this topic has been here a couple of times, sorry for bothering
you, but I do not dare yet to make the switch.
Thanks for comments on this. I won't blame anybody for suggesting to make
the switch in case I will regret this later :)
BTW, when I test this and enable ~x86 in make.conf, I first need to set
the extras use flag for udev, and then I get these blockers. So I have to
go to openrc, okay. And again trouble with my ati drivers. But maybe this
will be over once I have completed the switch.
[blocks B ] <sys-apps/sysvinit-2.86-r11 ("<sys-apps/sysvinit-2.86-
r11" is blocking sys-apps/openrc-0.5.2-r2)
[blocks B ] >=x11-base/xorg-server-1.7.0 (">=x11-base/xorg-
server-1.7.0" is blocking x11-drivers/ati-drivers-9.9-r2, x11-drivers/ati-
drivers-9.10)
Total: 611 packages (548 upgrades, 1 downgrade, 45 new, 13 in new slots, 4
reinstalls, 1 interactive), Size of downloads: 1,114,567 kB
Conflict: 15 blocks (1 unsatisfied)
Portage tree and overlays:
[0] /usr/portage/tree
[1] /usr/local/portage/layman/zugaina
[2] /usr/local/portage/layman/kde-testing
[3] /usr/local/portage/layman/science
[4] /usr/local/portage
* Error: The above package list contains packages which cannot be
* installed at the same time on the same system.
('ebuild', '/', 'x11-base/xorg-server-1.7.1', 'merge') pulled in by
>=x11-base/xorg-server-1.0.99 required by ('installed', '/', 'x11-
drivers/xf86-video-vesa-2.2.1', 'nomerge')
>=x11-base/xorg-server-1.5.99.901 required by ('ebuild', '/', 'x11-
drivers/xf86-input-mouse-1.5.0', 'merge')
>=x11-base/xorg-server-1.2[-minimal] required by ('installed', '/',
'x11-drivers/xf86-video-ati-6.12.4', 'nomerge')
(and 5 more)
('ebuild', '/', 'x11-drivers/ati-drivers-9.10', 'merge') pulled in by
x11-drivers/ati-drivers:1 required by @world
x11-drivers/ati-drivers required by ('ebuild', '/', 'x11-base/xorg-
drivers-1.7', 'merge')
x11-drivers/ati-drivers required by @world
Wonko
Alan McKinnon
> Hi there!
> I wonder if it's worth the trouble. I read here that running a full ~x86
> system would probably be easier. And I'd like to try, but while going from
> x86 to ~x86 is easy, the other way is quite hard, isn't it? If possible at
> all.
yes, it is easier to just go ~x86. Yes, it is very very very hard to go back -
easier to reinstall
> What about stability problems? I'd expect some, as the ~x86 stuff is not
> so fully tested. What are your experiences? And, do you also get blockers
> from time to time that are hard to solve?
I get a few problems now and then, mostly blockers from incompatible packages.
But note that you are going to get exactly the same thing when those packages
move to stable.
> BTW, when I test this and enable ~x86 in make.conf, I first need to set
> the extras use flag for udev, and then I get these blockers. So I have to
> go to openrc, okay. And again trouble with my ati drivers. But maybe this
> will be over once I have completed the switch.
There are several documents you should read first at gentoo.org, all related
to upgrades. They are in the docs section, the page with the big long list:
- the switch to openrc
- the most recent X.org upgrade
- installing KDE4
- the horrendous amoun of work to get x and hal working if it doesn't work out
the box
Deal with these blocks individually for best results:
> [blocks B ] <sys-apps/sysvinit-2.86-r11 ("<sys-apps/sysvinit-2.86-
> r11" is blocking sys-apps/openrc-0.5.2-r2)
emerge -av1 openrc
read the elog message and do *exactly* what it says
> [blocks B ] >=x11-base/xorg-server-1.7.0 (">=x11-base/xorg-
> server-1.7.0" is blocking x11-drivers/ati-drivers-9.9-r2, x11-drivers/ati-
> drivers-9.10)
unmerge ati-drivers, make sure VIDEO_CARDS is correct in make.conf and merge X
then remerge ALL your drivers. The elog tells you how to proceed
emerge -avuND world
Everything you run into will be solved using the normal fix-my-gentoo process
:-)
--
alan dot mckinnon at gmail dot com
Willie Wong
> On Wednesday 11 November 2009 17:21:26 Alex Schuster wrote:
> > Hi there!
>
> > I wonder if it's worth the trouble. I read here that running a full ~x86
> > system would probably be easier. And I'd like to try, but while going from
> > x86 to ~x86 is easy, the other way is quite hard, isn't it? If possible at
> > all.
>
> yes, it is easier to just go ~x86. Yes, it is very very very hard to go back -
> easier to reinstall
It is actually not that bad... if you are willing to wait a bit.
Just keyword all currently installed packages (w. version number)
and change ACCEPT_KEYWORD to "x86". After a few months (if you are
lucky) or a few years (if you are unlucky), x86 will catch up and pass
the package versions you have installed.
If you want it done yesterday, however, I agree that it is easier to
re-install x86.
W
--
ZAPHOD Hey, this rock...
FORD Marble...
ZAPHOD Marble...
FORD Ice-covered marble...
ZAPHOD Right... it's as slippery as... as... What's the
slipperiest
thing you can think of?
FORD At the moment? This marble.
ZAPHOD Right. This marble is as slippery as this marble.
- Zaphod and Ford trying to get a grip on things in
Brontitall, Fit the Tenth.
Sortir en Pantoufles: up 1069 days, 15:09
Albert Hopkins
people on IRC as well and for the most part I think people will disagree
with me.
But they are wrong ;-)
I'm actually against mixing testing and stable branches. Here's why.
People choose "stable" because they are under the impression that it's
somehow "safer" or "less troublesome" than "testing" (or what some
people call "unstable"). I'm not so sure I agree but that's not my
argument. My argument is when these people go and then try to get the
"best of both worlds" by inter-marrying the branches. From my
experience these people end up with less stable systems than choosing
either "stable" or "testing". The problem is that they are mixing
software that were not tested or intended to run with each other. And
they come into problems even people in the so-called "unstable" branch
don't experience. Recent examples include Xorg and GNOME updates. So
these people, and the majority of them are newbies, come to think Gentoo
is flaky but it's really their behavior.
Unfortunately the Official Handbook tends to encourage this behavior.
In theory this should be fine, but in practice it seems to produce
less-stable-than-unstable software setups, so I try to discourage people
from doing so. Then they laugh at me.
But I've been in unstable forever. I never use the stable branch
(except for testing ironically) and I remember the days when there was
no distinction between stable/testing. Few times I've had problems with
an update and the solution is always simple: downgrade the package in
question. When I had problems with the cups upgrade, I simply reported
a bug and downgraded cups. When I had a problem with findutils, I
simply CC'ed myself on the bug and keyworded findutils to stable. To me
that's been a lot easier than trying to figure out how to get stable
package A and unstable package B to agree on
inter-operability/configuration/dependencies/etc.
So my advice is: pick and branch and stick with your own kind. It's far
fewer headaches in the long run. And "unstable" isn't really unstable,
it's "untested". There's a difference.
Mark Knecht
<SNIP>
>
> yes, it is easier to just go ~x86. Yes, it is very very very hard to go back -
> easier to reinstall
>
Isn't there a lot more work to do to keep it up to date? Seems to me
testing packages are going to change more often and as not every one
of them will eventually become stable. Isn't it just a lot more
electrons burned to keep things emerge -DuN @world clean?
I run stable except for portage and eix, and then a couple of audio
apps I care about like Ardour and Jack which come from external
overlays and aren't tested by the mainline Gentoo guys anyway.
- Mark
Volker Armin Hemmann
not really. there isn't such a big difference between the daily stabilization
and the daily version bump. so you might emerge a few packages more in the
same time frame, but the difference is not that big.
Roy Wright
So my advice is: pick and branch and stick with your own kind. It's far
fewer headaches in the long run. And "unstable" isn't really unstable,
it's "untested". There's a difference.
KH
> Hi there!
> [snip]Or net-misc/youtube-dl, which changes quite
> frequently to adopt to youtube changes, and I want to always have the
Hi,
see bgo 286366 and report you are fine with it. Maybe it will become
stable, then.
https://bugs.gentoo.org/show_bug.cgi?id=286366
Even better, also report a new bug as stablrq for youtube-dl-2009.09.13
kh
Stefan G. Weichinger
> Also keep in mind that it's the ebuild that is "untested". The package
> is usually what upstream has released as stable.
I haven't yet looked at it that way, good point.
> My advice is if you are willing to upgrade at least weekly then go
> "untested", if you are willing to upgrade at least monthly, then go
> "stable", else really be willing to work thru some hard upgrade scenarios.
Hmm, and this now as I just got somehow happy with my strange mixture of
stable and unstable ;-)
I am now looking at some
# ACCEPT_KEYWORDS="~amd64" emerge -avuDN world
;-)
Thanks, greetings, Stefan
KH
> [snip]
> But they are wrong ;-)
>
> I'm actually against mixing testing and stable branches. Here's why.
> People choose "stable" because they are under the impression that it's
> somehow "safer" or "less troublesome" than "testing" (or what some
> people call "unstable"). I'm not so sure I agree but that's not my
> argument. My argument is when these people go and then try to get the
> "best of both worlds" by inter-marrying the branches. From my
> experience these people end up with less stable systems than choosing
> either "stable" or "testing". The problem is that they are mixing
> software that were not tested or intended to run with each other. And
> they come into problems even people in the so-called "unstable" branch
> don't experience. Recent examples include Xorg and GNOME updates. So
> these people, and the majority of them are newbies, come to think Gentoo
> is flaky but it's really their behavior.
>
Hi,
this for shure is not right, if you are only running few testing
programs. I'd never run ~amd64 just for youtube-dl to be working fine.
kh
Stefan G. Weichinger
> I am now looking at some
>
> # ACCEPT_KEYWORDS="~amd64" emerge -avuDN world
This gives me 464 packages (441 upgrades, 15 new, 6 in new slots, 2
reinstalls, 4 uninstalls) ... phew ... maybe tomorrow ...
;-)
Volker Armin Hemmann
is a GOOD THING on stable, but even more so on unstable. Will save you a lot
of blood sweat and tears.
Marcus Wanner
That's what I'm doing, after reading that bit about the ebuilds and not
the packages being unstable :D
Marcus
Neil Bothwick
> > I am now looking at some
> >
> > # ACCEPT_KEYWORDS="~amd64" emerge -avuDN world
>
> This gives me 464 packages (441 upgrades, 15 new, 6 in new slots, 2
> reinstalls, 4 uninstalls) ... phew ... maybe tomorrow ...
I'd emerge @system first, then reboot and make sure everything works
correctly before updating the rest of @world.
--
Neil Bothwick
Downloading - A quick way of catching a virus from anywhere in the world.
Stefan G. Weichinger
> I'd emerge @system first, then reboot and make sure everything works
> correctly before updating the rest of @world.
Good point, yes ... hmm, it was half way through @world ... now I do
@system and will see what happens. Thanks for the hint, I should have
thought of that.
Stefan G. Weichinger
> How 'bout overnight :p
>
> That's what I'm doing, after reading that bit about the ebuilds and not
> the packages being unstable :D
Sure, me too :)
Alan McKinnon
> So my advice is: pick and branch and stick with your own kind. It's far
> fewer headaches in the long run. And "unstable" isn't really unstable,
> it's "untested". There's a difference.
>
Actually it's not "untested", it's "still being tested". There's a difference.
Alan McKinnon
> On Wed, Nov 11, 2009 at 8:04 AM, Alan McKinnon <alan.m...@gmail.com>
> wrote: <SNIP>
>
> > yes, it is easier to just go ~x86. Yes, it is very very very hard to go
> > back - easier to reinstall
>
> Isn't there a lot more work to do to keep it up to date? Seems to me
> testing packages are going to change more often and as not every one
> of them will eventually become stable. Isn't it just a lot more
> electrons burned to keep things emerge -DuN @world clean?
Yes, ~arch is higher-touch than arch so ~arch users will emerge lots more
stuff.
Is it worth it? That depends on the reason why the box is there and only it's
admin can decide. And everyone's reasoning will be different.
I run ~arch everything because
1. I'm a geek
2. I like to fiddle
3. I can have as much bandwidth as I want
4. I can test/use new softwares locally before rolling it out to my production
machines
5. I can warn others using more stable OSes about deep changes coming down the
tubes (X for instance. RHEL users are in for a big surprise sometime in the
next 6 months to 5 years...)
Alan McKinnon
Good god, please don't ever do that.
If you don't know why it's a terrible idea, then you *really* should not be
doing it
Volker Armin Hemmann
> 5. I can warn others using more stable OSes about deep changes coming down
> the tubes (X for instance. RHEL users are in for a big surprise sometime
> in the next 6 months to 5 years...)
>
friends using stable ask me if they hit a problem. Because most of the time I
hit the same problem a couple of weeks earlier...
Marcus Wanner
Marcus
Alex Schuster
to do now. And that is... wait. Until I have some time to spare for this.
Then, after a backup, I will perform the migration. Now let's see that
this openrc and baselayout-2 is that I have read people talking about for
quite a while here. Emerging more stuff is okay, also small problems here
and there. Generally having newer stuff is nice and geekier. I also have
some other Gentoo machines I maintain, and there are two people whose
machines I look after, so it may help if I see new problems first. The
eix-test-obsolete will be much shorter for sure!
Again, thanks for the nice discussion.
Wonko
Alex Schuster
> Alex Schuster schrieb:
> > [snip]
> > Or net-misc/youtube-dl, which changes quite
> > frequently to adopt to youtube changes, and I want to always have the
> > newest version. [snip]
> see bgo 286366 and report you are fine with it. Maybe it will become
> stable, then.
>
> https://bugs.gentoo.org/show_bug.cgi?id=286366
Did so. I'd like all newer versions to become stable soon, or even as soon
as they are released, because it seems the older version won't work
anymore with Google then anyway.
Wonko
Stefan G. Weichinger
I did *not* do that. I ran that command to just get an impression of
what changing $ACCEPT_KEYWORDS would do.
Stefan G. Weichinger
I interrupted my @world and finished @system first, rebooted ok, then
finished @world, added some revdep-rebuild-runs on the way (some
stoppers inbetween, but nothing too serious) ... now I am through and
have my complete ~amd64-box.
So far nearly everything seems to work (only half an hour usage so far,
we'll see ...). I will add another reboot now and have a look at the
minor issues.
Additional thought: /etc/portage/package.keywords should be useless now, hm?
Greets, Stefan
Stefan G. Weichinger
>>>>> # ACCEPT_KEYWORDS="~amd64" emerge -avuDN world
>>>> Good god, please don't ever do that.
>> I ran that command to just get an impression of
>> what changing $ACCEPT_KEYWORDS would do
>
> in that case emerge -p is better than emerge -a
>
> just in case you hit enter by mistake then walk away...
ok ... lesson learned, thanks ...
Alan McKinnon
in that case emerge -p is better than emerge -a
just in case you hit enter by mistake then walk away...
>
--
Alan McKinnon
No, you will still need it for ebuilds that having missing keywords. For
everything else, it's duplication. Test if you need it by:
- moving the file out the way
- emerge -pv @installed
If you get any messages at all before the list of packages, you have stuff to
fix
Joshua Murphy
Useless? well, not exactly. ~amd64 marked packages in it are
redundant, but every box I put wine on runs git builds
(=app-emulation/wine-9999 in the portage tree), and as such has to
have a "=app-emulation/wine-9999 **" line in package.keywords to get
around being "masked by missing keyword." Of course, this also
involves me knowing full well that, in the process of any rebuild of
wine, I could end up with a terribly broken install and potential data
loss, as is true of running anything from sources that aren't even
being released as "stable" even by the upstream developers.
--
Poison [BLX]
Joshua M. Murphy
Alan McKinnon
> Useless? well, not exactly. ~amd64 marked packages in it are
> redundant, but every box I put wine on runs git builds
> (=app-emulation/wine-9999 in the portage tree), and as such has to
> have a "=app-emulation/wine-9999 **" line in package.keywords to get
> around being "masked by missing keyword." Of course, this also
> involves me knowing full well that, in the process of any rebuild of
> wine, I could end up with a terribly broken install and potential data
> loss, as is true of running anything from sources that aren't even
> being released as "stable" even by the upstream developers.
>
How do you find latest wine git commits compares to the fortnightly snapshots?
I use Alexandre's snapshots almost as soon as they are released, I figure I
can wait the max two weeks to get a latest feature
Joshua Murphy
I only bother rebuilding wine when I hit a problem, or I'm doing an
otherwise fairly big set of upgrades to everything else on the system,
so I don't keep it running on the 'latest', though I will mention I
find it very rare that it gives me even the slightest problem that I
can blame on Wine itself.
daid kahl
> system would probably be easier. And I'd like to try, but while going from
> x86 to ~x86 is easy, the other way is quite hard, isn't it? If possible at
> all.
I just wanted to throw my two-cents in here, although much has been said.
I was running ~x86 for about two years. Then I waited 6 months and
was able to shift to x86 with only a few things in the keywords. (For
example, I had already shifted to openrc and I didn't see the point in
shifting back and then back-once-again.) However, for these cases, I
almost exclusively keyword <= version numbers, so that, in theory, I
will eventually hit x86 minus a very few packages (for example, the
ones that there is no x86 version available).
But honestly, I've been nearly stable (x86) for a couple months now,
and I can't say that the system seems any different. Problems still
crop up, and I still have to deal with them.
As one poster mentioned, when I was running ~x86 and an ebuild was
annoying, I'd just emerge the stable one. This was a solution for 90%
of the things I couldn't google up a bug report on. But the problems
I've hit lately are taking me a lot more time. It could be the mixing
of x86 ~and x86, even though the mixture is nearly all x86.
While shifitng from ~x86 to x86 is 'harder' than the other way around,
basically the way you're shifting is, by-and-large, just waiting for
x86 to catch up to ~x86.
Regards,
daid
Alex Schuster
> On Wednesday 11 November 2009 17:21:26 Alex Schuster wrote:
> > I wonder if it's worth the trouble. I read here that running a full
> > ~x86 system would probably be easier. And I'd like to try, but while
> > going from x86 to ~x86 is easy, the other way is quite hard, isn't
> > it? If possible at all.
>
> yes, it is easier to just go ~x86. Yes, it is very very very hard to go
> back - easier to reinstall
I hope I will not have to do so :) But I have a backup, just in case.
BTW, why would the downgrade be so painful? Is this because of the
impossible glibc downgrade, or are there even more problems?
> > BTW, when I test this and enable ~x86 in make.conf, I first need to
> > set the extras use flag for udev, and then I get these blockers. So I
> > have to go to openrc, okay. And again trouble with my ati drivers.
> > But maybe this will be over once I have completed the switch.
>
> There are several documents you should read first at gentoo.org, all
> related to upgrades. They are in the docs section, the page with the
> big long list:
>
> - the switch to openrc
Done. Did not yet reboot, though :)
> - the most recent X.org upgrade
Not done, that does not work with ati-drivers.
> - installing KDE4
Already have that.
> - the horrendous amoun of work to get x and hal working if it doesn't
> work out the box
The horror.... but think not much will change here.
> Deal with these blocks individually for best results:
> > [blocks B ] <sys-apps/sysvinit-2.86-r11
> > ("<sys-apps/sysvinit-2.86- r11" is blocking sys-apps/openrc-0.5.2-r2)
>
> emerge -av1 openrc
>
> read the elog message and do *exactly* what it says
I think I was just able to update baselayout. Was I really liked was that
I did not have so much to do, things were done automatically, like
migrating new services into the boot runlevel. Nice work!
> > [blocks B ] >=x11-base/xorg-server-1.7.0 (">=x11-base/xorg-
> > server-1.7.0" is blocking x11-drivers/ati-drivers-9.9-r2,
> > x11-drivers/ati- drivers-9.10)
>
> unmerge ati-drivers, make sure VIDEO_CARDS is correct in make.conf and
> merge X then remerge ALL your drivers. The elog tells you how to proceed
Um, no. ati-drivers is not compatible with xorg-server-1.7, and after I
was not able to get the radeon driver to work (I tried... oh how I tried),
I keep my old X.org. I put this into package.mask (got most of it from bug
#290739 [1]), maybe I could trim it some more:
>=x11-base/xorg-server-1.7
#>=x11-proto/xcmiscproto-1.2.0
#>=x11-proto/bigreqsproto-1.1.0
#>=x11-proto/xf86driproto-2.1.0
#>=x11-proto/xf86bigfontproto-1.2.0
>=x11-base/xorg-drivers-1.7
>=x11-proto/xextproto-7.1.1
>=x11-proto/fixesproto-4.1.1
>=x11-proto/inputproto-2.0
>=x11-libs/libX11-1.3.2
>=x11-libs/libXext-1.1.1
>=x11-libs/libXi-1.3
>=x11-apps/xinput-1.5.0
>=x11-proto/xf86vidmodeproto-2.3
>=x11-libs/libXxf86vm-1.1.0
>=x11-proto/recordproto-1.14
>=x11-libs/libXtst-1.1.0
>=x11-proto/scrnsaverproto-1.2.0
>=x11-libs/libXScrnSaver-1.2.0
>=x11-proto/xineramaproto-1.2
>=x11-libs/libXinerama-1.1
>=x11-proto/xf86dgaproto-2.1
>=x11-libs/libXxf86dga-1.1.1
>=media-libs/mesa-7.6
Looks ugly, but as long as my package.mask will be smaller than my current
package.keywords...
> emerge -avuND world
I had to remove samba and poppler to resolve blockers, but I'm emerging
@system now. Hooray!
Now I have a final question (for the moment). What is this ~x86 called?
Writing is easy, 4 characters, but how is this pronounced? Tilde-ex-
eightysix / tilde-arch? Or is it just testing? The problem came up when I
was at the Chaos Communication Congress in Berlin and talked to the guys
at the Gentoo desk.
Oh, dev-libs/klibc-1.5.15-r1 just failed to build. #285355 [2] suggests to
disable distcc, and yes, this does the trick. Strange, but, whatever. 107
packages to go now.
Wonko
[1] http://bugs.gentoo.org/290739
[2] http://bugs.gentoo.org/show_bug.cgi?id=285355
Alan McKinnon
> Some time ago, Alan McKinnon wrote:
> > On Wednesday 11 November 2009 17:21:26 Alex Schuster wrote:
> > > I wonder if it's worth the trouble. I read here that running a full
> > > ~x86 system would probably be easier. And I'd like to try, but while
> > > going from x86 to ~x86 is easy, the other way is quite hard, isn't
> > > it? If possible at all.
> >
> > yes, it is easier to just go ~x86. Yes, it is very very very hard to go
> > back - easier to reinstall
>
> I hope I will not have to do so :) But I have a backup, just in case.
> BTW, why would the downgrade be so painful? Is this because of the
> impossible glibc downgrade, or are there even more problems?
glibc is the one thing that makes it almost impossible. Everything else just
makes it very very hard.
[snip]
> Now I have a final question (for the moment). What is this ~x86 called?
> Writing is easy, 4 characters, but how is this pronounced? Tilde-ex-
> eightysix / tilde-arch? Or is it just testing? The problem came up when I
> was at the Chaos Communication Congress in Berlin and talked to the guys
> at the Gentoo desk.
any of those will do. Even "unstable arch".
Anyone with more than a few days experience with gentoo will know what you are
talking about.
Alex Schuster
It's done! I'm at ~x86 now. The upgrade went quite smooth - had to resolve
some blockers, and mask the new x.org 1.7 because it does not work at all
with ati-drivers.
**BUT:** After rebooting, I ran into a very nasty KDE4 bug. All
authentication dialogs did not work. So I had no KDE wallet, no kmail, no
kopete, no webmail... now this was annoying! Must be some strange side
effect, I do not think anything of KDE itself had been updated.
I spent quite some time trying to solve this. Without an existing ~/.kde4
directory, it worked, but all of my .kde4 backups (I have lots, I make one
whenever I save the session, because this does not work sometimes) had the
problem. So I searched for the file in ~/.kde4 that was responsible for
it, and finally I found .kde4/share/config/kdeglobals. And, more
prrecisely, this setting:
[Passwords]
EchoMode=ThreeStars
I commented this out, and all is working again. Yes, I will file a bug
report upstream.
This kind of bug is what made me not switch to KDE for a long time. The
possibility of suddenly having a little problem which makes the whole KDE
thing unusable until solved.
Wonko