How I installed GIMP 2.7:
- Install BABL 0.1:
configure --prefix=/opt make -j3 sudo make -j3 install
- Install GEGL 0.1:
PKG_CONFIG_PATH=/opt/lib/pkgconfig ./configure --prefix=/opt make -j3 sudo make -j3 install
- Install libtiff (libtiff4, libtiffxx0c2, libtiff4-dev, libtiff-tools, libtiff-doc)
- Install GIMP 2.7:
PKG_CONFIG_PATH=/opt/lib/pkgconfig ./configure --prefix=/opt/gimp-2.7 --without-alsa --enable-debug make -j3 sudo make -j3 install
Posted by Kurt Wall at 21:36 2009-11-09 | Trackbacks (0) | Comments (0)
Building mpg123 (Linux)
In the amusing software messages category, I offer this entry, seen while running the configure script for mpg123 (a command-line MP3 player):
… checking for artsc... ./configure: line 21938: artsc-config: command not found no checking if you are too dumbing dumb for the dummy... no configure: creating ./config.status …
I, for one, welcome our new too dumbing dumb for the dummy overlords am quite relieved to know I'm not too dumbing dumb for the dummy.
Posted by Kurt Wall at 19:57 2009-02-21 | Trackbacks (0) | Comments (0)
CCache Over NFS Considered Harmful (Linux)
With apologies to Edsger W. Dykstra.
I frequently (or is that constantly?) build and rebuild portions of our software stack at work. Because my home directory is an NFS export, I build on the local disk to avoid the overhead of compiles over NFS. Starting Tuesday, I noticed that compiles that usually took 10 minutes or so on my desktop system were taking nearly an hour and not finishing before I grew impatient and killed them. Clearly, something was wrong and by late morning Thursday, I was frustrated enough to start troubleshooting the problem.
I looked for the usual suspects. ps and top didn't show any processes hung, consuming CPU, or in an uninterruptible sleep. In fact, CPU usage was surprisingly low for a parallel build. The kernel wasn't OOPSing. Every other process or application was running fine. After concluding (wrongly, it turns out) that the culprit was not software, I started looking at hardware. SMARTD didn't show anything amiss with the disk. memtest86+ didn't uncover memory errors. The CPU wasn't downclocked. All the fans were working, so the box wasn't overheating. The GPU was fine.
I pulled the disk out my desktop system and put it into a crash test dummy and tried the compile, which ran equally slowly. I put another disk into the desktop system, booted as a local user (rather than using my normal user, which authenticates using LDAP), and ran a compile. It blazed right along. From this, I concluded that the original disk was bad but the desktop system was fine. So, I installed F10 on the new disk and went home.
Returning Friday morning, I logged in as usual, started another compile, and quickly saw the slow compilation problems had returned. This forced me to the conclusion that something was not right with my environment. While running yet another compilation, I ran watch ls -alt $HOME in another terminal and noticed that the $HOME/.ccache directory, which I had previously deleted, had mysteriously returned.
In the first place, I didn't install ccache when I installed Fedora 10 before the break. Secondly, its cache directory should not have returned after I deleted it. After killing the compile, running rpm -e ccache, and re-deleting $HOME/.ccache, compiling our software stack completed in 10 minutes. Mystery solved!
It was slow because even though the build was happening on local disk, ccache was building and updating its cache on a NFS mount, which requires lots of round trips to the NFS server. Thus, ccache over NFS considered harmful. What remains a mystery, though, is how ccache came to be installed in the first place. I didn't install it initially, but it might have been installed during an update. The perverse part of that story is that the version that did get installed was from Fedora 9. WTF?
So, I spent seven hours over two work days resolving this issue. Grmph.
Posted by Kurt Wall at 09:50 2009-01-24 | Trackbacks (0) | Comments (0)
Ubuntu Release Names (Linux)
Here are my suggestions for the next few Ubuntu releases, continuing their alphabetic, alliterative habit:
- Jaundiced Jackal
- Keelhauled Kestrel
- Leprosied Lemur
- Mangy Mongoose
- Narcissistic Newt
- Obese Ocelot
- Paunchy Peacock
- Queasy Quahog
- Retarded Rhesus
- Salacious Salamander
- Turgid Tadpole
- Ulcerated Urial
- Vapid Vole
- Wasted Walrus
- Xenophobic Xenopsylla
- Yammering Yak
- Zombied Zebra
The list is complete. Now perhaps Ubuntu's developers can focus on fixing the distribution instead of coming up with cutesy names.
Posted by Kurt Wall at 11:47 2008-11-29 | Trackbacks (0) | Comments (0)
Convert FLACs to MP3s (Linux)
I whined last night that TruckWerks' nifty neato new MP3 player only understands ID3v1 tags. Naturally, all of my MP3s, FLACs, and OGGs use ID3v2 tags (in the case of MP3s) or FLAC- and OGG-specific tags (in, duh, the case of FLACs and OGGs, respectively). So, I needed to convert those uncooperative tags to ID3v1. After some Googling and some research, I came up with the following flac2mp3 script to do the deed for me. You'll need flac and lame installed.
Here's the script, which is loosely based on Converting flac to mp3:
#!/bin/bash
# flac2mp3
# Convert FLACs to MP3s, downgrading ID3v2 tags to ID3v1 tags
for _fin in $@
do
_fout=${_fin%.flac}.mp3
metaflac --export-tags-to=tag.tmp "$_fin"
sed -i '{s/[a-z]/\u&/g
s/=\(.*\)/="\1"/}' tag.tmp
source tag.tmp
rm tag.tmp
echo -n "Recoding $_fin to $_fout..."
flac -scd "$_fin" | lame -q 2 -V 2 \
--ta "$ARTIST" \
--tl "$ALBUM" \
--tn "$TRACKNUMBER" \
--tt "$TITLE" \
--ty "$DATE" \
--id3v1-only \
--nohist \
-S \
- "$_fout"
if [ $? -eq 0 ]; then
echo "done"
else
echo "ERROR"
fi
done
To use it, pass the file names of one or more FLAC files, thus:
$ flac2mp3 bring_me_to_life.flac Recoding bring_me_to_life.flac to bring_me_to_life.mp3...done $
Or:
$ flac2mp3 *.flac Recoding bring_me_to_life.flac to bring_me_to_life.mp3...done Recoding everybody's_fool.flac to everybody's_fool.mp3...done Recoding going_under.flac to going_under.mp3...done Recoding haunted.flac to haunted.mp3...done Recoding hello.flac to hello.mp3...done Recoding imaginary.flac to imaginary.mp3...done Recoding my_immortal.flac to my_immortal.mp3...done Recoding my_last_breath.flac to my_last_breath.mp3...done Recoding taking_over_me.flac to taking_over_me.mp3...done Recoding tourniquet.flac to tourniquet.mp3...done Recoding whisper.flac to whisper.mp3...done
It's not fancy, but It Works For Me©.
Posted by Kurt Wall at 09:53 2008-10-05 | Trackbacks (0) | Comments (0)
Using DAR (Linux)
DAR is a Disk ARchiver, or, in other words, a nice utility for creating backups. I've been experimenting with it over here, comparing the trade-off between speed and compression. The story so far:
Compression Time Size ---------------------------------- None 13.7s 511MB gzip 99.7s 210MB bzip2 173.6s 196MB
I'm backing up to a spare disk, with the eventual goal of moving the archive files to CD-Rs, so compression isn't as important as it might be otherwise (CD-R blanks are cheap). I'm going to live with DAR for awhile before I render judgement, but I'm still looking for something that can back up straight to CD-R or DVD-R.
Tip o' the hat to Grzegorz Adam Hankiewicz for his HOWTO
that got me started.
Posted by Kurt Wall
at 23:01 2008-04-29
| Trackbacks (0)
| Comments (0)
CD Backup Utilities
(Linux)
I've been evaluating utilities for backing up to CDs and/or DVDs. Candidates culled from a Freshmeat search include:
- multicd
- CDBackup
- sync2cd
- Better Backup
- RAB (Random Access Backup)
- yacdback (Yet Another CD Backup Tool)
- bak2disc
I'm trying to use existing utilities instead of rolling my own. My requirements include:
- Easy to configure and use
- Backup to CD and/or DVD
- Ability to create/maintain searchable index files
- Console operation
- No odious dependencies; work with installed programs and utilities
- Executable by root or merely mortal users
multicd is out because it doesn't work well on udev-enabled systems. Although configurable, it makes assumptions about devices and device names that don't apply and it isn't easy to persuade it to use growisofs instead of cdrecord if you want to back up to DVDs.
I eliminated scdbackup because it had a totally
bizarre configuration procedure. CDBackup eliminated
itself by requiring Joerg Schilling's cdrecord-ProDVD for DVD support
(instead of growisofs). I tossed out sync2cd after a promising
start because the syntax was confusing and poorly documented. For example,
the output from sync2cd --help showed that I needed to specify
a configuration file as an final option, but this was not indicated
anywhere in the examples. In addition, I kept getting obscure Python
stack dumps:
# sync2cd_mkdvd.sh sync2cd.cfg Traceback (most recent call last): File "/usr/bin/sync2cd", line 30, insys.exit(main(sys.argv)) File "/usr/lib/python2.5/site-packages/sync2cd.py", line 1315, in main createGraftList(sys.stdout, config) File "/usr/lib/python2.5/site-packages/sync2cd.py", line 974, in createGraftList out.write(graftEntry(os.path.abspath(item.name), item.name) + "\n") IOError: [Errno 32] Broken pipe
Not only is the dump inscrutable (to mortals, anyway; I sorted it out), it overflows the text column in my blog. I can tolerate opaque errors, but screwing up my blog is inexcusable. ;-)
Better Backup wouldn't even compile:
$ make backup […] g++ -static -Wall -Wshadow -g -c backup.cpp tty_lock.h: In constructor 'tty_lock::tty_lock()': tty_lock.h:27: error: 'assert' was not declared in this scope tty_lock.h: In destructor 'tty_lock::~tty_lock()': tty_lock.h:61: error: 'assert' was not declared in this scope make: *** [backup.o] Error 1
Dude, one word: autoconf.
RAB required too much set up. Oddly, its model involved writing to rewritable media (specifically mentioning rewritable DVDs) until an archive was "full" and then making a permanent copy on CD-ROM. If I've gone to the trouble of using rewritable DVDs, why not keep them there or write the archive to vanilla DVDs? Go figure. Better still, populate the archive on disk and then write the permanent archive to removable media.
So far, this is not going well.
Posted by Kurt Wall at 16:56 2008-01-20 | Trackbacks (0) | Comments (0)
Stupid *NIX Tricks (Linux)
In the Stupid *NIX Tricks category, I offer this gem that I discovered tonight.
Before installing Slackware, I tarred up my local copy of my
Web site. Nothing exciting or unusual about that. Under Fedora,
DocumentRoot is /var/www/html. Under Slackware,
DocumentRoot defaults to /var/www/htdocs. Thus, because of
the way I'd executed the tar command, the archive's members
were located relative to var/www/html, that is:
var/www/html/ var/www/html/blogwerks/ var/www/html/blogwerks/archives/ var/www/html/blogwerks/archives/2007/ var/www/html/blogwerks/archives/2007/11/ …
Instead of untarring the archive and then manually moving the
files from /var/www/html to /var/www/htdocs, I learned that GNU
tar lets you transform archive member names while you
extract them. The syntax of this handy little option is --transform
SED_EXPR. So, the following command saved me 60 seconds
of extra typing, albeit for the cost of five minutes reading the tar
info page:
tar xzf www.tgz --transform 's;/html/;/htdocs/;'
Yup. I'm going to remember that little jewel of an option.
Posted by Kurt Wall at 00:02 2008-01-16 | Trackbacks (0) | Comments (0)
Slackware Again? (Linux)
I must have a short attention span or be bored or something, because I'm thinking of trying out the latest Slackware release, 12.0. Why?
Funny you should ask. Slackware was my first distribution, back in 1993. In the intervening years, I've used OpenLinux, Red Hat, Fedora, SUSE, Slamd64, Debian, and Ubuntu. I think I tried Mandriva and Turbo Linux, and at least nodded in the general direction of some of the small-time Linux distributions. But I keep coming back to Slackware because I'm sentimental. I also have found Slackware to be stable and (subjectively, to be sure) faster than other distributions on the same hardware.
In any event, Slackware has always had my attention. Its appeal to me is totally counter-intuitive. It lacks nifty configuration utilities; the installer is still text-based; "package management" is nothing more tarballs with a few pieces of metadata; and there is nothing like the automated update system modern distributions possess. I think I like it for the same reason that I enjoy building furniture and gardening; Slackware is an OS shop or garden in which I can putter and futz to my heart's content.
You can't do that with the big, shiny distributions anymore without running a genuine risk of trashing your installation and having to perform serious surgery to recover. I want to putter and remodel, not rebuild from bare framing.
Posted by Kurt Wall at 22:19 2008-01-14 | Trackbacks (0) | Comments (0)
Ubuntu Killing my Laptop (Linux)
...or at least it sounded like it.
While running the latest Ubuntu, the zoologically named Gutsy Gibbon, I noticed that the hard drive kept clicking every few minutes. A little bit of googling showed that the disk heads were parking aggressively, with the potential to shorten the disk's lifetime. This issue was covered with the hysterial typical of Slashdot in Ubuntu May Be Killing Your Laptop's Hard Drive.
The solution was simple. Use the following hdparm command
to disable the disk's power-saving feature:
# hdparm -B /dev/sda 255
Or, use this command to reduce the frequency with which the drive attempts to park the heads:
# hdparm -B /dev/sda 254
Of course, replace /dev/sda with the device that corresponds to your hard disk. It is still unclear who's fault it is, but I'll blame Ubuntu because they were delightfully slow to acknowledge the problem and seem only to have been prodded into action after the Slashdot story.
Posted by Kurt Wall at 15:22 2008-01-05 | Trackbacks (0) | Comments (0)
Cedega: Bah! (Linux)
I wanted to play a Windows game, Half-Life
2, so I grabbed the latest Cedega release, installed it, and
then installed Half-Life. Steam under Cedega is slow, but it did
install. Despite my best efforts, the game itself just froze at the
"Loading..." screen. I gave it 15 minutes and then gave up. Perusing
Transgaming's forums showed that other people had had similar issues,
but the none of the suggested workarounds actually worked. So, after
apt-get purge cedega-small, I installed Wine.
The Wine-based installation was smoother and faster, but when I started to install Half-Life, none of the screens had fonts, which made it rather difficult to know which buttons to press. Again, none of the workarounds suggested in the forums at WineHQ worked. I was disappointed, but not really surprised.
Equally unsurprising was the fact that installation and playing worked just fine under an actual Vista installation on my laptop.
Posted by Kurt Wall at 10:03 2007-12-31 | Trackbacks (0) | Comments (0)
Silly ISPs (Linux)
They're silly because most of the obstacles they put in your way you can work around.
Tonight's challenge was to figure out why I couldn't send outbound email. After a little trial and error, it become clear that my ISP, AT&T (pacbell.net), blocks traffic on port 25 that isn't destined for one of their servers. So, working with the guy who hosts KurtWerks, I configured Postfix to use a different port, 465 (the ssmtp port).
The configuration proved to be pretty simple:
- Don't use
relayhost = mail.example.com. - Create or edit /etc/postfix/transport, adding the line
* smtp:[mail.example.com]:465. This tells Postfix to send all outbound mail through the SMTP server listening on port 465 at mail.example.com. The square brackets aroundmail.example.comdisable DNS lookups, which makes the actual delivery process much faster. - Third, add the entry
transport_maps = hash:/etc/postfix/transportto /etc/postfix/main.cf. This tell Postfix to use the map you created in the previous step. - Run the command
postmap /etc/postfix/transportto create a hash table (/etc/postfix/transport.db) from the text file you edited. - Restart Postfix so it will pick up your changes.
Voila! Outbound email is flowing once again.
Granted, Joe Sixpack wouldn't have the knowledge (or need or desire, I suspect) to work this out, so the ISP gets what it wants, "control." The technically savvy user can find a way around it. It's also true that the technically savvy user probably won't have his or her machine turned into a zombie controlled by some spammer in Russia.
Posted by Kurt Wall at 21:39 2007-12-07 | Trackbacks (0) | Comments (0)
A Bash Debug Function (Linux)
I wrote a debug function for a largish bash script I've been working on. I'm sure others have thought of something similar, but this one is mine. Mine, I say! Mine! Mine! Mine!
Here's the code:
function debug()
{
_date=`date +%H:%M:%S`
_line="$BASH_LINENO"
if [ "$1" == "-v" ]; then
shift
while [ $# -ne 0 ]; do
echo "$_date [$_line] $1 ${!1}"
shift
done
else
echo "$_date [$_line] $1"
fi
}
Called as debug -v VARNAME, it prints the name
of the variable specified by VARNAME, followed by
the variable's value:
debug -v FOO
This yields output that looks like the following. A timestamp,
the line number where the debug() function was called,
followed by the variable name and it's value:
20:59:12 [6]: FOO=this is the foo string
I coded the function so you can specify multiple variables to a
single debug() call. Thus, debug -v FOO BAR
BAZ results in the following:
debug -v FOO BAR BAZ
00:23:07 [10]: FOO=this is the foo string 00:23:07 [10]: BAR=and this is a bar string 00:23:07 [10]: BAZ=don't forget the baz string
Called as debug STRING, it prints the specified
STRING:
debug "Your message here"
Here's the output of the second, simpler form. Again, it's a timestamp,
the line number where the debug() function was called,
followed by the string message:
20:59:12 [7]: Your message here
Sure, it's nothing to write home about, unless you're debugging someone else's bash script, which was the original motivation for writing this thing. I was debugging a script written by someone else and needed a function that would make it easy to sort out what it was doing when. This little function helped out enormously.
Posted by Kurt Wall at 00:34 2007-11-17 | Trackbacks (0) | Comments (0)