Failed kolab 2.01 install

[Thomas Lotterer]

>>>> <vincent at acheson.uk.com> 2005-10-27 15:57:07 >>>
> Have just tried with a fresh download of kolab2.01 source rpms
> from erfrakon - exactly the same message:
>
> # ./obmtool kolab
> ---- boot/build ptarmigan %kolab ----
> obmtool:NOTICE: did not find openpkg/rpm executable. Checking/fetching
> binary sh.
> OpenPKG 2.4-SOLID Binary Bootstrap Package, version 2.4.2
> Built for prefix /kolab on target platform ix86-debian3.0
> ++ hooking OpenPKG instance into system environment
> ++ fixating OpenPKG instance root directory "/kolab"
> ++ extracting OpenPKG binary distribution
> ++ installing OpenPKG binary distribution
>
> openpkg.bzip2: Data integrity error when decompressing.
>  Input file = openpkg.tar.bz2, output file = (stdout)
>
> It is possible that the compressed file(s) have become corrupted.
> You can use the -tvv option to test integrity of such files.
>
Please note that any OpenPKG instance manages itself which naturally
leads to a chicken-egg problem. The solution is to use a bootstrap
procedure independent of a pre-existing OpenPKG install and it was
implemented as a portable shell script. There is a common "source"
shell script for all platforms to be used when starting from source
and it's output is a platform specific "binary" shell script. Both
shell scripts are kinda selfextracing archive carrying program code and
data. In the early days of OpenPKG that data was pure ASCII by engaging
uuencode(5). However, Linux vendors started to drop shipping/installing
sharutils which are are required to uudecode(5) the data. Also that data
format increased the size of the files. Almost exactly two years ago
the solution was to put the binary data directly into the shell script
[1]. This relaxed the dependency to sharutils and reduced file size by
approximately 30%. In the past we sometimes experienced problems with
environments running download applications and/or proxies which try to
be smart and fetch files whose filename ends with .sh or whose first few
blocks of content look like text as ASCII downloads, possibly modifying
any embedded newlines or tabs. These clever clogs destroy the binary
content of the bootstrap and make it unusable.

To check whether the archive contents in the shell script work try
something like

$ sh openpkg-2.5.0-2.5.0.ix86-freebsd5.4-openpkg.sh --tar \
  | tar tf - >/dev/null && echo "GOOD"

You might also check the MD5 of the file given the publisher
offers a reference like OpenPKG.org does [2].

> You can use the `bzip2recover' program to attempt to recover
> data from undamaged sections of corrupted files.
>
In the situation described above the data is destroyed and cannot
be recovered. You must track down the root cause of the ASCII download.

> Is there something else I'm missing?
>
Please understand that the "obmtool" tries to find the binary .sh (for
installs) or .rpm (for upgrades) in /kolab/RPM/PKG and only if this file
is missing it tries to copy it from the PWD, possibly downloading it
first. Note once a corrupted file is in /kolab/RPM/PKG any good download
to the PWD is ignored! Be sure the good file is in the right place or at
least the bad one is discarded.

[1] http://cvs.openpkg.org/chngview?cn=13071 
[2] ftp://ftp.openpkg.org/release/2.5/BIN/00README