Benjamin wrote a comment on my last post, and I'll share my answers here because those questions come up every now and then, so it's better to try to inform everyone. (That and I never write on this blog, so this is a perfect excuse to do so)

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.

It's out there now, available in ~arch. Like always, you'll need to rebuild your drivers, just look-up the command given by the server's ebuild (use eread if you've lost the output).

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.

Turned out that xorg-server 1.6 is pretty much ready for stabilization, as only a handful of bugs were reported over the testing period since last week, and they only concerned the stabilization list.

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.

Here we go again. This time, we're going for the double sweepstakes as we're trying to stabilize both libxcb 1.4 and xorg-server 1.6!

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

Xorg 1.5.3 is now officially stable on 4 of the major arches : amd64, ppc, ppc64 and x86. Props to for ppc/ppc64 for getting there first

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

Brace yourselves, Xorg 1.5.3 is going stable.

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...

It has indeed been quite a while since I've written anything here, but I'll try to keep it both short and focused. Longer rants on other topics should follow once I have some more time.

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

Hum, 2 blog posts in a week, this is highly unusual for me

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

*sigh* I should have written this post a long time ago, but I didn't. My bad...

And just yesterday, Sune was rightfully complaining about the situation. Now it's my turn to blog and to let you in on all the secrets I've been withholding

Quick xorg-server 1.5 Input How To:

If you've built xorg-server with the USE=hal, you might have weird issues with your synaptics touchpad or weird keyboard layouts.

There are currently 2 ways of configuring input in Xorg :

1. Disabling HAL in Xorg: it basically tells Xorg not to look at HAL for input devices and it'll only read your xorg.conf for configured devices. If you don't want to muck around with HAL yet, it's probably a good option. Just stick this piece in your xorg.conf and you'll be fine.

   Section "ServerFlags"
       Option "AutoAddDevices" "false"
   EndSection

2. Migrate to HAL: this is not exactly trivial and might require a lot of tweaking. But once you wrap your head around it, it's not that complicated.

   The idea is to completely remove all the InputDevice sections from your xorg.conf (or even to completely remove your xorg.conf) and let Xorg request input devices from HAL. But we can modify HAL to return configuration values to Xorg.

   For some examples of this method, I suggest reading this sample file which contains almost all the needed documentation.

   Don't forget to read /var/log/Xorg.0.log towards the end, that's where input handling prints warnings and errors.

Intel graphics driver with xorg-server 1.5

For some reason, the server crashes if your xorg.conf file tries to load the i810 driver instead of the intel driver. This is indeed really weird as the former has been a symlink to the latter ever since 2.0.0 came out. I'm guessing the migration to libpciaccess broke some assumptions about driver names.

A lot of people have been bit by this, including me, but I of course do intend to properly fix this. First I need to do the pkgmove, and then I'll just remove all references to "i810" from installed files (mostly the symlink to the driver and the duplicate man page). Finally, I'll make the driver print out elog messages if you still have the old driver name in your xorg.conf

GEM

Although I first believed otherwise, a lot of users were actually using TTM with xorg 1.4. Since TTM has been dropped from Mesa and the supporting bits have been removed from the Intel driver, a lot of people are anxiously waiting for GEM support to arrive.

First the good news, I'm actually working on that. I'm tracking branches and building code.

The bad news... it doesn't work, at least not yet. Intel developers are busy adding support for G4x chipsets and older ones such as my 855GM are not the immediate priority. I've asked for help on the various mailing lists but I'm still waiting. To be honest, I'm not even sure I've built the various components with the right configure options...

My plan is to wait a little bit for the kernel bits to settle (right now, devs are hacking up 5~10 patches per day for the 2.6.28-rc1 merge window!) before asking again.

Watch this space in the coming weeks if you are interested in Intel graphics on a Gentoo system near you

Cheers

Just a quick post to let you all know that xf86-video-i810-2.4.2 has hit portage in ~arch.

Here's my request : please test the hell out of it !!

It seems to be a good improvement over the original 2.4.0 release as it has less flicker, but it needs some serious testing. I think there are still cases where I can see flickering but the conditions seem to vary over time and I can't reliably reproduce the issue.

So please test this new release as much as you can and let me know how it works for you. Bugs should be filed in Bugzilla and not in the comments

As for the new 2.5 branch, it should hit ~arch with a big fat package.mask over the next couple of days.

Oh, and now I'm part of the X11 Team as I have to work with X stuff for my job, I might as well contribute some efforts there too.

Cheers!

Update : Please please file bugs if you still see flickering! Bugs won't solve themselves! Thanks

Hi all,

Just a quick update to let you know that I've just put x11-drivers/xf86-video-i810-2.4.1 to Portage.

Overall, I'm not very happy with this release. It's definitely not as smooth as 2.3.2 which turned out to be very solid. So please test it out with a recent xorg-server (read, 1.4.2) and let me know in bugzilla if anything breaks.

Again, be prepared to continue the bug hunt in FreeDesktop's bugzilla as my Intel Powers (tm) are very limited. It just so happens that half a dozen Intel developers also roam there, so all in all, it's a good place to file bugs. Just add "remi at gentoo dot org" as a CC on those bugs so I can keep track of the issues.

Thanks

Update :

Josh asked me a couple questions and the answers might interest all those of you who have Intel chips but don't follow X development closely. So here goes :

My Thinkpad R61i has an Intel X3100 chip, so I'll be sure to test out the new drivers. I am sorta scared by your blog post, but, well, as long as I quickpkg the relevant packages before upgrading, I should be okay, right?

Yes, let's get this straight, the driver won't eat your laptop and won't kill kittens either. A lot of the core features do work, but there are some instabilities and some quirky behaviors, and those are the issues I'm worried about.

I normally run the hardmasked/~arch X and Intel packages, with all their quirks, on that machine, so 2.4 shouldn't all that different.

Yep, 2.4.1-r1 is in ~arch, so ~ users will probably already have it installed by now.

I wasn't aware of the git overlay. Are there any fixes in upstream's git that just didn't make it into 2.4.1? If so, I may have to make the move to the overlay.

Donnie's X11 overlay has live ebuilds for the "master" branch of all X packages. Beware that intel/master is very different from intel/xf86-video-intel-2.4-branch. I'm currently backporting patches from the latter into Portage as they will end up in the next release anyway. So there's no need to create a live git ebuild for this particular branch.

As for the current git master, as you may have read on Phoronix and Planet FreeDesktop, the driver is going through major changes. Definitely not for the faint of heart.

Also, when's the namechange to xf86-video-intel?

I plan to tackle this tiny issue when Donnie decides to put Xorg 7.4 (aka xorg-server-1.5) into portage.

Replying to Ryan's post...

https://bugzilla.mozilla.org/show_bug.cgi?id=384090#c41

And I'll just quote that comment here:

Firefox-3 (now that the patch is applied) will behave like Gtk, i.e. it will read the font dpi from any standards-compliant XSETTINGS manager. If Gtk programs have the right font dpi on your system, then so will firefox.

As for the gconf key, it won't help you unless you are also running gnome-settings-daemon (the default XSETTINGS manager for the Gnome desktop).

Let's not spread unnecessary false information, shall we?

As it has been announced on several mailing lists, Intel released version 2.3.0 of their X driver. Being back from vacation and all, I've only just committed it to portage. Here are a few things Gentoo users might want to know about it.

• This version is definitely not as disruptive as 2.2.0 (which will probably be remembered as one of the worst driver releases in all of Xorg history). Overall, it really is an incremental release on top of 2.2 with all the bug fixes.
• Laptop users of i915 chipsets and newer should enjoy new xrandr options to control how the image is displayed on the LCD when not using its native resolution: the old behavior was to stretch the image in both X and Y directions, now the driver supports stretching with aspect ration constraints and not stretching the image at all to keep a 1:1 ratio.
• i965 does have a video overlay and I think it's enabled by default now.
• XvMC support should be much better now on i945 and newer. As I can't test XvMC (and I don't really need it anyway), some testing might be interesting. Please let me know how it works on your systems, I'd like to hear from you
• Not really technical but very important IMHO: the new release process is now much much smoother. Intel decided to release a new driver every quarter and that's a great improvement. "Release early, release often". Intel now also releases beta versions of the driver. It might not seem like much, but it does make my job a lot easier and it really helps to get real users to test drivers on their systems. And it shows: only hours after each beta, bugs get reported and fixed. If only more FOSS projects could work like that...

As a whole, it's a good release that shows that even big companies such as Intel can successfully build communities that are committed to quality and openness. Big props to all who worked on it.

On the Gentoo side of things, here are some additional notes:

• As it looks today, 2.3.0 is a prime candidate for stabilization. As such, I encourage all stable users to unmask it and try it on their systems. It should work properly with xorg-server-1.3. If not, please don't hesitate to open a bug.
• I'd also like to remind everyone that opening a bug in Gentoo's bugzilla is a great step to get your problems solved. But in the case of the Intel driver, there's very little I can actually do to fix bugs: I don't work for Intel, I don't know their code nor how the hardware works, I just know about bugs and patches. So if I ask you to open a bug in FreeDesktop's bugzilla, it's not because I don't want to fix the bug, it's just that I can't do it myself. Users who actually take the time to do so are usually rewarded by having their issue fixed in a matter of days. So please, take the time to report bugs upstream, it's in your best interest.

Now, off to work.

Funny how sometimes different people try to fix the same issues at the same time.

First, I'd like to provide a little insight into Libtool and Dolt because a few people have been talking about it for a week or so, but not that many people know what libtool really does, yet everybody agrees on hating it.

Libtool started as a brilliant idea to have one script that could be used to compile C files and link the resulting object files into whatever we want : executables, static libraries or dynamic libraries. That's what /usr/bin/libtool does. It's a cross platform LIBrary TOOL, all in a 218KB shell script. All that code knows about all the C compilers out there, all the linkers and all the subtleties in the command line arguments each and every one supports.

The problem with libtool is that it's a 218KB shell script. Everytime you build something with an Autotooled project that uses libtool (so basically, all projects that build libraries), for every C file in that project, libtool gets called.

For C++ files, it's not that big a deal since g++ is quite slow. But for plain C, it's a whole other issue, as running libtool can sometimes be slower than the actual compiling of the C code it's used for.

That's where Dolt kicks in. Basically, Dolt is set up during ./configure and will create a small shell script that takes the same arguments that libtool does. But instead of being 218KB, it's only going to be a few dozens of lines because ./configure did all the hard work of knowing which compiler and linker are going to be used. Dolt is basically a caching system for libtool. And that's good.

Now, libtool 2.2 is supposed to be much faster than 1.5.26, and that's a good thing too because Dolt doesn't speed up all the operations. Dolt only kicks in for the compiling, not the linking. So all in all, Dolt + libtool-2.2 should be a very good thing for Gentoo users. Let's hope both gain wide acceptance by upstream projects.

Let's move on to .la files. Those are text files that everybody has on their systems. Just take a look in /usr/lib, there's one for almost every .so file. Those are again something libtool creates for the following reasons :

• .la files contain information about both dynamic (.so) and static (.a) libs. .a files unlike ELF .so files do not contain dependencies, so .la files contains those deps. So this is an interesting feature, but mostly aimed for those who need static binaries.
• Dynamic libraries have different naming conventions on different operating systems. .la files make it somewhat easier to be cross-platform.

In theory, .la files are a very good thing... In practice, they hurt us more than they do help solve problems.

• When building applications with dynamic libraries, .la files contain redundant information and therefor are quite useless.
• When using --as-needed in your LDFLAGS, .la files won't benefit from the work done by the linker to prune unneeded libraries because .la files are generated by libtool and not the linker. Diego said he would try to write a script that could clean up .la files, but it's still not a good long-term solution.
• File system pollution... I have 1096 .la files on a "standard" Gentoo systems with Gnome and a few other apps. 'Nuf said.

"Well, why don't you remove them? Can't libtool work correctly without .la files?"

The simple answer is Yes, libtool can work without .la files, but there are exceptions. Basically those include any app that use libtool's dlopen wrapper library. libltdl expects .la files to work properly, so that's a PITA. Apps in that category include PulseAudio, Dia (although I've fixed it in upstream, awaiting for a new release), ... and KDE.

Yep, KDE 3 really sucks on that very point because if you remove KDE's .la files, it will just not work anymore. I truly hope KDE 4 doesn't have that flaw (could anyone let me know?).

I have a plan for the Gnome Herd, which I will probably explain when I have some time to work on it Hopefully, it should make everyone happy.

Update: I've been reminded (and how could I ever forget!) that KDE 4 uses CMake, so it's thankfully immune to that problem.

Folks who follow Intel drivers development have probably noticed that Intel released 2 release candidates in the past 2 weeks.

.901 has been in Portage for a little while, and so far, no one has reported bugs with it. That's a big first in recent Intel history! .902 was released a couple days ago but I have not yet added it to Portage. And the reason is quite simple: it basically breaks all i855 laptops (including mine!)

The gory details is that the second RC saw a few patches to enable LFP fitting and rescaling properties through xrandr, which is a cool stuff to have anyway. But for now, this feature only works on i915 and above (chips below i855 don't seem to offer any sort of scaling or fitting, if I understand correctly)

So once this bug has been sorted out, I'll put .902 with the correct patch in portage for y'all to test. Please do try those releases and push them to the limit: use xrandr, use Xv, use DRI, (maybe not suspending though, that part of the driver still looks shady to me), and please report bugs!

And remember, for each non-dupe bug that you open, God spares a kitten.

Yesterday night, Gilles finished moving Gnome 2.22 to portage. Left in the Gnome Overlay are :

• swfdec and friends, Doug and Mart will be working on it.
• metacity-2.23, yes you read that right. Upstream has already branched for Gnome 2.24 but we'll stick with metacity 2.22 of course.
• pkgconfig, Saleem had created a special ebuild that would make pkgconfig use the system's glib. But Gilles and I feared this might introduce a circular dependency hell, so we erred on the safe sides of things and just bumped the old ebuild for pkgconfig-0.22. We'll have to sort this out though.
• libsigc++, we've bumped it in the overlay (versions 2.1.1 and 2.2.2) but they broke cdrdao which used the old "SigC" c++ namespace. So this one might break other packages. Again, this one will have to be sorted out at some point.

Now, back to the good news! Gnome 2.22 is in the tree!

If you want to try it out here's what you should do :

1. Sync your portage tree and emerge -DuNa world
2. Copy-paste the "The Great GNOME 2.22 Mask (tm)" from /usr/portage/profiles/package.mask into /etc/portage/package.unmask
3. Update your system again using emerge -DuNa world

WARNING #1 !

Do not try this on a stable Gentoo system. Is this clear enough? If you open a bug and we see that you have a stable system, we will close the bug WONTFIX. You have all been warned.

WARNING #2 !

We have not yet written the Upgrade Guide (which I'll start today), so we don't yet really know all of what might break during the upgrade. This is a work in progress.

But if anything breaks for you, please report it to bugzilla, we need feedback so that we can write a better Upgrade Guide, which will help everyone in return.

Other than that, enjoy Gnome 2.22

PS, big props to Mart and Gilles who did almost all of the grunt work in the past few days to move everything from the overlay to portage.

Update: We still have to take care of the various Gnome bindings too, I plan to take on the gnome-mm ones really soon, but I don't know for the others.

Oh, we are working on a major update for the gnome-python packages, but since I'm not fully up to date on the subject, I'll leave that up for another post.

While the others are actually working on this, I'll just be writing a blog post, because the question has come up often enough these days :

Q: When will Gnome 2.22 be available in portage ?

A:

<dang>The mask is in place, and a few packages have been brought over.
<leio> When it's ready. We are working on moving it to portage right now. So, say, in 2-3 days is realistic for unmasking - no promises.

There, now y'all know.

Finally, a new official release of the Intel driver.

A lot of work by Intel and the test community has been put into this release. I for one have been pushing people who posted bugs in Gentoo's bugzilla to repost to FreeDesktop's bugzilla. Most of these bugs have been fixed by upstream Intel devs, or at least acknowledged, which is a significant improvement over the previous situation.

Just this morning, Intel's Gordon Jin has created an intel-gfx community mailing list. Although it requires moderator approval, it's a great way forward.

Hopefully, b0rked releases like 2.2.0 will be caught much earlier from now on, and the number of regressions should go down as well. From a maintainer point of view, this is making my job much less painful :-)

As always, if you have any issues with this release, Bugzilla is your friend. If you're planning to use 2.2.1 on top of xorg-server-1.3*, please keep in mind that no-one upstream has tested this configuration, and if you file any bugs, I'll ask you to reproduce with 1.4.0.90.

Cheers

Saturday morning started really quietly, so quietly in fact that I actually missed the opening keynotes... That'll teach me not to look at the schedule before the event starts.

Over the 2 days, I mostly stayed around the Xorg dev room. I had the chance to talk to a lot of really cool people: Fr

Short blurb before the first Xorg talk starts :

I arrived on Friday morning, way before the first event was set to start. That gave me the opportunity to walk around Brussels for a couple hours. Nice city, I'll definitely have to come back later for a proper visit.

I also took an hour to finish my talk for sunday morning.

Around 7:00PM, I set out to find the FOSDEM Beer Event, which as it turned out, was about 4 blocks away from my hotel. Rock on!

So I finally had the chance to meet a few non-French Gentoo devs : Wolfram (wschlich), Santiago (coldwin) and later in the night Daniel (dsd) and Peter (welp). I'm really glad to be able to link names with actual faces now.

We had a few really nice conversations, some concerning directly Gentoo and what we want to do or see being done, but that probably requires another post of its own.

Beer wise, I remember drinking Chimay Bleue and Delirium Tremens. As for the quantity, the headache I had this morning wasn't too bad - considering the little food I had eaten - I'd say I had something like 5 or 6 glasses, but I can't remember

More later