Upgrading Slack 10.2 to X11R7.1

[Hunter2]

Hi, I'm trying to upgrade my X.org because Slack 10.2 (apparently) doesn't come with the X11 evdev driver, and doesn't come with the X source packages. In order to satisfy the dependencies for building X with Mesa/DRI support, I built DRM and Mesa from source (since I can't find source packages for Slack for those either). I also updated to pkg-config 0.20 (latest).

I tried following the instructions here:
http://wiki.x.org/wiki/ModularDevelopersGuide

I assume that this is the *only* way to build the latest version of x.org. However, while running build-from-tarballs.sh (for older tarball build, using the 'everything' option), it quits on this error:

checking for pkg-config... /usr/local/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for XEXT... configure: error: Package requirements (xproto x11 xextproto xau) were not met:

No package 'x11' found
No package 'xextproto' found

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables XEXT_CFLAGS
and XEXT_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.

WTF? To build X I must have X installed?

I also did a search for 'x11.pc' (locate x11) and 'xextproto.pc'. Neither gave any results, even in (build-prefix)/lib/pkgconfig.

Can anyone help out?

[stubbe]

I think you should install the X-devel package? Try install em both (the devel and X11 binary package) just to make sure. You can uninstall them later anyway.

[Hunter2]

I'm installing from source, not from a package (and anyway, there aren't any up-to-date Slack packages for X).

[Hunter2]

ALSDFKJALGUSOBADG@#%@^_Q(AWEF)SDVJKLAW

-_-'

OK, well, I *think* I've figured it out. In the X11R7.1/doc folder of the X.org FTP server, I found:
README.html
README1.html
README2.html
(...)
README7.html
RELNOTES.html
RELNOTES1.html
(...)
RELNOTES7.html

Earlier, I'd clicked on README.html and found the SAME FREAKING CONTENTS AS A LINK FROM THE WEBSITE. Then I clicked on README6.html and found THE SAME FREAKING THING. So I figured that they were all THE SAME FREAKING THING.

WRONG. Several of the README's contain oh-so-useful information about mailing lists and contributing to X.org's "efforts". Boring, skip all.

Well, README1.html just happens to contain this bombshell, which I don't believe is stated ANYWHERE ELSE ON THE WEBSITE:

X11R7.1 is the second release in the X11R7 series. [good work, dipsh*t.] Tarballs for packages that have had updates since the 7.0 release are included in this release. [wtf else would you have a new release for, you @sshat...] To build this release, you will first need to get the packages from X11R7.0 and then add the new packages from X11R7.1 to them. [fsck you. i hope you segfault and die.]

Note that the first line just happens to look pretty damn similar to the first line in README7.html, instinctive reactions included:

This is the second release of the new modular source code tree. [good work, dipsh*t.] The source code has been split into nine logical modules: app, data, doc, driver, font, lib. proto, util and xserver. [so what's new, you @sshat...] Each of these modules contain one or more packages that can be configured, built and installed separately. [whoopdy doo.]

Good work, X.org. You've just wasted half a week of my hard-earned summer holidays with your @ssf*cking sh*tty website and b*tchingly retarded docs. And props to all those Google hits for 'installing x.org 7.1' that helpfully state: "Instructions for installing Modular Xorg: Modular Developers' Guide" *

*yes, I'm bitter. Slack has sh*tty and unavailable packages, and X.org just sucks.
**if you're having trouble with the link, try clicking the '*'.

[Hunter2]

Great. Apparently X11R7.1 requires the latest devel-version of Mesa, which also wasn't stated AFAIK.

And compiling X11R7.0 with Mesa 6.4.2 installed, and with the Mesa source path specified, dies on:
"configure: error: cannot find GL library - make sure Mesa or other OpenGL package is installed"

I hate X.org.

**EDIT**
And, it doesn't fail right away either. It fails after half an hour of compiling. It also spews out warnings like mad, about libtool integer expression expected, expr syntax errors and implicit declarations. Real pat on the back there, X.org.

**UPDATE: Finally got it to compile. Apparently when building xdriinfo, it looks for the Mesa includes in the PREFIX directory. But to build Mesa (and therefore use 'make install' to automate installation of the appropriate headers), you need to *complete* the build of X.org first (some required GL headers are generated near end of X.org build). So you have to manually copy mesa/include/GL/* and mesa/src/glw/* to PREFIX/include/GL, before the build will complete.

[vda]

Disclaimer: I am not a X developer

> This is the second release of the new modular source code tree. [good work, dipsh*t.]

I'd say that your attitude is not acceptable. All open source projects provides to you _the source_, and _free of charge_, don mostly by volunteers, and now you _***** about it having some rough edges on the bleeding edge_?

Instead of doing this, you should report the problems encountered back to relevant projects. POLITELY.

(I do follow my own advice given above whenever I have trouble with open source projects)

[carlosponti]

its common to have a base released installed first before you continue on with the most current edition. Oracle for instance we use and you have to go from 8.1.7.3 to 8.1.7.4 to 8.1.7.4.11 you cant go strait to the .11 release. so you will have to just go back to installing the base release then install the second version after the base release.

[Hunter2]

@vda: You must've really gone digging to have found this post. Been dead for over a month. For more details on the eventual resolution of the problem, visit here:
http://www.linuxquestions.org/questi...hlight=x11r7.1

In any case, the comment was directed at the inclusion of redundant information to the point where useful information becomes nearly impossible to find. I'd estimate, only about 6% of the contents of those readmes was genuinely useful in *any* way, and it certainly doesn't help that they're broken into 14 different files, some of them containing only one line.

>>Instead of doing this, you should report the problems encountered back to relevant projects. POLITELY.
This has some merit. I've never gotten hold of anyone with this kind of contact in the past, but then I've only ever attempted with small/obscure projects, or else with large commercial projects. Perhaps large open-source projects are a different breed.

P.S. Welcome to the boards, vda You sure picked a great thread for your grand entry.