Intel video drivers 2.2.1 snapshots

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.

The Road to Gnome 2.20

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 🙂

Gnome 2.20 is out of p.mask

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!

Gnome’s cool features : gnome-keyring & pam

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

auth required pam_env.so
auth optional pam_gnome_keyring.so
auth sufficient pam_unix.so try_first_pass likeauth nullok
auth required pam_deny.so

account required pam_unix.so

# This can be used only if you enabled the cracklib USE flag
password required pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 try_first_pass retry=3
password optional pam_gnome_keyring.so
# This can be used only if you enabled the cracklib USE flag
password sufficient pam_unix.so try_first_pass use_authtok nullok md5 shadow
# This can be used only if you enabled the !cracklib USE flag
# password sufficient pam_unix.so try_first_pass nullok md5 shadow
password required pam_deny.so

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 🙂

xf86-video-i810 2.2.0 woes

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.

News update on the Intel Xorg drivers

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.