Mumblings about Gnome 3.12, geolocation and gsettings/dconf

A couple of days ago, like everyone using ~arch, I upgraded my Gnome desktop to 3.12. Though a few packages failed to build, the upgrade itself went pretty smooth. Hats off to the Gnome herders.

Overall, 3.12 feels like a solid and well put together release. There were a few disappointments. The biggest of which being the removal of changing tab titles in gnome-terminal. I’ll spare everyone a long rant but this is feature I have been using extensively for the better part of a decade and I’m very disappointed to see this useful features go away without much justification. Material for another blog post… maybe.

One thing I did notice really quickly is the new geolocation entry in the shell’s main top-right menu. Not being a fan of geolocation, I went out to see how I could turn it off by default system-wide as my system has more than one regular user.

Going through dconf-editor, I found the correct setting key: This key is an enum and the correct value (at least to my taste) is ‘off’. Setting this for each user is a matter of running “gsettings set”. However, to change the default value, a little elbow grease is required.

GLib’s GSettings is actually an API for various backends. The one we use on Linux is dconf. So this is what I’ll have to bang on. This basically has all the reasoning behind it all. I’ll just summarize what I did.

  1. Create a /etc/dconf/profile/user with the following content:
  2. Create a matching ‘site’ settings database (I could have called it anything really) in /etc/dconf/db/site.d/ containing my new default settings file ’00_settings’
  3. Run ‘dconf-update’ which will translate the INI-like settings file into a binary dconf file ‘/etc/dconf/db/site’

Now, I assume GSettings did not pick up this new profile on its own, so I had to restart my session. But from there, all changes to the settings file followed by a ‘dconf update’ automatically propagates to running applications, gnome-shell included.

Overall, this was easier than I anticipated. Hope that helps anyone trying to do similar things.

The Road to Gnome 2.22

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 ?


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

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 :


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.


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


auth required
auth optional
auth sufficient try_first_pass likeauth nullok
auth required

account required

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

session required
session optional auto_start
session required

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 🙂