Setting up JACK on Fedora 12

Jan 26, 2010

Audacity is somewhat of a broken joke these days, so I needed to use Ardour to record. And that meant setting up JACK. Since JACK insists on exclusivity, I also needed to route pulseaudio through JACK so I could use other apps at the same time. Unfortunately, this is a bit of a pig to figure out. I hacked it as follows:

First edit /etc/pulse/, you need to add two lines:

load-module module-jack-sink
load-module module-jack-source

In theory now, a restart of pulseaudio should start using JACK for recording and playback, if jackd is running. However, it tends not to work very well: you might find PA hanging and you have to kill -9 it.

This isn’t enough of course, now when you log in again, gnome-session will try to start pulseaudio, but not jackd, so nothing works. It’s far from the right way, but I edited /usr/bin/start-pulseaudio-x11 (which is started from a /etc/xdg/autostart/ script), as follows:

amixer -c 0 sset 'Input Source' 'Line'

nohup jackd -d alsa &

sleep 5

/usr/bin/pulseaudio --start "[email protected]"

Note that I have to set the input source by hand: something in desktop start up used to do this for me, but now I’m going through JACK it has to be done by hand.

Liferea strict feed validation tip

Jan 17, 2010

New versions of Liferea refuse to parse any feed that fails to validate, even for relatively “minor” problems (the libxml2 recovery facility is no longer used; besides, it abandons the rest of the feed when it hits such problems). I don’t want to use Google Reader, since I don’t like the interface.

Typically bad feeds have things like high-bit chars or bare ampersands. Thankfully, there’s a “conversion filter” feature that you can use to work around the bad feeds. On the two bad feeds, I run this filter:

[[email protected] ~]$ cat bin/fix-ampersands 

sed 's/\o226/&/g' | sed 's/& /\&/g' | sed 's/\o243/GBP/g'


Nov 10, 2009

“The main indicators of egotism as I intend it here are are loud self-display, insecurity, constant approval-seeking, overinflating one’s accomplishments, touchiness about slights, and territorial twitchiness about one’s expertise. My claim is that egotism is a disease of the incapable, and vanishes or nearly vanishes among the super-capable.”

“I’m the crippled kid who became a black-belt martial artist and teacher of martial artists. I’ve made the New York Times bestseller list as a writer. You can hardly use a browser, a cellphone, or a game console without relying on my code. I’ve been a session musician on two records. I’ve blown up the software industry once, reinvented the hacker culture twice, and am without doubt one of the dozen most famous geeks alive.”

No prizes for guessing who this was.

Enabling xVM on OpenSolaris

Oct 29, 2009
Another significant usability improvement that landed in build 126 is Gary and Bill's work on enabling Xen. Now, running xVM should be as simple as:

# pkg install xvm-gui
# echo 'set zfs:zfs_arc_max = 0x10000000' >>/etc/system # yes, you still need this, sadly
# svcadm enable -r milestone/xvm
# reboot

There's also a new Visual Panel for doing this if you prefer a graphical method. More in the flag day message.


Dry-run migration

Oct 29, 2009
As part of our ongoing work on improving the ease of use of xVM, the newly available build 126 of OpenSolaris has my putback for:

6878952 Would like dry-run migration

This feature is useful for doing a simple check as to whether a guest can successfully migrate to another dom0 host. For example, domu-221 here is using a disk path that doesn't exist on the remote host hiss:

# virsh migrate --dryrun domu-221 xen:/// hiss    
error: POST operation failed: xend_post: error from xen daemon:
(xend.err 'Remote server error: Access to vbd:768 failed: error: "/iscsi/nevada-hvm" is not a valid block device.')

This works both with running and shutdown guests. Currently, the checks are fairly limited: are disks of the same path available on the remote host (note there is no checking of GUIDs or whatever to verify they really are the same piece of shared storage); is there enough memory on the remote host; and is the remote host the same CPU vendor. We expect these checks to improve both in scope and in reliability in the future.


A horrible little ElementTree gotcha

Oct 20, 2009

What does this print:

from lxml import etree
doc = etree.fromstring('<a><b><c/></b></a>')
newdoc = etree.ElementTree(doc.find('b'))
print newdoc.xpath('/b/c')[0].xpath('/a')

The answer is: [<Element a at 817548c>]. The first point to note is that xpath() against an element is only relative to that element: any absolute XPaths enumerate from the top of the containing tree. The second point is that the shallow copying of etree means that _Element::xpath, unlike _ElementTree::xpath, evaluates absolute paths from the top of the original underlying tree! So even though there’s no <a> in newdoc, an absolute XPath on a child element can still reach it.

YouTube annoyance

Oct 19, 2009

How much time would it really take to order multi-part videos, so the suggestion at the end of the video is the next part? Please!


Oct 15, 2009
I recently had cause to try out COMSTAR for the first time, and I thought I'd write up the steps needed. Unfortunately, it's considerably more complex than the fall-over-easy shareiscsi=on ZFS feature.

Configuring the COMSTAR server

First install the storage-server packages and enable the services:

# svcadm enable -r stmf
# svcadm enable -r iscsi/target

We want to create a target group for each of our xVM guests, each of which will have one LUN in it. After creating the LUN, we define a "view" that allows that LUN to be visible for that target group:

# stmfadm create-tg domu-226
# zfs create -V 15G export/domu-226
# stmfadm create-lu /dev/zvol/rdsk/export/domu-226
Logical unit created: 600144F0C73ABF0F00004AD75DF2001A
# stmfadm add-view -t domu-226 600144F0C73ABF0F00004AD75DF2001A

Now we need to create the iSCSI target for this target group, that has our single LUN in it.

# itadm create-target -l domu-226
Target successfully created

Here (finally) is our iSCSI Alias we can use in the clients. But we're not done yet. By default, this target will be able to see all LUNs not in a target group. So we need to make it a member of our domu-226 target group:

# stmfadm add-tg-member -g domu-226
# stmfadm list-tg -v
Target Group: domu-226

Configuring the iSCSI initiator (client)

We do this in the usual manner:

# svcadm enable -r svc:/network/iscsi/initiator:default
# iscsiadm add discovery-address
# iscsiadm modify discovery --sendtargets enable

Installing a guest onto the LUN

We went through the above gymnastics so we can have a human-readable Alias for each of the domu's root LUNs. So now we can do:

# virt-install --paravirt --name domu-226 --ram 1024 --os-type solaris --os-variant opensolaris \
  --location nfs: --network bridge,mac=00:14:4f:0f:b5:3e \
  --disk path=/alias/domu-226,driver=phy,subdriver=iscsi \


An annoying Python gotcha

Oct 10, 2009

Imagine you have this in

import foo

class bar(object):

   def __del__(self):

Seems fine right? In fact, there’s a nasty bug here. If I try to use this module in like so:

import mod
mybar = bar()

Then you’re likely to get an exception when the program exits. This is because Python, for some bizarre reason, Nones out the globals in when taking down the interpreter. The actual __del__ method can be called sometime after this, and it ends up trying None.cleanup(), with the resultant AttributeError. It seems extremely bizarre that it happens in this order, but it does (a real example).

Kernel solipsism

Jun 4, 2009

Thomas Gleixner:

Exactly that’s the point. Adding dom0 makes life easier for a group of users who decided to use Xen some time ago, but what Ingo wants is technical improvement of the kernel… The kernel policy always was and still is to accept only those features which have a technical benefit to the code base.

It boggles the mind that someone could get things so backwards. The kernel exists to provide services to the outside world, not the other way around. By all means criticise the details of the Xen dom0 code, but this argument makes zero sense. How precisely did x86_64 support provide a technical benefit to the code base?