Major highlights:

• Support for AUR updates: pak -Su --aur
• Support for .tar.xz packages
• Support for custom Paktahn directory

More details can be found on Brit’s blog.

To upgrade or install just use the quick installer.

• Version comparison no longer fails on provider packages (#8)
• Reinstallation works properly again (#7)
• Trying to install or get pkgbuilds for non-existent packages is handled correctly (#5 and #6)
• Question the user in case of malformed pkgbuild dependencies (#12)
• Proxy support works correctly now (#15, reported by nitralime)
• update cache after package removal (proposed by Ralith)
• handle non-Unicode strings more gracefully (#9, reported by zajca)

Syncing up

Use the quickinstall script or sync your Paktahn repo to get it.

It must be christmas of course since Paktahn 0.8.2 is now out as promised! ;D

As it often happens in software development it’s a little later than originally expected, but there’s a lot of good stuff that has made it into this release.

Highlights

• fixed arch=(any) case (reported by magus)
• proper error reporting and restarts when AUR results cannot be fetched (Brit)
• Paktahn now remembers which PKGBUILD files it already presented for review (Brit)
• Paktahn now has proper customizepkg support for AUR packages and will automatically build packages with customizepkg definitions from source (Brit)
• support for just getting a pkgbuild (i.e. yaourt -G) with pak -G pkgnames (Brit)
• makepkg’s PKGDEST variable is detected and used correctly (reported by Stefan Husmann)
• AUR package dependencies are no longer installed explicitly (reported by bram85)
• Basic proxy support (no authentication) (Brit)
• Basic versioning support (Wei Hu, Leslie)

Also, we no longer depend on a custom version of SBCL!

Thanks to Jürgen Hötzel, Wei Hu and of course my colleague Brit Butler for their help with this release.

Syncing up

Use the quickinstall script or sync your Paktahn repo to get it.

It will add the Paktahn binary repository to /etc/pacman.conf and run Pacman to install Paktahn.

wget -qO- http://viridian-project.de/\~sky/paktahn/quickinstall.sh | sudo sh

You just need to paste this line into a terminal. Review the script here, it’s very simple:

http://viridian-project.de/~sky/paktahn/quickinstall.sh

Just sync-install your Paktahn package; rc testers will have to remove and reinstall explicitly.

New users should refer to the original blog post for instructions.

Changes

Bug fixes

* fixed x86_64 package building/installation
* fixed case when $EDITOR also had args in it (e.g. “emacsclient -l”)
* throw an error when the user attempts to build an AUR package as root
* fixed –help and -h arguments (reported by Ralith)

New features

* package removal support
* support for provider packages
* support for reinstallation of packages
* ask the user whether he wants to add his arch if it’s not listed in the PKGBUILD.

Comments?

As usual please let me know of any bugs and your wishes.

Paktahn 0.8.1 is ready but has only been tested by me, so here’s a prerelease for you to run and help find bugs:

http://viridian-project.de/~sky/paktahn/rc/paktahn-0.8.1-1-i686.pkg.tar.gz

Changes:

* package removal support
* support for provider packages
* support reinstallation of packages
* throw an error when the user attempts to build an AUR package as root

You’ve already been very supportive with your feedback for 0.8! Thanks!

yaourt, the popular Pacman wrapper, doesn’t seem to be maintained anymore and has quite some problems (e.g. UI nits, security issues, huge shell codebase). And people are starting to get tired of it because basic things stop working.

But since yaourt’s interface is so great I have decided to code up an alternative called Paktahn (after a ship type from Wing Commander).

But what can it do?

For now it supports yaourt’s two most helpful (IMHO) operation modes:

pak query

Search AUR and repositories for QUERY in packages names and descriptions and display the results. Ask for one or more packages to be installed.

pak -S package

Install PACKAGE from repositories or AUR.

Paktahn comes with a highly efficient caching system resulting in a speed that will blow your mind if you’re used to Pacman or yaourt.

I’ve been using the current version of Paktahn for weeks now and it has never failed me.

How to get it

Add one of the following sections to your pacman.conf:

# i686
[paktahn]
Server = http://viridian-project.de/~sky/paktahn/repo

# x86_64, package contributed by Gour
[paktahn]
Server = http://viridian-project.de/~sky/paktahn/repo/x86_64

There’s no x86_64 package yet since I cannot build them and no one else has contributed one yet. However you can build it from source: Paktahn on AUR. You need to install a patched version of SBCL before attempting to do so.

Development happens here: http://developer.berlios.de/projects/paktahn/

Discussion thread: http://bbs.archlinux.org/viewtopic.php?id=77674

Contributions, bug reports, comments and praise are all welcome, as are donations since I’m an independent software developer.

If the new definition is at variance with the current state of that package, the consequences are undefined; an implementation might choose to modify the existing package to reflect the new definition.

SBCL opts to modify the package but throws a warning, most often in the form of “PACKAGE also exports the following symbols: …”.

Luckily the warning is a specific one, i.e. SB-INT:PACKAGE-AT-VARIANCE.

So to get rid of the warning the following macro helps:

(defmacro without-package-variance-warnings (&body body)
  `(eval-when (:compile-toplevel :load-toplevel :execute)
     (handler-bind (#+sbcl(sb-int:package-at-variance #'muffle-warning))
       ,@body)))

Apply sparsely.

We need the EVAL-WHEN to ensure that the non-toplevel definition of the package is available at compile time.

There’s a minor catch here. One might be tempted to put the EVAL-WHEN clause inside the HANDLER-BIND. But this leads to the package not being available at compile time (therefore rendering the EVAL-WHEN ineffective) because “the compile-time side effects described in Section 3.2 (Compilation) only take place when eval-when appears as a top level form.” (CLHS on EVAL-WHEN).

Does anyone know how to muffle these redefinition warnings in other implementations?

It was recently uploaded to ArchLinux AUR and I gave it a whirl.

Its output for one of my disks claimed it to be close to failure:

HDD Device  2: /dev/sda
HDD Model ID : ST3160023A
HDD Serial No: 5JS2NX0R
HDD Revision : 3.06
HDD Size     : 152628 MB
Interface    : IDE/ATA
Temperature  : 42 °C
Health       : 13 %
Performance  : 100 %
Power on time: 658 days, 7 hours
Est. lifetime: 19 days

The theory behind HDSentinel seems sound, so I’m looking forward to see whether the prediction will hold.

You just have to enable it in your .zshrc (after installing ZSH, of course):

autoload -U url-quote-magic
zle -N self-insert url-quote-magic