Category: Uncategorized

Recently I’ve been looking at the abrt project. It’s looking pretty good so far, with one notable exception: Currently they install the debugging packages using the Fedora script debuginfo-install, and scrape the standard out for errors, and inject to standard in an unconditional ‘Y’ to anything that looks like a question. The script is also used by gdb to ask the user to install certain debuginfo packages. It’s not great form to ask the user to run a random command, when the program is more than capable.

Program received signal SIGINT, Interrupt.
0x00a63422 in __kernel_vsyscall ()
Missing separate debuginfos, use: debuginfo-install DeviceKit-003-1.i586 DeviceKit-power-009-0.74.20090628git.fc11.i586 GConf2-2.26.2-1.fc11.i586

Now, some explaining. Fedora stores debuginfo packages in separate debuginfo repositories. This means the install-debuginfo script has to enable sources, get the deps of the packages to install, and install as many of the debuginfo packages as it can find, and then disable the sources it enabled. This is all horribly Fedora specific, and of course has to be done as root.

[hughsie@hughsie-laptop src]$ debuginfo-install DeviceKit-003-1.i586 DeviceKit-power-009-0.74.20090628git.fc11.i586 GConf2-2.26.2-1.fc11.i586
You must be root to run this command.

For a cool trick, I’ve make a PackageKit version of this script, called pk-install-debuginfo. It does exactly the same thing as the Fedora debuginfo-install script, but runs as the user and uses all the PK methods underneath the hood. So in theory pk-install-debuginfo would run on Kubuntu or on Foresight (or the others too) with a little tweaking.

[hughsie@hughsie-laptop ~]$ pk-debuginfo-install DeviceKit-003-1.i586
1. Getting sources list...OK. Found 10 enabled and 29 disabled sources.
2. Finding debugging sources...OK. Found 4 disabled debuginfo repos.
3. Enabling debugging sources...OK. Enabled 4 debugging sources.
4. Finding debugging packages...OK. Found 1 packages:
5. Finding packages that depend on these packages...OK. No extra packages required.
Found 1 packages to install:
1    DeviceKit-debuginfo-003-1(i586)    fedora-debuginfo
6. Installing packages...OK.
7. Disabling sources previously enabled...OK. Disabled 4 debugging sources.

Except it won’t, as other distros do things differently. I’m guessing some store the debuginfo files in the main repositories (and hence no sources need to be enabled), and some others call the files -dbg rather than -debuginfo. So now I need your help. If your distro does things differently from the Fedora way, please tell me how, and I’ll add support for it in pk-install-debuginfo.

Of course, if the sources are signed and no repos need to be enabled, then things just install without authentication. This is how it’s supposed to work. I’ve also added a man page and I’ll be adding a config file for pk-install-debuginfo soon.

Of course, if you don’t like the idea, just pass –disable-debuginfo-install to the configure script when compiling PackageKit. Comments welcome.

In times of 2-21 to 2-25, gnome-power-manager maintained an big fat elaborate cache of power devices and combination devices which was populated by HAL. This allowed us to have “virtual” devices such as multiple composite laptop batteries. This abstraction sucked and made some horrible assumptions about devices. And it was slow.

These virtual batteries were used for policy, and generally multiple batteries sort-of-just-worked, with a few random things happening when the engine virtual layer fell down. I couldn’t test virtual devices, as my Toshiba only had one battery with no expansion available, so I relied on random patches from strangers.

Fast forward to last-week/2-26/DeviceKit. Now gnome-power-manager had a very small new ‘thin’ engine with all the devices supplied by DeviceKit-power. Batteries, on the whole were a whole lot more predictable, and the architecture was at last fairly sane. I had now got a nice shiny Thinkpad, still with only one battery, but with extra space for another. But wait, I know what you are thinking; Thin engine means no composite devices, which makes people with multiple battery laptops sad.

Fast forward to this weekend/2-27/DeviceKit. My ultrabay battery arrived in the post from the US (with customs charge, bahh) which I plugged in to the Thinkpad. Much hacking was done, and a few changes (related to empty batteries) went into DeviceKit-power and a few changes went into gnome-power-manager. Now we have a composite store with a thin engine, so the best of both worlds.

So, long story, short: if you have laptop with multiple batteries and your experience with gnome-power-manager sucks, update to git versions of DeviceKit-power and gnome-power-manager. I’ll be making releases later this week, and backporting to stable once it’s had some testing.

I’m thinking of buying an ASUS EEE 900A for testing power saving stuff and generally having a Fedora machine to travel with on the bus rather than the N800. Any advice? Thanks.

Yesterday, somebody asked me on IRC if there was a list of projects using PackageKit. I said no. I’m now adding a section on the website with just this content.

So, please send an email to me or the mailing list if your project is using PackageKit BY DEFAULT. This doesn’t mean “can be installed on”, but means “is usable when freshly installed”. I think it makes sense to add projects like nautilus that hook into the session interface too.

So far we’ve got replies from Fedora, Foresight, Moblin and Kubuntu. If you’re interested, please follow the instructions here or email me off-list. Thanks.

I’m looking for ideas for a web host to replace namezero. I’ve been with namezero for years and years for my personal website mostly due to laziness, but now their service has got beyond a joke and I’m looking for a replacement.

Can anyone recommend a (possibly UK based) hosting provider? I need about 1GB/month, about 50Mb webspace. I need just apache for static HTML pages, no MySQL, PHP, or any CMS fancy-whatsits. I need to transfer a single .com domain, and setup a few mail redirects — no mailboxes needed.

I don’t mind paying a little extra for uptime or for a company that isn’t going to go bust anytime soon. Ideas welcome. Thanks.

Richard.

Recently there has been a period of where gnome-power-manager wasn’t quite as stable and bug free as I would like. The reasons basically boil down to:

• Rewriting the engine to support DeviceKit-power rather than HAL
• Switching to using xbacklight rather than HAL to change the backlight (but falling back to HAL if xbacklight is not available)
• Rewriting the idle interactions to not rely on gnome-screensaver, but instead using gnome-session and X idletime
• Supporting HAL buttons and X buttons, and trying to filter out the duplicates
• Working around the fact that switching the monitor off using DPMS resets the IDLETIME…. urgh.
• Switching to using DeviceKit-power to do the suspend and hibernate, instead of using HAL

So, for the last few months I’ve been essentially trying to do the software equivalent of underpinning a house. I’ve spent the last couple of days adding more self check code, and fixing up the bugs that the new tests have found. Specifically, if your machine randomly switched off your display when you’re working, or when switching sessions didn’t restore your brightness correctly then git master probably might work for you.

Could people that have had problems, please try git master and give me success/failure as comments to the blog comment please. If the idletime and dimming stuff is 100% fixed now, then I’ll backport the fixes to stable and do a new release. Thanks.

p.s. If you change the value of GPM_USE_COMPOSITE in src/gpm-engine.c to 1 and recompile, then multiple batteries might work correctly too. Untested (still waiting for my ultra-bay battery to be delivered), so no promises.

On Thursday I’m getting married. Due to this, I’ll be offline (and pretty much uncontactable) from today, for nearly a week. I’m also honeymooning later in May too, so if you send me mail or report bugs there might be a fair delay to me responding. Wish me luck!

I’ve just checked a few fixes into git to fix the compile of PackageKit on FreeBSD. I’ve been using 7.1-RELEASE-p4 for testing.

Obviously, there is no pkg backend (hint, hint) but the dummy backend seems to be working well. Now all somebody has to do is contribute a backend!

This evening I’ve been trying to convert my projects (gnome-packagekit and gnome-power-manager) away from libgade to the shinier GtkBuilder. One less library, right? So far so good, except for the fancy super sexy custom widgets.

Stuff like the graph widget in gnome-power-statistics was created using the glade_set_custom_handler function, which was then creating the widget using gpm_graph_widget_new() in that callback. I’m not sure how to do this with GtkBuilder and the new markup format. Google isn’t being very helpful. Help appreciated. Thanks!

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.