Rémi Cardona

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édéric Crozat, Dodji Seketeli, Marc-André Lureau, Daniel Stone, just to name of few.

Here are some random thoughts about what I saw over the weekend :

• Too many talks about driver updates, Gallium3D, radeon, radonhd, nouveau. Although the work they've done is extremely cool and awesome, their talks had too much overlapping content. Very insightful nonetheless.
• I almost fell off my chair when I saw Open Arena run on nouveau... I guess most of the audience was stumped too, considering glxgears barely worked at last year's FOSDEM
• Daniel Stone's talk about X's input support was very interesting, especially for my current work on Metisse and input redirection. In a nutshell, the input layer in 1.4.0.90 and even git master really sucks, MPX cleans up almost all this mess, the remaining bits are expected to be fixed over the coming months. I guess I'll be hacking on the MPX branch for Metisse.
• XAudio ... I wish Helge had more talked about why he thought putting audio in the X server was a good idea, rather than using an independent server like PulseAudio. Shame on me for not asking though.
• ProjectVGA, that's just plain awesome. Nuff said.
• I was a bit disappointed by the Gallium3D talk, I guess I was expecting a bit more detail about how it actually worked, not a 10,000 ft overview.
• Keith Packard's talk was just a blast. Basically, he summed up what everyone is currently doing in the Xorg community. My take on it: hell is breaking loose in the X ecosystem, almost all pieces are currently broken or barely working (X, the drivers, the new graphics subsystem in the kernel, Gallium3D, mesa, ...) but the improvements should be well worth the wait and the pain. I recommend his talk to anyone who doesn't regularly follows Planet FreeDesktop or the Xorg mailing lists.
• Off topic: the temperature in the dev room was waaay too hot. Try to imagine about a hundred geeks, with their laptops, in a room where it's 35°C, with only one door... Tough.

As for my talk, it went rather well. I kind of screwed up the bimanual interaction part of my demo, but apart from that, everything went OK. I hope I'll have another chance to present something at FOSDEM or other conferences, it's a great experience.

That's all for now. Back to work.

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

Hi all,

I've just uploaded xf86-video-i810-2.2.1_pre20080123 as upstream wants distros to do more testing for "old" chipsets. So please, unmask this ebuild and let upstream know how it works/breaks on your hardware.

If you have any bugs, please report them directly to FreeDesktop's bugzilla and add "remi [at] gentoo [dot] org" as a CC on the bug report. That way, I'll know when the patch is committed and I can push another snapshot.

Thanks

Edit: I've changed to the Gentoo package name as to not confuse Nightmorph I promise I'll do the pkgmove as soon as possible.

Hi all,

This going to be like a Public Service Announcement for x11-drivers/xf86-video-i810.

• Both Doug (Cardoe) and Josh (nightmorph) have asked me to do a pkgmove to xf86-video-intel to better match upstream's naming. It's been something I would have liked to see, even before Donnie (dberkholz) gave me the ownership of the driver. For now, my plan is to do the pkgmove when Intel releases a new version of the driver that can be safely unmasked.

• On the issue of masked drivers, one of Intel's engineers - Gordon Jim - recently asked for better community cooperation. His plan is to organize testing for older graphic chipsets which they can't (or no longer want to) test.

  So this is a big shout out to all of us who have felt disenchanted by Intel's latest drivers. So please, click on the above link to let him know what device you have, and that you're willing to help. If those tests require patches, I'll try my best to put those patches in portage (p.masked of course) for everyone to easily test and report back failures.

That's it for now, hopefully more news about Gnome in the next couple of days.

Hi all,

Just a quick word that I'll be masking xf86-video-i810-2.2.0. It's currently in ~arch only so stable users don't need to worry about losing their driver.

Why am I masking it? Well, it's quite simple: it sucks. Not that I want to belittle upstream's hard work, but this release is one of the worst since the new 2.x series.

• Random segfaults on all 965 and older chipsets when using the DRI
• XVideo is almost entirely broken on 8xx chips
• Modesetting also doesn't work on some chips

So while I'll be masking 2.2.0 for now, I really would like it if people tried this driver and reported on xorg's mailing list if they have any issues. I and others have already notified Intel devs about these issues and they are taking it seriously. But nonetheless, testing it and reporting what breaks could possibly help xorg devs identify the bugs and fix them for the next release.

Thanks for listening to this Public Announcement

Cheers, and Happy Holidays to all.

Today, I'm starting a new theme for this blog. Instead of ranting or trolling like a good chunk of bloggers out there, I'll be writing about the cool new stuff upstream Gnome developers have coded during the past 6 months (probably more, since I'll try to go back to older features as well) and that we offer in Gentoo, but are hidden.

As many know, Gentoo is about choice, and the default choice is to "opt-in". So if you install Gnome on Gentoo, you get a bare-bone Gnome experience, sometimes in stark contrast to what other distros do. So in order to level the playing field, I'll be writing about how to enable some of those cool features.

Today's special : gnome-keyring's pam module.

Gnome-keyring now provides its own pam module, so you don't need to emerge pam_keyring. Just enable the pam use flag (it should be on by default) and you'll be ready to start configuring it

All in all it's not that complicated. Here's my /etc/pam.d/system-auth

#%PAM-1.0

session required pam_limits.so
session optional pam_gnome_keyring.so auto_start
session required pam_unix.so

There are a few things to keep in mind though :

1. Always keep an open root shell when doing pam modifications. Better safe than sorry.
2. Don't try it on pam 0.78, it should work but it needs more tweaking and I'm not entirely sure about it. Flameeyes is pushing for pam 0.99 to hit stable on most arches anyway. Things should move quickly.
3. Your keyring password must be the same as your pam password. If they are not the same, you need to delete your keyring inside ~/.gnome2/keyrings.
4. Once the passwords are the same, gnome-keyring will keep the two passwords in sync provided you use passwd to modify your password. If root does it for you, it won't work.
5. Using this configuration file as-is will launch gnome-keyring for every pam service that includes system-auth. If you run other services on your machine, I'd recommend putting the same pam commands inside gdm and gnome-screensaver. Just make sure to put them before the include statements in those two files.

I'd like to thank Flameeyes for his help, Tester and wltjr for testing things out with me yesterday when I was hitting a roadblock trying to figure out how it all works So thanks to the three of you.

Other than that, enjoy

Update : check out the blog comment from welp, there's some good additional info

It's 1:20am in my timezone, I just pulled out Gnome 2.20 from package.mask, which is great because both Fedora and Ubuntu still haven't been released (that was my personal goal for this release).

I'm tired, I probably messed a few things up, so don't hesitate to open bugs in bugzilla

NB: do not try to mix and match Gnome 2.20 if you're not running an unstable system. Such bugs will be closed.

Enjoy!

This post started out as a major rant against CVS and how it sucks to be using it from Europe and how all those round trips in the protocol make even just bumping a single ebuild a tedious task that I have never been able to do in under 4~5 minutes.

But no! I shall not lower myself to this level and instead write a praise for the OpenSSH folks who through their l33t coding skills give us the opportunity to improve CVS for free

The problem : the CVS protocol sucks because for each file/directory you want to update, CVS will open a new SSH connection to send its command. The SSH protocol does not really help with that since creating a new connection brings a lot of overhead.

The solution : use the OpenSSH ControlMaster option to tell it to use a single connection that stays open (somewhat like Keep-alive in HTTP) and that will be used to create new "sub-connections" that are much cheaper.

"How?" you ask me. Well, here's how.

1. Add this to your ~/.ssh/config

   Host *
   ControlMaster auto
   ControlPath ~/.ssh/master-%r@%h:%p

2. After running ssh-agent, run the following command :

   ssh -M -N -f login@cvs.gentoo.org

3. Enjoy a 3x speed-up like I did! For those that doubt it, here's how I measured

   cd gentoo-x86/profiles
   find &> /dev/null
   time cvs up -dP
   ssh -M -N -f login@cvs.gentoo.org
   time cvs up -dP

I'd like to give a big "Thank You" to Robin who suggested I try those steps and helped me set them up. Here's to hoping it helps other fellow devs

References

• http://www.linux.com/articles/54498 for the configuration file
• http://gcc.gnu.org/wiki/SSH%20connection%20caching for a simple explanation of the command line options

As I'm sure all you Gnome lovers already know, Gnome 2.20 has been released. [Cue the now traditional props to all the Gnome Hackers for their brilliant work] As neither Daniel nor Mart have blogged about it, I'll take it up and give some news about Gnome in Gentoo.

This past weekend, we've brought gtk+-2.12 and its friends (glib, pango and atk) from the gnome overlay.

We've already seen a bunch of stuff break from it, from Xfce (for which Samuli had a nice patch ready) to some unexpected packages like OpenOffice and netscape-flash if used outside Gnome or Xfce (e.g. in Kde or *box). Patches are pending, please bear with us while we figure out where to really patch things in a smart way.

Another round of breakage is probably going to be more widespread, but waaay easier to fix. For some unknown reason, some upstream devs decide to ship their tarballs with this kind of cruft lying around in their configure.ac :

-DG_DISABLE_DEPRECATED -DGDK_PIXBUF_DISABLE_DEPRECATED -DGDK_DISABLE_DEPRECATED -DGNOME_DISABLE_DEPRECATED

It's like shipping makefiles with -Werror in them. While this is a great idea for development releases or SCM checkouts, this is a nightmare for official releases. In our case, the GtkTooltip API was completely revamped and the old API marked as deprecated. So stuff that used to build just fine with gtk 2.10 now breaks with gtk 2.12. The old API is still there, but those #defines block you from using it.

So if any Gnome Hackers are reading Planet Gentoo, please think of downstream maintainers and don't put those #defines in stable tarballs. Thanks a bunch from the Gnome Herd

Other than that, we'll probably start masking and moving the rest of Gnome 2.20 over the next weekend and week. None of us want to have 2.20 be like 2.18 where we were almost 2 months behind every other distro. No ETA yet for unmasking.

Cheers

Yeah ... lame, I know. First post on Planet Gentoo, so Hi all.

A couple weeks ago, I posted an offer for fellow gentoo devs to send me pictures of them so that I could replace/create a hackergotchi for them.

To this day, I've created 3 hackergotchis for :

• lavajoe :
• opfer :
• p-y :

If any of you Planet posters want to have your very own cool hackergotchi, please send your pictures my way.

PS, maybe I should make one for me ...