Cool Software: SlowMP3

Slow MP3 allows you to speed up and down MP3 files without getting “chipmunk” voices, transpose them up and down and other cool stuff.

It’s awesome if you’re trying to learn that new song on your guitar and can’t find the tabs for it.

Try it out!

http://www.finki.net/pekka/slowmp3/ (now dead – see my copy below)

SlowMP3.jar

gitolite: ‘foo’ does not appear to be a git repository – ForceCommand

Many people seem to get the following error message when trying to manipulate a remote git/-olite repository:
fatal: ‘foo’ does not appear to be a git repository
fatal: The remote end hung up unexpectedly

The problem here, which is absolutely not explained by the above error message, is likely to be that the remote command gitolite specifies in ~/.ssh/authorized_keys is not used.

This can in turn be caused by two things, as far as I know:

  • You are using an ssh key which appears in the authorized_keys file without gitolite’s “command=…” configuration, in which case the solution is to use a separate public/private key pair for git
  • Your SSH server has a ForceCommand directive in sshd_config (/etc/ssh/sshd_config on debian) which overrides the “command=…” setting in authorized_keys. To solve this, that directive has to go, or an exception needs to be added for your git user with a Match clause in sshd_config.

In the latter case, there does not seem to be any sane way to retrieve the contents of the “command=…” statement. While the user supplied command is available in the environment variable $SSH_ORIGINAL_COMMAND while using ForceCommand, the command supplied by authorized_keys seems nowhere to be found. Thus you need an exception for the ForceCommand directive. If you find another way to avoid this, please leave a comment below?

Creating .deb-Packages With Checkinstall

If you’ve exhausted all other options, it might be time to compile from source, even in Debian.

If you’re about to do that though, don’t abandon the concept of .deb files and the advantages they bring with versioning and easy removal. Use “checkinstall“.

Checkinstall is in the standard Debian repositories and encapsulates your install into a nice, easily installable and distributable .deb file. apt-getting it and reading the manual is easy enough, but if you want a howto, falkotimme.com has a nice one, archived here as a PDF.

Fixing “shmget() failed: No space left on device”

I had this happen when someone ran a script to kill x11vnc every so often, using kill -9 (don’t ask).

Killing x11vnc with SIGTERM (15) allows it to clean up its shared memory segments. SIGKILL (9) will not.

Googling around, I found a script over here (backup copy here).

The problem with that was that it’s aimed at being run as the user, and it only supports usernames up to 10 characters, because of how “ipcs -m” prints its entries on Linux.

I wanted a solution that supported any length of username, and that could be run periodically, by root, as a cronjob to clean up after silly users, and that would also give me a report when it cleaned something, so I could see who was causing this.

The result was this script. It only supports Linux, and thus is a bit less portable than the one at karlrunge.com, but it does the job, even with long usernames, and generates such nice reports:

Removed SHM Segments:
___________________________
|   OWNER    |   COUNT    |
|------------|------------|
| bolt       |         42 |
|____________|____________|

Total: 42

Oops…

EDIT:
Updated script, automatically synced with the one I’m actually using available here.

SSH in a while loop – stdin problems

When SSH is used with a line like “while read ….”, the while loop will only run once.
This can be seen by running this simple example:

$ seq 1 10 | while read line; do ssh remotehostname "echo x${line}x"; done
x1x

You might expect this to connect to the host with the name “remotehostname” 10 times, and each time print one of the numbers in the sequence from 1 to 10. This will, however, not be the case. The result is a single line, saying “1”.

Where did the rest of the numbers go? To the SSH process.
By default, SSH runs off with the stdin file descriptor, preventing “read” from reading anything else from it. You can see this by trying the following example:

$ seq 1 10 | while read line; do ssh remotehostname "echo x${line}x; cat -"; done
x1x
2
3
4
5
6
7
8
9
10

Now all the numbers were printed, but they were all in a single ssh connection. As you can see, only the number “1” got the X’es on both sides, indicating it was printed by the “echo” instruction. The rest of the numbers come from “cat –“, which basically takes whatever comes in on SSH’s stdin, and dumps it to the stdout (the screen, in this case). So that’s where they went!

Now, how do you remedy this?

Answer: SSH’s -n switch. From the manual:

-n Redirects stdin from /dev/null (actually, prevents reading from stdin).
This must be used when ssh is run in the background. A common trick is to use
this to run X11 programs on a remote machine. For example, ssh -n
shadows.cs.hut.fi emacs & will start an emacs on shadows.cs.hut.fi, and
the X11 connection will be automatically forwarded over an encrypted channel.
The ssh program will be put in the background. (This does not work if ssh needs
to ask for a password or passphrase; see also the -f option.)

So let’s try that with -n, shall we?

$ seq 1 10 | while read line; do ssh -n remotehostname "echo x${line}x; cat -"; done
x1x
x2x
x3x
x4x
x5x
x6x
x7x
x8x
x9x
x10x

There. 10 SSH connections opened, 1 number printed each time. A total waste of time, but a rather simple example to follow 🙂

Set php.ini values using .htaccess

Did you know that you can set php.ini values right inside the .htaccess file?
You can do so by adding lines like these:

#format
php_value setting_name setting_value

#example
php_value  upload_max_filesize  128M

GCC stray X in program

Problem:

IEMGD_HEAD_Linux/common/drm/emgd/display/pi/cmn/pi.c:1: error: stray ‘\357’ in program

This is caused by “invalid” characters in the code, specifically I encountered this while trying to compile the Intel EMGD driver for my EEEPC’s graphics card.

Thanks to the helpful folks over here, there’s a solution:

cd IEMGD_HEAD_Linux/common/drm/emgd/display/pi/cmn
cat -v pi.c | awk '{if(NR>1) print $0}' > tmp # make strange characters on first visible and remove
mv tmp pi.c

That makes the invalid characters visible and removes them.
In this case, it leaves some partial, garbage comments behind, so the file still wont compile.
To resolve this, I opened the file in vim, and quickly searched for and removed the faulty comments (and some I didn’t have to remove).
Remember to answer “no” to the question of re-extracting the tarball each time you retry building this.
Attached is the original driver file, and my modified copy of pi.c

Result:

"Completed EMGD Installation"

Lin_EMGD_1_6_RC_1922
modified pi.c