A while ago I made this post about how all these excellent video game anthologies for various platforms are spoiling me and leaving me wanting more of the obscure yet awesome titles of yore. Specifically, I said

The point is that I want to know "Where the hell is my TruboGraphix collection?" ...... "Where is my collection of Jaguar games?" ..... "Where is my Sega Master System collection?"

and then proceeded to innumerate several collections that I wanted to see including a collection of classic Sega Master System and Game Gear games.

Well you know what? Someone did it :-)

more...

Next week I will be giving a small presentation on VirtualBox at the CINLUG June 6, 2007 General Meeting. The presentation will honestly be pretty small and focus entirely on what VirtualBox is and what you can do with it, but any folks in the Indy area who are interested are encouraged to come as it should at least be fun if not terribly informative.

more...

Recently I've had a need for virtual machines as I have to run various distros for work-related testing. Traditionally I probably would have just chrooted all my work and called it good, but I was very busy with other things, and decided to try real VMs instead.

The problem is, I didn't want any high maintenance ones that required a lot of tweaking and configuration (like bochs or qemu) and I also didn't want any proprietary hunk of shit like VMWare. So it was with great delight that I found VirtualBox.

more...

more...

When it's all said and done, you should have a working Hg repository server and should be able to pull/push from/to it.

more...

Setting up the Hg http interface

As I said before, I used SVN via WebDAV and it was pretty painless once I got it going. Thus, I want Hg to behave exactly the same way when I do my pushes and pulls. Hg doesn't use WebDAV (at least, if it does, I didn't look deep enough into the documentation to figure out how to set it up), but it does come with a handy CGI script for giving you the same basic functionality.

Configuring hgwebdir.cgi

If you're only running one repo, there is a script called hgweb.cgi which is easy to configure and will handle your needs. However, since I run multiple repos, I decided to use another script called hgwebdir.cgi that serves up multiple Hg repos in one web-interface.

hgwebdir.cgi takes an external configuration file that defines the repos it will monitor. There are two ways you can configure this file for the repos.

The first is to use the [collections] directive which auto-magickally determines all of your Hg repos based upon some common root directory. For example, let's say that all your repos are under /var/repos:

/var/repos
      projecta/
      projectb/
      projectc/foo

You would then place the following in your hgwebdir.cgi configuration file if you wanted to use the [collections] directive:

[collections]
/var/repos = /var/repos

This configuration file would make your repos available online as "projecta", "projectb" and "projectc/foo".

However, if your repos are not under some common directory, or if maybe there's other items that aren't repos alongside your repos, then you can use the [paths] directive to itemize each one:

[paths]
projecta = /home/fred/hg/projecta/
projectb = /var/repo/

Whichever you do, save the file (the name doesn't matter, I just used hgweb.config) and edit the line in hgwebdir.cgi to point to this newly created configuration file. For example:

def make_web_app():
    return hgwebdir("/etc/hgweb/hgweb.config")

Configuring your webserver

Technically speaking, you're already set. Just stick the hgwebdir.cgi file someplace where CGI scripts can be executed and point your browser at it. However, at this point you can't push repository changes via this web interface. Additionally, I kind of wanted the URLs to look cleaner.

Clean URLs

You may be fine handing out repository URLs like http://someurl.com/cgi-bin/hgwebdir.cgi?mf=b22511d1eb56;path=/, but I'm not. I want my repository to have URLs that are clean as possible. So, I make sure mod_rewrite is enabled in my server (a2enmod rewrite, if you're running Apache2) and add the following to my Apache2 configuration entry on my hgwebdir.cgi:

        <IfModule mod_rewrite.c>
                RewriteEngine on
                RewriteRule ^/(.*) /hgwebdir.cgi/$1
        </IfModule>

User Authentication

Next up, I want users to have the ability to view and clone the repository anonymously, but need to be authenticated in order to push back to the server. Additionally, I want a central place for the htpasswd file (you could do this on a per-project basis, but I'll explain why you don't want to in a bit). So, I add the following to my Apache2 configuration entry on my hgwebdir.cgi:

        AuthUserFile /etc/hg/htpasswd
        AuthName "Dev Repo"
        AuthType Basic
        <Limit POST PUT>
                 Require valid-user
        </Limit>

The <Limit> segment is the magic that allows us to have anonymous access to the repository but in order to push you must be authenticated.

Note that in my example here we're using "AuthType Basic", which is probably not the best way to do it. However, it is the most simple way to show for this example. I leave it to the reader to figure out how to use another AuthType (or, make pushes go across SSL).

Making the CGI the index

The final thing we need to do is make it so that the hgwebdir.cgi script is the index when the server attempts to serve up the page and to make sure the server can handle CGI.

         DirectoryIndex hgwebdir.cgi
         AddHandler cgi-script .cgi
         Options ExecCGI
         Order allow,deny
         Allow from all

Putting it all together

If we put it all together and assign it to a virtual host, we get an entry like the following (which, if you're using Apache2 can just be placed as a file in sites-available):

<VirtualHost XXX.XXX.XXX.XXX:80>
        ServerName hg.someplace.com
        DocumentRoot /var/hg/hgweb
        <IfModule mod_rewrite.c>
                RewriteEngine on
                RewriteRule ^/(.*) /hgwebdir.cgi/$1
        </IfModule>
        <Directory /var/hg/hgweb>
                DirectoryIndex hgwebdir.cgi
                AddHandler cgi-script .cgi
                Options ExecCGI
                Order allow,deny
                Allow from all
                AuthUserFile /etc/hg/htpasswd
                AuthName "Dev Repo"
                AuthType Basic
                <Limit POST PUT>
                        Require valid-user
                </Limit>
        </Directory>
</VirtualHost>

Configuring your hgrc file(s)

The hgrc file is the general configuration file for all things Mercurial. There are always at least two possible hgrc files for every repository:

• A system-wide hgrc (usually /etc/mercurial/hgrc) that defines Mercurial globally.


• A repository hgrc (${PROJECT_ROOT}/.hg/hgrc) that defines specific Mercurial properties for a given repository.

Inside of these hgrcs, you can define a directive called [web] which controls the behavior of the web-interface used in hgweb.cgi and hgwebdir.cgi.

System-wide web hgrc settings

Hg's web-interface defaults using a style that I personally find to be ugly and confusing to use. I much prefer the "gitweb" style over the default Mercurial style. So I set the "style" parameter in the [web] section of the system-wide hgrc to "gitweb" to make it the default style.

Additionally, I want compressed archives to be made available, and I want to set a system-wide contact. Finally, if you're using the same setup I've detailed above, you aren't using SSL for your pushes, which means that the push over SSL requirement should be disabled.

[web]
style = gitweb
allow_archive = bz2 gz zip
contact = Myself, me@somewhere.com
push_ssl = false

Per repository hgrc settings and user authentication

For each repo, you can define a specific hgrc file that will override the system-wide settings from /etc/mercurial/hgrc.

Generally speaking, you want to at least define a description for the repository as well as who is allowed to push. Additionally, you can define new contact information if it differs from the system-wide setting.

[web]
description = An addressbook for keeping track of your "friends"
contact = Ted Haggard, tedh@ilikethemens.com
allow_push = tedh

Now, you can easily define per repository htpasswd files, however, this can get unwieldy and is completely unnecessary. Instead, it makes more sense to define a global htpasswd file, but then define push rights per repository in the hgrc.

So I could have a global htpasswd file that defines all of my users like this

tedh:HGand8176
fred:87JIkn7j1*9
joe:87/joiqKl91
jake:jasmn1%1tba

But then define the following project push rights via their hgrc's:

Project A

[web]
descrtiption = Project A
allow_push = tedh, joe

Project B

[web]
descrtiption = Project B
allow_push = jake, fred

Project C

[web]
descrtiption = Project C
allow_push = tedh, jake, joe

more...

Converting single/multiple SVN repos to Hg repos

This was perhaps the trickiest part of the process for me. This was because there's a plethora of tools for doing SVN to Hg conversions, but most of them don't seem to work well. I first tried yasvn2hg, but I couldn't get the damned script to even run. Next I tried Tailor which promised to be the Swiss Army Knife of repo conversion utilities. However, I had hours of headache and no progress using it. Finally, I tried hgsvn, and it worked like a charm.

hgsvn is apt-gettable in Debian. However hgsvn needs the functionality from python-setuptools, but its package does not require it. This means that, unless you already have python-setuptools installed for something else, chances are you will see this error when you install hgsvn and try to run it:

$ hgimportsvn http://url.to.repo/repo
Traceback (most recent call last):
  File "/usr/bin/hgimportsvn", line 5, in 
    from pkg_resources import load_entry_point
ImportError: No module named pkg_resources

If you get this error, simply install the python-setuptools package (or equivalent) and try again.

Once hgsvn and its needed libraries are installed on your system, the basic method to convert a repository is as follows:

$ hgimportsvn http://url.to.repo/repo
...^^^Sets up the import
$ cd repo
...^^^Changes to the freshly created subdir
$ hgpullsvn
...^^^Pulls down all the changes from svn and creates an hg history
$ hg update (optional)

Once you've done these steps, your repo will have been converted to Hg. This works well for single repositories, but what if you have something more complicated?

Splitting a single repo into multiple repos

If you're like me, when you originally set up SVN you did so in the laziest way possible.

Setting up SVN repos is more work than it should be. It involves using commands that you normally never have to touch (svnadmin), setting up new entries for those repos in your http server's configuration files (if you're using Apache and WebDAV), and setting up user permissions to those repos. Thus, the lazy way to set them up is to make one central SVN repo under which you have multiple sub-repos. This has the advantage of making your repository very easy to maintain. However has a big disadvantage in that a user with write access to any sub-repo will have write access to the entire repo.

In Hg, on the other hand, setting up a new repository is much easier, and maintaining multiple repositories more manageable. So, if you're like me, you may be tempted to remedy past sins by splitting your single gargantuan SVN repo into smaller Hg repos. Thankfully, hgsvn makes this very easy.

Let's say that you have one core SVN repo, called "main" which has the following sub-directories which you are treating as sub-repos:

main/
  projecta/
  projectb/
  projectc/

hgsvn can actually handle sub-directories of SVN repos and generate histories of just those sub-directories, effectively splitting the directories into repos of their own. It will even keep track of changes that only affect the individual sub-repo (meaning parent or neighbor changes don't get entered, unless they were otherwise combined in the original SVN).

A method for splitting the above could be:

$ hgimportsvn http://url.to.repo/main/projecta/
...^^^Start with "projecta/"
$ cd projecta
$ hgpullsvn
...^^^Pull the history for "projecta/"
$ hg update
...
$ cd ..
$ hgimportsvn http://url.to.repo/main/projectb/
...^^^Move on to "projectb/"
$ cd projectb
$ hgpullsvn
...^^^Pull the history for "projectb/"
$ hg update
...
etc.

Cleaning up the SVN cruft

When you're done using the hgimportsvn and hgpullsvn tools, you will have repos in a strange half-SVN/half-Hg form. They will be legitimate Hg repos, but they will still have the .svn directories strewn throughout them, and have some .hgignore files telling Hg to ignore said .svn directories. So, if we're going to go 100% Hg, we may as well get rid of this stuff.

$ cd repo/  (whatever the path is to your hgsvn made repo)
$ find . -name .svn | xargs rm -fr
...^^^Get rid of the .svn/ directories
$ find . -name .hgignore | xargs rm -fr
...^^^Get rid of the .hgignore entries

more...

As I said in my last entry, I've been evaluating the various modern DVCSes to try and figure out which of them would give me the most benefit, while at the same time irritate me the least.

I've been using Subversion (SVN) for a few years now on my dev servers (formerly, svn.samhart.net and friends) and have mostly been pleased with it. In fact, the only reason I even considered replacing SVN was because there were certain aspects of DVCS that I felt could make my life easier, namely the ability to have a repo's entire history available locally and the fact that offline work can be done so much easier with them.

Additionally, I've been working with a lot of modern DVCSes lately (namely bzr, git and svk) and I've been very displeased by each of them. They all had at least one critical problem that, for me, made them impractical to even consider for use in my own repos. The end result is that I've spent a lot of time frustratingly researching and testing as many DVCSes as I could to try and figure out if I should switch or just stick with SVN.

But, after the smoke cleared and the fires died down, I discovered that one DVCS, Mercurial (Hg) was left standing on equal ground with SVN in the "has to not irritate me" department.

The problem? Conversion from SVN to Hg isn't as straightforward as one would like. Thus, I'm documenting the steps I had to do to try and help out anyone else who's attempting to go down this path.

more...

Moved to here.

more...

Well, I've been migrating my development server to a new hoster (actually, they aren't new, I've used them for years for my other stuff, and been very pleased with them). In the process of the move, I've been cleaning things up and re-engineering things somewhat to solve some of the problems I've had traditionally.

One of the things that does keep coming up is a question as to whether or not I should continue to use Subversion for my online code repo. So, I've been looking at other alternatives, especially DVCSes, trying to see whether I would get any real benefit from them, or just be more burdened.

What's my conclusion? My conclusion is that they all suck, and maybe I just need to stick with SVN. Read on for the details...

more...

Friends and regular readers of this site know I have had numerous and continual problems with email. Part of it is that spam is such a prevalent problem (and has caused me to create several
iterations of an anti-spam system).

Another part has always been the email clients themselves. I've tried everything, but it's been very hard to fit my needs exactly.

more...

Just as a heads up, Sam Hart.net Webmail is now dead. It was badly neglected, and I've been reorganizing my email system anyway. If you *really* need a webmail system then I'd suggest trying GMail or some other alternative. If you had an account and need your message archives, let me know, I still have them all.

more...

I know, way to state the obvious. The thing is, I'll confess that I've always liked the horror and thriller genres. When I was entirely too young I had nightmares from the ghosts in Poltergeist. I spazzed out over the guy in the dog suit in The Shining. Leaped from my seat when Lois Maxwell as Grace Markway reached from the attic in The Haunting. Later on I thrilled at the campy ways Freddy Kruger tormented and killed his prey in the Nightmare on Elm Street movies.

And yet here I am, at two in the morning, watching the 2006 remake of "The Hills Have Eyes", and for the life of me, I can't remember the last time a movie really scared me.

more...

Well, the Progeny closure I mentioned here is starting to get more press, as you can see in this Linux.com article. However, I'd just like to say that a lot of what is in that article is total bullshit. Sorry, but it's true.

I was there at Progeny up until their last few weeks of operations. Additionally, I'm good friends with the former employees, and was able to keep apprised on the situation at Progeny after I left. Hell, I'm even still owed money by Progeny, so you can say that I'm considerably connected to the former company.

more...

GAH! When the hell did I go bald? And why didn't any one tell me? What the hell?! I thought you people were my friends! And yet, here I've been living my life as a bald git and no one told me. Egads, people!

Don't believe me? Take a gander at all this deforestation.

Seriously, what the hell? When did this happen?

more...

For those who haven't seen the tiny coverage it's getting, Progeny Linux Systems has shut down. From the website:

We are sorry to inform you that Progeny Linux Systems, Inc. ceased operations April 30, 2007. Questions may be directed to:

board_at_p.c

Offers to purchase the progeny.com, progenylinux.com, progenylinux.org, progenylinux.net, componentizedlinux.com, componentizedlinux.net, componentizedlinux.org, or globalinuxsupport.com domain names should be made to:

webmaster_at_p.c

more...

Recall this. And then note this. I've now redirected the Tux4Kids sites to their new home on Debian's Alioth. However, for legacy purposes, I've archived the old old OLD T4K site here.

more...

So in my recent move I've bought a new HDTV. I had some very specific needs; I play a lot of games and can't have *any* lag, burn-in, etc. regardless of which system I'm playing; I want to be able to watch normal TV and VHS inputs lag-free as well; and I needed something not very expensive.

After a lot of research, I finally settled on one. Specifically, I purchased the "Sony KDF-E50A10Grand WEGA 50" LCD Projection TV", which was reported as lag-free at numerous sources. I managed to get it very inexpensively, and thus far I've been absolutely thrilled with it. I can plug in my old Atari 2600 and the games are lag-free. It's awesome.

However, there's one problem, and that problem is with the one game I play the most: Final Fantasy XI.

more...

My first path for testing LSB-compliance of Firefox is to check the official binary packages for Linux. I obtained them here and set out to do some initial checks against them. Later on, I likely will build from source and continue there.

Unfortunately, my first stab at compliance testing seemed to expose a problem with the lsbappchk tool itself:

$ /opt/lsb/bin/lsbappchk firefox-bin 
LSB Application Checker Report
==============================

Binary firefox-bin:
*** glibc detected *** free(): invalid next size (fast): 0x08224a70 ***
Aborted

more...

Linux Foundation taxonomy.

more...