Feb 8
Thanks to the work of David Henningsson, we now have a proper Apport symptom for audio bugs. It just got updated again to set default bug titles, which include the card/codec name and the problem, so that Launchpad’s suggested duplicates should work much more reliably.
So from now on you are strongly encouraged to report sound problems with
$ ubuntu-bug audio
instead of trying to guess the package right.
These days I often use launchpadlib in my projects for scripting access/modifications in Launchpad. While launchpadlib has quite a good API documentation, this only covers the method calls, not the attributes or collections. So it often takes some poking and trying until you figure out how to access/change things.
I found myself typing the same things over and over, so I finally wrote a little script called lpshell:
#!/usr/bin/python -i
import code, os, sys
from launchpadlib.launchpad import Launchpad, STAGING_SERVICE_ROOT, EDGE_SERVICE_ROOT
lp = Launchpad.login_with('test', STAGING_SERVICE_ROOT)
This logs into Launchpad and gives you an interactive Python shell with an “lp” object:
$ lpshell >>> lp.bugs[439482].duplicate_of
Update: I committed this to ubuntu-dev-tools now, renamed to lp-shell for consistency with the other lp-* commands.
Nov 27
The day has come!
Yesterday I dropped the superfluous hal dependency from gparted, today I uploaded gdm to stop using hal for getting the keyboard layout and use libxklavier instead.
I also applied Julian Cristau’s udevified X.org branch to our xorg-edgers packages into my halsectomy PPA, created some udev rules for udev-based X.org input detection ([1], [2]), and off we go: that was the last hal reverse dependency. My system now fully boots and works without hal.
It has been broken for two months, since we upgraded to the “new” (not quite any more) gdm in Karmic: But I finally got around to re-doing the gdm patch for supporting a guest session for 2.27. I use it myself a lot for testing stuff with a clean user profile, so I can finally delete my herd of test users again.
One known drawback is that the guest session is not currently restricted by AppArmor rules yet. I’ll get to this at some point, I filed LP #425793 to keep it on the radar.
I often do upstream releases of my upstream projects that I do on Launchpad, mostly for Apport and jockey. But doing this has been quite tedious until now: You have to go to the project page, pick the series (usually “trunk”), create a new release, create a new milestone along the way, then go to “add download file”, and upload your .tar.gz and .tar.gz.asc.
Because this is rather inconvenient, I don’t do as many upstream releases as I should. But thanks to our tireless launchpadlib developers it is now possible to automate all that, so I wrote a new script lp-project-upload which does all that in a simple command:
$ lp-project-upload apport 1.8.2 apport-1.8.2.tar.gz Release 1.8.2 could not be found for project. Create it? (Y/n) y
The script is based on Brad Crittenden’s recipe for uploading project files, and I added the creation of milestones and releases.
The script is contained in current Karmic’s ubuntu-dev-tools package now. Enjoy, and of course feel free to extend it for changelogs, release notes, etc.
Jul 3
In the merciless vendetta for purging hal we now reached another major milestone: gvfs, GNOME’s file system layer which handles USB storage as well as virtual file systems for libgphoto2 cameras, Bluetooth devices, audio CDs, or ftp/sftp/cifs mounts, is now fully ported to libgudev and doesn’t need hal at all any more. These long nights of porting weren’t in vain, after all \o/.
Now I just need to hassle David Zeuthen to apply the patches soon. Of course I couldn’t wait and already uploaded them to Karmic, so please test the hell out of it and let me know about problems.
https://wiki.ubuntu.com/Halsectomy is a little greener once again. 
So far, Apport package hooks were limited to collecting data from the local system. However, a lot of debugging recipes and standard bug triage ping pong involves asking the reporter further questions which need reponses from a human. This can range from a very simple information message box “Now, please plug in the camera which is not detected” until a complex decision tree based on the symptoms the user sees.
As discussed at UDS Barcelona, Apport will grow this functionality in Karmic. A first preview is available in my PPA. The GUI looks horrible, but the API for hooks won’t change any more, so you can now begin to develop your interactive hooks.
Example:
import apport.hookutils
def add_info(report, ui):
apport.hookutils.attach_alsa(report)
ui.information('Now playing test sound...')
report['AplayOut'] = apport.hookutils.command_output(['aplay',
'/usr/share/sounds/question.wav'])
response = ui.yesno('Did you hear the sound?')
if response == None: # user cancelled
raise StopIteration
report['SoundAudible'] = str(response)
Please see the package-hooks.txt documentation for details.
I implemented all currently existing UI functions (information, yes/no question, file selector, multiple choice dialog) for GTK and CLI, and all except the multiple choice dialog for Qt. Anyone willing to hack on an implementation of ui_question_choice() similar to what the GTK frontend is doing?
Update:I merged Richard Johnson’s branch (thanks!) and uploaded a new package into my PPA. apport-qt is now fully functional.
Jun 3
The migration away from hal continues. Yesterday I uploaded new udev-extras and hal packages which move the handling of local device access from hal to /lib/udev/rules.d/70-acl.rules. Note that this temporarily breaks device access to old cameras which don’t speak the standard PTP protocol yet (and aren’t mass-storage). Most devices should work fine, though, please let me know if something fails (ubuntu-bug udev-extras).
I started a discussion with upstream about how to migrate the libgphoto bits away from hal to udev rules. It shoulnd’t actually be hard to do, and I’m keen on working on it, but it needs agreement between the libgphoto, udev-extras, and gvfs/KDE upstreams, so some coordination work is in order.
I also created a wiki page of the current migration status. Please edit if I forgot something. If you feel inclined to work on a particular bit, the Linux world will heavily appreciate this! It’s still a major Karmic goal to push the transition as far as possible, to avoid intrusive system changes for Ubuntu 10.04 (which is likely to become an LTS).
I recently started working on packaging pieces of the new DeviceKit world, which is gradually replacing hal. In particular, DeviceKit-disks and DeviceKit-power are in Karmic now, and gnome-disk-utility and a patches gvfs are in the ubuntu-desktop PPA.
A few days ago I wondered what the replacement of hal-setup-keymap would be. This is the bit that makes your laptop’s magic Fn keys work, such as “brightness up”, “next song”, “WWW browser”. I became quite acquainted with this component in the last six months and committed a fair share of fixes to hal-info for those. A quick discussion revealed that nobody was working on this, so I picked that up and created a tool to convert hal keymap .fdi files to udev rules and keymap files, and an udev-extra git branch with those maps, the udev rules, and a small callout which pokes the maps into the corresponding evdev device whenever an input device gets added.
I tested it on my Dell Latitude D430, and it works just fine. Dell laptops are all alike in terms of Fn keys, but I need testing on other laptops. I’m particularly interested in the Sony and ThinkPad models, which don’t send “magic” keys as high keycodes on
a standard i8042 atkbd, but as low keycodes on a separate input device (30-keymap-module-* in hal-info). Testing on Acer and Fujitsu models is also highly welcome.
For testing, add my PPA and do
$ sudo apt-get install udev-extras
# disable the current hal-info keymaps:
$ sudo rm /usr/share/hal/fdi/*/*/30-keymap-*
Packages are available for Jauny and Karmic.
Then reboot, and check if your magic Fn keys still work. Please send success and failure reports by private mail or as comments here. I’ll fix the issues and send a conclusion back here in a few days. If things don’t work for you, please do
$ sudo true
$ sudo udevadm monitor --udev -e > /tmp/udev.log 2>&1
$ sudo udevadm trigger --subsystem-match=input
$ fg
# press Control-C
$ grep . /sys/class/dmi/id/* 2>/dev/null
Please send the output of the last command, and /tmp/udev.log.
If you need to revert, purge udev-extras again and do sudo apt-get install --reinstall hal-info.
Many thanks in advance!
Update (2009-05-09): I got my kernel.org account now, and testing showed a lot of positive and no negative results. Thank you for all your feedback! I pushed the changes to udev master now.
2009-11-01 update:Updated git link from udev-extras (which got removed recently) to udev (where it was merged into a while ago).
Some days ago, the first public beta of PostgreSQL 8.4 was announced. I uploaded a CVS snapshot to Debian experimental two weeks ago, but it didn’t make it out of NEW yet.
Packaging the actual 8.4 bits was actually pretty easy, just took me half a day to adapt the 8.3 packaging and eventually figuring out how to build the entire documentation from SGML sources with Debian/Ubuntu’s broken docbook-utils.
I spent much more work work on supporting 8.4 in postgresql-common, especially with the new per-database locales, migrating changed postgresql.conf parameters in pg_upgradecluster, and so on. Now almost all of the > 1000 tests pass, so I believe it is pretty solid now.
The only exception is the changed behaviour in verifying the server side’s SSL certificate from the client side. At first I thought it was a bug, and reported it to upstream, but it evolved into a pretty lengthy and interesting discussion about the right defaults for SSL verification. I’ll work on better defaults, and the test suite to pass 100% soon.
I invite you give the beta a good beating. Packages for Ubuntu 8.04 LTS and 9.04 are in my
postgresql PPA. Due to postgresql-common, you can safely run 8.4 in parallel with existing 8.3 instances, test-upgrade your 8.3 ones to 8.4 and compare them, etc.
Feedback appreciated!