Bug reports

As Fink currently lacks a structured mechanism to report bugs, users send bug reports in various flavours, sometimes lacking relevant information. I’ll try to describe how to proceed when you find a Fink-related bug, focusing on package build errors.

Before you submit a bug report

Reproducing the error

Sometimes the error has already been reported and fixed. Please run

fink selfupdate
fink update-all

and try to reproduce the error.

Moving /usr/local away

Some programs tend to think that the folder/directory /usr/local should have priority over Fink, and files in that folder might interfere with Fink’s build process. Try moving it away whilst Fink compiles packages. The following sequence of commands renames /usr/local before building the terminator package, restoring it after having installed the package.

sudo mv /usr/local /usr/local.moved
fink build terminator
sudo mv /usr/local.moved /usr/local

There is a FAQ entry describing this problem.

Searching the Web

Gmane keeps an archive of Fink’s mailing lists: fink-beginners, fink-users, fink-devel. Search engines are you friends.

Bug report information

Identifying the package

Say you’ve tried to install the terminator package and there was a build problem. That doesn’t necessarily mean that the problem resides in the terminator package – it could be a problem in one of its dependencies. Let’s take a look at an output example of build error:

make: *** [xxx] Error xxx

### execution of make failed, exit code xxx
Removing runtime build-lock
Removing build-lock package...
/sw/bin/dpkg-locwait -r fink-buildlock-python26-2.6.2-2
(Reading database ... 9999 files and directories currently installed.)
Removing fink-buildlock-python26-2.6.2-2 ...
Failed: phase compiling: python26-2.6.2-2 failed

Before reporting any errors, please run "fink selfupdate" and
try again.  If you continue to have issues, please check to see if the
FAQ on fink's website solves the problem.  If not, ask on the
fink-users or fink-beginners mailing lists, with a carbon copy
to the maintainer:

        XXX <someone@somewhere.net>

Note that this is preferable to emailing the maintainer directly, since
most fink package maintainers do not have access to all possible
hardware and software configurations.

This output shows that the offending package is not terminator itself but one of its dependencies instead, namely python26-2.6.2-2.


In most cases it is important to include the following version information:

  • OS X version, such as Mac OS X 10.5.7. It can be obtained via the


  • Fink version, which can be obtained by running
    fink -V | head -n 2

    Note that this command will grab the first two lines outputted by

    fink -V

    The first line in the output tells the package manager version and the second line tells what distribution you’re using, including your selfupdate method, as well as platform information;

  • Xcode version, which can be obtained by the command
    xcodebuild -version | head -n 1

    which grabs the first line outputted by xcodebuild. If you’re on OS X < 10.5, use the following command.

    defaults read /Developer/Applications/Xcode.app/Contents/version CFBundleShortVersionString

    or, alternatively,

    fink dumpinfo -fversion xcode 2> /dev/null


  • Package version, such as terminator-0.12-2. If you’re having trouble to build a package, Fink will tell you what version it was trying to build. If you need to identify versions of packages that are already installed, read this post.

Steps to reproduce the error

Identify the minimum steps required to reproduce the error. Usually they are a single command such as fink install package, but it could be the case that two or more steps are necessary to cause the error.

Unofficial binary distributions

If you are using unofficial binary distributions such as Todai or W.G. Scott’s, mention that in your bug report.


If you’ve encountered an error whilst trying to build a package, it’s quite possible that Fink has outputted many lines up to that actual error. Defining what information is truly important varies considerably. In general, start from copying the first two or three lines before the error and proceed until the end of the output. Note that compilation lines tend to be quite long, so they are split into multiple lines in the terminal window. Identifying what constitutes an output line can be tricky.

Fink has a couple of options that help with capturing the output. The –log-output option tells Fink to save a copy of the terminal output to a file named fink-build-log-name-version-revision-date-time in the /tmp folder. For example, run

fink --log-output install terminator

and check the /tmp folder for a file (or files) named fink-build-log-terminator-… If you’d like the output to be saved in a different folder or file name, use the –logfile=filename option as in the following example.

fink --log-output --logfile=$HOME/terminator.log install terminator

Check fink’s man page for more information on –logfile.

Saving the output to a file helps with copying-and-pasting the last lines outputted by Fink, and might be important later if the person in charge of the bug asks you for more information.

Submitting a bug report

After having gathered all the relevant information you need to determine to whom you should send the bug report. If you were trying to install a package Fink should have printed out the maintainer of the offending package (which, once again, is not necessarily the one you were originally trying to install). Send him an e-mail with a carbon copy to either fink-beginners at lists.sourceforge.net or fink-users at lists.sourceforge.net. The carbon copy is useful because other users might be able to help before the maintainer reads your message, the issue might happen on a platform the maintainer doesn’t have access, and it helps with keeping a searchable history of issues.

Some packages do not have a maintainer – Fink will then print None <fink-devel at lists.sourceforge.net> as the maintainer. Send an e-mail to that address. Because those packages are unmaintained, there are no guarantees that someone will be able to fix the error you’ve found. If you have packaging or programming skills, consider trying to fix the error yourself and becoming a maintainer!

If the error is not related to a package at all and you believe the error is in Fink itself, send an e-mail to fink-beginners or fink-users at lists.sourceforge.net. Depending on the replies you might have to send the report to fink-core at lists.sourceforge.net, which is a mailing list for Fink core issues.

Fink does have a Bugs tracker at SourceForge.net. It is not used much, though, because not every maintainer checks regularly their e-mail address listed at SourceForge.net, besides other issues. From time to time bugs are triaged there but this doesn’t seem reliable at the moment.


If it’s been a couple of days and the maintainer haven’t sent you a reply, send the bug report to fink-devel at lists.sourceforge.net, stating that you haven’t heard from the maintainer.

If the maintainer tells you that he has fixed the error and a new version is available, you need to update your distribution by running

fink selfupdate
fink update-all

If you’re using the rsync selfupdate method, it takes about an hour from the time the maintainer uploads a new package description until it is available on the rsync servers. After having selfupdated, make sure that either the package version or revision of the package that caused the error (or sometimes a related package) have been updated. Try to install the package again and notify the maintainer of whether the error has been fixed or not.

6 responses to “Bug reports

  1. Alex Hansen

    The Xcode Tools version is important reasonably often, too.

    Also, it should be stressed that the package to report upon is whatever is having the immediate failure; the ultimate package that the user is trying to install is pretty much irrelevant (but is often what gets reported).

  2. Thanks, Alex. I’ve edited the post accordingly.

  3. Also:

    xcodebuild –version doesn’t give the human-readable Xcode version on 10.4.

  4. Hmm, didn’t know that. I’m adding an alternative method that works on 10.4.

  5. For those who are unsure of their version or are trying to script something, I like this way of reporting your Mac OSX version. Perhaps there is a good subset of fields for bug reports.

    system_profiler -detailLevel basic | grep ‘System Version’
    System Version: Mac OS X 10.6.2 (10C540)

  6. Kurt, sw_vers is a much simpler way to get that information.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s