Posts Tagged ‘hint’

Connecting QEMU/KVM virtual machines via serial port

If for some weird reason you need to connect two QEMU/KVM instances via a virtual null modem cable, here’s how to do it:

$ mkfifo null-cable-1.{in,out}
$ ln null-cable-1.in null-cable-2.out
$ ln null-cable-1.out null-cable-2.in
$ qemu -m 512 -nographic -serial pty -serial pipe:null-cable-1 -hda image1.qcow2
$ qemu -m 512 -nographic -serial pty -serial pipe:null-cable-2 -hda image2.qcow2

For each instance, you’ll be dropped into a monitor prompt:

char device redirected to /dev/pts/9
QEMU 0.12.1 monitor - type 'help' for more information

The machine is running already, but in the background. To access its console, open the pty mentioned in the output:

$ screen /dev/pts/9

Read Full Post »

I have been meaning to write this post for a long time.

One thing which I often found myself doing was typing echo $? after running a command to find out if there was any error, or appending || echo failed to the end of the command line.

Commands generally warn if there was an error, but you have to stop for a second and carefully read the output to see whether anything went wrong. I’m lazy and that additional second and the extra cognitive effort always bothered me.

I eventually had the idea of making the shell prompt show the exit status of the last command if it was non-zero. I use zsh, so it’s got to be possible. 🙂

It turns out it is, this is my PS1 variable now:


export PS1="${CYAN}%m${NORM}%# %(?..${RED}(%?%)${NORM} )"

The magical part is %(?..${RED}(%?%)${NORM} ). Here’s the result:

zsh prompt

As a side note, one other thing that the screenshot shows is the right-hand prompt. This is a great feature of zsh, and I use it to show the current working directory. That way, no matter where I am in the filesystem, the cursor prompt always starts at the same column. Here’s my RPS1 variable:


export RPS1="${MAGENTA}%~${NORM}"

Read Full Post »

Since version 2.6, you can tell Amarok to convert (transcode) every music track to MP3 when copying it to a given device.

There’s a bug, however which causes MP3 files converted from Ogg Vorbis to lose all metadata (artist, album, title etc). This is a showstopper for me.

This happens because Amarok needs to pass an option to ffmpeg to tell it to get the metadata from the first stream found in the Ogg file as opposed to the default of getting it from global metadata. Unfortunately as far as I can tell there’s no way to configure the ffmpeg command line used by Amarok. The solution then is to replace the ffmpeg binary in the path with a script that will do that, like this one:

import os
import sys

AVCONV_FFMPEG = '/usr/bin/ffmpeg.distrib'
os.execv(AVCONV_FFMPEG, sys.argv + ['-map_metadata', '0:0,s0'])

In Debian or Ubuntu, you can divert the real ffmpeg binary and install the script above as /usr/bin/ffmpeg:

$ sudo dpkg-divert --add /usr/bin/ffmpeg
$ sudo cp /tmp/fake-ffmpeg.py /usr/bin/ffmpeg
$ sudo chmod +x /usr/bin/ffmpeg

There’s another bug where Amarok needlessly converts even MP3 files when copying them to the device.

Read Full Post »

just do it.

ps: it’s just marketing, I know. But I really liked the  message…

Read Full Post »

Despite being a KDE person, I use Evolution as my mail client, including for reading mailing lists and posting patches. Up until now I’ve been doing the latter by attaching patches instead of including them in the message body, to avoid whitespace mangling and linewrap.

But this method is inconvenient sometimes: when you want to comment on a patch posted on the list, portions of that patch (which may include long lines that shouldn’t wrap) will show up in the message body and you can have trouble. This is a problem especially when the poster also sent their patch as attachment, because you will most likely need to copy & paste the patch into your reply window and things will get mangled right there.

Turns out that there is a way to include a patch in the message body in Evolution’s compose window and it will get through unmaimed: select the Preformat option in the paragraph style dropdown, and then paste in your patch or use the Insert -> Text File… option.

Caveat: Older versions of Evolution converted tabs to spaces when pasting text, so you had to insert it from a text file to preserve whitespace. I just tested with version 2.12.3 from Debian (package version 2.12.3-1), and pasting a patch containing tabs worked fine so the bug has been fixed.

Thanks Klaus Kiwi for the tip!

Read Full Post »

As I mentioned before, I’ve been working on and off on adding Python scripting support to GDB, with Tom Tromey and Vladimir Prus. We did the work in a git repository, separate from the GDB main repo (which still uses CVS, by the way). Now came the time to get the work we did there, separate it in patches and post them for review on the gdb-patches mailing list.

This is the tale of my patch-producing efforts. I’m sorry, it is most likely boring for everyone but me. Still, I wanted to write it down so you are free to stop reading the post here. 🙂

Anyway, back to where I was: I (foolishly, perhaps?) volunteered to create the patches. One reason for me to do that is that I actually enjoy working with and learning about source code management and related issues, and this was a good opportunity for me to improve my git-fu (since I thought git could help me do the job in a sane way, which fortunately proved to be the case).

I say foolishly because I thought it wouldn’t take too much time to cut out the patches, since I knew what I would have to do… The task of course took longer than I expected, in part because of unforeseen autotools woes, but of course also because I underestimated the effort (I am an optimist).

Here is the method I used:

First of all, I wanted to update the code to the latest CVS version of GDB, because the work in the git repo was done based on a CVS version from February… Nothing to see here, actually. I just created a new branch with the latest CVS update, and rebased the commits on top of that. In hindsight, I should have merged the new CVS update into the python branch, which would have made me deal with less conflicts. I used rebase because I thought I would cherry pick the commits later, so I wanted each of them refreshed.

Then the real fun began. I started using interactive mode of git rebase to squash related commits together (to form the patches), and reorder them. I quickly realised that with this approach I would have a bit of difficulty with commits which touched different areas of the code and crossed the borders I had in my mind for the patches I wanted to generate. I would have to first split those into smaller, more behaving commits and only then squash them with other similar changes. That seemed to be more work than really necessary.

Also, the older commits did things in ways and places which were later changed, and it looked like I would have some trouble reconciling older and newer code to fit in one patch (maybe not though, maybe that would be taken care of more or less naturally). Also, I would need to take some time to familiarise myself with the commits in the branch, because I only authored some of them. The “shuffle commits around” approach wasn’t looking very promising.

I then turned to a different strategy: I generated a big patch containing all of the code in the branch, and applied it (using the plain old patch command) on top of a clean branch which contained only the CVS HEAD version I was using as a base. All I needed to do now was to selectively add to the index the changes that I wanted to include in a patch and then commit those changes together. And repeat the process for the next patch and so on.

It proved to be a good approach, especially because of the interactive mode of git-add. This mode asks you about each change inside a modified file, letting you add that change to the index or skip it, leaving it in the working directory for a future commit. git add -i streamlined the “change picking” process quite a lot, and made the patch-cutting almost mechanical. (By the way, this feature is also available in Mercurial, with the Record extension. I even believe (not sure though) that the Mercurial extension predates git add -i) (I don’t know if Bazaar has it, would be nice to know).

In this phase of the process, git rebase -i was useful. Sometimes I came accross a change in the working directory which would fit better in a patch which I had already committed. It was simply a matter of committing that change and then shuflling it back and squashing with the proper patch.

At each commit I pushed the changes to a pristine repo which I used to build GDB and guarantee that each patch included all the changes it needed.

Voilà, at the end of the process I had a git branch where each commit corresponded to one patch which I wanted to send to the mailing list.

Read Full Post »

autoconf tip

I always dreaded having to do modifications in Makefile.in (e.g., adding a new file to the compilation) because then I’d have to nuke the build directory (you do build your project outside of the source tree, right? 😉 ) and run configure again for the Makefile to be generated and then rebuild everything again.

Well, of course this is a dumb approach to the problem, and today I just found out (almost by accident) the smarter way to do it: run the config.status script in the build directory. It will regenerate the Makefile and you can just type make from there, compiling or recompiling just what’s needed.

Read Full Post »

Older Posts »