Technical Blog of Richard Hughes

Ania and I spend a good chunk of this weekend calibrating more ColorHug devices, the open-hardware colorimeter. A combination of me being unwell last week and the stress of a house extension (and a baby on the way) meant this batch has been far more delayed than we wanted it to be. Devices can be purchased on the website with no pre-order required as we’ve now worked through the backlog and have got stock spare.

If you’re interested in the latest things we’ve been working on have a look the FAQ entry about the new measurement modes available in the latest experimental firmware.

Thanks!

All weekend I’ve been hacking on PackageKit and systemd to be able to have a GNOME 3.6 user experience that looks like the new update mockups.

So what’s the plan?

• gnome-settings-daemon will automatically prepare the transaction using PackageKit downloading all packages (either all, or just security updates) and deps which in turns creates a /var/lib/PackageKit/prepared-update file when ready [works]
• If /var/lib/PackageKit/prepared-update exists then gnome-shell will show a “Restart and install updates” option, that if clicked will call pkexec pk-trigger-offline-update which creates /system-update and the session is rebooted [needs gnome-shell patch]
• On next boot, if /system-update exists, then the systemd generator starts system-update.target which in turn starts packagekit-offline-update.service, which in turn makes PackageKit run the prepared update transaction. On error, /system-update is removed, and on success both /system-update and /var/lib/PackageKit/prepared-update are removed. [works]
• Plymouth will show a package icon (or something) with a widget that fills up as the transactions are processed (0 to 100%) [needs-work]
• Plymouth will show a message after the updates are applied like “Rebooting after installing updates” [needs-work]
• Show a message at next boot if the offline update succeeded or failed [working-on-right-now]

So why bother with all this?

• Installing updates while the session is running causes havoc with some apps like firefox that have file resources that have not been locked (just try updating xulrunner when firefox or thunderbird is open…)
• Installing library updates when apps are running against the old copies means the processed need to be restarted (gnome-session, sshd, etc) before the changes are in effect (for all users logged into the machine)
• Installing core OS updates and doing OS upgrades in the running session works for most people most of the time, and then when it fails it destroys your system completely with no way to recover
• Using a minimal pre-boot environment we can snapshot the system before we update the OS and afterwards (requires btrfs or something else)
• Using a fresh pre-boot environment means we can easily check OS sanity before we start updating core bits of the OS, without lots of additional processes running.

Of course, we’ll still support updating applications in the session for GNOME 3.6 (as long as they are not running) just not the core OS bits. Comments, as always, welcome.

From the 16th to 19th November we’re planning a hackfest in Brno, Czech Republic. The venue is kindly being sponsored by Red Hat.

What we’re trying to achieve is to get all color-minded people in the same place at the same time, to try to join up some of the color management stack in Linux. We’ll be discussing toolkit color management, the print color pipeline using CUPS and printerd and application level color management. It’s being arranged by S.Kemter and Kai-Uwe Behrmann so if you want to be there, email one of them or jump into the #openicc channel on freenode. There’s some sponsorship available, but not a lot. It’s also going to be a hackfest, i.e. writing code rather than giving talks like “a dummies guide color management”. I’m pretty excited.

I’m at LGM this year, and so far it’s rocking pretty hard. The number one question people have asked is “how do I get the screen profile for a window“. I figured this should be easy to get using colord, and then spent a few minutes working on some proof-of-concept code. This ballooned into a couple of hours doing it properly asynchronously and making it work correctly on multihead, and the result was a few hundred lines of complicated code with quite a few exit points. I don’t want people to add 300 lines of boilerplate to their project just to map a GtkWindow to a .icc filename.

So I’m now shipping an additional optional colord-gtk helper library in colord that allow you to use one async function to get the profile a given widget should use. There’s a demo available here.

The alternative is of course to read the X11 _ICC_PROFILE atom, but that does not support multi-head, and really won’t work when we move to Wayland. It’s also not a lot of fun grabbing lots of binary data from the xserver in a GUI program. In the long term future we’ll be doing full screen color management in shaders, with full toolkit support using Wayland, but that’s a few years from being reality. If you’ve got any ideas or have comments about the API, let us know on the mailing list. Thanks.

Nobody refers to “Running Fedora Verne” and choosing the name every few months is just a giant waste of time and waste of a very busy legal team that has to review and research each stupid name. I think “Beefy Miracle” is a ridiculous name that really takes the edge off an otherwise most professional release.

Just have the next release name as Fedora 18 and be done with the nonsense names once and for all.

Daniel released colord-kde 0.2 today. I’m really excited about the amount of progress he’s made in such a short amount of time. He’s has had a bit of rough ride with the loss of his daughter last year and this year he’s been hacking on colord-kde and PackageKit and trying to make open source a better place. If you’ve got a spare couple of dollars this month, he’d really appreciate a donation to buy hardware to test things on.

I was a strapped-for-cash geek myself a few years ago, and I know how hard it was to develop software when you don’t have the right hardware. I donated $25. Donate here. Thanks.

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.

 

Great news this morning when I saw that Daniel had released the first version of colord-kde.

If you’re a KDE dude, please try out the tarball and let us know what you think!

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.

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.