Allan McRae

The recent release of Duke Nukem Forever got me thinking back to the original game and how many hours I sunk into as a child. (If you are thinking I mean Duke Nukem 3D, I shake my fist at you and yell “Get of my lawn”!) As with many games at the time, I only had the shareware version and not the complete game. So I decided it was time to relive my youth and obtain a copy of the complete game. Time to crank up DOSBox and get playing!

The original Duke Nukem had three “episodes”; Sharpnel City, Mission: Moonbase and Trapped in the Future. The first episode was the shareware game many people would have played. Set in the futuristic time of 1997, Dr. Proton was brain damaged in some sort of nasty radiation accident (not ironic despite his name, as there apparently was a name change there…) and developed an army of evil robots to protect his base. The military have failed to overcome such evil so the C.I.A. have stepped in and hired our hero!

Given how many times I had played through the first episode in my youth, it took me about a hour to race through and finish it. I still took some time out to explore some levels and relive the excitement of going to those very easy to find secret rooms. I still do not understand how Duke decides how often he can pull the trigger. It is not a function of reload time as if you hit something close range, you can immediately fire again. But miss and you will need to wait until the bullet goes out of the screen… Strange they had not sorted such things out in the future that is 1997, but you eventually upgrade your pistol and are allowed to fire four shots at once which is more than enough. Another thing that concerned me is the shooting of a turkey leg turns it into an entire turkey which Duke then eats for double health recovery. I would have thought eating food shoot with a nuclear pistol was not recommended…

Anyway, moving on to Episodes 2 and 3 that I had not played before. There is nothing new in game play in these episodes, only slightly different scenery. In Episode Two: “Mission: Moonbase” (yes, multiple colons in the title), Duke follows Dr. Proton to his moonbase using his time transport machine. That is right… time transport to get to the moon. The second episode was rather non-challenging – I died once for the entire game. You get pistol upgrades all over the place so enemies are readily defeated. I found more than the three you need to fully upgrade your pistol and I hardly explored everywhere. I was also slightly surprised the “Super Jump Boots” were not given in an early level given we are on the moon. The only real challenge was the level designer was obviously bored with having nothing new to work with, so just made larger mazes and put more bad guys everywhere. That does not so much increase the difficulty but rather just makes the game longer. Only on one level was the path to take in the maze not particularly obvious. A little more than two hours of game play and I had beaten Dr. Proton again. That boss battle was also poorly programmed as I noticed Dr. Proton flies up and down in the room in front of you and you can just stand back and shoot without going near him. I was far too manly to do that and attacked the good old fashioned way and just ran in guns blazing.

Episode Three: “Trapped in the Future!” sees Dr. Proton escape to the future in his time machine. Duke immediately follows without so much as a short rest even though he would much rather watch Opera. He is obviously not the brightest guy… he could assumably still watch Opera and then go to the point in the future where he was needed at his leisure. Again, nothing much changed in the third episode. The mazes got more annoying (when you start right beside a keycard access point, you know you are going to have to walk all the way back once you collect the key…). The main difference was that in the future there seems to be some horrid green colour to everything and so some levels are hard to look at. Also, random spikes are put everywhere on the ground so when you jump or drop down blindly to the next platform, you are going to take damage. No way to avoid that either as you can not take a look around slightly off screen before jumping there. This episode also appeared to be much shorter to me. I did try exploring most places, but obviously I was not very thorough as when I (very unexpectedly) arrived at the final fight with Dr. Proton, I did not have a fully powered up pistol. I did die a couple of times on the final fight, so there was some increase of difficulty. Although both of those were due to shear surprise that as soon as you drop into the final room you are being blasted by some flame and the boss is right above you and there are spikes everywhere you look to hide. As soon as I realized I just needed to get to the other side of the room, turn and shoot, Dr. Proton was soundly defeated.

Overall, I enjoyed coming back to play Duke. I do not think it is just nostalgia talking when I say the first episode was still the most enjoyable. I think the younger me would have been disappointed if after playing the first episode for free, I had then purchased the next two episodes. They just did not seem to have the same polish. I imagine the game developers being told “Great game. We are going to give it away for free. Make us two more quickly so we can sell them and actually make some money.” and them looking at each other and thinking “You could have mentioned this earlier…”.

But this has not put me off playing the rest of games that I only had the shareware version years ago. Next up is the three episodes of “Commander Keen: Invasion of the Vorticons”. Yay pogo sticks!

I often package pre-releases of software that various developers post for testing before making a final release. I thought it would be good to put these in a repo where others can easily test them out too, as finding bugs before the main release saves me time later… Note that this software is pre-release and so you should expect it to have bugs, but I will generally stick to releases that the upstream developers consider ready for widespread testing and not alpha quality code. However, if you want to use this repo, you should be prepared to rescue your system from a bad package upgrade and to report your issues to the upstream developers (and not me…).

To use this repo, add this to your pacman.conf:

[allanbrokeit]
Server = http://allanmcrae.com/$repo/$arch

The packages are built on top of [testing], so you should have that enabled too.

Note the repo is fully signed with my GPG key (get the full fingerprint from my About page), so when something breaks, you can be guaranteed that it is my package that caused the issue! More importantly, this serves as a bit of a test for the signature checking in the developmental version of pacman.

Currently, the only package in the repo is the beta of gawk-4.0.0. I will tend to only add packages that I deal with for Arch Linux (which is mainly packages in [core]), but if someone has a particular package that would be of interest then let me know and I will consider it.

I have been noticing that there are some things that people could be improve when reporting bugs to the Arch Linux bug tracker. So here are some guidelines for what I personally like to see in a bug report. Following these would make finding and fixing the bug less work for me (and I assume other developers).

1. Check the bug is not already reported. This includes checking the recently closed bug reports as your issue may already be fixed and in the process of propagating out to the mirrors. This will prevent multiple bug reports for the same issue, which just creates more work for everyone involved.

2. Provide all information. In particular, do not assume the bug is obvious. What might seem an obvious bug to you may not occur on the developers system, so full information about the packages involved and detailed information on how to replicate the issue is essential. I always like to see at minimum the exact package version involved (including pkgver and pkgrel) and the architecture the bug is occurring on (i686 or x86_64). Do not just report it is the “current version” of a package as that can be useless within a few days on a rolling release distro. The more specific you can be with the package update where the issue started occurring, the easier it is to track down the change that caused it.

3. Stick to relevant information. The list of 50 packages you updated before noticing this bug likely contains the problem package, but there is also a lot of unrelated updates. Reduce this down as much as possible before reporting the issue. More time spent by a packager filtering down to only the relevant information means less time actually fixing bugs.

4. Do not report bugs via links. Providing a link to a forum/mailing list thread that describes the bug is not enough. You still need to provide a detailed summary. This is to keep all information in one place, but also prevents the bug being lost if the link goes dead.

5. One bug report, one issue. Even if you have multiple issues with a package, it is usually better to open a new bug report for each issue. This allows each bug to be closed as it is fixed (which might not be all at the same time…) and prevents issues getting lost among the others. The possible exception to this is when many minor issues with a package are being reported along with a PKGBUILD that fixes them all.

6. Report upstream bugs upstream. If a bug is clearly an upstream bug and not a packaging error, then it needs to be reported upstream. It is fine to also report the issue in the Arch bug tracker (if it is a bug and not a feature request) with a link to the upstream report so the Arch package maintainer can track and apply the fix when available. This not only saves the packager a lot of time (they have many bugs to deal with) but it is also useful for upstream to be hearing the bug information directly from the person experiencing it. The exception to this is glibc who do not accept bug reports from users…

7. Follow up any queries. This is particularly important for bugs that can not be replicated by the relevant Arch packager. The longer a query sits unanswered, the longer it will take to trace and fix your bug. If you can no longer replicate the issue due to (e.g.) changing hardware or distribution, then tell us and we can close the bug report.

8. Do not “me too”. There is a vote link on the bug reports you can use to show you also experience the issue. Posting “me too” as a comment only clutters the tracker.

9. Use “LANG=C” for output. Prefixing a command with “LANG=C” will result in the output using the strings in the original code (English for most software). That way, we do not have to reverse-translate messages to understand the error.

Finally, remember that a bug does not exist until it is in the bug tracker. Reporting a bug on the mailing lists, forum, IRC, jabber, etc does not count. These are all fine for tracing the source of your bug before reporting it, but remember that bug trackers exist for a reason.

Edit (2001/05/12): Added #9.

Recently I went to Tasmania on a quest to see the Forty-spotted Pardalote. Some might say it was a work trip given I spent most of my time at a conference and work paid for the the travel. And they might be right… but there are twelve species of birds found only on Tasmania, so I might have had other ideas!

Given I only had a two and a half day window to actually have a look around Tasmania (which I had never visited before), and the Forty-spotted Pardalote is restricted to a small area of the island, my chances of success were always low. The odds were made worse given that I was not going to have time to go to either of the islands with the main breeding populations. But the internet had assured me that the Peter Murrell Reserve had a breeding population and it was only a ten minute drive from my hotel, so I could easily go there early morning before heading off elsewhere.

Day 1: Finished with work and had checked into the new hotel by 3pm, so a quick trip out to the reserve before the evening meal. Three hours, no Forty-Spotted Pardalote… but I saw plenty of other endemics including the Green Rosella, Yellow Wattlebird, Yellow-throated and Black-headed Honeyeaters and the Tasmanian Native Hen.

Day 2: This was my day to see Tasmania. A complete impossibility for one day, but I gave it my best shot. An early morning start, and I drove up the east coast from Hobart to St. Helens, cut across to Launceston and then back to Hobart. About 600km in total and a 12 hour journey by the time I stopped at a bunch of tourist attractions and did a couple of small beach and forest walks. I highly recommend anyone who visits the area to spend a lot more time exploring the region. I also recommend never renting a Nissan Micra to drive, as that was an underpowered piece of crap.

Day 3: Up early and headed to the reserve. Four hours of searching, no Forty-Spotted Pardalote… Decided to take a break and drove to Mt. Wellington for a view over Hobart and then to the Tahune Airwalk – a 600m walk through the treetops of a wet eucalypt forest (pictured). See the cantilever at the end there? That is about 50m off the ground… and there was no way I was walking out on it! Headed back to the reserve for another couple of hours. Still no Forty-Spotted Pardalote…

Overall, I managed to see eight of the twelve endemic bird species and thirteen bird species I have not seen in total. So a good haul overall. However…

Final score: Forty-spotted Pardalote 3: Allan 0

A big thank you to the Arch user who bought me a book from my Amazon Wishlist. Hopefully this will get me past the steep learning curve for Autotools and let me actually understand that changes I make rather than the “adjust and hope” approach I currently use…

No, I have not been dropped off in the middle of nowhere and made my way back to civilization by jumping into every river and exploring every cave I come across. But I have finished reading the “SAS Survival Handbook, Revised Edition: For Any Climate, in Any Situation”, which was generously bought for me off my Amazon Wishlist by an Arch Linux user.

Am I now prepared to survive in any climate and in any situation? Not really! The lists of safe and poisonous plants have merged together in my head, so that is not particularly helpful to any future survival endeavour. But, if I ever get stuck in the Arctic and manage to kill a polar bear, I now know not to eat its liver due to potentially dangerous levels of vitamin A. That seems an important factoid to store away…

When Arch Linux switched its /usr/bin/python from python-2.x to python-3.x, it caused a little controversy… There were rumours that it had been decided upstream that /usr/bin/python would always point at a python-2.x install (although what version that should be was unclear). Although these rumours were abundant and so more than likely such a discussion did occur (probably offline at PyCon 2009), this decision was never documented. Also, whether such a decision can formally be made off the main development list is debatable.

Enter PEP 394. Depending on how I am feeling, I call this the “justify Arch’s treatment of python” PEP or the “make Debian include a python2 symlink” PEP. Either way, the basic outcome is:

• python2 will refer to some version of Python 2.x
• python3 will refer to some version of Python 3.x
• python should refer to the same target as python2 but may refer to python3 on some bleeding edge distributions

The PEP is still labeled as a draft, but all discussion is over as far as I can tell and I think it will probably be accepted without much of any further modification. The upshot is, using “#!/usr/bin/env python2” and “#!/usr/bin/env python3” in your code will become the gold standard (unless of course you code can run on both python-2.x and python-3.x). There is still no guarantee what versions of python-2.x or python-3.x you will get, but it is better than nothing…

One recommendation made by the PEP is that all distribution packages use the python2/python3 convention. That means the packages containing python-3.x code in Arch should have their shebangs changed to point at python3 rather than python. Given our experience doing the same thing with python2, this should not be too hard to achieve and is something that we should do once the PEP is out of draft stage. This has a couple of advantages. Firstly, we will likely get more success with upstream developers preparing their software to have a versioned python in their shebangs (or at least change all of them when installing with PYTHON=python2 ...). That would remove many sed lines from our PKGBUILDs. Secondly, if all packages only use python2 or python3, then the only use of the /usr/bin/python symlink would be interactively. That would mean that a system administrator could potentially change that symlink to point at any version of python that they wished.

And if they are less than 140 characters long, you will find them on my freshly created identi.ca account. So everyone rush there and subscribe so I can regale you with my witty banter…

It is time for another major pacman release. Here is a brief overview of the new features:

The feature that will be immediately noticed on the pacman upgrade is the change of database format. This was a step towards reducing the large number of small files pacman had to read, which was a major cause of performance issues (particularly on systems with slow hard-drives). Two major changes occurred: the sync database became a single file per repo and the local database had some of its files merged. The sync databases are now read directly from the database (compressed tarball) that is downloaded from the mirrors. No extraction means no fragmentation of the database across the filesystem. The “depends” and “desc” files in the local package database were merged into one file as there was actually little point for them being separate. This results in an approximately 30% less files to be read for the local database on an average system. A script (pacman-db-upgrade) is provided to preform this database upgrade and pacman will abort if a database in the old format is found. Any scripts that read directly from the database will need to be updated to deal with these new formats. Or better yet, they could be written to use libalpm which would make them robust to future changes (the local database format could be improved further). Combine the database changes with other speed enhancements (improved internal storage of package caches, faster pkgname/depends searches) and this pacman release is notably faster.

Until now, a great way to break your system during an update was to run out of disk space. Pacman now attempts to avoid this in two ways. Firstly, it will (optionally) calculate the amount of disk space needed to perform the update/install and check that your partitions have enough room. Doing this calculation is actually fairly involved and I’m sure we will encounter some case of a filesystem and platform combination that we have not tested where this calculation is not correct… I know for certain that it does not work in chroots. The “solution” in these cases is to disable this check in pacman.conf and make a bug report with all the details needed to replicate the issue (except the chroot case). As a second line of defence for disk space issues, pacman will report any extraction error it encounters and attempt to stop installation on the important ones.

A much missed feature in pacman-3.4 was the ability to select which packages you wanted to install from a group. Well, that is back and better than ever! Additionally, the selection dialog is also extended to package provisions, allowing the user to select which provider package they want installed rather than pacman just installing the first one it found.

A feature that will primarily affect packagers is the removal of the “force” option that would result in packages being installed from the repo even if the version was not considered newer by pacman. This was useful for packages with weird versioning schemes (is that “a” for alpha or the first patch level?), but it resulted in strange update behaviour for those who had built themselves newer versions of a package locally. This has been replaced by the use of an optional “epoch” value in the package version – so a “complete” package version looks like epoch:pkgver-pkgrel. If present, the value of the epoch field takes precedent over the rest of the package version.

The main addition to makepkg is the ability to run a check() function between build() and package(). This optional function is useful for running package test suites (or even better, not running them in the early builds when bootstrapping a package). Other changes include the removal of STRIP_DIRS (now all files are stripped by default), adding a buildflags option to disable CFLAGS etc, and allowing the use of $pkgname in split package functions.

For a more complete list of changes in pacman-3.5, see the NEWS and README files in the source code.