Software Sorcery

I spent some time last night installing Trac (a project wiki/source viewing/issue tracking system) and Subversion, a version control system on my FreeBSD server. The process went pretty smoothly - once again, the pile o' praise I heap on the ports system continues to grow. I would still like more info when an options dialog pops up, so I can make better decisions, but besides that, it went like clockwork.

Personally, I'm a Perforce man when it coms to SCCS. I've been using it for years, and really feel like it is an excellent client/server system. The support has always been phenomenal and I've brought it along to several jobs since I first began using it. The biggest problem with Perforce is that it is incredibly expensive. It is a real "enterprise solution" and charges as such. It cost US$800 for each license! They do have a free evaluation, where you can create two users but only five clients (local views of the source tree), which is too limited for any kind of real usage. I used to have a single developer license for it, but I don't have that any more. They also have a free version for Open Source projects, but as I'm not sure where, if anywhere, we're going with our little project, it doesn't seem like it fits.

So the next option looks to be Subversion, an open source CVS replacement, that is also supported by Trac "out of the box". It was reasonably easy to set up, although getting it "locked down" was hard to figure out. I wish these things would be installed with no access and then force me to open them up, rather than the other way around. I do like the idea of the SSL that is built into svnserve, although it seemed complicated to set up, so I passed on that for now. It also occured to me that Subversion doesn't let you know when another developer is working on code, as you "check out" the entire source tree when you begin work and then just "commit" your changes to it. I like being able to see in Perfore when someone else has a file checked out, so I know if I should ask about it first, or just be sure to get my changes checked in quickly and force the other developer to deal with merges!-)

The devel/subversion-python port installed /usr/local/etc/rc.d/svnserve.sh, which is the spot where startup scripts are supposed to go, so always look there when you install a new server. For some reason, the test install on my PC-BSD called the file just 'svnserve'. Odd. Anyway, if you look in that file, it graciously tells you the options that need to be set in the /etc/rc.conf file in order for the server to run and to get going at start up. It says:

# Add the following line to /etc/rc.conf to enable SVNServe:
#
#  svnserve_enable="YES"
#  # optional
#  svnserve_flags="-d --listen-port=3690"
#  svnserve_data="/usr/local/repositories"
#  svnserve_user="svn"
#  svnserve_group="svn"

So I put my own values in there and started it up. I had to add "--listen-hostname=amazingdev.com" to the svnserve_flags line, as my machine hosts several domains and the connection didn't work at first. It must verify a hostname or something. I ran the svnadmin create command to initially set up the "repository" (I like Perforce's nomenclature of "depot" better - sounds less like an anal medicine:-), but it's off to the races!

Then I installed www/trac, which seems like a nice integrated web-based project site. It includes a wiki area, a way to browse syntactically colored source files in your Subversion repository, as well as bug tracking (it calls them "tickets"). It also keeps track of all changes and allows you to create milestones. Once again, the installation went smoothly, with a single prompt asking if I wanted to use Silvercity for syntax highlighting. Luckily, I had looked at the web site and noticed a caveat warning that Python highlighting doesn't work with the 0.9.6 version of Silvercity, which is what is currently in the ports. Seeing as textutils/enscript-letter works just as well, albeit perhaps slower but with more options, it doesn't seem like a big loss to not add it in, as I'm not sure you can get the 0.9.5 version recommended on the Trac website.

The one thing the port didn't do was to put a startup script for the builtin tracd server into the /usr/local/etc/rc.d folder, like the Subversion port did. Not sure why it didn't, as there isn't a real downside to putting one there, as it won't run until the admin modifies /etc/rc.conf. Maybe the port maintainer uses the Apache mod_python version of Trac? Anyway, using the svnserve.sh file as a model, I created my own tracd.sh file:

#!/bin/sh
#
# tracd.sh for rc.d usage (c) 2006 Jonathan Arnold
# $Id$

# PROVIDE: tracd
# REQUIRE: DAEMON
# BEFORE: LOGIN
# KEYWORD: shutdown
#
# Add the following line to /etc/rc.conf to enable Tracd:
#
#  tracd_enable="YES"
#  # optional
#  tracd_flags="-d --listen-port=3690"
#  tracd_data="/usr/local/path/to/project"

. "/etc/rc.subr"

# Set some defaults
tracd_enable=${tracd_enable:-"NO"}
tracd_flags=${tracd_flags:-"-d --port=8080 --pidfile=/var/run/tracd.pid "}
tracd_data=${tracd_data:-"/usr/local/trac"}
tracd_pidfile=${tracd_pidfile-"/var/run/tracd.pid"}

name="tracd"
rcvar=`set_rcvar`
load_rc_config $name
command=/usr/local/bin/tracd
command_args=" ${tracd_data}"
command_interpreter="/usr/local/bin/python"
pidfile="${tracd_pidfile}"

run_rc_command "$1"

I had to modify a few things from the svnserve.sh file. Most importantly, tracd is a python script, so you need to add the "command_interpreter" line, as the standard startup/shutdown commands look at the name of the process attached to the pid and if it doesn't match 'name', it won't kill it. But it will first check for 'command_interpreter' to check against. I also added the --pidfile option to the command arguments, so tracd would write out its PID to a standard place. And then tell the standard scripts where this is. But other than that, it was pretty easy and now I have a script to start up the builtin trac server by adding tracd_enable="YES" to my /etc/rc.conf file.

We've got another live one

Another entry into the FreeBSD LiveCD pool. This one is called TrueBSD and has the excellent new feature whereby you can actually eject the boot CD and still run the OS. Now that's independence!

Official Web-site operation system TrueBSD

Permission Granted

Informative and very complete page explaining just what those pesky Unix file permissions bits mean. Carefully details each bit, along with some history and other tidbits. Looks like a nice wiki in general.

Unix Permissions

Cleaning up after yourself

A few interesting things came up on the .ports mailing list vis-a-vis cleaning up the ports. After you've done a make in the ports, a "work" folder is created. In here, the package is unzipped and then built, so there's a bunch of mostly wasted space, because chances are you don't care about the intermediary files. So if you do a # make clean after you've done the # make install, you'll clean up these temporary files.

But what if you forget to do the make clean? Or you don't normally do it, but at some point you want to clean it all up? JR Lenz posted the following shell script to do this for you:

#!/bin/sh
#
# remove_work.sh
# removes nasty, disk-hogging source code
#   and compiled objects from ports tree
#
# J. Ralf Lenz 
#

for i in `ls -Ad *`
do
if [ -d /usr/ports/$i ]; then
cd $i
DIR=`pwd`
DESIRED_PATH=/usr/ports/$i
if [ "${DIR}" = "${DESIRED_PATH}" ]; then
for j in `ls -Ad *`
do
if [ -d /usr/ports/$i/$j ]; then
cd /usr/ports/$i/$j
if [ -d /usr/ports/$i/$j/work ]; then
CUR_DIR=`pwd`
echo "Removing ${CUR_DIR}/work..."
rm -rf work
fi
cd /usr/ports/$i
fi
done
cd /usr/ports
fi
fi
done

While this is a usefully informative script, this also does the trick, albeit in a more arbitrary fashion:

# rm -rf /usr/ports/*/*/work


Boom - find all the port subfolders called 'work' and just remove them.

You can also change where the port system puts the work files by defining the WRKDIRPREFIX in /etc/make.conf (you can see other interesting variables for make.conf in the file /usr/ports/Mk/bsd.port.mk). WRKDIRPREFIX is explained thusly:

# WRKDIRPREFIX	- The place to root the temporary working directory
#				  hierarchy.

So if you don't want it to go into the port subfolder, just set it in /etc/make.conf. So to put the work folders into /usr/obj, add this:

WRKDIRPREFIX=/usr/obj

And, lastly, don't forget the 'portsclean' command. I guess the magic flags for this command would be:

# portsclean -CDLP

I don't see portsclean in the online man pages, so I'm not sure if it is a standard command or came in with some other port. As I generally use portmanager, which I believe does a clean, I don't worry about it. And if I do a make, I do a # make all && make install && make clean command.

Flashy Firefox

One of the most common complaints about FreeBSD is that Flash doesn't work "out of the box", with either Firefox or Opera. For me, that's not such a bad thing generally, as I find 90% of the Flash usage to be for annying blinking ads. But there a few sites that require it, including most video sites for some reason. So on my old Windows box, I never did install it on Firefox, my main browser, but when I needed to open a Flash site, I would just use the extension to either open IE in a tab or a standalone Opera. Worked very nicely.

But that doesn't work on BSD, because there isn't a running Flash. There's plenty of pages out there that purport to get it to run, usually using the Linux emulation layer, linux-firefox and the Flash plugin, although the current Flash version is quite old and has some serious security holes. But here's Yet Another page that shows you how to do it, if you feel the need. For me, I just swap to my Windows box if I really really need to get Flash'ed.

Flash Plugin on FreeBSD

And here's another one: http://www.jail.se/freebsd.html

Here is a very long thread on the PC-BSD forums on how to get it to run on PC-BSD:

Flash7 with FreeBSD Firefox 1.5

Fire On BSD

Someone is porting the FireGL ATI Linux driver to BSD, which would be a wonderful thing if it were to come off. I'll have to give this a try.

ATI on FREEBSD FireGL Linux Driv

Monster Mash

Whatever you do, don't try this at home! I was trying to rebuild something (it was so long ago I don't even remember what it was!), when I interrupted the process because I needed to reboot. That's one thing with ports - you go to build something and it needs something else and before you know it, you're an hour into the building process and no idea how much longer it is going to take. So I killed the portmanager build, logged out and rebooted.

Well, KDE wouldn't start up, complaining of a missing library. Since I tend to muck about a great deal with my system, I don't have a graphical login screen (gdm or kdm). I log in and then run startx. That way, if my X setup is screwed up, I at least can easily make changes and get logged in. And in this case, KDE complained. So I thought, well, I just rebuild KDE. What was I thinking? The simple command :

# portmanager x11/kde -l

began its work late Wednesday evening and didn't finish until this (Friday!) morning. And even then, important pieces like kdelibs didn't rebuild, for reasons I don't know. One problem I was having was that my machine was freezing after a very short time. I suspected the special 80x60 text mode I had the text console in, as I had noticed if I swapped to it while running X (via the Ctrl-Alt-F2 keystroke), my machine would freeze after a bit. Sure enough, after I put it back into the standard 80x25 video mode via # vidcontrol 80x25 command, it stopped freezing up. So now I'm wondering if that was the cause of some of my other display freezes. Something to be investigated.

Then I restarted the port build (oh man, thanks be to Zeus for the --resume option in portmanager, as the kde port looks at upwards of almost 200 ports!) and went to bed. Thursday morning I was greeted with the sight of a menu from some random library asking for me to pick a single option. I'm not sure if I can do -dBATCH with portmanager, but I'm certainly going to have to find out. Another problem with the options screens for many ports is that you have no idea what they are talking about. Usually it enables some obscure acronym, and you have no idea what the pros and cons for each option are. So I usually just pick the default anyway. So I did in this case, and build trundled on.

And on. And on. Mysterious build commands whizzed by the screen all day long. By mid-afternoon, I got an option screen for KDE asking which KDE apps to install. I once again had a brain cramp and allowed it to install all of them. So dozens more apps that I don't want and don't need, like KOffice, got installed. Then, right around dinner time, it stopped scrolling, as it seemed to be linking some app. So I let it hang around for over two hours, and nothing changed. I couldn't even ctrl-C out of it, as the keystrokes just echoed to the screen. So I ctrl-Z'ed out of it, putting it in the background, and then killed it. But I forgot to check the log file before restarting the build, so I'm not even sure where it hung up.

And that build trundled on, Finally, just this morning it finished, although an important piece, kdelibs, failed to build for some reason. I just didn't have the intestinal fortitude to try and build it again, so here I am with some kind of Frankenstein system, which is seasonally appropriate at least.. Now I can't wait for PC-BSD 1.3 to come out, and I'll just start anew!