Heeding the advice of my productivity guru: “don’t bite off more than you can chew” (thanks ma!), I used the following grep sequence to generate some organic milestones. Now I know the number of actions per module

grep -c "function execute[A-Z]" apps/frontend/ -R | grep ".php:" | grep -v ":0$" | grep -v "components.class.php"


Of interest to me was trac-bzr. Since Bazzar has the power of Canonical behind it, a cursory glance at the “universe” repository shows a package named “trac-bzr”. However a closer look reveals that this package is quite outdated:

>apt-cache show trac-bzr
Package: trac-bzr
Priority: optional
Section: universe/python
Installed-Size: 156
Maintainer: Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com>
Original-Maintainer: Chris Lamb <chris@chris-lamb.co.uk>
Architecture: all
Version: 0.2+bzr31-3
...

This seemed like a bad idea, seeing as the main branch was already at r69.

Here are the instructions on installing the latest version:

1. Make sure you have bzr installed

sudo apt-get install bzr

2. Get the latest version of trac

sudo apt-get install trac

3. Get the latest version of trac-bzr, and put it in a revisioned directory.

bzr export ./trac-bzr-r`bzr revno lp:trac-bzr` lp:trac-bzr

4. Install the plugin

cd trac-bzr-r*
python setup.py install

5. Configure trac to use the plugin as described in the trac-bzr README

<?php
echo link_to('Name of Link', '@route_to_action?param1=value1&param2=value2');

And it would generate something like this:

<a href="/module/action/param1/value1/param2/value2">Name of Link</a>

However, for the first time, I found myself NOT wanting this behavior. I wanted:

<a href="/module/action?param1=value1&param2=value2">Name of Link</a>

I looked high and low, on and off for a few days. I finally found something in the forums, with a note saying it should be in the documentation, but isn’t.

<?php
echo link_to('Name of Link', '@route_to_action', array('query_string' => 'param1=value1&param2=value2');

If I had kmixer open, I could see that the keys were manipulating the PCM channel, not the Master or Front channels. A Google search later turned up a ticket on Launchpad. Turns out all you need to do is right click on the volume icon in the system tray and select “Select Master Channel…”.

For me, “PCM” was selected. I changed it to “Master” and viola

link ../path/to/link

I ran this snippet to find all locations of this event so I could fix them:

find . -size 1k -exec grep -E "^link" '{}' \; -print

Hope that helps.

Update: Wrote a script that will remove the old links and replace them for you.

#!/bin/bash

if [ $# -eq 1 ]
then
DIRNAME=$1
else
DIRNAME=`pwd`
fi

broken_links=`find $DIRNAME -size 1k -exec grep -Es "^link" '{}' \; -print \
| xargs -l2 echo -e "" | awk '{print $2 " " $3}'`

echo -e "$broken_links" | while read line; do
link=`echo "$line" | cut -d ' ' -f2`;
target=`echo "$line" | cut -d ' ' -f1`;
relative_dir=`dirname $link`

cd $relative_dir; rm $link; ln -s $target $link
done

What this does is:

1. hit http://checkip.dyndns.org, silencing wget’s output and redirecting the downloaded file to stdout
2. parse the html page as text
3. get rid of the cruft (I was thinking about using a complex regex here, but the IP address prefix seems less of a dependency concern than the actual dyndns service)

The problem originates somewhere between XGL and using your numeric keypad to control the pointer (known as Mouse Keys).

If you’re sure you don’t need XGL (check your xorg.conf first!), then simply remove it:

sudo apt-get remove xserver-xgl

And disable your Mouse Keys:

1. System -> Preferences -> Keyboard
2. Mouse Keys (tab)
3. Uncheck “Allow to control the pointer using the keyboard”

Now restart your machine, and Voilà

Solution:  For some reason I’m used to Subversion commands being recursive by default (guess I’m used to doing a lot of updating?). This is apparently not the case with revert. You need to explicitly indicate the -R [ --recursive ]  option

To revert an entire directory:
svn revert --recursive <directory>

There was even a convenient and deceivingly helpful little WiFi network prompt that showed me all of my local networks. I found mine, and clicked connect. The screen went away, I assumed I was connected, but alas to not avail, I was not.

For some reason, the little WiFi tool (that shall remain nameless) could identify that my network used WPA security, but couldn’t connect to it. Helpful, but only in a deceiving way. At first I didn’t think much of it. Even Ubuntu has its WPA woes a few releases ago.

So then I embarked on the “chicken-egg-chicken-egg” scenario of downloading drivers from the internet that enable my computer to connect to the internet. One Ethernet cable and a Google search later, I found the OpenSolaris laptop support page with a mini tutorial on how to install the wpa_supplicant (again, very reminiscent of the Ubuntu olden days).

Got everything downloaded and installed, but when I tried to start the wpa_supplicant daemon, I got this nasty, brutish error:

ld.so.1: wpa_supplicant: fatal : libssl.so.0.9.7: open failed: No such file or directory


“Okay” me thought to myself, “I need libssl”. But when I went to check, I sure enough had OpenSSL already and its version was 0.9.8a

At this point I was crying and screaming on the floor. My new toy wasn’t going to work. Why does this always happen to “me”?!? The last thing I wanted to do was start symlinking “shit” around in an OS I wasn’t familiar with.

What happened next is what highlights a fundamental difference b/w men and women (note: I am man). A woman by the name of Karen Tung simply asked how to fix this problem on an OpenSolaris forum. I guess its like the proverbial “let’s stop and ask for directions”…”go to hell, I’m not lost” scenario.

Here is the solution, reposted in its infinite glory:

# from the terminal...
# change to the root account.
# the root pw on the livecd is 'opensolaris'
su root
dladm create-secobj -c wpa mykey
# enter your psk twice
dladm connect-wifi -e "<essid>" -k mykey <interface>


If you don’t get any “shitty” feedback like a segmentation fault, you should get that overly persistent, initially deceiving WiFi dialog popup (within a few minutes, hang tight). Find your ESSID you entered above, enter your psk ONE MORE TIME and you should be cool. You should receive a dialog confirmation saying something like

Brought interface interface up, got address xxx.xxx.xxx.xxx

Now you can post on your blog from the liveCD…like someone I know…

1. Sun says: “OpenSolaris is desktop ready”
2. Out-of-the-box: no decent (WPA, etc) WiFi support
3. Manageable until: you realize OpenSolaris needs an internet connection to “function properly”.

Just upgraded to Ubuntu 8.04. Leave “desktop readiness” to the experts.