Author Archives: Allan

How To File A Bug Report

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.

The Quest For The Forty-Spotted Pardalote

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

Thanks For The Book!

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…

Posted in Books on by Allan – Comments Off on Thanks For The Book!

Nuclear Laptop

Tweet

My nuclear powered laptop batter is awesome – that converts to 50 hours total usage time!

Posted in Tweet on by Allan – Comments Off on Nuclear Laptop

GCC Patch

Tweet

Woo! My first patch accepted for gcc. Exciting even if it is only a test-suite fix…

Posted in Tweet on by Allan – Comments Off on GCC Patch

Hotel Internet

Tweet

Hotel internet is ridiculous – 0.55c/min or $27.50 a day with a limit of 300MB. Yay for finding open wireless access.

Posted in Tweet on by Allan – Comments Off on Hotel Internet

Allan Vs. Wild

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…

The “python2” PEP

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.

I Have Important Things To Say!

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…

Posted in General Rant on by Allan – Comments Off on I Have Important Things To Say!

Pacman 3.5.0 Released

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.