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.

How to make Gentoo’s CVS access suck less …

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

First post!

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 : lavajoe's hackergotchi
  • opfer : opfer's hackergotchi
  • p-y : p-y's hackergotchi

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 …