If you assume compile problems, why is that thing unmasked?

Xorg-server 1.7 is not getting stabilized, it's just getting unleashed onto unstable. Unstable means exactly that. Of course we try to do our best and we won't release something we know will break. The idea behind unstable is for users to test the new and shiny stuff before it hits stable.

If you don't want to help fix bugs, use stable. It's as simple as that.

I've always been irritated by the way the xorg team handled masked/unstable/stable releases, as even rc's were unmasked at times.

Releases in X-land are tough. The numbers almost mean nothing. For instance, the last stable version in the 1.5 series was 1.5.3-r6. And despite the apparently stable version number, it currently has 80 patches to make it run smoothly.

On the opposite side, the current stable server is 1.6.3.901-r2, which is indeed a "pre point release" only has a couple patches. And 1.7.1 doesn't have any patches.

So don't let the version number fool you, they mean almost nothing.

As for what we put in portage, well X is a complex piece of software. It used to have more than a million lines of code and it's been getting some tough love these last 2 or 3 years. And up until recently, drivers were a mess. I had shivers every time a new driver was released : "How many systems will this break?" was a question I asked myself over and over.

There are probably a lot of people who put the xorg-server in package.keywords because they needed/wanted feature X/Y or because it fixed some bug for them (it did for me). So now I get a release that possibly breaks build in unstable?

Again, unstable is for power users who are not afraid of filing bug reports if something breaks. We try to make sure that things don't break every day, but Gentoo being a source distro with billions of possibilities (USE flags, CFLAGS, arches, packages, ...),you can't reasonably expect us to try every possible combination.

So we ask for you help (via bugzilla) in return. Gentoo is a community distro, after all.

So there, that's it for today, I hope y'all know a bit more about how we manage X and unstable packages.

This release took a little longer to unmask not because of the server (it's a nice change). It's because a lot of headers were moved around from library packages to proto packages and vice versa. The ABI of X libraries has not changed, but I'm pretty sure there will be compile errors in some packages.

If that's the case, please file bugs in bugzilla.

Thanks for reading this public service announcement.

Edit: There will not be a package.keywords list for stable users. Xorg-server 1.7 is intended for ~arch users only, at this moment. And all bugs from stable users will be closed INVALID. We will start creating lists when we want to stabilize it.

Without further ado, I've asked our faithful Arch Teams (pretty much all of 'em) to stabilize xorg-server 1.6 and friends. amd64 was the first one to the finish line with a stabilization done in under a day!

Gentoo is again back in business for X. Woo!

Now to all stable users, don't forget to read the upgrade guides we wrote :

• server upgrade guide
• libxcb upgrade guide

Don't forget, please file bugs in bugzilla.

For once, the server upgrade shouldn't be too hard and the server upgrade guide is remarkably slim. There's been no change in input, nor HAL, nor just about anything else for most users.

Only Intel users might have a few surprises with DRI2 and UXA. But at this point, they should be good surprises

However, the libxcb upgrade is going to cause more troubles for some users. If you are/were using x11-libs/libX11 with USE="xcb", then you might have to rebuild lots of packages. This is why we've taken such a long time to unmask and stabilize libxcb 1.4. But now, we've worked hard to write a proper libxcb upgrade guide, which users are definitely going to want to read.

I would say the libxcb guide is more important than the xorg-server upgrade guide.

Anyhow, right now, I calling out for help among our stable users. If you've always wanted to contribute to Gentoo but didn't know how, here's your chance.

1. Grab the stabilization list from bug #282290
2. Append it to your /etc/portage/package.keywords
3. run : emerge -DuNa world like always to update

Again, don't forget to read both upgrade guides before running the update, just so you don't start panicking when portage is unable to continue the upgrade.

As always, you're more than welcome to CC yourself in the stabilization tracker, but please DO NOT COMMENT IN THE TRACKER if you have issues, you'll just annoy everyone there. Just file a new bug and we'll look at it.

Don't forget that most X maintainers lurk in #gentoo-desktop on FreeNode if you have any questions.

That's all for today

With this now done, I'll slowly start cleaning up old ebuilds. X in Gentoo deserves not to be a big mess anymore.

What bothers me most is that alpha still doesn't have xorg-server 1.5 keyworded at all. PCI on alpha is apparently more complicated than on other arches and they're still waiting for proper libpciaccess support.

It's a shame as I really wanted to get rid of 1.4.2 from portage, as it probably was one of the worst release in recent X history (management-wise).

Other than that, I'll be AFK for about 2 weeks starting from next Saturday, so don't expect much from me during this period.

Enjoy

Arch Teams have the final package list and the upgrade guide is now online.

Now I guess I can sit back and watch how it all turns out. I hope things won't be too bad on the driver front... Time will tell.

Thanks to all who tested the upgrade in the past few weeks, you guys really helped us out.

I think I'll have a beer tonight to celebrate

Edit: Don't report bugs in the comments of this blog, I will not look at them. Please file them in bugzilla.

Oh, and I was just too tired to have a beer... Sad...

So what's going on in the X/Gentoo land, you ask?

Well, we're aiming to stabilize xorg-server 1.5.3 and a whole batch of other stuff Real Soon Now (tm).

Why is this a big deal?

Because X is pretty much central when it comes to the desktop. While we can't risk breaking it too often, we can't afford staying with the current situation for stable users. Xorg 1.3 is old, unsupported, has unfixable bugs and it smells like that piece of meat in the back of your fridge.

But Xorg 1.5 doesn't do {feature X} or support {hardware Y}!!!

I know, and it's a tough call. We've been putting off the stabilization of newer Xorg servers precisely because of that. But now, we're in a situation where newer versions fix more bugs and support more hardware. Yes, some people will be pissed off and I'm not exactly thrilled about pissing users off. But we have to move on.

Can't you wait for Xorg 1.6 then?

No, because there are more users waiting for 1.5 than users who will benefit from 1.6. And by going to newer drivers now, we can help spot issues faster and get more bugs fixed for newer releases. With each new X release, the server handles less and less hardware details directly, leaving the kernel and X drivers do all the dirty work. Once we stabilize 1.5, going to 1.6 should be much easier than older upgrades.

Alright, you win, how can I help?

That's the spirit! I strongly urge as many stable users as possible to try this because, Xorg 1.5.3 will go stable one way or another. The sooner you test it, the sooner you can adapt.

1. Go to the stabilization bug,
2. Fetch the stabilization list "x11.stable.list" and append it to /etc/portage/package.keywords
3. run emerge -DuNav world
4. Just to be safe, run emerge $(qlist -C -I x11-drivers/) -1av to rebuild your X drivers (portage may have updated things in the wrong order, better safe than sorry)

Once all this is done, you should have a brand new Xorg on your machine. Here's a quick list of things you should look out for :

• HAL support now actually works but may conflict with your xorg.conf, it can be easily solved though.
• the Intel driver is no longer called i810, but intel. You'll need to update your xorg.conf, otherwise X won't start.
• the open-source ATI driver xf86-video-ati now only supports Radeon chipsets. Rage Pro owners will have to use xf86-video-mach64 or xf86-video-r128 instead.
• Please don't comment on the stabilization bug if you have issues. Either come talk to us on #gentoo-desktop or file bugs in our trusty Bugzilla

Please help us move away from Xorg 1.3 and into the present with Xorg 1.5. We'll take care of the future (aka 1.6) when this is done.

Cheers

Edit: added bullet on Radeon support
Edit 2: added --one-shot to the emerge command

Anyhow, back to the point.

About a week ago, I added the old i810 drivers (1.6.5 and 1.7.4) to package.mask. Since then, a few people have opened bugs and have sent me emails asking me to take them out of p.mask. I guess I owe an explanation to all who care about Intel drivers.

The situation is quite simple :

1. The old 1.x drivers are no longer maintained. Period. Upstream no longer cares about them and other distros (at least Fedora and Ubuntu) have started dropping the old drivers from their repositories.
2. Most importantly, starting with xorg-server 1.5, only 2.4.0 and up build correctly. So all drivers older than 2.3.2 do not work with xorg-server 1.5. I hope I made this statement clear enough.

I know that changing drivers can be a big pain, but there are only 2 good reasons for sticking with 1.x, I'll list them here because if you don't care about either, then you should move to 2.x.

• Old Xinerama support. XRandR is a very good extension but in some cases, the old driver was better. Especially with pre-915 chips where the framebuffer is limited to 2048 pixels in width.
• Unsupported chips. This one is very uncommon. In fact, I would say Gilles (eva) is the only one that has an unsupported DAC chip on his 830 tablet.

The rest of you, please try 2.x as soon as possible. If you still have issues, here's what you can do:

• Remove all HorizSync and VertRefresh from your xorg.conf
• Remove all "optimizations" from the Device section (such as forcing OffscreenPixmaps and what not)

If that still doesn't work, please open a bug and we'll try to sort it out.

Thanks

PS, I finally took care of the pkgmove. So please update VIDEO_CARDS in your make.conf to use "intel" instead of "i810".

Update: s/xorg.conf/make.conf/ ... thanks Donnie