I’ve been using the hawkey backend on my Fedora 20 system for about 6 weeks now. In that time, I’ve found bugs in hawkey, librepo and even libsolv and I’d like to thank Michael, Tomas and Ales for all the help debugging and reviewing all the fixes. Of course, there were quite a few PackageKit bugs fixed too. So if you’re testing PackageKit-hawkey you really want to update to these packages:
Those updates are currently on their way to updates-testing, but will be in Fedora 20 in a few short days barring any last minute problems. I am now happy we can switch Fedora 21 to using hawkey by default, and reap the rewards of all the hard work put in by so many people over the last few months. I for one am really happy about the speed boost brought to all the applications using PackageKit.
A few nice things have been happening lately. The first is the re-versioning of 0.4.4 to 2.27.1, so that we can stick to GNOME release versions and the promise of release freezes. This should make it a bit easier for distributors, and will make the transition to gnome.org a little bit easier.
We’ve also been doing some tinkering around the edges to make things work better, hopefully without getting in the way. This is shown quite nicely from the following UI from the new update viewer.
Saving you money every day of the week...
And, thanks to Daniel Nicoletti, PackageKit now understands media requests, so the backends can request the user do something with physical media. This is still using the non-blocking logic we’ve always been using, so if we’re using multiple disks then the content has to be copied off each one in turn before the transaction, rather then installing direct from the media. Trust me, it’s better this way.
New media change dialog
We’ve also been removing some dead code (libsexy, libglade, etc), and tidying up the existing objects, so hopefully 2.27.2 can be released in a few weeks. Comments, as always, welcomed.
We’ve got a new experimental update viewer in GNOME PackageKit. It looks something like this:
It’s currently called gpk-update-viewer2, and isn’t the default yet. I’ve patched Fedora rawhide to use it by default so we can get some early feedback and testing.
UI feedback welcome. Some of those strings are mighty difficult to understand, for instance, my fiancée didn’t know what a production system was. I also don’t like how the URL’s look. Ideas please. Thanks.
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.
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.
PackageKit now knows the type of connection you are using, thanks to NetworkManager. Many thanks for Dan Williams for the pointers, and the guys in #gnome-hackers for the wording. Now you can be less scared using PackageKit and “automatically install” when occasionally using expensive GPRS on a laptop.
Please don’t yet update DBus for CVE-2008-4311. It’s known to break PackageKit, cups, ConsoleKit, DeviceKit, DeviceKit-power, gdm, and system-config-services. There’s a partial bugfix that has been pushed so PackageKit tools still run (without the GetTid or SetLocale errors), but as introspection is still broken they’ll be odd little warnings and errors for other stuff.
I do understand how important this update is, but given this wasn’t a root login vulnerability, or anything crazy like that, I’m surprised it didn’t sit in updates-testing for a few days to fix up all the other system daemons. The worst bit is that it’s broken automatic updates for thousands of people.
I’m planning to spend this morning closing duplicate bugzillas. Fun.
I’ve been quietly admiring the Debian BASH command not found functionality for a while. For those unfamiliar with the functionality, it suggests installing packages if you typed a command that is not installed. It also seemed to be pretty helpful suggesting replacements for typos.
When Rahul opened a bug to include this in Fedora, I figured this is just the sort of thing a framework like PackageKit needs to hook into. Roman Rakus put a simple patch in Fedora for bash, and now we’ll try to get it upstream. Then it will work on all distros that support PackageKit.
I spent this afternoon hacking a simple implementation. It’s up to the distro whether it should be installed by default on a base install. It’s also pretty configurable, so if you just want it to launch lshal everytime you type lshla, you can have that. If you want it to ask you before it installs shed to provide /usr/bin/shed, then that’s possible too. The simple configuration file is available here for review.
PackageKit in git master has a new trick up its sleeve. Thanks to Behdad, It now optionally installs a gtk-module that integrates with Pango to detect when a document needs a new font installed to render correctly. No code changes are needed to any application using Pango, as all the magic is done in the gtk-module. When used with a session interface like KPackageKit or gnome-packagekit, the following UI is shown:
Font installer
I really want a way of being able to say “don’t ask about this language again” if not found so to not piss off the user. I also know my grammar is pretty shitty. All comments and recommendations gratefully received. Thanks.
In newer versions of gnome-packagekit there’s a tool called gpk-service-pack:
Service Pack Creator
This tool I’ve explained in the past, and there is now lots of information and diagrams in the help file about how it all works and what the point of the tool is. Anyway, the point of this blog post isn’t to promote service packs; it’s to scratch an itch that I see coming up when Fedora 10 is released.
The tool exposed one detail to the user: a package list.
This is a simple text file such as hughsie-laptop-f9.package-list. This file allows tools to operate on other similar computers with different packages installed. It’s really just a simple list of all the packages installed. It’s contents and format are unimportant for now as it lets you do some cool stuff.
My personal situation, right now: I’m running a F9/F10/rawhide-ish laptop that I’ve been running for a few months, installing packages using yum, rpm and PackageKit, and have now got all the packages I need for building all my stuff, and all the programs I need on a day-to-day basis.
When F10 comes out, I normally nuke / and reinstall from the live CD as I’ve got so much cruft and brokenness from the months of a rawhide development cycle. On the first boot, I run:
yum -Y install <paste long list of packages from a tomboy note that's got bigger over the years>
Now, what I need is an admin tools that says:
Capture all the package names on my old system
Show me all the differences between what I had then, and what I have now
Use the old package list to install all my normal stuff, not specifying versions
So, two hours of hacking later:
pkcon list-create hughsie-laptop-f9.package-list
pkcon list-diff hughsie-laptop-f9.package-list
pkcon list-install hughsie-laptop-f9.package-list
I know I can do some of step 3 using a custom kickstart if I wanted, but I normally don’t know what I install manually. Maybe it’s only me that’ll find this useful. Code is in git. itch2scratch–;
