Allan McRae

I thought I would record what I contributed towards Arch Linux for a week so people can have an idea of what goes on “behind the scenes” in the development of the distribution. While there is no such thing as a typical week for me in Arch Linux development, this week will almost certainly be atypical given I am off work on sick leave for the week. So there is probably going to be more time for some coding than usual. Saying that, I am not intending to spend all that additional time doing Arch stuff (or even the majority of it), so we will see…

Monday

• Starting the week with a fairly clean slate – no package updates or items on the developer TODO lists for me to deal with. Although the glibc-2.14 toolchain did move to [core] yesterday so that may result in looking for bug fixes…
• Daily dealing with email. Typically I receive ~200 emails over night between the Arch mailing lists and the various software development lists I am subscribed to. A few emails to pacman-dev I will deal with later but the rest just get marked as read after skimming the subject line. This is of course ongoing during the day.
• Nothing relevant to my packages reported on the forums or bugtracker overnight. Yay!
• Quick patch review and follow-up on pacman-dev (makepkg: ln -sf and POSIX and makepkg: warning messages for missing VCS tools).
• Investigated FS#24884 – a claim of a glibc memory leak. The bug report is wrong about the cause and the testcase is an entire piece of software which does not work out of the box. My bet is not a bug, so leave it for the user to prove me wrong.
• Test out some software prereleases – sudo-1.8.2rc4 and alpha releases of wget (1.12.2504) and patch (2.6.1.136). All added to the [allanbrokeit] repo.
• Updated the toolchain testsuite wiki page now that the glibc-2.14 toolchain build is in [core]. Should really investigate that x86_64 only failure in glibc… (Debian sees it too so probably not urgent.)
• FS#24571 – “file -i” gives incorrect output on zip files. Annoying, because makepkg uses this to detect how to extract files (although it should fall back to the same method anyway…). It was not due to our patching (which all comes from upstream) so bisected the issue and reported upstream.
• FS#23989 – readline does not update infodir. This is actually trickier than it sounds to deal with. We can not run a post_install script as readline will be installed before bash. Required double checking what pacman does when there is an install script but the function is not defined, but it looks fine to have post_upgrade only.
• More patch review for pacman. This time a couple of patches from Dan making sync DB reading more flexible and a really interesting bug fix for our fgets function for reading from archives.
• Binutils-2.21.1 is released. Not much of an update given we use CVS snapshots from the 2.21 branch anyway and only a small number of bugfixes landed since the last one. Package updated and pushed to [testing].

Tuesday

• Check emails. A few comments on my patches on pacman-dev and new patches to review. Also a push to pacman git master to rebase my work upon. And gcc-4.6.1 is released so I will be updating that today.
• Rebase my pacman git working branch. Revert a patch that got pushed incorrectly (and one claiming I broke something at that!).
• Update to gcc-4.6.1. Takes about two to three hours to build and run the testsuite per architecture on my computer… Also do the required libtool rebuild.
• Review new patches from Dan on pacman-dev. The package signing work is really starting to take shape.
• Discussed lots of pacman development on IRC… Decide to continue with lots more API breakage for pacman-4.0!
• Made a large patchset renaming a lot of structs in the libalpm codebase: 62 files changed, 1048 insertions(+), 1048 deletions(-). It is not as big as it sounds…
• Fixed a small bug introduced into makepkg by a recent commit.
• First pass review of patches for adding PGP signature checks for source files in makepkg. Need to think on the implementation more before commenting.

Wednesday

• Checked emails/bug tracker/forums. Nothing new for me to deal with this morning!
• Replied to patches for adding PGP signature checks to source files in makepkg. Still some areas to figure out, but I think the approach I proposed is fairly solid without adding too much complexity to makepkg. Then replied again with more thoughts after investigating what gpg does with its –signal-files option.
• Dan tells me my code to determine whether makepkg signs a package or not is not working… It is all lies and we find an unexpected behavior in makepkg with respect to config file overrides instead.
• Reviewed a patch to have makepkg automatically add packages to a repo after they are created. The patch needs work, but a good start for a first time contributor to any code base.
• Move my packages (readline, binutils, gcc, libtool) from [testing] to [core]. Then look at what other packages I have installed from [testing] that need a sign-off.
• Fix all packages in [core] that run “make check” but do not use a check() function. This will make the following run much faster with --nocheck…
• Rebuild the entire [core] repo to check for any failures due to recent toolchain updates. Without running testsuites, this takes about three hours on our build server.
• More API breakage for pacman-4.0! This time rename functions using “grp” to “group” as it is much clearer for the cost of two letters…
• Review patch from Dan on pacman-dev improving the reading of the local package database.
• Hmm… a lot more build failures in [core] than I expected… or believe. Manually checking a few packages shows they should not have failed. And there goes the bad assumption in my rebuild script. Fix that and rerun the failures and we are back to only grub failing to build with the latest binutils.
• Looked into the grub build issue. Did not solve. It is probably just time to drop this package with the number of patches required to have it being functional.

Thursday

• Daily email/bug/forum reading. A new sudo RC and a follow-up to the makepkg source signature work is all of interest.
• Subscribed to a bunch of mailing lists that I really should skim read (bug-autoconf, bug-automake, bug-findutils, bug-gawk, bug-libtool and bug-m4).
• Tested out the sudo RC (1.8.2rc5) and an alpha of findutils (4.5.10). Added to the [allanbrokeit] repo.
• Quick review of some patches sent to pacman-dev.
• Fix the “pure 64bit” patch to work with the latest gcc developmental snapshots.
• Researched and decided not to implement the changes to the gcc “pure 64bit” patch requested in FS#24271. In fact, the 32bit linker should go in /lib32 with a symlink in /lib and that would avoid any adjustments needing made.

Friday

• What happened over night… A couple of pushes to the pacman git repo, a major mkinitcpio release and a new bug report for me (FS#24970).
• Look at FS#24970. Definitely not a binutils bug as I can replicate using only sed.
• Spent a lot of time trying to make a sed build from git complete… Failed, but as a bonus I did learn a lot about gnulib.
• Made a package for gnulib and uploaded it to the AUR.
• Looked at why we need a /lib64 folder in our x86_64 install. Probably only issues with binary blobs… Call for testing some real world usage without the folder to see what issues are run into.
• More investigation of FS#24970. Valgrind finds memory issues only with the hu_HU.UTF8 locale. Interesting…
• Prepare script to generate patches for one final large API breakage in libalpm: PM_* to ALPM_*

Saturday

• Another morning with not much new to deal with. Some new patches from Dave on pacman-dev for improving the download code, but they look complex so I think I’ll leave those to others (i.e. Dan) to review.
• Clean up SVN entries for some perl packages that were converted to arch=('any').
• Discussion about including more information about installed files in the local pacman database and where that information should be calculated (during packaging or install). This will allow for more stringent system checking with pacman -Qk.
• Review and merge some of Matt’s (our new ABS developer) patch queue. Rather big job (57 patches!), but is all my fault for dropping the ball for so long there. Got to the point where an abs-2.4.3 release should be made. Impressed with the progress towards ABS-3.0 and the new features there.
• Updated my bigpkg script to work with pacman-3.5…

Sunday

• Read emails, etc… The db-5.2 rebuild has hit [testing] so that will be a big update to test. Also a new bug reported against bash.
• Addressed comments on my patch for a memory usage optimization when removing packages with pacman. Revised patches posted.
• Closed FS#24992 as “Won’t Implement”. I’m not adjusting man pages in our packages.
• Spent lots of time looking at the alpm_list_t implementation. I really want to change it a whole lot…
• Initial look at adjusting the option parsing code currently only used by makepkg. Started implementing a couple of new features to it so that it can be used in the new pacman keyring management script (pacman-key) too.

And that wraps up my Arch Linux contributions for this week. Looking back at the week, the amount done on Monday to Wednesday was more than what I would consider usual on account of me being off work, but the rest of the week is probably not too far off what I normally do. I definitely got more coding and patch review done for the week, but I also had only two minor package updates to do which was atypically low. And I still did not get to finishing the patch merge for pacman-key, which was one of my primary development goals at the start of the week. Oh, well… there is always next week…

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…