Technical Blog of Richard Hughes

One of the best parts of working at Red Hat is that you are encouraged to do things properly, even if they take a long time. I guess the logic is that if you’re going to be supporting the code in RHEL for years and years, then it pays to do it the right way, and not use some evil hack that’s going to break for a customer at some inopportune time.

As some of you might know, I’ve been hacking on colord for a few months (at the same time as PackageKit, upower and GNOME3!) and am now starting to get some upstream progress. To fix color management when printing, we really need to integrate with quite a few layers. This afternoon I rewrote pstoraster and pdftoraster into gstoraster, and added the required hooks to get the ICC profile from colord. I’ve still got to do the same for foomatic-rip, and then that’s the “query” side of the problem finished.

The next part, is to finish the work done by Tim Waugh, so that CUPS registers devices and embedded profiles with colord. With all the patches in place, it basically means that making a printer color managed becomes trivial.

Thanks go to Till Kamppeter for reviewing the different iterations of the ghostscript filter code patch, and initially pointing me in the right direction. Now I’ll brave CUPS upstream and try to get the other patch accepted there.

This is probably all a bit late for GNOME 3 and Fedora 15, but you can be sure that GNOME 3.2 and Fedora 16 will look consistently beautiful across all different types of devices. If you are feeling brave and want to try it out, try the “icc” branch of cups, the “colord” branch of gnome-color-manager, and the recently released colord 0.1.3.

Imitation is the sincerest form of flattery: YUM is getting a DBus API.

Dear rpmfusion. Please build codec packages for Red Hat Enterprise Linux 6. My wife is stuck in bed and wants to watch a movie.

Thanks, The Hughes Family.

In GNOME 3.0, we’re defaulting to suspending the computer when the user shuts the lid, and not providing any preferences combobox to change this. This is what the UI designers for GNOME 3.0 want, and is probably a step in the right direction. We really can’t keep working around bugs in the kernel with extra UI controls.

This will upset people who are docked or using a laptop for a presentation with a projector. Worry not! If you have more than one active screen connected to the machine, then we’re going to just disable the internal screen and not suspend until the second screen is removed.

This will upset some macbook owners if they connect a projector and then shut the lid. Some macbook laptops overheat when the lid is closed and not suspended, leaving the owner with a hot white glooopy mess when they finish their presentation. This is something we can do something about, but I need the help of the community to work out what makes and models need to be blacklisted.

If you own a laptop that gets very hot and starts to smell like hot plastic if you shut the lid without suspending, please send me the output of dmidecode and I’ll add the entry into upower. Thanks.

EDIT: Comments are now closed. Please see this entry from Allan Day.

For three days last week I attended a conference on application installing in Germany, hosted by Vincent Untz and the other guys from Novell. There were experts sent from Fedora, Ubuntu, Debian, Suse, and Mageia. From Fedora both I and Florian Festi attended.

The idea of the conference was to talk about defining some APIs we can share, to discuss interchange formats, and talking to the UI designers to make installing and removing software on Linux suck less.

Overview:

• Lots of progress, people were willing to help solve a common problem in a unified way.
• The right people were at the meeting and we came up with a really good technical plan with action items.
• Ubuntu Software Center really kicks ass, although we really need them to drop the CLA. USC will be ported to use PackageKit in the next couple of weeks.
• Packages and packaging are not that interesting to the end user.
• We will integrate with online social services to provide features like ratings and comments using OCS. OCS needs a couple of things added to the API, which will happen in the next few weeks
• We will produce appdata.xml metadata per-repository, rather than one super-package.
• I need to talk to the fedora-infrastructure guys – it might make sense to not refresh the metadata every day for the rawhide compose.
• We will use a xapian index to query the desktop metadata, rebuilding as repos are added / removed. This supports fast stemming and other advanced features.
• Will add several new optional fields to desktop file specification upstream for the proper solution, more details to come soon. This will allows us to search for photoshop and return gimp in the search results.
• Non .desktop files as applications do make sense, e.g. firefox plugins as .xpi or Chromium style web links. This makes sense to push to OCS, rather than in the distro metadata.

What this means for Fedora:

• We add a tiny script (to be written this week) to generate the xml file and the icon tarball for the distro at compose time (similar to my earlier app-install work)
• We ship the extra optional metadata in the fedora mirrors (+~9Mb)
• We download this in PackageKit if a repo is enabled or refreshed

We’ve put a few detailed documents with architecture plan on the wiki and Vincent has also uploaded all the notes from the meeting to the same location.

For more information still, there was a presentation we gave at the end of the conference. It’s nearly an hour and gets pretty technical, so get coffee before if you click the video.

Thanks again to Red Hat for sponsoring my travel and hotel expenses.

In the last couple of months, I’ve been talking quite a bit with Tim Waugh about color management of printers, and how to achieve working CM with CUPS. At the moment, gnome-color-manager locates CUPS devices and allows the user to calibrate them and assign profiles, but CUPS doesn’t actually use the assigned profiles for printing. Oops.

Needless to say, the combination of CUPS, ghostscript and other complicated little-known parts of the printing stack make this look almost impossible. OSX uses CUPS and CM works really well on printers using Apple products — and so it must be possible. We need to make it work on Linux too before Linux can become a serious option for artists and media professionals.

OSX uses a system-wide framework called ColorSync that does all the device<->profile mapping, and allows the user to change the ICC color profile for each device, and also allows the user to choose internal profiles listed in the printer definition file. ColorSync works really well, and is an integral piece of the OSX operating system.

GCM is a session process that provides session programs access to the per-user color management settings. Because GCM is running in the session it can integrate deeply into the GNOME desktop environment and is not particularly security sensitive. But, because the framework is per-session, system frameworks like CUPS cannot access the data, and we also have to rely on cludges like naming the display ICC file to be the same as the device ID and putting it in a well know location to be able to have a color corrected GDM screen. Urgh.
So, we need a trivial device<->profile daemon that works like a subset of ColorSync that the session GCM instances can use for defaults and also set profiles system wide for projects like CUPS. Over the Christmas holidays I wrote a small dameon called colord that provides a way for applications (or other daemons) to create, destroy and assign devices and profiles.

colord doesn’t do any file parsing or anything terribly unsafe, it’s just a simple system activated system DBus PolicyKit enabled daemon that has a simple database of devices that can reference specific profiles. Profiles are optionally assigned ICC profiles, and also have qualifiers that can be used to match them. For instance, a qualifier could be Epson.RGB.300dpi, which would match from the qualifier search of “Epson*”.

One thing to note: colord isn’t anything related to systemd. The name was chosen because colordaemon was too long to type and ColorManager and ColorKit names were already taken. It’s also intentionally techy, as users are not going to have to interact with colord whatsoever.

At the moment there is a test GTK application for developers and color geeks shipped in the colord package, but long term GCM is just going to use colord and all the configuration and settings will be done in the session by GCM itself.

Tim is working on the CUPS parts as I speak, and hopefully we can have something working in a few days. Exciting times.

This week, I’ve spent a bit of time working on a network panel for the new control center. The old network settings configuration dialog allowed you to do everything to anything, and most users (myself included) only touched a fraction of one percent of the functionality, and the complexity of other other controls made the UI very difficult and unintuative to use.

In the design research we’ve looked at what other OS’s do, such as Meego, OSX, etc and have started working on some design mockups. The network control panel will probably change quite a lot in GNOME 3 from what I’m showing here, based on user feedback and designers doing proper mockups. So, onto the interesting bit:

It’s all work in progress, and comments welcome. It’s using NetworkManager as a backend. Woot.

Last week I sat down and implemented some of the gnome-control-center mockups for GNOME 3.

This is the screen mockup, which as the name suggests, is all the settings related to the screen.

We’ve also made the power panel much, much easier to use. All the power-user settings are still available in GSettings, if you’re the geeky sort who likes to tweak. The conclusion we’ve come to, is that we should fix drivers, rather than provide workarounds for hardware bugs in the UI.

This is all available right now if you compile using jhbuild, and will be available in Fedora rawhide soon.

Yesterday I merged a patch to PackageKit which added the UpgradeSystem() method to the transaction interface. This is the natural compliment of the GetDistropUgrades() method which was added last year. This allows a session user to upgrade the OS using the same familiar PackageKit tools, and without doing dumb things like asking for the admin pasword and running GTK and python graphically as the root user.

In Fedora, we use a package called preupgrade. This was created by Will Woods and Seth Vidal in 2008, and I was asked to maintain it last year. I’ve been helped by James Laska, which has been very much appreciated. Preupgrade has been fixed up a few times, but the majority of the code is the same as when I inherited it. Preupgrade was a nearly-good-enough monolithic lump of code that kinda worked.

In my humble opinion, Fedora (and all other distros) are too small to maintain such mission critical stuff such as distribution upgraders. The PackageKit project has shown people that by distributions combining forces, they can share frontends and write different small backends and free up developers for other things. As a team, we have a better quality product than the results of one developer on one distribution.

So I figured preupgrade should have the same love. 99% of the preupgrade code is GUI interface code and this was easily converted to C, and to use PackageKit. The result of this is in gnome-packagekit git master, with a new tool gpk-distro-upgrade.

Don’t go and try this code just yet. None of the preupgrade backend code has been moved to the yum backend, although I don’t assume I’ll have many problems, and plan to do this later in the week. If you want to test this use the “dummy” backend, although this won’t actually perform any changes of course.

Hopefully some of the other distros can play with gpk-distro-upgrade and improve it. Hopefully the translators will file bugs about the bad English, and translate it to 50 languages. Hopefully another distro will port their os updater to use this new functionality and find bugs or speed up the common code a little.

All I know is preupgrade will live on as part of PackageKit, and now it’s targeted at a bigger audience than just the few million of Fedora users.

PackageKit tries really hard to work for these people. PackageKit is designed for these people.

Debconf is a simple protocol that dpkg uses to ask the user configuration data at install time. I think it’s generally a bad idea, as installing should generally be silent and automatic and configuration should be a separate step. That said, PackageKit needs to also work on Debian, as some people seem to really like debconf and are not happy shipping a PackageKit that won’t talk the debconf protocol.

So, last weekend I sat down and wrote the required PackageKit-glib2 patches to make the PackageKit-enabled frontends setup a pipe for use in apt, and to spawn debconf when required. Of course, this is a no-op for things like searching and when a package needs no configuration, but for other packages it blocks (urgh) the transaction and the user gets asked questions. Of course, if the transaction is running non-interactively, then the backend won’t ask any questions at all.

Of course, I’m kinda disappointed someone from Debian didn’t write the patch themselves; with all the blogs, wiki articles and emails about the “lack of debconf support in PackageKit” it would have been less typing to actually write the patch. Hey ho, it’s done now. If you install the recently released 0.6.10, then it “just works” with no re-compiles of any front-end clients required.

Of course, I should also like to thank Daniel Nicoletti and Sebastian Heinlein for development help, and Matthias Klumpp for testing. Thanks.