Month: March 2012

Building GNOME For Fedora 17

At the moment the GNOME updates in Fedora are a bit of chaotic affair. They mostly work, but only because of people like Matthias who spend hours and hours building packages and putting everything together manually.

For 3.3.92 I experimented doing a mega-bodhi-update and trying to get all the 3.3.92 builds in one place, and working with other people on a google spreadsheet to make sure everything was built in good time, and nothing was left behind.

For the GNOME 3.4.0 release, I’m asking people to copy this pattern, and try to get all the builds into *one* update rather than 90% of the builds in one mega-update and then 10% in random updates that other people have filed. If this works, I’m intending to do the 3.4.1 update as one update as well.

TL;DR. If you’re packaging a GNOME package that’s just had a 3.3.92 upstream release and is about to have a 3.4.0 release, please build the package like normal, but don’t file an update. Instead add the build ID to the spreadsheet and then I’ll pick up the build for the mega update for F17. Hopefully this makes the updates system easier to QA, as GNOME is more and more interconnected, and it’ just not possible to QA updates when you have a 3.3.91 version of gnome-settings-daemon and 3.4.1 version of gnome-screenshot.

 

Zif wants new blood

A few years ago I wrote Zif, which is basically a package tool that works with librpm and the Fedora metadata. Zif is very much of a side project for me, mainly written out of curiosity and to try and make things work a bit faster just when using PackageKit. It seems most people try to write a package manager at some stage of their open source career. :)

So, fast-forward a few years. Quite a few people are using Zif now, and there are even a few people writing new code and fixing bugs. I’m wondering if anybody new to programming or new to open source wants to help me improve Zif, and to try to fix little-but-important self contained bugs like this.

Anyway, if you’re interested, let me know. Thanks.

SANE crashy crashy

I spend quite a lot of time triaging bugs in Fedora for stuff I maintain upstream. The most common crasher bug I come across is colord segfaulting deep in libsane. Digging even more, 99% of those libsane crashers are when the user has installed closed source binary drivers to make the scanner “work”.

Of course, segfaulting colord just because it automatically assigns color profiles to scanners is not a good idea, even if we can blame non-free code. Something had to be done, as it was starting to make colord look bad as all the display and print color management would suddenly stop working in quite a dramatic way.

Now, in an ideal world, there would be a scanner daemon, scannerd, that I could patch for colord support, just like we’re doing for printers and dispays. This would then register devices with colord, and if it crashed, it could be autorestarted. Such a thing doesn’t exist, and so I had to do something that involved separating the libsane code from the main colord process.

In git master I’ve added a tiny dbus daemon called colord-sane, that basically does nothing except for rescanning sane whenever a USB device is plugged in and creating and deleting devices in colord. It only has one method “Refresh” and it is started when colord is started (usually in early boot) if the UseSANE=true option is specified in /etc/colord/colord.conf

In an ideal world, someone could take that code, and make a proper scannerd or saned project that adds some DeviceAdded and DeviceRemoved signals, a GetDevices() method and some more properties on each device, hopefully using something l33t like GDBusObjectServer. This would mean that the session could just use that for device discovery (e.g. in Simple Scan) and the world would be a much nicer place.

So, if you see a tiny colord-sane process show up in your system that’s not doing anything, don’t panic. You can disable the functionality if you know you’ll never have a scanner attached.