I’ve started using pbranch
hg more seriously. It works nicely but is a little rough
around the edges, in particular:
No hg qpop/push equivalent
I really miss this. I find myself constantly doing
hg pgraph to figure
out where I am and then typing the patch above or below.
No way to shelve a patch
With MQ, I can easily guard a patch to temporarily remove it from the
queue. There doesn’t seem to be a simple way to do that with pbranch.
Editing patch messages.
You use peditmessage, but because this modifies the repository, you then
have to always
hg pmerge -all. This pops to the top and causes a bunch
of extra changesets, and it gets annoying quickly. And frustratingly,
these patch messages do *not* appear in the repo history. So your code
reviews of the main repo are just showered in useless merge messages,
instead of the actual commit message you care about.
I don’t know why, but there’s no way to automatically commit a patch as
a single changeset on the root default tip, then close the patch
Inserting and deleting patches is horrible
Yuck - I really
hope this gets easier soon.
Showing the current patch history
A little tip not mentioned on the pbranch site: the way to show the
changelog history of the current patch is to do
hg log -b patchname.
Create the following as
<?xml version="1.0” encoding="UTF-8”?>
Default X.org input configuration is defined in:
Settings here modify or override the default configuration.
See comment in the file above for more information.
To see the currently active hal X.org input configuration
run lshal or hal-device(1m) and search for “input.x11*” keys.
Hal and X must be restarted for changes here to take any effect
<match key="info.capabilities” contains="input.keys”>
and then restart hald and Xorg.
echo ‘gtk-error-bell = 0’ »$HOME/.gtkrc-2.0
Liferea has no keyboard shortcut editor itself, but “Toggle unread
status” demands the wrist-breaking chord action of Control-U. It expects
you to be able to edit the shortcuts via the editable menu feature of
Unfortunately that’s disabled on all modern GNOME installs, and there’s
no UI for re-enabling it. As usual,
gconf-editor to the rescue. The
key you need to change is
After re-starting Liferea, you can then edit via hovering over the menu
item and pressing the combination. Of course, this in itself is buggy:
if it clashes with a menu accelerator (as ‘r’ is), it will perform that
It’s simpler to directly edit the
accels file in your Liferea dot dir.
Browsing the net, you might get the impression that Epson Stylus
All-in-ones are well supported under Linux. Unfortunately this is not
the case. The pipslite driver you have to install is extremely flaky,
and Fedora SELinux doesn’t work properly with it. There’s no “draft”
mode for some bizarre reason; printing is extremely slow and often
randomly cancels half-printed jobs due to USB resets
The scanner doesn’t work at all with the iscan software, despite claims
to the contrary.
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:
/etc/pulse/default.pa, you need to add two lines:
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
is started from a
/etc/xdg/autostart/ script), as follows:
amixer -c 0 sset 'Input Source' 'Line'
nohup jackd -d alsa &
/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.
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
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'
“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.
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
There's also a new Visual Panel for doing this if you prefer a graphical method. More in
the flag day message.
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.