xorg-x11-7.0 I can't Stand it!!

Message

grofaz · Post by **grofaz** » Wed Jul 05, 2006 12:31 am

Nothing frigging works!! I've spent the last few days dealing with this lousey stinking update to so called stable Modular X and it's driving me crazy. After rebuilding 151 of 191 packages I cosistently get a build failure cause I don't have this file. So I emerge this file, but then I don't have that file. On and on chasing my tail. What the hell is going on here??

If I unmerge xorg-x11 and do an emerge -aveD xorg-x11, why the hell does it keep failing?? The last time I messed with mod x I ended up reinstalling gentoo from scratch and I sure as hell don't want to do that again. So will some kind hearted soul please help me install xorg-x11 successfully??

I'm in limbo now, can't go back to 6.8.2-r8 and can't go forward to 7.0. Im running x86 stable. Right now I'm on my windows machine so I can't post any console output. I'm missing x header files and gl header files as far as I can tell.

grofaz · Post by **grofaz** » Wed Jul 05, 2006 1:10 am

Near as I can figure portage is not finding the directories where the necessary header files are located, but the directories do exist. If I run locate they are listed. Any ideas ??

Raffi · Post by **Raffi** » Wed Jul 05, 2006 1:14 am

I have installed modular x on over 6 machines at this point. I would suggest after unmerging the old x11 that you try a simple

Code: Select all

emerge -av x11

You don't need the a unless you want to see what it is going to do first. I found on at least one of my installs that the ordering did not go quite as it should with more complicated flags. Specifically, I think it screwed up on the D flag.

sternklang · Post by **sternklang** » Wed Jul 05, 2006 3:23 am

The opengl files are symlinked so you can switch between different opengl implementations. Sometimes the symlinks are broken, but you can usually restore them with "eselect opengl". As an example, I'll assume you use the nvidia binary drivers:

Code: Select all

eselect opengl list          # this will show you the opengl implementations installed
eselect opengl set nvidia    # this is what you would use to run opengl apps
eselect opengl set xorg-x11  # mesa is better for building against. This is probably what you want for building xorg-x11

Try running the last command, then continuing your modular X build.

Also, did you follow the Migrating to Modular X HOWTO? Or did you just unmerge monolithic X and try to install modular X without following the steps outlined there?

grofaz · Post by **grofaz** » Thu Jul 06, 2006 3:02 am

Resolved: I bit the bullet and reinstalled gentoo from scratch!
Now everything works...heh heh heh.

Also I had opportunity to build a system based solely on fluxbox. Very cool!

Anyway...got modular x now - the hard way!!

:)

J3N7iL · Post by **J3N7iL** » Thu Jul 06, 2006 6:25 am

I upgraded my gentoo box to the modulare, I only did xorg-server and I havent missed any of the other xorg packages, to this day I have no idea what the other packages do.

The only thing I had to add was xf86-video-sis, xorg-input-keyboard and xorg-input-mouse

I have noticed that I had to re-emerge a few apps like KDM and VNC, but not the whole app, I just did a

emerge --update --newuse --deep kdm

and 3 packages later I was in.

I wish you posted errors to find the issue.

chrysler · Post by **chrysler** » Thu Jul 06, 2006 12:27 pm

If you don't post what exactly your problem is nobody would be able to help you!
I have upgraded to the modular X yesterday without _any_ problems!
Follow the doc(RTFM):

http://www.gentoo.org/proj/en/desktop/x ... -howto.xml

silverback011 · Post by **silverback011** » Thu Jul 06, 2006 2:00 pm

I have managed to get the modular X to install, but all is not well. Xterm will no longer work, xlockmore looks like hell, and some of my custom apps give me some strange behavior (no color where there shoud be etc. ). I used per advice on this forum:

Code: Select all

emerge --resume --skipfirst

This got me by the linuxwacom problem.

I would like to be clear I am frustrated/angry at this point. So if I come off cranky don't take it personally. I use my machine for work. I did not choose gentoo as the OS, it came installed on the machine. I am a BSD person by preference. When you update BSD they have a file called /usr/ports/UPDATING that gives out information that you may need to know before updates are installed to help make sure things go more smoothly.

I have seen several people reference this howto

http://www.gentoo.org/proj/en/desktop/x ... -howto.xml

I had no idea of it's existence until after I run into trouble. Is there something that I should be reading prior to updating telling me about these things?

This is not intended as flamebait. I just want to make sure that I don't have this happen again. I need my computer for work, so I rely on it being stable. At this point I am considering another OS because gentoo stable has not been as stable as I need or want. I want to be clear I DO NOT want to reinstall. It would take me a minimum of two days to get back up even with a package based distro. Most of problems I have had are minor annoyances, but this one... this one was bad.

I just want to make sure I have not missed anything important in the documentation that may be the source of my problems.

Thanks

Raffi · Post by **Raffi** » Thu Jul 06, 2006 2:06 pm

Information from portage has long been a sore point with people regularly missing important information. However, the latest stable version of portage has options for logging and/or emailing these notices. Please check out the latest make.conf.example file.

A little more information about your problems might help us help you. What are the symptoms of Xterm not working? Is xlockmore displaying fire and brimstone or are we talking font problems?

chrysler · Post by **chrysler** » Thu Jul 06, 2006 2:34 pm

have you run revdep-rebuild?

aguettinger · Post by **aguettinger** » Thu Jul 06, 2006 3:07 pm

Actually I had no problems installing modular x11, but funny is, after installing the package xorg-x11-7.0-r1 emerge is briefly showing a message that you should look in the HOWTO for help how to install modular x11, but this message is only visible for the very good eye because almost immediately the screen output for the next package appears. I always wonder about the usefulness of such output messages, because I'm sure less than 1% of the users is looking at the screen at the right time and can actually read it.

Maybe by default the emerge process should wait after an important output and wait for user confirmation, which could be overridden by a emerge flag 'emerge -y' (or vice-versa). And in case of modular xorg-x11, the message for consulting the HOWTO should appear BEFORE emerging all the packages!!

Just my two cents.

sundialsvc4 · Post by **sundialsvc4** » Thu Jul 06, 2006 3:07 pm

You know, silverback011 is right on the money. I think that his points need to be taken .. squarely, soberly, and not defensively.

The "stable" operating system must be stable. Certainly in the case of the X11 update (which tipped big warning-bells to me because it was so huge, and I thank my lucky stars that I haven't installed it) it was not stable and it brought-down a lot of systems .. systems that are primarily used for production work of some kind. And the Gentooers who are responsible for this issue cannot, must not, point-fingers at the X11 group and say "it was their fault." Maybe they released something that's not right; and, maybe, Gentoo should have decided "therefore we will mark this as unstable and keep it that way for the next six months."

Many users schedule "update world" and then fuhgeddaboudit. Therefore, the updates that are released to this venue need to be chosen very conservatively.

Cryptic commands that no one has heard about (as in "what in the heck is 'revdep-rebuild' and why should I care?") are not a good solution, especially if one only hears about them in the eleventh hour.

It is a disaster, and yet it happens a lot, that you apply what you expect to be "a routine update," and suddenly your system is hosed, and now you are scrambling to find out "what to do," and only then do you discover that, oh, by the way, a document was published about this a long time ago... Too Late!

Portage updates need to be furnished with detailed advisory notices that are furnished .. are pushed right in front of the user's face .. first. This forum is an extremely logical place to start.

My goal .. is not to flame anyone. Please see beyond your initial temptation to "flame me" and understand that I am not "flaming you." This is an urgent issue and we're missing the mark here, and it's costing a lot of businesses seriously expensive (and unexpected and unplanned-for) downtime. The stakes are high, the process is highly-pervasive, and the need for improvement is both crucial and immediate.

Many users do not understand, will never understand, and therefore need not to be required to deeply understand the Portage system upon which their businesses do critically depend. This is no fault, either of them or of Portage's designers. It is simply a requirement that is not being adequately met.

J3N7iL · Post by **J3N7iL** » Thu Jul 06, 2006 3:30 pm

silverback011 wrote:I have seen several people reference this howto

http://www.gentoo.org/proj/en/desktop/x ... -howto.xml

I had no idea of it's existence until after I run into trouble. Is there something that I should be reading prior to updating telling me about these things?

Dooood!

go to the main gentoo.org and read the news thiers a link to the how to.

Raffi · Post by **Raffi** » Thu Jul 06, 2006 3:51 pm

sundialsvc4 wrote:You know, silverback011 is right on the money. I think that his points need to be taken .. squarely, soberly, and not defensively.

The "stable" operating system must be stable. Certainly in the case of the X11 update (which tipped big warning-bells to me because it was so huge, and I thank my lucky stars that I haven't installed it) it was not stable and it brought-down a lot of systems .. systems that are primarily used for production work of some kind. And the Gentooers who are responsible for this issue cannot, must not, point-fingers at the X11 group and say "it was their fault." Maybe they released something that's not right; and, maybe, Gentoo should have decided "therefore we will mark this as unstable and keep it that way for the next six months."

Actually, it has been marked as unstable for some time. Considering the magnitude of the change, I was impressed by how well it went on all the system I put it on.

sundialsvc4 wrote:
Many users schedule "update world" and then fuhgeddaboudit. Therefore, the updates that are released to this venue need to be chosen very conservatively.

I don't think I'm following what you are saying here. If you are saying most people do a emerge -uD world regularly from cron, we should probably start by educating people not to do that. Even very stable changes can require intervention because of fundamental package changes upstream.

sundialsvc4 wrote: Cryptic commands that no one has heard about (as in "what in the heck is 'revdep-rebuild' and why should I care?") are not a good solution, especially if one only hears about them in the eleventh hour.

You got a point there. The revdep-rebuild comment should have included a few more details. However, I believe the modular x guide does give those details.

sundialsvc4 wrote: It is a disaster, and yet it happens a lot, that you apply what you expect to be "a routine update," and suddenly your system is hosed, and now you are scrambling to find out "what to do," and only then do you discover that, oh, by the way, a document was published about this a long time ago... Too Late!

Not sure I can agree with you on this. Certainly not in the case of xorg. There was no way to do the upgrade without user intervention and something as fundamental as x needing to be unmerged should raise a red flag even for beginners.

sundialsvc4 wrote: Portage updates need to be furnished with detailed advisory notices that are furnished .. are pushed right in front of the user's face .. first. This forum is an extremely logical place to start.

Yes they do! And fortunately, with the latest version of portage, those advisories are much more available than ever before.

sundialsvc4 wrote: Many users do not understand, will never understand, and therefore need not to be required to deeply understand the Portage system upon which their businesses do critically depend. This is no fault, either of them or of Portage's designers. It is simply a requirement that is not being adequately met.

The recent changes to portage have gone a long way in addressing these problems. The developers are open to improving things even more (even if they are a little slow to implement them). If you have other improvements to suggest, you should probably suggest them.

aguettinger · Post by **aguettinger** » Thu Jul 06, 2006 4:53 pm

sundialsvc4 wrote:You know, silverback011 is right on the money. I think that his points need to be taken .. squarely, soberly, and not defensively.

The "stable" operating system must be stable. Certainly in the case of the X11 update (which tipped big warning-bells to me because it was so huge, and I thank my lucky stars that I haven't installed it) it was not stable and it brought-down a lot of systems .. systems that are primarily used for production work of some kind. And the Gentooers who are responsible for this issue cannot, must not, point-fingers at the X11 group and say "it was their fault." Maybe they released something that's not right; and, maybe, Gentoo should have decided "therefore we will mark this as unstable and keep it that way for the next six months."

In my oppinion xorg-x11-7.0 is as stable as it get's, meaning that it will go fine on the majority of systems that are not borked up somehow. For others that have dependency problems, I don't think there's is something the devs could do to prevent blowing up there systems, except issue a warning that it could go wrong. If you need your system to not break down for a few days, I would not try to update it.

For me emerging xorg-x11-6.8.2-r8 brought down my system, I would not even emerge anything anymore. So I could ask now why the heck was xorg-x11-6.8.2-r8 marked stable? I turned out that I forgot to change some symlinks on an profile update a year ago, but didn't realize that until last week.

By contrast xorg-x11-7.0 was really easy to install for me compared to xorg-x11-6.8.2-r8, where I lost half a day until I found the corresponding bugzilla entry.

at240 · Post by **at240** » Thu Jul 06, 2006 5:09 pm

Raffi wrote:
sundialsvc4 wrote:
Many users schedule "update world" and then fuhgeddaboudit. Therefore, the updates that are released to this venue need to be chosen very conservatively.
I don't think I'm following what you are saying here. If you are saying most people do a emerge -uD world regularly from cron, we should probably start by educating people not to do that. Even very stable changes can require intervention because of fundamental package changes upstream.

I very much agree with Raffi. Running emerges as cron jobs is just not the best idea, no matter how many people report happily that it works for them. At the very least, you need to look to see what is going to be updated, then check the gentoo website front page & documentation, and any advisories published on the forums or via the GLSA list. (I also check the ebuilds for information I might miss as the emerge scrolls by, if we're dealing with a major package.) Also, you need to exercise some discretion: if there are a lot of problems with something being reported on the mailing lists or forums, then don't upgrade.

sundialsvc4 wrote: Cryptic commands that no one has heard about (as in "what in the heck is 'revdep-rebuild' and why should I care?") are not a good solution, especially if one only hears about them in the eleventh hour.

Again, I just don't have much sympathy. Gentoo users should read the gentoo handbook, which introduces revdep-rebuild adequately. (It is not a cryptic command, and lots of people have heard about it.)

This is why gentoo is often considered more high-maintenance than something like ubuntu---it asks more of its users, and, in return, the users can get more from it. Like all solutions, it has weaknesses as well as strengths. One "weakness" is that updates shouldn't be automated. So don't do it.

You know, I sometimes have the feeling these problems stem from a regrettable mentality whereby the user takes considerable pride in being able to feel absolutely postively up-to-the-minute---and often with regards to upgrades that barely change the user-level experience. Hence the desire to automate updates and then bask in the glow of an on-the-edge system. Sorry to be blunt, but Gentoo demands a more discerning user.

Sorry for being grumpy.

silverback011 · Post by **silverback011** » Thu Jul 06, 2006 7:02 pm

Raffi -- thanks for the information I will look into it.

chrysler -- I was doing revdep-rebuild when I made the post. It fixed most of the problems.

I guess from the information I have been able to obtain here I need to

Code: Select all

#emerge --sync

then check the main Gentoo web page (hat tip J3N7iL) and forums for a couple of days and then

Code: Select all

#emerge -puDN world            /* Look at the changes     */
#emerge -uDN world

or do another emerge --sync depending on what I find.

I have managed to fix almost everything at this point except xlockmore graphics look poor, but it still locks the screen and that is all I want. So I will live with it until I get more time to fix the issues with it. Xterm will lauch but seems to have trouble with some flags

Code: Select all

$xterm -fg white -bg black -font 10x20
Warning: Color name "black" is not defined
Warning: Color name "white" is not defined
xterm: Cannot allocate color green
$

This process seems very "chaotic" to me. Some of you have mentioned things have improved. That is good. I just don't see what is so hard about including a file like BSD does that gives the information a user should read before updating. A simple text file does not take up much space and it would give a single location for the most important information. A good example would be a note about about reading the howto before upgrading X. This simple thing would have saved me some down time. I don't think this would be hard to implement, but I have not tried to manage an OS before. I only have experience with individual programs.

Thanks to everyone for your help. I hope my comments have not offended anyone. That is not my intention.

Raffi · Post by **Raffi** » Thu Jul 06, 2006 7:09 pm

Color names might have changed (White instead of white? etc.) or you may be missing your /usr/share/X11/rgb.txt file (comes with .x11-apps/rgb).

blandoon · Post by **blandoon** » Thu Jul 06, 2006 7:51 pm

This is usually right about when I want to go find Ken and Dennis and break their knuckles for thinking case-sensitivity was a bright idea.

And about revdep-rebuild: The modular X how-to briefly mentions that it should be run, but nothing beyond that. On the two systems I've run this mess on, revdep-rebuild didn't finish and had to be manually massaged quite a bit before everything worked. Worse yet, it decided it wanted to emerge openoffice (which takes hours). Openoffice then failed during the emerge and had to be manually emerged again by itself (which takes hours, and hours, and hours, and hours, and hours).

I certainly don't schedule the world update, although I've been tempted to at times, because it seems like the longer I leave it, the more stuff accumulates to be updated - which makes the potential for breakage increase exponentially as time goes on.

Again, don't take this as flamebait. Gentoo's most meaningful asset is these forums and the community that runs them - for every problem I've had, this has been the only possible route to solving it.

Drone1 · Post by **Drone1** » Thu Jul 06, 2006 10:30 pm

I upgraded to modular X from vs. 6.8, only after 3+~ days of effort. Here is where some of the problems IMHumbleO, lie.

The modular X upgrade howto previously linked, I can only guess, assumes you update your system *religiously*. Meaning ALL packages are current, and any that might not be, will have no problem getting upgraded along the way; a few notes notwithstanding.... Sorry, this is probably not the case the majority of the time ( and if it is, do you people even get work done???)

The next 'rock in the shoe', is hardware, driver, package compatability. The latest xorg-server and xorg-x11 aren't compatible with the latest nvidia-glx /nvidia-kernel vs. 1.0.8762 packages, yet you can get the latest xorg-server and xorg-x11 working with older nvidia-glx/nvidia-kernel pre-1.0.8756 drivers ??? I may be slightly off on this (not gonna sleep over it), but to get modular X on my Geforce FX5700 dual head system stable, it needed:

xorg-x11 : 7.0-r1 (7.1)
xorg-server : 1.0.2-r7 (1.1.0-r1)
nvidia-glx : 1.0.8762
nvidia-kernel: 1.0.8762
xf86-input-mouse : 1.0.4 (1.1.1)
xf86-input-keyboard : 1.0.1.3 (1.1.0
xf86-video-mga : 1.2.1.3 (for 3rd monitor, which consequently crashes X with the following error courtesy of Xorg.0.log):

Code: Select all

*****INVALID MEM ALLOCATION**** b: 0xffffc000 e: 0xffffffff correcting
MGA(2): Cannot read V_BIOS

Which brings me to my next problem: When I had
xorg-x11 7.1
xorg-server 1.1.0-r1
xf86-video-mga 1.4.1
nvidia-* 1.0.8762

installed, X would show up fine across all 3 monitors. However, I had no text on the kdm login screen for users, 'Menu' pulldown, or field labels.
This post here, seemed to propose solutions, but I refuse to run the 'nv' driver, and any other posts I found regarding this problem seemed to state updating the nvidia-kernel driver would fix the issue. To late already there....

So the solution for me, was to downgrade 1 version number for xorg-server, xorg-x11, and xf86-input-mouse & keyboard, which required package.mask inputs for each to limit there want for upgrading when I emerge. Though not a difficult venture by any sort, but figuring out how to get to that point amidst the 'libexpat.so.0', 'libstdc++.so.6', 'qt', 'kde-3.5.3', and 'revdep-rebuild' issues, and package, library and solution searching in the forums/wiki/google for each, this experience was a PAIN IN THE ASS trying my patience to the last.

I'm currently running on 2 monitors w/ kde 3.5.3 and am picking through packages to get them updating so an '-uDav world' will work properly. Still getting 'libstdc++.so.6' and 'libexpat.so.0' errors on various apps, so that will continue to pain me. 'revdep-rebuild' has still never finished properly and I can guaruntee I'll post my woes for help in another thread.

As I still have my home system to upgrade to modular X, my hopes are for an easier transition. Like the ones we read so prevalently about in these forums....wiki....yea.....

I hope this sheds light on any poor soul having as many problems as I did/do, and possibly give those who didn't/don't have such problems, a little warmth knowing that they had it easier.

silverback011 · Post by **silverback011** » Thu Jul 06, 2006 11:15 pm

It turns out my color problems were due to the paths being changed in the new modular version. At the very bottom of the howto they mention that the modules path and RbgPath had changed. I simply put

Code: Select all

RgbPath     "/usr/share/X11/rgb"

into my xorg.conf and now the xterm works as it should as well as xlockmore. So far it seems everything is restored back to normal.

Thanks Raffi for putting me on the correct path.

Kaddy · Post by **Kaddy** » Thu Jul 06, 2006 11:18 pm

I know that this might be something silly and not going to help a whole lot of people, but, as far as I have seen, there are some issues with xorg-x11-6.8.2-* (better known as "xorg-x11-6.9*" in the package.mask file) blocking everything for xorg-x11-7.0. For the most part, this shoult be a simple fix,

Code: Select all

emerge -C xorg-x11 && emerge xorg-x11

as for what Drone1 said, it seems like he is using the unstable build, okiedoke, mask it down, or up, whichever you'd prefer. Linky goes here

dmpogo · Post by **dmpogo** » Fri Jul 07, 2006 1:19 am

Raffi wrote:Color names might have changed (White instead of white? etc.) or you may be missing your /usr/share/X11/rgb.txt file (comes with .x11-apps/rgb).

I actually have the same problem with colour and some fonts (this I don't worry about after the upgrade)

I have /usr/share/X11/rgb.txt

but

$ aterm -bg black
aterm: cannot load color "black", colorID=0, (29)
aterm: cannot load color "Black", colorID=0, (29)
aterm: aborting
$

also, my prompt, which consists usually of red/blue (from /etc/DIR_COLORS)

Code: Select all

PS1='\[\033[01;31m\]\h\[\033[01;34m\] \W \$\[\033[00m\] '

or green/blue

Code: Select all

PS1='\[\033[01;32m\]\u@\h\[\033[01;34m\] \w \$\[\033[00m\] '

is now black/blue. So red and green are not found, but blue apparently is

Raffi · Post by **Raffi** » Fri Jul 07, 2006 2:13 am

Someone else got it right on this thread. It is probably from not taking the path changes when you did etc-update or dispatch-conf. You did do one of those right?

dmpogo · Post by **dmpogo** » Fri Jul 07, 2006 2:37 am

Raffi wrote:Someone else got it right on this thread. It is probably from not taking the path changes when you did etc-update or dispatch-conf. You did do one of those right?

I surely did etc-update, but you are right, it is a path to rgb database somewhere.

Perhaps since I looked at this through vnc, and vnc compiles agains 6.8.1 sources it has an rgb path build in somewhere.