Fixins

So what does it make sense to do the week after FUDCon, with Fedora 17 Alpha impending? Why, work on fixing random annoying bugs, of course! That's pretty much what I've done this week. For some reason - I can't even remember what the reason was any more - I decided to finally nail down the bug in libconcord which prevented things from connecting to the remote without root privileges. libconcord is the library for programming Logitech Harmony smart remote controls: you're supposed to use Logitech's web interface to define how you want the remote to work, then it sends you what's effectively a custom firmware file for the remote, which needs to get flashed onto the remote. libconcord is the library that can do this, but for a long time, apps based on it (concordance is the CLI and congruity the GUI) have needed to run as root, which is kind of useless, as we can't just trigger congruity from Firefox and have everything 'just work'. With lots of help from Kay Sievers (thanks Kay!) we managed to nail down the couple of issues which were screwing it up, so now it's fixed, until the next time they decide to change udev, anyway: if you have a Harmony remote, you can just 'yum install congruity' and go use the Logitech web interface, and when it sends you a file, congruity should pop up and handle writing it to your remote, nothing else required. Make sure you have updates-testing enabled, of course. Today I decided, again for no very good reason, to finally nail down the mysterious 25 second delay I and (probably) others sometimes see after waking from suspend, before the network kicks in. This turned out to be one of those extremely annoying bugs where you're trying to track five different variables at once: at various points I thought it was somehow down to pm-utils' convenience 'dbus_send' function vs. the straight command 'dbus-send', or the fact that packagekit's pm-utils sleep hook didn't run its dbus-send command with && at the end, and the fact that it seems I hit the bug reliably on the first suspend after boot but not if I suspend again soon after didn't help. But finally I'm pretty sure I figured it out. When you suspend, pm-suspend calls all the hooks in /usr/lib64/pm-utils/sleep.d in numerical order. When you resume, it calls the same hooks in *reverse* numerical order (just like how old-school SysV boot and shutdown work) - so when you're resuming, 95packagekit happens before 55NetworkManager. This was about the key thing. For some reason, the dbus-send call in 95packagekit often fails on my system, on resume. The fact that it uses the parameter --print-reply means that the command doesn't return immediately and leave dbus to work in the background; instead it blocks and will only return when it gets a reply or times out. So when the call fails, it has to timeout before pm-suspend will proceed to the rest of the hooks (and the rest of the resume process in general). Just dropping the --print-reply parameter seems to fix the problem ideally: the network comes up quickly on resume, and the dbus call even now seems to succeed, a few seconds later; I suspect that, for some reason, the network has to be up for it to reliably succeed. There's a second bug which is that the dbus methods used by 55NetworkManager got killed in 0.9, so that hook doesn't actually work, but this is less important than you'd think, because NM has a 'backup' mechanism where it wakes up in response to upower waking up, and that kicks in just fine as long as 95packagekit isn't blocking it. So that's two annoying niggles that have been bugging me for months cleared up, and my FUDCon todo list entirely neglected. Fun times! Jon Stanley, I promise you those links soon, though. I will also finish up my FUDCon wrap posts with one looking at QA activity, of which there was quite a bit. We start ramping up for Fedora 17 in earnest around about now: the first RATS run is scheduled for this week, and the first blocker review meeting is next Friday. So everyone start clearing your Friday schedules!