Tag Archives: fink

New new hosting outage

You may have noticed that http://www.finkproject.org is unavailable again.  We regret the inconvenience, believe me.

As before, this also affects distribution of updated package descriptions via the rsync mirrors.  The following two workarounds are available:

  1. Use fink selfupdate-cvs to switch to CVS updating, since CVS service is not affected.
  2. Use a different rsync mirror.  The following mirrors update directly from CVS and are not affected by the outage:
    rsync://ber.de.eu.finkmirrors.net/finkinfo/
    rsync://hnd.jp.asi.finkmirrors.net/finkinfo/
    The easiest option to change this is to edit /sw/etc/fink.conf as a super user (e.g. by using sudo nano /sw/etc/fink.conf) and change the Mirror-rsync line directly.

The disruption also affects the mirroring of package sources.  The following two workarounds are suggested:

  1. Use fink configure --mirror and select option 2 at the first prompt, then go through and just hit return to leave everything else unchanged.  This will have fink try to download from the original source first.
  2. Use a different master mirror.  The following mirrors  are not affected by the outage:
    http://distfiles.ber.de.eu.finkmirrors.net/
    http://distfiles.hnd.jp.asi.finkmirrors.net/
    The easiest option to change this is to edit /sw/etc/fink.conf as a super user (e.g. by using sudo nano /sw/etc/fink.conf) and change the Mirror-master line directly.

http://fink.thetis.ig42.org (also redirected from fink.sourceforge.net) has current content, but doesn’t have the package database or RSS feed.

Check back here for updates.

fink-0.34.7 released

This is a bugfix release to address tar hanging when unpacking sources when fink is run as root.

New hosting outage

You may have noticed that http://www.finkproject.org is unavailable again.  We regret the inconvenience, believe me.

As before, this also affects distribution of updated package descriptions via the rsync mirrors.  The following two workarounds are available:

  1. Use fink selfupdate-cvs to switch to CVS updating, since CVS service is not affected.
  2. Use a different rsync mirror.  The following mirrors update directly from CVS and are not affected by the outage:
    rsync://ber.de.eu.finkmirrors.net/finkinfo/
    rsync://hnd.jp.asi.finkmirrors.net/finkinfo/
    The easiest option to change this is to edit /sw/etc/fink.conf as a super user (e.g. by using sudo nano /sw/etc/fink.conf) and change the Mirror-rsync line directly.

The disruption also affects the mirroring of package sources.  The following two workarounds are suggested:

  1. Use fink configure --mirror and select option 2 at the first prompt, then go through and just hit return to leave everything else unchanged.  This will have fink try to download from the original source first.
  2. Use a different master mirror.  The following mirrors  are not affected by the outage:
    http://distfiles.ber.de.eu.finkmirrors.net/
    http://distfiles.hnd.jp.asi.finkmirrors.net/
    The easiest option to change this is to edit /sw/etc/fink.conf as a super user (e.g. by using sudo nano /sw/etc/fink.conf) and change the Mirror-master line directly.

The online documentation is still available through the Sourceforge CVS browser.   

Check back here for updates.

New hosting outage

You may have noticed that http://www.finkproject.org is unavailable again.  We regret the inconvenience, believe me.

As before, this also affects distribution of updated package descriptions via the rsync mirrors.  The following two workarounds are available:

  1. Use fink selfupdate-cvs to switch to CVS updating, since CVS service is not affected.
  2. Use a different rsync mirror.  The following mirrors update directly from CVS and are not affected by the outage:
    rsync://ber.de.eu.finkmirrors.net/finkinfo/
    rsync://hnd.jp.asi.finkmirrors.net/finkinfo/
    The easiest option to change this is to edit /sw/etc/fink.conf as a super user (e.g. by using sudo nano /sw/etc/fink.conf) and change the Mirror-rsync line directly.

The disruption also affects the mirroring of package sources.  The following two workarounds are suggested:

  1. Use fink configure --mirror and select option 2 at the first prompt, then go through and just hit return to leave everything else unchanged.  This will have fink try to download from the original source first.
  2. Use a different master mirror.  The following mirrors  are not affected by the outage:
    http://distfiles.ber.de.eu.finkmirrors.net/
    http://distfiles.hnd.jp.asi.finkmirrors.net/
    The easiest option to change this is to edit /sw/etc/fink.conf as a super user (e.g. by using sudo nano /sw/etc/fink.conf) and change the Mirror-master line directly.

The online documentation is still available through the Sourceforge CVS browser.   

Check back here for updates.

Hosting outage

You may have noticed that http://www.finkproject.org is unavailable.  The hosting provider at xs4all, where the machine is located, has been notified.  We regret the inconvenience.

In addition to web services, this also affects distribution of updated package descriptions via the rsync mirrors.  The following two workarounds are available:

  1. Use fink selfupdate-cvs to switch to CVS updating, since CVS service is not affected.
  2. Use a different rsync mirror.  The following mirrors update directly from CVS and are not affected by the outage:
    rsync://ber.de.eu.finkmirrors.net/finkinfo/
    rsync://hnd.jp.asi.finkmirrors.net/finkinfo/
    The easiest option to change this is to edit /sw/etc/fink.conf as a super user (e.g. by using sudo nano /sw/etc/fink.conf) and change the Mirror-rsync line directly.

The disruption also affects the mirroring of package sources.  The following two workarounds are suggested:

  1. Use fink configure --mirror and select option 2 at the first prompt, then go through and just hit return to leave everything else unchanged.  This will have fink try to download from the original source first.
  2. Use a different master mirror.  The following mirrors  are not affected by the outage:
    http://distfiles.ber.de.eu.finkmirrors.net/
    http://distfiles.hnd.jp.asi.finkmirrors.net/
    The easiest option to change this is to edit /sw/etc/fink.conf as a super user (e.g. by using sudo nano /sw/etc/fink.conf) and change the Mirror-master line directly. 

Check back here for updates.

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.