Installing Subversion on Windows Vista

Just installed Subversion on my (relatively) new Vista notebook just now, for bookkeeping purposes in the midst of iffy edits.  Followed the notes on the VertigoSystems blog, which in turn are following the notes on Joe White’s blog, which were overall very useful.  A point that I discovered after some digging, that might help you:  When you go to run “sc …” to register the service, ensure that you’re running in a command window started with “Run as Administrator”.

Updating from Hardy Heron to Jaunty Jackalope

Finally got around to updating Ubuntu this evening.  Had to go from Hardy to Intrepid first (purely as a waypoint), then to Jaunty Jackalope.

No major problems, although HAL quit for me at some point and had to be restarted remotely (stopped recognizing my mouse and keyboard when I kvm’d back from another machine).

After booting into Jaunty, I started getting the error “Tracker Applet: There was an error while performing indexing: Index corrupted.”  This appears to be a pretty common error.  For instance:

You probably want to read those to draw your own conclusions, but what worked for me was to install the tracker-utils package, and then wipe out trackers.

# Install the tracker utilities
sudo apt-get install tracker-utils
# Kill all the processes and wipe out the database
sudo tracker-processes -r
# Remove the cache
rm -rf ~/.cache/tracker
# Clear local settings
rm -rf ~/.local/share/tracker
# Remake the directory
mkdir ~/.local/share/tracker
# Restart the daemon
sudo /usr/lib/tracker/trackerd &

Now … I suspect that’s not permanent, but we’ll see what happens after the next reboot.

Followup:  That worked fine.  After logging out and logging back in, the tracker applet restarted, indexing restarted, and finished pretty quickly.

Chill your Notebook with NHC

Having had all sorts of problems with my Lenovo T42p overheating after the fan blew, even with the fan kept on maximum, I had to find ways to force the temperature down.  Not cool when trying to run a backup causes an abrupt system shutdown!

I found the answer in the really nifty application Notebook Hardware Control.  This application allows you to control the various settings on your notebook associated with power management.  You can assign different profiles for docked and undocked.  Most importantly, you can throttle down the speed your CPU’s running at by controlling the voltage, triggered by different CPU loads.


Notebook Hardware Control
Notebook Hardware Control

By doing this, you can turn your CPU speed — which you generally don’t need most of, given a modern machine — way down.  I find this useful for keeping my machine cool … but you’ll probably find it useful because by turning the speed down, you can substantially prolong your battery life.  I find that — even with the fan kept on full all the time — I’m adding another 0:30 or so to my battery time.

Building MP3 support into Sox

I rip all my old CDs as MP3s now.  I used to rip as Ogg Vorbis, both for the higher quality, and because Ogg isn’t a patent-encumbered format, but there are just too many music applications (both software and embedded systems, such as the Netgear MP-101 wireless music streamers I picked up cheap to scatter around the house) that don’t understand Ogg, so I gave up.  MP3 it is.

Now, I’m trying to put together a simple script to merge an MP3 playlist into a single MP3.  Sox should do the trick … but it doesn’t come with built-in MP3 support (for obvious reasons).  Here’s what I did to build MP3 support into Sox — many thanks to a good post by Michael Walma on the Ubuntu Forums.

First, make sure you have what you’ll need.  LibLAME is the library for encoding MP3s — your specific version may vary from what’s below (use Synaptic Pkg Mgr to check what’s available with a search on “lame” if in doubt).  Be sure that you have universe, multiverse and restricted enabled in your package sources (/etc/apt/sources.list), as anything MP3-related is going to come from the non-standard locations.

sudo apt-get install sox liblame0 liblame-dev
sudo apt-get build-dep sox

Switch to where you’re going to build it (e.g., cd /usr/local/src).

sudo apt-get source sox

Unpack the source and switch to the source directory (your version is likely to vary):

sudo dpkg-source -x sox_14.0.0-5.dsc
cd sox-14.0.0

Now you need to enable LAME support:

sudo vi debian/rules

And comment out the line that reads:


Build it:

sudo dpkg-buildpackage -b

Back up to the parent directory (cd ..) and install the newly-built packages.  For me, only new Sox packages were in the directory, so I just swept them up together.  Otherwise, you’d need to do them one by one, or with a filter such as *sox*.deb:

sudo dpkg -i *.deb

And, now, you should be able to confirm that you have support with:

sox -h


Creating Large Partitions on Ubuntu

While I had my server open to mount the WD (formerly external) drive, I threw in the two 1.5Tb (!) drives I’d brought back from the US … yep, time to start regularly backing up all the machines sitting around the house.

GPartEd refused to create 1.5Tb partitions (kept getting the error “a partition cannot have a length of -1 sectors”).  Setting the disk label to GPT rather than MSDOS (as suggested here) didn’t do the trick.  Instead, what worked was a combination of cfdisk and mke2fs.  In my case (assuming /dev/sde):

sudo cfdisk /dev/sde
sudo mke2fs -j /dev/sde1

Finally, to get the volume ID (for ID-based mounting, which is always best!):

sudo vol_id /dev/sde1

… and add it to the fstab.

Samsung SyncMaster 204B died as well …

(Note on previous post … simple as pie to pop the WD drive out of the enclosure and directly mount it in my server … back with access.)

Also, my (2.5 year old) Samsung SyncMaster 204B has started to go — when first turned on, it’s dark, then gradually starts showing the picture, although as of today it remains dim and flickering.  Presumably the backlight inverter … apparently pretty common to fail, at least as discussed here (with pix and hints on fixing with capacitor replacements) and here.  You can buy at least some inverters from LCD Parts, and InventGeek has an article on how to swap them.  Luckily, I’m still under warranty (which includes the backlight) … unluckily, I bought it in the US, and am now in the Netherlands.  We’ll see how it goes …

Western Digital Elements external hard drive power supply dead

It’s certainly not been a great week for hardware for me.  Now the USB 2 Western Digital Elements (1Tb) external drive that I had hooked up to my Linux box quit on me.  Appears to be the power brick — disconnecting the enclosure and unplugging/plugging the brick causes the green light to light briefly, then fade away — although I haven’t actually tested the pins to prove that they’re dead and it’s not the enclosure itself.  The thing is only about 6 months old; what a crock.

Apparently, the failure for these drives is endemic.  See, for instance:

The consensus appears to be that WD can’t/won’t replace the power supplies without, at best, a hassle.  While Asian Power Devices appears to manufacture a compatible brick, I think I’m just going to go get a new SATA enclosure (or maybe just remount the drive internally) … which is too bad, as I liked the rubber feet on the WD enclosure.  Sigh.

Anyhow … given the similar problems others have had, and the minimal opportunities to rectify the problem, I’d stay away from these drives.

Chrome ate my Thinkpad

OK … not quite, but close enough.  I’ve now noticed that when running Chrome (in my typically abusive manner — with 15-30 tabs open for my queued up reading matter slash multi-tasking), my CPU temperature rises about 2-4° (C) due to the Chrome hammering of the CPU.  Is that an essential design trade-off (separate processes per page = constant processing of javascript, Flash, etc.), or is this just an (incredibly annoying) implementation defect, and will a future version of Chrome hibernate the processes/pages that aren’t currently active/visible (if I can’t see it, either turn it off, or nice it down so far that it won’t substantially impact the CPU).  As it is, if I leave Chrome running (again, with many tabs), I typically see CPU usage > 75%, and eventually approaching > 95%.  Luckily, Chrome has automatic saving of current tabs … so it’s a breeze to just start and stop it at will (hint, Firefox:  stop asking me if I want to save my current tabs … of course I do!).

But why am I now monitoring the Chrome effect on my CPU temperature?  Because earlier this week, in the midst of all sorts of irreproducible work (of course), my 3-year-old Lenovo T42P abruptly quit, and wouldn’t return to life.  BIOS diagnosis:  fan kaput — and to the point, the notebook would shut down immediately thereafter.

Took the old fan out, which was very easy, following the instructions in the clean T42 Manual.  For finding the right part number (a cutely named FRU = “Field Replaceable Unit” … guess I’m in the field now!), I used the Service Parts Diagram for the T42p.  Turns out that my part number – 13R2657– has been replaced by part number 41W5204 (confirmed in the Thinkpad forums, and also by IBM NL).  Since I’m in the Netherlands, I had to order from IBM NL … they were pleasant and efficient, and I received the fan overnight.  Putting the new fan in was a breeze.

Disturbingly, though, the Thinkpad booted up, but then would quit after 10-20 minutes … and by “quit”, I mean:  turn off abruptly, with no traces left in the event logs.  Not so cool.  So I installed “Emeritus'” Windows Thinkpad fan management app (if you’re running Linux on a Thinkpad, there’s a whole host of app support for you … Google it), as discussed in this thread, set it to be a bit more aggressive about kicking the fan up in response to temperature steps … and … so far, so good.  I’m holding at about 53-54° C when on battery, even with my Chrome abuse.

WordPress Plug-In Install Problem

I encountered the following error when installing a new plug-in (edited for details):

Warning: include_once() [function.include]: Failed opening ##path-to-wordpress##/wp-content/plugins/twitter-for-wordpress/’ for inclusion (include_path=’.:/usr/share/php:/usr/share/pear’) in ‘##path-to-wordpress##/wp-settings.php on line 473

I’d installed the plug-in “manually” (that is, downloaded it  and unzipped it into the plug-ins directory).  Some quick web searching didn’t exactly point to the error.  Nor did looking at the wp-settings.php file line 473 (just a straightforward directory include … of a directory that’s already been confirmed to exist!).

Everything pointed to a permissions problem.  OK.  Checked the permissions … and they were, indeed, bad.  So I fixed up all the permissions (so that Apache and its friends could read the directory) … still the same error.  Even recycled Apache … still a problem.  Googling didn’t really help … one page was on point (but without a fix), and the rest of the hits were all on pages that were throwing this same error <g>.

Turns out that once you’ve started a plug-in install, if your permissions are bad, you’re hosed.  You need to remove, then re-install the plug-in.  I did this, which fixed the problem:

  1. Moved the new plug-in directory out of the plugins folder.
  2. Reloaded the admin plugins page … OK, error disappears.
  3. Moved the new plug-in directory back in.
  4. … voila, able to install and configure the plug-in.