Forum OpenACS Q&A: Debian Installer Update (openacs 5.4.3 debian/ubuntu packages released)

Request notifications


Malte recently told me about the new Debian "openacs" package. I decided to checkout this package after visiting the "Open Source Meets Business" conference in Nuremberg last week. A survey from showed that Debian + Ubuntu together hold some 80% of Linux "market share" in Germany. So I guess the Debian installer should be the highest priority in this community (apart from a Windows installer), isn't it?

However, the install was quite a pain for a non-Debian expert, or is it my advanced age? I started with , but I can't confirm that these instructions "facilitate the adoption by novices"...

As a result I have set up our own ]project-open[ Debian instructions at: Maybe you want to copy some content of our page to the OpenACS page above? Or am I the only one who doesn't intuitively get why you need to add a "testing" repository line in sources.conf?


Hi Frank,

The package is not intended to be used on the stable distribution as you are doing, that's why you are having a painly install experience, it's not a package/age problem.

First of all, I don't think it's a good idea to have a stable/etch-backport/testing system mix.
Some openacs dependencies, like tdom 0.8.3, need a version of the libc6 more recent than the etch version, so you'll have a testing system even if you want it or not.

Also, this configuration has the problem of having to increase the size of apt cache to contain all the packages of the three repositories. I bet that the TCLLIBPATH problem is related to that config too, I have never seen it on lenny installations.

Finally, there is no need to add the compatibility options on postgresql.conf, the installer sets this options directly on the openacs database.

Héctor Romojaro


The Debian distribution targeted is mentioned prominently at the wiki page:

"[...] Beware, our packaging activity explicitly targets Debian GNU/Linux unstable ("sid") [...]"

If you plan to support stable, it would be a valuable contribution (by ]project-open[) to provide for official backports from unstable to stable (rather than documenting a "stable/etch-backport/testing system mix, as correctly hinted at by Héctor).


Geez a mix like that's going to be just a bit of a maintenance headache ...

The decision to choose one debian version that supports the packages we need is the correct one.

Well, there are actually three strategies available for supporting Debian distributions other than unstable:

1. official backports, contributed to or

2. non-official backports in a self-maintained deb repository

3. a "disciplined" mix-and-match strategy using

just to clarify possible ways of action for Frank and ]project-open[ ...


Hi Héctor,

> "[...] Beware, our packaging activity explicitly targets
> Debian GNU/Linux unstable ("sid") [...]"

Good point, I read over this.

And (I've said that this is the first time I'm really starting with Debian, didn't I?) I had no idea that I was setting up a "mixed" system.

And just taking this "novice" route - could somebody please point me to a place where I can download a suitable "sid" cdroom image? I've check the now for at least 10 minutes and didn't find anything...

I think that this would also be a wonderful extension for your page...

Keep up the good work and thanks for the patience guys!

I suggest using Ubuntu 8.04 LTS which should work more easily since Ubuntu is based on sid. The long term service edition should be good for a server.

And just taking this "novice" route - could somebody please point me to a place where I can download a suitable "sid" cdroom image? I've check the now for at least 10 minutes and didn't find anything...

There are no distribution images for the unstable/"sid" branch, see

You have to get a testing/"lenny" installation (released daily and is checked for its soundness and installability), see Select the appropriate "netinst" platform variant, then proceed with a raw installation. Then:

1. update your sources.list for the deb package manager (basically substituting "testing" occurrences for "unstable").

2. call "apt-get dist-upgrade"

3. your system will upgrade and will so track unstable

However, for production use, Dave Bauer's hint at the ubuntu server installation (preferably the long-time support LTS version 8.04) is the way to go: you get the advantage of an assembled and checked debian unstable, our packages, and security fixes through 2013.


Who here has set up the build environment for generating Debian Unstable packages?

We would be interested in helping maintain up to date Debian Stable repos as anything with the words "Ubuntu Server" sends chills up our spines (Debian Unstable not appropriate for a production environment either).

Our schedule is a little tight to deploy this out to everyone but we would like to learn about the current build environment that has been pulled together, replicate it internally first for our own use and then when we are proficient enough at it open up the repos to the community or something.

Thoughts? Contacts?

Hi Robert,

At this point, the persons involved on the debian/ubuntu openacs/dotlrn packages are Stefan Sobernig, Avni Khatri, Carl Blesius and me, and we are mantaining the following packages:

- xotcl packages (now on debian testing/sid and ubuntu intrepid/jaunty)
- tdom 0.8.3 (now on debian testing/sid and ubuntu jaunty)
- openacs (waiting for revision of the debian tcl/tk team)
- dotlrn (waiting for revision of the debian tcl/tk team)

Debian testing is freeze right now (since 27 Jul), and is expected to be released in a *short* period of time. Once it's released, there will be no problem on installing the openacs and ubuntu packages, because the dependencies will be on stable.

After that, debian people will revise the openacs/dotlrn packages, and they will get into the next debian stable release (I hope so!).

Meanwhile, it's possible to build a backport of the packages (xotcl-*, tdom, openacs and dotlrn). If the dependencies are backported, I can backport openacs and dotlrn packages easily, but I'd like to know other's people opinion, specially Stefan's, about that.

Also, you should take into account if it's worth to build the backport before lenny is released...

Cheers, Héctor

You are probably right.

We'll wait to see how it works out.


Thanks for your expression of interest. Even if later, this is highly welcomed by those involved.

I can only second Héctor's statements: Going for a concerted backporting initiative for the current debian stable ("etch") *now* would not pay off in the mid run.

Waiting for lenny to become the stable distribution and then setting up backports of upcoming packages versions from unstable is certainly a valuable contribution.

In the meantime, you can use the current testing distribution for your server installations. All openacs|dotlrn dependencies are in there (by now). Backporting openacs|dotlrn packages themselves should be a relative ease.

As for the "package building environment", you can freely use the package sources for setting up your playing ground:

1. see, follow the package links to the Debian Package Tracking System (PTS). There, links to the SVN repositories are given. You can use the Debian "svn-buildpackage" facilities to get the sources, mangle them, and build binaries and distribution packs therefrom.

2. the openacs|dotlrn packages are managed at Here, go for "cvs-buildpackage". Once approved by the Debian Tcl/Tk Team, they will certainly move to the Debian SVN.

I am always happy to help out, once you decide to get started.


Hi Robert,

Debian Lenny is supposed to be released this weekend (14-F), if nothing goes wrong, maybe to coincide with @1234567890 Unix time ;-)

Cheers, Héctor

They made the @1234567890 time; Debian 5 Lenny has landed:



I've splitted the debian repository on two:

* Lenny: Only packages which work on Lenny.

deb lenny main

* Sid: Unstable packages. May not work on Lenny.

deb sid main

At this time, the two repositories has the same packages, but this may change in the future. Lenny users should use the first one.

BTW, I updated the debian xowiki page with the new repo.

Cheers, Héctor

I'm testing and I've found a problem:

apt-get install openacs
Leyendo lista de paquetes... Hecho
Creando árbol de dependencias
Leyendo la información de estado... Hecho
No se pudieron instalar algunos paquetes. Esto puede significar que
usted pidió una situación imposible o, si está usando la distribución
inestable, que algunos paquetes necesarios no han sido creados o han
sido movidos fuera de Incoming.
La siguiente información puede ayudar a resolver la situación:

Los siguientes paquetes tienen dependencias incumplidas:
  openacs: Depende: aolserver4-nscache pero no es instalable
E: Paquetes rotos

Hi David nice to read you :)

The debian aolserver maintainer is updating the packages to 4.5.1 version, maybe the error is a side-effect of that.

BTW, if you are installing the openacs packages on lenny, I recommend you to use the official instructions, on

Cheers, Héctor

Hi David & all,

I've just updated the packages on the sid repository, removing the aolserver4-nscache dependency, which is now integrated into the aolserver4-core package (thanks Stefan for pointing it out :-)).

Cheers, Héctor

Great!. We're advancing, apt runs now.

I've had a problem from /var/log/aolserver4/openacs/error.log:

[27/Mar/2009:18:21:57][11627.3083134640][-main-] Fatal: modload: failed to load module '/usr/lib/aolserver4/bin/'


If you are using aolserver 4.5.1, you have to comment the line:

ns_param nscache ${bindir}/

in your config file, because the nscache module is not needed anymore ( there is a built-in version of ns_cache ).

Victor, can we check the AOLserver version and conditionally include that line in the default config file in the next OpenACS release?
I just comited the change to HEAD.
OpenACS is running, now. Thanks!

I've added the aolserver version check to enable the nscache module to the debian packages, and uploaded a new version of them to the debian repo.

Cheers, Héctor