Application Installing (II)

I’ve been hacking more on the app-install framework. It’s now an independent project, with a tarball here.

What do the tools do?

$ app-install-create: creates the initial database, only used in the post section of the app-install package
$ app-install-add: adds data to the system database, used in repo packages
$ app-install-remove: removes data from the system database, used in repo packages
$ app-install-generate: generates the data for a desktop file, used when generating data from the distro helper

Now, the latter file is designed to be called from a distro specific helper, so for yum we do something like this:

$ app-install-generate-yum.py –repo=rawhide –dist=./dist

This downloads all the rawhide packages that ship a desktop file, uncompress them, and extract the data from the desktop files. There’s a cache, so repeated runs of this don’t have to re-download all the data. This tool takes about 10 minutes to run when the download has completed.

This tools creates ./dist/rawhide-icons.tar.gz and ./dist/rawhide.sqldata which are designed to be shipped in a distro package file.

In a package file, for instance, fedora-app-install, the post action would be something like:

$ app-install-add –repo=fedora –source=/var/lib/app-install/rawhide.sqldata

and in the preun:

$ app-install-remove –repo=fedora

I’m inviting other distros to submit distro generate tools, and I’ll ship them in the tarball.

Application installing

In the Linux desktop we have a very big problem: We focus very much on packages. Packages are interesting to programmers, but users care about applications.

I’ll explain the difference:

  • Packages can contain none, one or multiple applications. Packages are called “openoffice-common”
  • Applications only belong to one package. Applications are called “OpenOffice.org Writer”

Now, when a user wants to install an application, they have to research on Google what the package name is called (which is different on each distro) or hope that the application name is mentioned in the description of the package in the distro metadata. Not ideal at all.

Now, I said as a desktop we have one big problem, well, we actually have two: We don’t all speak English well. Some of us speak no English at all.

We want to be able to display package descriptions to the user in all languages, but we don’t want to download 80x the metadata to do so. Most packaging systems only understand en_US anyway, and there certainly isn’t the resources to translate every spec file or emerge instruction for each distro. To add to the problems, each package needs an icon, in various sizes so we can show the application icon rather than a generic box.

So we’re sunk, right?

No. In each package, there are desktop files that contain all the applications, with nice translations gently massaged and QA’d by upstream. It would be nice if we could search on that data. At the moment, this is impossible, unless we want to download every package in the archive, and extract the data from it. This is sort of how Ubuntu does gnome-app-install, and it seems to work fairly well. It is Ubuntu specific, but maybe we could work on that.

So, we cache all the desktop files, and push this out to the repo metadata?

No. If you did that you make a lot of people very unhappy, as even compressed the metadata and icons make up over 80Mb.

So we’re sunk, right?

No. What we can do is create sub-packages for each repo (e.g. rpmfusion-appdata) which ships a tarball of icons and a few hundred Kb of SQL. Every time the repo maintainer can be bothered (once a month?) the new data is generated, and a new package pushed out to the mirrors. If the repo maintainer can’t be bothered to do that, then none of the new packages will show up in the application browser. It’s optional.

This data clogs up my system right?

Well, it’s only a few tens of Mb if you want all the icons in most of the sizes, if you only choose the 48×48 option then it’s much less. When you install the new $repo-appdata subpackage, it removes all the stale applications and re-adds the latest data. This happens in the vendor spec files as postinst scripts.

How do I query the data?

It’s a simple sqlite database in /var/lib/app-install/desktop.db — the icons are located in /usr/share/app-install/icons/$size/*.png — there’s no GUI installer yet using this, but expect a few before two long.

Great! Another Ubuntu v.s. Red Hat standards war!

No. Roderick Greening, Sebastian Heinlein and myself together drafted the specification together, and made it generic enough for all the distros to use. It’s totally expected that each distro will code a different tool to extract the metadata, but that’s because they are different in some important ways.

So the maintainers have to install everything just to get the desktop files?!

No. You can download and install a package to a prefix without the deps — we don’t need the binary to run, we just need the data. in this way we don’t need to download -data subpackages, only the one with the desktop file in.

Can I add some more features to the spec?

Yes, in a little while. We want to get version 1 of the spec finished, with it being used in a few distros. When we’re comfortable this works correctly, we’ll start working on version 2, and add stuff like popularity metrics and metadata about suggesting gnome-power-manager rather than kpowersave if you’re running GNOME. There are lots of things we need to add for this to work really well.

So, Comments?

gnome-power-manager and gnome session icon bug

gnome-power-manager shows a GtkStatusIcon of the battery state. When gnome-power-manager is launched from gnome-session at login time, the icon is not shown on the panel, even though the icon name is set and it’s set visible. It isn’t shown even doing by setting the filename icon again and doing gtk_status_icon_set_visible() several seconds after starting. gtk_status_icon_is_embedded() is always false.

If I do “killall gnome-power-manager”, gnome-session respawns the binary (because of X-GNOME-AutoRestart) and the icon shows correctly. It also starts correctly if you launch it manually from gnome-terminal.

Even if I remove the X-GNOME-Autostart-Phase=Panel (so that it starts as an application, well after the panel is formed) it still doesn’t show.

If you’ve got any tips on how to debug this I would appreciate it. I’m out of ideas. Thanks.

gnome-power-manager and processor wakeups

Powertop is a great tool. Is does however have some disadvantages:

  • ncurses GUI
  • You have to run it as root
  • It gives you hardcore suggestions that you have to do manually, which in turn disable bits of the desktop
  • You can only run one instance of powertop at a time, else you get crazy readings
  • There’s no shared library giving access to the data
  • It’s not extensible, so you can’t do much with the data

Now, it turns out the actual data processing code of powertop is pretty easy, sampling /proc/interrupts and /proc/timer_stats every few seconds and throwing away interrupts that are defered and that sort of thing.

In a couple of hundred lines of C, I’ve added this support to DeviceKit-power on a new DBus interface, and added a trivial GObject helper for applications to use.


Long term I want to get this functionality in gnome-system-monitor (it’s querying a simple DBus interface), as I think this data better fits there. gnome-power-statistics is just a handy module that already depends on DeviceKit-power.

As usual, comments and suggestions welcome.

gnome-power-manager and buttons

Another change coming in 2-27 – gnome-power-manager will stop listening to HAL for button events. Peter has been rocking with evdev over the last few months and now all the multimedia buttons come up through both X and HAL. g-p-m has to filter the second button, and mostly this works well. Some distros are still not configuring evdev properly, and some still inject events into HAL, or rely on HAL to scrape events from oddball kernel interfaces. The way forward is using INPUT in the kernel, and the vast majority of events are now coming through INPUT from random devices, and through X to applications.

Inhibits, and the new world order

Once upon a time there were three inhibit API’s:

Obviously, this has a few big flaws:

  • An application might have to inhibit three services, using slightly different methods
  • gnome-screensaver has to expose lots of low level icky stuff for g-p-m to consume
  • We’ve got a screensaver doing idle detection
  • We’ve got gnome-power-manager writing into gnome-screensaver GConf keys to get the timeouts correct
  • It’s not possible to prevent logout or user switching
  • The hand-off between the session and power manager is poorly defined, so we get stupid libnotify popups rather than nice dialogue integration.
  • We don’t integrate with presence services, so we just ignore away/busy/idle status.

Basically, we need the session manager to take care of the all registrations and handle the interactions. Luckily, this is what Jon McCann has done in gnome-session.

These new interfaces are session management done right. Of course, this breaks the old world order of inhibiting gnome-power-manager and gnome-screensaver. For the 2-26 series all inhibits are proxied by g-p-m and g-s to gnome-session, so everything should pretty much just work like before. But, early in the 2-27 cycle we’re going to remove this compat code and everything will have to go through gnome-session. For most code it’ll just be a couple of lines changed and behind the scenes it’s a much simpler and more powerful design.

Like some of the other changes we are making at the moment (DeviceKit, PulseAudio, KMS) this is a new way of doing things, and things might temporarily break. They’ll be regressions, but things can be fixed quickly and most importantly, correctly. What we were using before just wasn’t good enough. With this new framework, we can do it right for GNOME 3.0.

Libnotifytastic

Every now and then, somebody chastises me for abusing libnotify to display something to to user. I guess it’s easier to just spam a fire-and-forget notification that thinking about how to present the data properly to the user.

A classic example is the messages the PackageKit daemon passes to the client program. These messages are packets of data containing the message type and any specific details. An example of this might be a message telling you that a config file has been automatically merged, or that a non-critical error has been worked around. These also tell you when things like prelink fail, which is a pain when you’re running something like rawhide. These messages arrive as the transaction is running, and are designed to be shown to the user at the end of the transaction and not get in the way.

Now, due to some “just get it working as quickly as possible” design standards, I used libnotify to display these to the user. Bad me. My excuse is that I’ve been very busy with other stuff, and life seemed to get in the way over Christmas.

Now I guess the right way to show the user this sort of data is for an icon to appear, something like this:

When the icon is clicked, something like this would appear:


So comments and feedback appreciated. No code in git yet, until it looks nicer. Thanks.

Microcode pushes and pulls

Every time I start my laptop, I get a firmware request from the kernel for /lib/firmware/intel-ucode/06-0f-0b for a microcode update. This fails, and no package provides it, but I would like to know why the kernel is requesting this. As far as I knew, all microcode is located in microcode.dat, and pushed from userspace to kernel using microcode_ctl, rather than the kernel requesting it itself. If I can’t find any explanation, I’ll just block all microcode requests in the client to avoid PackageKit users having searches automatically done for files that aren’t going to exist.

Help appreciated. Thanks.