Category Archives: usage

Fink and Lion

OS X 10.7 “Lion” was released on July 20, 2011, along with fink-0.31.0. We want to let Fink
users know what to expect if updating.

First, the fink program itself will not run on a system which has been upgraded to Lion, so it is not possible currently to update a Fink installation in place. However, is possible to use the dpkg program to extract a list of the Fink packages which are currently installed so that they can be reinstalled
under 10.7. Use

dpkg --get-selections | cut -f1 > fink_packages.txt

before updating to 10.7 to dump the package names to a text file, and

cat fink_packages.txt | xargs fink install

once you have installed Fink on 10.7.

To upgrade Fink after upgrading to Lion, one will have to bootstrap
Fink again, using a tarball for fink-0.31.0 or later. If you want to use the same directory (e.g. /sw) for Fink that you were using on 10.6, you’ll need to remove that before bootstrapping, since the bootstrap doesn’t allow you to overwrite an existing Fink tree.

Second, due to lots of changes under the hood, there currently are many fewer
Fink packages which build under 10.7 as opposed to 10.6. Thus, even if you’ve extracted a list of Fink packages which had been installed under 10.6, some of them may not yet be installable under 10.7. We are currently creating a database showing which packages can be successfully installed under 10.7, and work is ongoing to add packages.

10.7 introduces several drastic changes to how the system works. While this may
cause a slight delay in full Fink functionality in the short term, it will
make Fink work better in the future.

Advertisements

Using multiple Fink distributions.

There are various reasons that you might want to have more than one Fink tree on your system:

  • Testing packages on both  the i386 and the x86_64 architectures.
  • To use a package that is only available on i386 or x86_64 when you primarily are using the other architecture.
  • To set up a clean Fink tree for test purposes.

Setting up another distribution is relatively straightforward.

  1. Follow the Fink source install instructions, but stop before the point of running pathsetup.sh.
  2. You are only going to want to have one Fink tree active when you’re building packages.   You can switch between trees by editing $HOME/.profile (or whichever startup file your Fink setup is using). For example, change
    test -r /sw/bin/init.sh && . /sw/bin/init.sh

    to

    test -r /sw64/bin/init.sh && . /sw64/bin/init.sh

    if you have a Fink tree in /sw and another one in /sw64.  Then start a new terminal window to load the new environment settings.

  3. To use executables from one Fink tree while the other is active, append its executable directories to your PATH. An example from a $HOME/.profile would be:
    test -r /sw64/bin/init.sh && . /sw64/bin/init.sh
    export PATH=$PATH:/sw/bin:/sw/sbin

    Note:  some packages use executable scripts for build configuration purposes, so you may need to remove the second Fink executable directory from the PATH if you’re having problems.

Interaction issue between XQuartz-2.6.0 and fink on Leopard.

Users who perform clean installs of XQuartz-2.6.0 on Leopard will find that fink will report

could not determine XFree86 version number

and it will no longer detect the X11 installation.
To fix this issue while we wait for CVS to come back online, either edit /sw/lib/perl5/Fink/VirtPackage.pm as a superuser, and change:

if (open (XBIN, "$xdir/bin/$binary -version -iokit 2>\&1 |")) {

(around line 1736) to

if (open (XBIN, "$xdir/bin/$binary -version 2>\&1 |")) {

or download a replacement VirtPackage.pm file from http://fink.cvs.sourceforge.net/viewvc/fink/fink/perlmod/Fink/VirtPackage.pm?revision=1.146.2.7 and copy it over your existing /sw/lib/perl5/Fink/VirtPackage.pm

The -iokit flag appears not to be needed on 10.4, and harmful on 10.5 and later, and it will be removed in the next release of fink.

Fink’s xinitrc, GNOME, and KDE

Fink’s xinitrc package provides similar functionality to X11 on 10.4 as is available on 10.5 and 10.6.   It provides Fink packages with a straightforward way to have executables run automatically when X11 is started without modifying the system area, instead using scripts in /sw/etc/xinitrc.d (assuming a default fink setup).  Moreover, when a package is removed, its script will also be removed.  Currently, the following packages use it:

  • dbus
  • kinput2
  • uim
  • user-ja
  • xfontpath

xinitrc is used by these packages on 10.5 and later as well as 10.4.  Since dbus is in the dependency chain for both GNOME and KDE, the behavior of xinitrc is important for users of those desktop environments.

Issues

xinitrc does have a side effect that needs to be taken into account.  It is set up, deliberately, to circumvent the default script setup from 10.5 or 10.6’s X11 with its own, similar, setup, cf.:
http://article.gmane.org/gmane.os.macosx.fink.devel/18879
and its default setup doesn’t search $HOME.xinitrc.d for user scripts.
Fortunately, it’s straightforward to do so, and the method provides 10.4 users with the ability to set up scripts in $HOME/.xinitrc.d, too.

Also, if you’re using xinitrc because other Fink packages Depend on it, you may lose some functionality if you need to reinstall X11 (e.g. if you’re using Xquartz on 10.5).  If so, then use

fink reinstall xinitrc

to restore it.

10.5 and 10.6

Basically, we just need a way to reactivate the existing handling of $HOME/.xinitrc.d .   The xinitrc package provides a couple of system administrator entry points.  Let’s use  one which gets processed after the script files that are installed by fink packages.  We can do this via the following steps:

  1. Edit /sw/etc/xinitrc-last-hook as a superuser (again assuming a default Fink path).
  2. Put the following in it:
    #!/bin/sh
    . /usr/X11/lib/X11/xinit/xinitrc.d/98-user.sh

    and save the file.

  3. That’s it! The next time you start X11, it will process any scripts in $HOME/.xinitrc.d .

10.4

10.4 requires writing the script that processes scripts in $HOME/.xinitrc.d :

  1. Edit /sw/etc/xinitrc-last-hook as a superuser (again assuming a default Fink path).
  2. Put the following in it:
    #!/bin/sh
    if [ -d "${HOME}/.xinitrc.d" ] ; then
    for f in "${HOME}"/.xinitrc.d/*.sh ; do
    [ -x "$f" ] && . "$f"
    done
    unset f
    fi

    and save the file.

  3. That’s it! The next time you start X11, it will process any scripts in $HOME/.xinitrc.d .

Setting up GNOME or KDE

To make sure that GNOME or KDE get started after any other apps, we will want to give their startup scripts names that get processed after anything else we want, e.g. ‘zzz-gnome.sh’.

Full GNOME Desktop

  1. Edit e.g. $HOME/.xinitrc.d/zzz-gnome-session.sh .
  2. Put the following in it (assuming a default Fink setup):
    #!/bin/sh
    . /sw/bin/init.sh
    metacity &
    exec gnome-session

    then save the file.

  3. Run
    chmod a+x $HOME/.xinitrc.d/zzz-gnome-session.sh

    to make the script executable.

Rootless GNOME

  1. Edit e.g. $HOME/.xinitrc.d/zzzz-gnome-panel.sh .
  2. Put the following in it (assuming a default Fink setup):
    #!/bin/sh
    . /sw/bin/init.sh
    metacity &
    exec gnome-panel

    then save the file.

  3. Run
    chmod a+x $HOME/.xinitrc.d/zzzz-gnome-panel.sh

    to make the script executable.

KDE3

  1. Edit e.g. $HOME/.xinitrc.d/zzzzz-kde3.sh .
  2. Put the following in it (assuming a default Fink setup):
    #!/bin/sh
    . /sw/bin/init.sh
    exec startkde

    then save the file.

  3. Run
    chmod a+x $HOME/.xinitrc.d/zzzzz-kde3.sh

    to make the script executable.

KDE4

  1. Edit e.g. $HOME/.xinitrc.d/zzzzzz-kde4.sh .
  2. Put the following in it (assuming a default Fink setup):
    #!/bin/sh
    . /sw/bin/init.sh
    exec /sw/opt/kde4/x11/bin/startkde

    then save the file.

  3. Run
    chmod a+x $HOME/.xinitrc.d/zzzzzz-kde4.sh

    to make the script executable.

User Customization of X11 on 10.5 and 10.6

The use of a $HOME/.xinitrc file to customize X11 has been deprecated as of OS 10.5.  Unfortunately, due to time constraints, we haven’t set down in the documentation what users should be doing.  I hope to set some ideas down here to clarify the situation.

The old way:

The presence of a $HOME/.xinitrc file replaces the system’s default X11 startup sequence.  A couple of consequences are:

  1. The user must make sure to run a window manager (unless one isn’t desired), e.g. just having
    xterm
    will generate an xterm with no window decorations, and any further X11 applications started from that xterm will be unmanaged. In this case the user probably wanted something like
    xterm &
    quartz-wm
  2. The user must make sure that $HOME/.xinitrc ends with a non-backgrounding command, or X11 will quit immediately. This would be the case in the prior example above if the user had
    xterm &
    quartz-wm &

The new way:

Instead of a single $HOME/.xinitrc file, under the current incarnation of Apple’s X11 (and any Xorg 7, really), one can do the following:

  1. Create the directory $HOME/.xinitrc.d
  2. For anything you want to run, create an executable shell script in that directory.  For example, to run Fink’s xpad application on startup, create a $HOME/.xinitrc.d/xpad.sh (the name is somewhat arbitrary, but see below) with contents
    #!/bin/sh
    /sw/bin/xpad
  3. and make it executable via

    chmod a+x $HOME/.xinitrc.d/xpad.sh

    Note that in this case you don’t have to set a window manager.

    The window manager can be changed in the same way.  There is only one subtlety:  the contents of  $HOME/.xinitrc.d are run in the order that the filenames appear in a listing, and generally one will want the window manager to be run last, so its script should be named appropriately. For example, you could have 0-xpad.sh and 99-evilwm.sh scripts to run the evilwm window manager and start xpad automatically.

  4. It’s easy to keep a list of scripts that start one item, and to set whether they get run or not by using
    chmod a+x <name of script>.sh

    or

    chmod a-x <name of script>.sh

    respectively.

Note: It’s slightly more complicated to set things up for GNOME or KDE, and I will discuss that issue in a subsequent entry.

Finding files in Fink

Let’s see some methods to find files and their packages in Fink.

Using find

find is a command that is provided by most, if not all, Unix-based systems, including Mac OS X. Let’s say you want to find a file named zipfile.py in your Fink installation. On my system,

$ find /sw -name zipfile.py
/sw/lib/python2.5/zipfile.py
/sw/lib/python2.6/zipfile.py

You can be more specific if you’re sure that a file resides in a certain directory, e.g.

$ find /sw/lib -name libgutils\*dylib
/sw/lib/fontforge/libgutils.1.0.3.dylib
/sw/lib/fontforge/libgutils.1.dylib
/sw/lib/fontforge/libgutils.dylib

In the command above I also used \* to indicate that I was interested in any file whose name starts with libgutils and ends with dylib.

Furthermore, depending on your configuration, you may use locate or mdfind for this purpose.

Using dpkg

Fink uses a fork of Debian’s dpkg tool for binary package management. Here are some useful dpkg commands.

If you want to find out which package installed a given file, use dpkg -S. For example,

$ dpkg -S zipfile.py
python26: /sw/lib/python2.6/zipfile.pyc
python26: /sw/lib/python2.6/zipfile.pyo
python26: /sw/lib/python2.6/test/test_zipfile.pyc
python26: /sw/lib/python2.6/test/test_zipfile.pyo
python25: /sw/lib/python2.5/zipfile.py
python25: /sw/lib/python2.5/zipfile.pyc
python25: /sw/lib/python2.5/zipfile.pyo
python25: /sw/lib/python2.5/test/test_zipfile.pyc
python25: /sw/lib/python2.5/test/test_zipfile.pyo
python26: /sw/lib/python2.6/test/test_zipfile.py
python25: /sw/lib/python2.5/test/test_zipfile.py
python26: /sw/lib/python2.6/zipfile.py

Specifying an absolute path will limit the results:

$ dpkg -S /sw/lib/python2.6/zipfile.py
python26: /sw/lib/python2.6/zipfile.py

If you want to list the files installed by a given package (e.g. the di package), use dpkg -L:

$ dpkg -L di
/.
/sw
/sw/bin
/sw/bin/di
/sw/bin/mi
/sw/share
/sw/share/doc
/sw/share/doc/di
/sw/share/doc/di/MANIFEST
/sw/share/doc/di/README
/sw/share/man
/sw/share/man/man1
/sw/share/man/man1/di.1

The grep command can be useful to filter the results: to list only the binaries (programs) installed under /sw/bin,

$ dpkg -L di | grep ^/sw/bin
/sw/bin
/sw/bin/di
/sw/bin/mi

If you have a binary package (i.e., a .deb file that was either built on your machine or obtained via a binary distribution), you need to use dpkg -c instead:

$ dpkg -c /sw/fink/debs/bibclean_2.11.4-2_darwin-i386.deb
drwxr-xr-x root/admin        0 2009-09-16 09:04 ./
drwxr-xr-x root/admin        0 2009-09-16 09:04 ./sw/
drwxr-xr-x root/admin        0 2009-09-16 09:04 ./sw/bin/
-rwxr-xr-x root/admin   112564 2009-09-16 09:04 ./sw/bin/bibclean
drwxr-xr-x root/admin        0 2009-09-16 09:04 ./sw/share/
drwxr-xr-x root/admin        0 2009-09-16 09:04 ./sw/share/doc/
drwxr-xr-x root/admin        0 2009-09-16 09:04 ./sw/share/doc/bibclean/
-rw-r--r-- root/admin    26550 2009-09-16 09:04 ./sw/share/doc/bibclean/README
-rw-r--r-- root/admin     2932 2009-09-16 09:04 ./sw/share/doc/bibclean/bibclean.copyright
-rw-r--r-- root/admin    48768 2009-09-16 09:04 ./sw/share/doc/bibclean/bibclean.pdf
-rw-r--r-- root/admin    76512 2009-09-16 09:04 ./sw/share/doc/bibclean/bibclean.ps
-rw-r--r-- root/admin    55226 2009-09-16 09:04 ./sw/share/doc/bibclean/bibclean.txt
drwxr-xr-x root/admin        0 2009-09-16 09:04 ./sw/share/man/
drwxr-xr-x root/admin        0 2009-09-16 09:04 ./sw/share/man/man1/
-rw-r--r-- root/admin    42974 2009-09-16 09:04 ./sw/share/man/man1/bibclean.1

The directory/folder /sw/fink/debs contains convenient symbolic links to the actual .deb files created when packages were built on your machine. On the other hand, .deb files obtained via binary distributions are located under /sw/var/cache/apt/archives.

Manual download of source files

Fink automatically downloads source files as needed using your DownloadMethod of choice. But say you need/want to download them separately — on a higher-speed connection, using a different download manager, or using customised settings for the download. You are free to do so as long as you place the source files under /sw/src or FetchAltDir.

In order to find out which files are needed by a given package, run

fink fetch --dry-run packagename

This command dumps the source file name(s), its(their) MD5 checksum(s), the list of URLs whence the file(s) can be obtained, and the maintainer of the package. If you want/need to download from a Fink mirror instead of the original URLs, use

http://mirrorname/filename

as in

http://distfiles.master.finkmirrors.net/filename