| 1 |
Caleb Tennis posted |
| 2 |
<63052.69.136.169.173.1144147119.squirrel@××××××××××××.com>, excerpted |
| 3 |
below, on Tue, 04 Apr 2006 06:38:39 -0400: |
| 4 |
|
| 5 |
> I think historically we were much more bleeding edge with our stable KDE |
| 6 |
> versions than at the moment, but if you've spent any significant time |
| 7 |
> playing with 3.5.0 or 3.5.1, I think you would agree that they are |
| 8 |
> terribly less stable than 3.4.3. But in a few weeks I think 3.5.2 will be |
| 9 |
> stable and it will all be behind us. |
| 10 |
|
| 11 |
I have, and it seems decently stable here. (Well, there's that expat |
| 12 |
upgrade like a day after I had finished compiling 3.5.2, but some things |
| 13 |
can't be helped and that upgrade would kill 3.4.x as well, if I'm not |
| 14 |
mistaken -- may I suggest a KDE 3.5 and the expat upgrade go stable |
| 15 |
together?) In general, however, fairly stable. |
| 16 |
|
| 17 |
However, part of that may well be that I'm running ~amd64, not x86, with |
| 18 |
its many sub-archs hardware-wise and the problems some of them have. As |
| 19 |
amd64 is fairly new, there are only a couple of hardware subarchs for it |
| 20 |
yet, and they are quite compatible, so stuff generally either works for |
| 21 |
everyone or noone. I've learned that I can safely comment out many of the |
| 22 |
calls to stripflags or filterflags, as often, the condition they are |
| 23 |
correcting for doesn't affect amd64, yet unfortunately, the calls aren't |
| 24 |
conditioned on arch as they would be in a perfect world with access to |
| 25 |
full testing on all archs right away. |
| 26 |
|
| 27 |
-- |
| 28 |
Duncan - List replies preferred. No HTML msgs. |
| 29 |
"Every nonfree program has a lord, a master -- |
| 30 |
and if you use the program, he is your master." Richard Stallman in |
| 31 |
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html |
| 32 |
|
| 33 |
|
| 34 |
-- |
| 35 |
gentoo-dev@g.o mailing list |
Archives