Package all of Xorg/X11/XCB

[adamjstewart]

I'm trying to install a newer version of Mesa, but there's a lot of missing Xorg dependencies needed for DRI and hardware acceleration.

I decided to take a swing at packaging all of Xorg/X11/XCB, or at least the important parts. Everything can be found at https://www.x.org/archive/individual/. Here is my progress so far:

• app - packaged, some are missing dependencies
• data - Miscellaneous data, mostly for xcursor and xkeyboard
• doc - documentation utilities
• driver - hardware-specific drivers
• font - fonts and font-related utilities
• lib - the actually important stuff
• proto - protocol extensions/headers heavily used by Xorg libraries
• test - packaged but not yet tested
• util - m4 macros used by most Xorg packages
• xcb - same as in https://xcb.freedesktop.org/dist/
• xserver - packaged, missing dependencies

[adamjstewart]

By the way, I remember @hartzell expressed interest in packaging X11/Xorg in #1368.

It looks like @alfredo-gimenez is the only one who's ever touched the Mesa package before. If he has any advice or opinions it would certainly be welcome.

[tgamblin]

@adamjstewart: this is awesome!

[tgamblin]

@adamjstewart: I believe mesa was in there to support OpenGL in MemAxes. I am not an expert on how OpenGL stuff should be packaged but I think you should feel free to hack on that. As I remember it was a fairly nasty dependency

[adamjstewart]

Current problem I'm running into:

Mesa claims that it depends on Xorg server, but xorg-server depends on libgl. I couldn't find any libgl for download anywhere, but multiple sources suggest that libgl is provided by Mesa, creating a circular dependency.

Intended solution:

I'm going to assume that Mesa doesn't actually need the entire Xorg server, just various X11/Xorg libraries. Then I can allow xorg-server to depend on mesa.

[hartzell]

@adamjstewart -- This is great. I haven't had a chance to dig into it, but will try to find time. I ended up just using system libraries back when I was wondering about it and haven't had a reason to go any further. The only resource I had in mind was looking at how Linuxbrew does it.

[adamjstewart]

@hartzell That Linuxbrew repo looks very useful, although I already have way more packages than it does. If you see any inconsistencies between their packages and mine let me know.

[adamjstewart]

New hurdle. The Mesa build script crashes with the error message:

checking for LIBUDEV... no
configure: error: libudev-dev or sysfs required for building DRI

Apparently libudev is now part of systemd, but when I install that with dnf the build script still doesn't pick it up. I was going to try adding packages for systemd or libudev, but they have a ton of dependencies that aren't a part of Xorg.

At this point, I think I'm going to give up on Mesa.

[adamjstewart]

@tgamblin At this point, I've added a package for everything except the drivers. I think those are hardware specific, making it difficult to manage with Spack. So far I haven't seen anything that depends on them, except for maybe xorg-server and mesa. Since there are like 60-70 of them, I don't really want to package them unless someone specifically requests them...

As for the rest of the packages, I think everything in proto, lib, and xcb should be solid, and that's the important stuff. There were a few apps that are missing dependencies that are outside of the Xorg ecosystem. Xorg-server, mesa, gconf, compiz, and xmlto in particular are missing a lot of dependencies. What do you want me to do with packages like these? Should I leave them in and let someone else work out the details? Should I remove them for the time being?

[tgamblin]

@adamjstewart: I think leaving out the drivers makes sense, since Spack is primarily a secondary package manager. If you don't need the OpenGL stuff or xorg-server, feel free to leave them out and let someone else work on them. I think it's better to get this stuff in and let it live in the main repo than to get all of those working perfectly.

Does someone want to test these on OS X? @davydden?

@adamjstewart: I haven't looked at the structure of Xorg packges in a while -- are there some roots in the DAG that would be good tests for the whole stack?

[adamjstewart]

@tgamblin I don't have high hopes for macOS support. I tried building one package and it couldn't install for some reason.

A good test for the whole stack would be xorg-server, if it worked. Otherwise, the most important libraries are libx11, libxcb, libxaw, and libxau.

Let me take one last look through the packages to make sure there aren't any missing dependencies I left in there. Then it should be ready to merge unless someone catches anything else.

[davydden]

once @adamjstewart removes wip, i think this should be merged as-is. Simply too many packages to test, we'll figure out along the way if something does not work.

p.s. at the moment, none of the packages i use for work need x11.

[adamjstewart]

Alright, I think this one is ready to go.

[tgamblin]

@adamjstewart: can you rebase?

[adamjstewart]

@tgamblin Done.

[adamjstewart]

By the way, once this is merged, we'll be up to 994 packages in Spack! Ever closer to the big 1,000!

[tgamblin]

Merged! Thanks @adamjstewart!

[tgamblin]

@hartzell: FYI, this is merged now.

[hartzell]

@tgamblin -- Thanks for the heads up!

@adamjstewart -- Wow. This is great!

Back when I asked about it I was building something (I forget what...) that needed some X bits. I ended up including these CentOS packages in my base build instead:

• libX11-devel
• libXt-devel
• libXext-devel
• xorg-x11-xauth
• libXrender
• libXtst

I just built (Digital Ocean CentOS 7 base image with the prereq's that linuxbrew calls for) them all (their spack names are a bit different...) and everything went without a hitch.

Then I built emacs (defaults to X support), again w/out a hitch.

Then I did ssh -X hostname and (after spending a bit of time trying to explain to ssh where I'd hidden xauth and eventually just dropping a symlink into /usr/bin) I had a genuine X based emacs on my screen.

Wonderful!

[adamjstewart]

@hartzell Glad to hear it!