Gentoo, btrfs arrays and systemd: a public service announcement

This week, I upgraded my media center/filer and after a reboot (new kernel), systemd was blocking on my btrfs mount. It’s a 3-partition RAID1 array (until upstream says RAID5 is safe). Systemd was somehow waiting on it, with the infamous red spinner. Adding noauto to fstab did allow the machine to boot properly, but the mount itself silently failed: mount /my/mount/point would return 0 but nothing would show up in /proc/mounts nor in the mount point itself.

It turns out that the latest version of systemd reaches the local-fs target faster than earlier releases (at least that’s my theory) and the kernel has not yet fully figured out what partitions belong in which array. So what I needed was to tell systemd to run btrfs dev scan before attempting to mount local filesystems.

While searching for clues, I came across this stack exchange question which has the correct answer (though I did make a few changes). I’ll reproduce here the correct version for Gentoo, in case anyone runs into this:

$ cat /etc/systemd/system/local-fs-pre.target.wants/btrfs-dev-scan.service
[Unit]
Description=Btrfs scan devices
Before=local-fs-pre.target
DefaultDependencies=false

[Service]
Type=oneshot
ExecStart=/sbin/btrfs device scan

[Install]
WantedBy=local-fs-pre.target

I’m not exactly sure why “local-fs-pre.target” needs to be specified three times (twice inside the file, once in the path), but it does the trick: systemd waits for btrfs’s device scan to return before mounting file systems. Maybe btrfs-progs should ship such a file…

As a side note, while digging for information, I found out that systemd actually reads the fstab and translates it into unit files at boot time. The generated files are located in /run/systemd/generator/.

One final piece of information: if I had taken the time to read journalctl -b carefully, I would have saved hours. If you have any issues with systemd, read the damn journal.

I’ll take the opportunity to thank the kinds folks of #btrfs on FreeNode who promptly helped me.

That’s it for tonight, thanks for reading.

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: org.gnome.shell.location.max-accuracy-level. 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 https://wiki.gnome.org/action/show/Projects/dconf/SystemAdministrators 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:
    user-db:user
    system-db:site
  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’
    [org/gnome/shell/location]
    max-accuracy-level='off'
  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.

Bug in xorg-server and random thoughts…

Zach recently wrote a post about an issue he’s had with fresh installs of x11-base/xorg-server and the Intel driver. The bug was already filed and Michał Gorny (our next recruit!) had already provided a patch.

However, it took more than 2 weeks to get this fixed, and that’s what I want to talk about today:

  • Lack of time from current team members. We’re all busy with Real Life ™, my job keeps me busy, Tómaš – when not busy having his skull reconstructed – is also busy with his job, and Chi-Tahn is busy with university. Help, in any form, is always welcome!
  • The bug was filed more than 2 weeks ago but was not assigned to the x11 team. We weren’t even CCed on it! It just didn’t show up on my bug queue and that’s partly why I kept forgetting to fix it. Bug triaging is vital for Gentoo, help is needed there as well.

So that’s it for those semi-random thoughts, it gave me a reason to blog about something…

Call For Testers: Xorg 1.7 going stable

It’s been a while since we last stabilized a new version of Xorg, so we’re calling for stable testers again.

Please head over to bug #308521, grab the latest stabilization list and append it to /etc/portage/package.keywords. Then run emerge -DuNa world to upgrade your system. You’ll have a brand new Xorg version.

Intel users may have to use a newer kernel from ~arch.

Any help will be greatly appreciated.

Update: Please don’t comment on the linked bug if you have issues. File another bug report, do point out that you’re testing out Xorg 1.7 and we’ll help you out as best as we can.

Christmas left-overs

Beware : non-Gentoo post ahead, feel free to skip if you don’t care, I won’t hold a grudge against you.

By all measures, I can safely say I’m not really a Christmas-y fellow. I hate Christmas shopping because I’m really bad at it (or is it the other way around?), I give the rest of my family a hard time at Christmas since I never know what I want and I’m really hard to shop for (took me 3 years to find an MP3 player that matched with my needs).

And usually, just a few days before Christmas, I’ll turn into the Grinch: people on the subway carry even bigger bags than usual, people on the streets are way more careless than usual, ads and commercials everywhere overload my senses with Christmas references, etc.

So there, Christmas is not my favorite time of year.

However, there is something I love about Christmas: food. Point in case, I just had left-over foie gras along with a glass of Sauternes.

I’ll just say that after my light lunch, I positively love Christmas.

Edit: To all the people who are trying to ruin my Christmas left-overs by trying to make me feel guilty about how foie gras is produced: take a step to realize that all industrialized agriculture works like this (especially eggs), not just foie gras. So unless you are 100% vegan, don’t even try. If you are vegan, then just forget I even talked about the foie gras and have a glass of Sauternes, I’ll happily share the rest of my bottle.

Looking for a padawan, Part II

Gilles had me promise to write a follow up to a post of his, and since I don’t want him to call me a liar, here goes.

The Gnome Team (of which I’m officially a member, but I guess it’s mostly honorary these days) is looking for fresh blood. Between our day jobs, the growing size of Gnome and slacking recruits (/me waves at Arun, Nirbheek and Romain :>> I’m just kidding, you guys rock!), we’re having a hell of a time making proper releases. You may not realize, but a full Gnome release is something like 60+ packages to bump, build and test.

So if you’re a Gnome user, here’s how you can help us.

First of all, the Gnome overlay. That’s where upstream’s odd-numbered releases go before we put them in portage. As of today, that’s Gnome 2.29. If you want to start helping, then grab the overlay with layman and start testing. Update the overlay every day and report bugs. First to us on IRC, then upstream if needs be.

Second way to help us, the Gnome overlay. Yeah, like #1. Except this time, you can pitch in by doing bumps as they come in. The best way to check new releases is Gnome’s ftp mailing list. You can do bumps locally and then push your changes to github or send us git-formatted patches.

Of course, come talk to us so that we can better explain how our ebuilds are supposed to work and how we do commits. Aside from me, no one has swine flu so the chances of getting sick are close to none.

Like most projects, if we like your work, we’ll gladly grant you commit privs to the overlay. That’s how Gilles and I first started.

Third way to help, bugzilla. That one’s easy. Pick a bug, help us close it. It doesn’t necessarily have to involve coding. A message telling us that you can still reproduce this bug several months after it was reported is good, forwarding bugs upstream is good, sending us a patch is good, closing a bug as a dupe of another bug is good, any help is good.

The big problem we (Gnome team) have with bugzilla is that we just have too many bugs and we just can’t keep up.

So any help with the “easy” bugs means the other Gnomers can spend time on the harder bugs.

If you want to help or if you have any questions, come see us on #gentoo-desktop on FreeNode.

Cheers

Attention all stable users

Tomáš (scarabeus) and I decided it was time to do another round of stabilizations.

Back in September when we stabilized xorg-server 1.6, upstream was in the process of releasing Xorg 7.5 (which includes xorg-server 1.7, are you still following?). So at that time, we decided to still go ahead with 1.6 and include the bits of 1.7 that were available and compatible.

Now that 7.5 has been fully released, we’re doing another mass stabilization… but without xorg-server 1.7. While the server itself is very stable, a few drivers still aren’t compatible with it. So we’re not going to stabilize it now. So we’re just stabilizing utilities and a few drivers, nothing major.

So yet again, I’m requesting help from stable users:

  1. go to the stabilization bug,
  2. grab the latest stabilization list and copy it to /etc/portage/package.keywords,
  3. update your system with emerge -DuNa world.

As always, bugs should be filed in bugzilla, not in the comments.

Response to a comment

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.

Xorg-server 1.7 in ~arch

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.

xorg-server 1.6 is now stable on amd64, other arches to follow soon

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 :

Don’t forget, please file bugs in bugzilla.