View · Index

Weblog

Filtered by category OpenACS Projects, 11 - 20 of 46 Postings (all, summary)

Debian/Ubuntu installer developing

Created by Adrian Catalan, last modified by Gustaf Neumann 26 Sep 2019, at 08:20 PM

 

Tools required for the development

The following packages come with the standard Debian installation, so you probably have them already. Still, you should check with `dpkg -s <package>`.

  • dpkg-dev
    this package contains the tools needed to unpack, build and upload Debian source packages.

  • file
    this handy program can determine what type a file is.

  • gcc
    the GNU C compiler, necessary if your program like most others is written in the C programming language. This package will also "pull in" several other packages such as binutils which includes programs used to assemble and link object files

  • g++
    the GNU C++ compiler, necessary if your program is written in C++. 

  • libc6-dev
    the C libraries and header files gcc needs to link with to create object files. (see `info libc` in the glibc-doc package)

  • make
    usually creation of a program takes several steps, so rather than having to type out the same commands over and over again, you can use this program to automate the process, creating `Makefile's.

  You'll probably want to install the following packages, too:

  • dh-make and debhelper
    dh-make is necessary to create the skeleton of our example package, and it will use some of the debhelper tools for creating packages. 

  • devscripts
    this package contains some nice and useful scripts that can be helpful to the maintainers.

  • fakeroot
    this utility lets you emulate being root which is necessary for some parts of the build process. (see fakeroot(1))

  • gnupg
    a tool that enables you to digitally sign packages. This is especially important if you want to distribute it to other people, and you will certainly be doing that when your work gets included in the Debian distribution. 

  • lintian
    this is the Debian package checker that can let you know of any common mistakes after you build the package, and explain the errors found.

Initial debianization

Please note that you should run dh_make only once, and that it won't behave correctly if you run it again in the same, already "debianized", directory.

Make sure you're in the program source directory, and issue this:

       dh_make -e your.maintainer@address -f ../openacs-5.1.5.tar.gz

Of course, replace the string "your.maintainer@address" with your e-mail address for inclusion in the changelog entry and other files.

Some information will come up. It will ask you what sort of package you want to create. Gentoo is a single binary package - it creates only one binary, and thus one .deb file - so we will select the first option, with the `s' key, check the information on the screen and confirm by pressing <enter>.

After this execution of dh_make, a copy of the upstream tarball is created as openacs-5.1.5.orig.tar.gz in the parent directory to accommodate the creation of the non-native Debian source package with the diff.gz

Debian release

Let's say that a bug report was filed against your package and it describes a problem that you can solve. To create a new Debian revision of the package, you need to:

  • Correct the problem in the package source, of course.
  • Add a new revision at the top of the Debian changelog file, for example with `dch -i`, or explicitly with `dch -v <version>-<revision>' and then insert the comments using your preferred editor.

        Tip: how to easily get the date in required format? Use `822-date', or `date -R'.
        Include a short description of the bug and the solution in the changelog entry.

  • Repeat a complete rebuild of the package. 

New upstream release

Let's consider a different, slightly more complicated situation - a new upstream version was released, and of course you want it packaged. You need to do the following:
 

  • Download the new sources and put the tarball (e.g. named `openacs.5.2.1.tar.gz') in the directory above the old source tree (e.g. ~/openacs/).
  • Enter the old source directory, and run:

            uupdate -u openacs.5.2.1.tar.gz
            uupdate will properly rename that tarball, try to apply all the changes from your previous .diff.gz file, and                 update the new debian/changelog file.

  • Change directory to `../openacs.5.2.1', the new package source tree, and repeat a complete rebuild of the package

Complete rebuild

Enter the program's main directory and then issue this command:
        dpkg-buildpackage -rfakeroot

This will do everything for you. It will:

  • clean the source tree (debian/rules clean), using fakeroot
  • build the source package (dpkg-source -b)
  • build the program (debian/rules build)
  • build the binary package (debian/rules binary), using fakeroot
  • sign the source .dsc file, using gnupg
  • create and sign the upload .changes file, using dpkg-genchanges and gnupg

The only input that will be required of you is your GPG key secret pass phrase, twice.

After all this is done, you will see the following files in the directory above (~/openacs/):

  • openacs_5.1.5.orig.tar.gz

This is the original source code tarball, merely renamed to the above so that it adheres to the Debian standard. Note that this was created using the `-f' option to dh_make when we initially ran it.

  • openacs_5.1.5.dsc

This is a summary of the contents of the source code. The file is generated from your `control' file, and is used when unpacking the source with dpkg-source. This file is GPG signed, so that people can be sure that it's really yours.

  • openacs_5.1.5.diff.gz

This compressed file contains each and every addition you made to the original source code, in the form known as "unified diff". It is made and used by dpkg-source. Warning: if you don't name the original tarball packagename_version.orig.tar.gz, dpkg-source will fail to generate the .diff.gz file properly!

If someone else wants to re-create your package from scratch, they can easily do so using the above three files. The extraction procedure is trivial: just copy the three files somewhere else and run dpkg-source -x openacs_5.1.5.dsc.

  • openacs_5.1.5_i386.deb

This is your completed binary package. You can use dpkg to install and remove this just like any other package.

  • openacs_5.1.5_i386.changes

This file describes all the changes made in the current package revision, and it is used by the Debian FTP archive maintenance programs to install the binary and source packages in it. It is partly generated from the `changelog' file and the .dsc file. This file is GPG signed, so that people can be sure that it's really yours.

Trivial repository construction

Trivial repositories consist of one root directory and of as many subdirectories as you wish. As the users have to specify the path to the root of the repository and the relative path between the root and the directory with the index files in it, you are free to do whatever you want (even to put everything into the root of the repository; then, the relative path will be simply “/”)

We'll create a trivial repository with two subdirectories 

(your repository root)
|
|-binary
+-source

 Creating Index Files

dpkg-scanpackages generates the Packages file and dpkg-scansources the Sources file.

They both send their output to stdout; thus, to generate compressed files, you can use a command chain like this one: dpkg-scanpackages arguments | gzip -9c > Packages.gz.

The two tools work the same way; they both take two arguments (in reality there are more, but I won't go into that here; you can read the manpages if you want to know more); the first the directory under which the packages are, and the second is the override file. We don't need override files for simple repositories, but as it is a required argument, we simply pass /dev/null.

dpkg-scanpackages scans the .deb packages; dpkg-scansources scans the .dsc files. It is thus necessary to put the .orig.gz, .diff.gz and .dsc files together. The .changes files are not needed.

$ cd my-repository
$ dpkg-scanpackages binary /dev/null | gzip -9c > binary/Packages.gz
$ dpkg-scansources source /dev/null | gzip -9c > source/Sources.gz

From Debian Maintainers' Guide, installer developed by Otto Solares updated by Adrián Catalán at Galileo University as a part of the E-LANE project

Related instructions for installing at:

Documentation Project Plan (Approach 4)

Created by OpenACS community, last modified by Gustaf Neumann 25 Sep 2019, at 10:13 PM

This is Approach 4 of the en:Documentation_Project as defined in Documentation_Project_Discussion.  Users benefit when they can read docs the way the brain likes to work. Contributions to various OpenACS topics that further the plan are welcome.

Background

See Documentation history

Goal

to write superb documentation, so that users, developers and administrators of OpenACS installations can enjoy working with and using the system (with fewer headaches! =)

Scope

OpenACS documentation, a systems view as a collection of subsystems and their parts.

API Documentation: there are no plans to move the API docs to XoWiki. That should remain as is.

DocBook docs at: https://openacs.org/doc/index.html are evolving separately at en:New_Documentation_Process

Requirements

Requirements is about setting specifications and milestones we can verify, and includes exploration of scenarios, use cases etc.

Here are documentation requirements for:

Available resources

  • volunteers dedicated to regularly managing and updating the documentation
  • other volunteers who contribute arguably more valuable documentation less frequently (such as magazine articles ;) (and may need some assistance etc. to have their work fit into docs well.)
  • openacs.org website, including use of xowiki
  • open-source software, text editors, spell checkers, HTML code validators etc.
  • Approaches in docs management explored. See en:Documentation_Project_Discussion

Strategy

Strategy is about creating an approach to doing work. It guides behavior and tactical decisions on the work effort.

Shape ongoing documentation efforts by using principles of continual improvement and following general requirements to re-engineer documentation production and management.

OpenACS documentation development is subject to constraints of the software project development and release methods and cycles (the section called “Using CVS with OpenACS”). Essentially, all phases of work may be active to accommodate the asynchronous nature of multiple subprojects evolving by the efforts of a global base of participants with culturally diverse time references and scheduling idiosyncrasies.

The documentation strategy is to use methods that inspire collaborating or obtaining guidance or feedback (peer review) to distribute the workload and increase the overall value of output for the OpenACS project.

subdivide by subsystems and how they are used (context). Why?

"..the human mind can only deal with a relatively small number of independent pieces of data at one time, but if data are chunked together in appropriate ways, the mind can perform higher order abstractions, and these in turn can be chunked together, with successive abstractions, until an entire complex situation is encompassed. The systems approach addresses this property of the human mind by providing strategies for the data gathering, chunking, and abstracting process." George G. Lendaris, On Systemness and the Problem Solver: Tutorial comments 1983.

XoWiki docs can use a systems strategy of multiple perspectives to help identify subsystems and how OpenACS works.

Each XoWiki page discusses a single topic.

These topics are pieced together by any number of other xowiki pages to present an ordered presentation of the topics with a common thread/topic connecting them.

For example, en:openacs-system-install is a page that links together the topics of installing the component software of Openacs. Similarly, each component software, such as en:aolserver, has its own view of some overlapping topics.

XoWiki documents organized by subsystems (and how they are used) are easy to update and maintain since there is only one place to put relevant information for a particular topic.

Pages are not encumbered by a maze of categories that tend to only address one or a few perspectives, since pages link to related pages, and a page that addresses each perspective can link to overlapping topics.

In an ideal world, XoWiki will be able to export a page and all the pages that link to it, to any depth of the linkage tree, to form one document. That way, innumerable documents, each with a valid perspective, can be built for a specific purpose.

Work Breakdown Structure

Or Objectives and Key Results (OKRs) is about explicitly stating the way to implement the strategy as a set of milestones and the methods to use.

Allow document writers to reference package API via api-doc by using package_url, or find the local package_id so a link can be supplied from the local documentation to current, up-to-date API and SQL docs, like: https://openacs.org/api-doc/package-view?version_id=358136 use links like this: /api-doc/index?about_package_key=acs-datetime The feature has been added to cvs head (OpenACS 5.3.x) so will be released soon.[DONE]

Iterate through each topic on each docbook page.

  • Port the docbook pages to xowiki manually, because it allows me to look at each part in details and separate to subsystem/object context. Here is the process:
  • Browse to docbook url (something in this tree: https://openacs.org/doc/)
  • View page source
  • Copy the relevant part of source
  • Paste that source to your favorite text editor (not word processor).
  • Edit the page source, removing DIV tags and TARGET="_blank" attributes. Look for any immediate way to improve the document, make additional edits, check for spelling etc.
  • In a browser, open or create the xowiki page. Choose "Source" to view source html. Be sure to make Name starting with "en:"
  • Paste edited source into the xowiki page, repeat editing if needed
  • Click "ok" to post the xowiki changes.
  • That's it! (repeat)

Example documentation outline in wiki

These pages contain links to other pages where items are discussed in context:

Name for/description
en:docs-end-user documentation for everyone
en:openacs-system end-user about OpenACS system, ties together much of the stuff below.
en:docs-end-user-reqs end-user doc requirements and checklist
en:docs-install installing OpenACS prerequisits
en:openacs-system-install installing OpenACS overview
en:openacs-system-install-redhat installing OpenACS on Redhat
en:docs-install-reqs installation- docs requirements and checklist
en:docs-admin administrators
en:docs-admin-reqs administration - doc requriments and checklist
en:docs-dev-tutorial tutorials for developers
en:docs-dev-tutorial-reqs developer tutorials - requirements and checklist
en:docs-eng developers
en:docs-eng-reqs developing - requirements and checklist

These pages describe various OpenACS subsystems, and link to external documents where possible and appropriate. Note that an "OpenACS system" en:openacs-system page that outlines the system and ties these together is part of the end-user docs.

Name subsystem of OpenACS
en:aolserver AOLserver
en:aolserver-install installing AOLserver
en:aolserver-admin administrating AOLserver
en:naviserver NaviServer
en:naviserver-openacs installing NaviServer
en:oracle Oracle relational database
en:oracle-install installing Oracle
en:oracle-notes  Oracle notes
en:postgresql PostgreSQL relational database
en:postgresql-install installing PostgreSQL
en:postgresql-admin administrating PostgreSQL
en:os-nix *nix operating system
en:os-nix-install installing an OS
en:tcl Tcl language
en:tcl-install installing Tcl
en:openacs-subsystem OpenACS subsystem (layer)
en:openacs-subsystem-install install OpenACS

Auxiliary systems

en:ide-emacs gnu emacs as IDE
[en:ide-emacs-nxml] gnu emacs nXML Mode
[en:ide-emacs-psgml] gnu emacs PSGML Mode
en:ide-vi vi/vim as IDE

Verification

This is where we measure how well this plan was implemented. Success is measured by

  • A) verifying if the project has met the established goals and requirements, and
  • B) reviewing for ongoing problem areas etc.

Observations then help to modify the plan for the next documentation revision.

OpenACS follows verification through different means on different projects, but in all cases, the OpenACS community verifies the project as a success through feedback including bug reports, user and administrator comments, and code changes.

Related links and sources

https://www.divio.com/blog/documentation/ 

OpenACS Packaging for Debian and Ubuntu

Created by Dirk Gomez, last modified by Gustaf Neumann 25 Sep 2019, at 10:05 PM

This page is mostly obsolete. Please refer to the newer guides for Ubuntu and Debian or the generic generic installer script.

Goal

Get all required software to run OpenACS into the next release of Ubuntu Server and Debian 

Dates

  • Debian: Dates are not published. Release cycle ~2 years. The required packages mostly exist already in unstable
  • Ubuntu: Next Debian Import Freeze for the Hardy Heron (Ubuntu 8.04) release is December 13th 2007 at which point new versions of packages will be automatically imported from Debian unstable. After this date, packages will only be imported from Debian in this way by explicit request from a developer.

Prior Work 

As far as we know to this point, there are several bodies of work, including Dirk Gomez's, Jim Lynch's, and some others. While our goal is to combine, for now I'll just put a list and as we begin to work together, we'll combine how we decide to.

  • work of Jim Lynch
    • A pair of scripts and some other stuff available as an arch repository (see applicable documentation on gnu arch and below for specifics on this project). Essentially, the plan is to package by taking everything in an openacs tarball except the packages/ dir, put that into a package called openacs-base, put each openacs package into its own package whose name is specified in the .info file and make a metapackage called openacs-core which installs all of the above.
    • Overall, I want to be able to:
      • feed an openacs tarball to one of these scripts and have it then generate a pile of debian packages which represent the entire tarball, and
      • be able to package any openacs package that wouldn't otherwise come in (say) an openacs core tarball.
    • Upon installation, there will be a script which builds a service by copying all of core into a dir specified in part by the user and in part based on the service name. In this process, the config file and startup scripts are established as well as the daemontools "run" script. A database for the service is created, and the service is started. From there, the new site admin will visit the site with the browser, fill out the form and hit "install data model" as is normal, and you end up with a running service after aolserver is hammered.
    • All non-core packages can be built into debian packages as well, identically to the packaging of core packages.
    • To get: (HI! Can someone besides me (jiml at cvs.openacs) see if this works?)
      the archive's physical location is

      http://jam.sessionsnet.org:7000/~jim/{archives}/jim@jsn.org--2004-pub

      the archive name (valid once you register the archive) is

      jim@jsn.org--2004-pub

      and the category, branch and version is specified as

      openacs-deb-packager--mainline--0.1
      so you would feed the physical location to "tla register-archive", and then you can "tla get jim@jsn.org--2004-pub/openacs-deb-packager--mainline--0.1".
  • combination (eventual goal hopefully)

List of Packages

The following table list the packages, and version, needed to install OpenACS 5.3/5.4 or .LRN 2.3/2.4

 Package Version in debian/etch  Version in debian/sid (unstable) Recommended Version 
aolserver4  4.0.10-7 4.5.0-14 -- 
aolserver4-nspostgres  4.0-3 4.0-4+b1  --
aolserver4-nssha1  0.1-1 0.1-1.0.1  --
aolserver4-nsxml 1.5-1 1.5-1.0.1 NONE don't use nsxml
aolserver4-nsopenssl 3.0beta22-3 3.0beta22-3+b1 --
aolserver4-nscache 1.5-1 1.5-1.0.1 --
aolserver4-dev 4.0.10-7 4.5.0-14 --
tdom 0.7.8-5 N.A. 0.8.2 ??
htmldoc 1.8.27-2 1.8.27-2+b1 --
tcllib 1.8-1 1.10-dfsg-2 1.10
daemontools-installer 0.76-9.2 0.76-9.2 [contrib] --
postgresql-8.1 8.1.9 postgresql-8.1 (8.1.10-1) AND postgresql (8.2.5-4) I think Ubuntu has 8.2 now
postgresql-client-8.1 8.1.9
postgresql-client-8.1 (8.1.10-1) AND postgresql-client (8.2.5-4)
--
postgresql-contrib-8.1 8.1.9 postgresql-contrib-8.1 (8.1.10-1) AND postgresql-contrib (8.2.5-4) --
xotcl 1.6.0 1.6.1 1.6.1
tclthread 20030827-2 2.6.5 2.6.5

 

Verifying installability on Debian 4rc3 sid/unstable


Basic installation steps for oacs-5-4 based on Debian 4rc3 unstable/sid:

 

 

  1. Existing binary dependencies in Debian 4rc3 unstable/sid repository (Feb 26, 2008)
     
    ~$ aptitude install tcllib postgresql-8.2 aolserver4 aolserver4-nscache aolserver4-nssha1 aolserver4-nspostgres tclthread tcllib
    
    
  2. Missing binary dependencies in Debian 4rc3 unstable/sid repository (Feb 26, 2008: tdom 0.8.x, xotcl):

    a) tdom
     
    # build dependencies: tdom
    aptitude install tcl-dev aolserver4-dev
    
    # fetch tdom 0.8.3
    
    cd /tmp
    cvs -z3 -d:pserver:anonymous@cvs.tdom.org:/usr/local/pubcvs co tdom
    cd tdom/unix
    
    # build tdom 0.8.3
    ../configure --enable-threads --disable-tdomalloc --prefix=/usr/lib/aolserver4 --exec-prefix=/usr/lib/aolserver4 --with-aolserver=/usr/include/aolserver4 --with-tcl=/usr/lib
    make install
    b) xotcl (based on forthcoming Debian distribution)
     
    # fetch temporary i386 builds from http://media.wu-wien.ac.at/download/debian
    
    wget http://media.wu-wien.ac.at/download/debian/xotcl_1.6.0-1_i386.deb
    wget http://media.wu-wien.ac.at/download/debian/aolserver4-xotcl_1.6.0-1_i386.deb
    
    # package install
    dpkg -i xotcl_1.6.0-1_i386.deb
    dpkg -i aolserver4-xotcl_1.6.0-1_i386.deb
    
  3. OpenACS as such ...

 


 

useradd oacs-5-4 mkdir /home/oacs-5-4 chown -R oacs-5-4.www-data /home/oacs-5-4 usermod -g web oacs-5-4 usermod -d /home/oacs-5-4 oacs-5-4

cd /home/oacs-5-4 cvs -d :pserver:anonymous@cvs.openacs.org:/cvsroot co -r oacs-5-4 openacs-4 mv openacs4/* . su - postgres createuser -U postgres -s oacs-5-4 exit su - oacs-5-4 createdb -E UNICODE -U oacs-5-4 oacs-5-4

4. Set PostgreSQL backward compatibility flags (in postgresql.conf)

5. Whatever remains to be done (aolserver instance, edit config.tcl, ...)
 

Findings/ Issues related to dependency ensemble

  • Need for Debian OpenACS policy document?
    • config.tcl prototypes for debian/ubuntu (debian defaults might not be adequate, address and hostname settings etc.)
    • environment spec (user, group names, ...)
    • Distribution support roadmap
  • PostgreSQL version support / version parallelism in Debian 4rc3 sid/unstable and Ubuntu 8.04+. To some extend, there is flexibility with respect to the OpenACS compatibility roadmap (whatever it looks like in the near future). Both Debian sid/unstable and, therefore, Ubuntu preserve postgresql-8.x versions in parallel (including 8.1, 8.2, and more recently 8.3). Two issues remain:
    1. Debian sid/unstable sets older PostgreSQL 8.x versions (for now < 8.3) to deprecated and issues an upgrade notification upon fetching and installing. Ubuntu 8.04+ is more silent in this respect.
    2. PostgreSQL Compatibility flags: In either case, OpenACS package will have to change the backward-compatibility settings of the Debian PostgreSQL installation on the target system.
  • AOLServer deb installation (aolserver4 in Debian sid/unstable + Ubuntu 7.10 Gutsy): There is a permission issue in the post-installation routine of the aolserver4 package:
    
     

    ... Setting up aolserver4 (4.5.0-10ubuntu2) ... * Starting web server aolserver4 [21/Feb/2008:20:31:00][5197.3083830960][-main-] Notice: prebind: bound: 127.0.0.1:80    ...done. [21/Feb/2008:20:31:00][5198.3083830960][-main-] Error: log: failed to re-open log file '/var/log/aolserver4/aolserver4.log': 'Permission denied' [21/Feb/2008:20:31:00][5198.3083830960][-main-] Fatal: log: failed to open server log '/var/log/aolserver4/aolserver4.log': 'Permission denied' ...

    This only shows in post-installation phase, manual start|stop|restart work fine ... TODO: Verify again and report to package maintainer
  • aolserver4-nspostgres package: The issue with ns*.so and libns*.so files specific to Aolserver 4.5 has been resolved in the aolserver4-* family of packages:
    • In Debian sid/unstable: since version 4.5-1 on Jan 6, 2008
    • In Ubuntu 8.04 Hardy before the Feature Freeze, on December 12, 2007
    • Post 8.04 will import fixed version from Debian unstable (TODO: Verify with aolserver4-nspostgres maintainer)
    • Issue of backport to Gutsy (depending on Distribution support plan)

Resurrecting tDOM Debian Package

Access to Debian source package (via svn/svn-buildpackage)

  • SVN Browser at Debian Tcl/Tk Repository
  • Steps to get your local working copy and build it using svn-buildpackage:
    
     

    # 1. svn checkout to <current_dir>/tdom svn co svn://svn.debian.org/svn/pkg-tcltk/tdom/ # 2. create a dir for the original tarballs mkdir tarballs (<current_dir>/tarballs) cd tarballs # grab the orig tarball from the link:

    wget openacs.org/xowiki/file/tdom_0%2e8%2e3%2eorig%2etar%2egz?m=download

    mv tdom_0.8.3.orig.tar.gz?m=download tdom_0.8.3.orig.tar.gz

    # 3. make sure you have svn-buildpackage and pbuilder installed and set-up # 4. build binaries from source package on trunk cd ../tdom/trunk

    # When building the package, you have to use --svn-ignore when you have local changes that haven't been committed; otherwise you will get an error.

    svn-buildpackage --svn-builder="pdebuild --buildresult `pwd`/../build-area" --svn-override=origDir=../../tarballs --svn-ignore

    # voilà

    # When you're ready to see lintian warning/errors, add --svn-lintian to the build package command:

    svn-buildpackage --svn-builder="pdebuild --buildresult `pwd`/../build-area" --svn-override=origDir=../../tarballs --svn-ignore --svn-lintian

    # For linda warnings/erros, add --svn-linda to the build package command

    svn-buildpackage --svn-builder="pdebuild --buildresult `pwd`/../build-area" --svn-override=origDir=../../tarballs --svn-ignore --svn-linda

  • References on svn-buildpackage

    http://workaround.org/moin/SvnBuildpackage
    http://debianpaket.de/svn-buildpackage
     
  • Auxiliary stuff

    The orig file

Issues of legacy source package

  • [Fixed] [carl] lintian warnings: "tdom: changelog should mention nmu"
    Problem:
    W: tdom source: changelog-should-mention-nmu
    W: tdom source: source-nmu-has-incorrect-version-number 0.8.3-1
    Fix:
    The maintainer should be Avni Khatri and Carl Blesius <tdom@blesius.org>. Modify debian/changelog to reflect this. This has been fixed temporarily, but since a few us of will be committing, we will have to review the uploader/maintainer names later.
  • [Fixed] [avni] lintian warnings: "tdom: bad distribution in changes file"
    Problem:
    E: tdom_0.8.3-1_source.changes: bad-distribution-in-changes-file UNRELEASED
    Fix:
    modify debian/changelog: change UNRELEASED to unstable on line 1
  • [Fixed (local issue)][avni] lintian warnings: "tdom: directory pwd/../build-area does not exist"
    Problem:
    W: Build-result Directory pwd/../build-area does not exist
    Fix: To avoid using the --buildresult flag, you might put the following
    line into your ~/.pbuilderrc:

    BUILDRESULT=.../build-area

    (make sure you replace the "..." by your directory walk to the actual
    build-area dir)

     
  • [Fixed by geoxito] [avni] lintian warnings: "tdom: package-contains-empty-directory *"
    Problem:
    W: tdom: package-contains-empty-directory usr/bin/
    W: tdom: package-contains-empty-directory usr/sbin/
    Fix:
    the answer/ solution is simple. you have, simplisticly speaking, two ways of creating the "virtual" directory structures. By virtual, I refer to the the paths created under debian/tdom which then go into the binary (*.deb) packages. Either do it manually in the debian/rules file or use template files under debian. look at debian/dirs ... it contains two entries: usr/bin, usr/sbin ... voilà ... these are default settings, created the first time the original author debianized the package. but tdom is a so-called "internal library" package in debian jargon, there will never be anything in bin or sbin. so, simply remove the file or empty it!!!!
  • [Fixed] Which version to package: 0.8.2 / 0.8.3? it is going to be CVS Head/ 0.8.3
  • [Fixed] [geoxito] Installation paths not compliant with Debian Tcl/Tk policy
    Study http://pkg-tcltk.alioth.debian.org/tcltk-policy.html/
    and make sure that you change debian/rules etc. accordingly.
    Most importantly, tcl package reside under /usr/lib/tcltk and not /usr/lib/ directly.
  • [Fixed] [mr_calvin] Dedicated tdom-dev binary package. There needs to be a dedicated development binary package.
    Fix:
    1. Add tdom-dev entry in debian/control
    2. debian/rules needs to copy following files into tdom-dev paths:
      /usr/include/tdom.h
      /usr/lib/tdomConfig.sh
      /usr/lib/tdom0.8.2/libtdomstub0.8.2.a
    3. Btw. change the include path to /usr/include/tdom/*
      and subsequently change the path settings in tdomConfig.sh through search/replace operations in debian/rules
      (see my xotcl examples in http://svn.debian.org/viewsvn/pkg-tcltk/xotcl/trunk/debian/rules?rev=544&view=markup). watch out for perl commands in there ...
  • [Fixed] [avni] Further lintian clean-up:
    Problem:

    > W: tdom: manpage-has-errors-from-man usr/share/man/man3/dom.3.gz  invalid option -wmac
    > W: tdom: manpage-has-errors-from-man usr/share/man/man3/domDoc.3.gz  invalid option -wmac
    > W: tdom: manpage-has-errors-from-man usr/share/man/man3/domNode.3.gz  invalid option -wmac
    > W: tdom: manpage-has-errors-from-man usr/share/man/man3/expat.3.gz  invalid option -wmac
    > W: tdom: manpage-has-errors-from-man usr/share/man/man3/expatapi.3.gz  invalid option -wmac
    > W: tdom: manpage-has-errors-from-man usr/share/man/man3/tdomcmd.3.gz  invalid option -wmac
    > W: tdom: manpage-has-errors-from-man usr/share/man/man3/tnc.3.gz  invalid option -wmac

    Fix: seems to be fixed now.
  • [Fixed] [mr_calvin] Expat integration: Using internal (expat 2.0.1 or 1.95) or external (1.95) libexpat (as provided by Debian); comment by Debian Tcl/Tk maintainers:
    "As far as I understand, the current version uses internal expat. I
    think it's unacceptable. We should use libexpat from Debian. An
    example of patches which allow to use system-wide expat could be found
    at svn://bamboo.nes.ru/debian/tcl/tdom/trunk"
  • [Fixed] [geoxito] Create tdom-doc package if possible. Fix: Not really needed, because there is no other tdom documentation apart the manpages.

 

Installing packages

 

 These are instructions for installing the alpha dotlrn and openacs packages on debian (and ubuntu).

  1. Build and install tdom packages (see above, on "Resurrecting tdom").
  2. Set up a postgresql 8.2 server, and allow access for postgresql administrator user and openacs/dotlrn user from the machine where you are installing dotlrn/openacs (no need to create the dotlrn/openacs user and database).
  3. Modify your /etc/apt/sources.list file:
    
     

    # debian sid deb http://debian.adenu.ia.uned.es/apt sid main # Ubuntu Hardy deb http://debian.adenu.ia.uned.es/apt hardy main

  4. Update the package list and install:
    
     

    # apt-get update - dotLRN # apt-get install dotlrn

    - OpenACS # apt-get install openacs

 After that, just follow the instructions on the install ant have fun!

OpenACS/.LRN for Debian

Created by Héctor Romojaro, Stefan Sobernig, last modified by Gustaf Neumann 22 Mar 2019, at 11:14 PM

 

Logo

 

Packages of OpenACS and .LRN are now available for Debian GNU/Linux. We hope to facilitate the adoption by novices and the infrastructure deployment by professional users, both running Debian GNU/Linux and its derivatives. Our packaging activity explicitly targets Debian GNU/Linux stable, testingand unstable. Important dependencies are co-maintained with the Debian Tcl/Tk Maintainers.

See also OpenACS for Ubuntu.

Getting started

Please, review the section on supported distributions first.  Currently, the core packages (openacs, dotlrn) and their dependencies are included into the official Debian GNU/Linux repositories.

Install


  1. Run:

    apt-get update

     

  2. (optional) Provide for a PostgreSQL environment: If you don't have a PostgreSQL installation at hand, provide one. You do not need to care about setting up a concrete data base. This is automatically done by the OpenACS and dotlrn post-install instructions. For further PostgreSQL-related set-up issue, see ...
     
    apt-get install postgresql
    
    If you run a remote PostgreSQL instance, remember to allow for access of the PostgreSQL Administrator (postgres) and the openacs/dotlrn user from machine hosting your OpenACS/.LRN installation.
     
  3. Install the core packages and follow the on-screen instructions:
     
    # OpenACS
    apt-get install openacs
    ... or ...
     
    # .LRN
    apt-get install dotlrn   

After Install

  1. (optional) To change IP address and port of the instance, please edit the file:
     
    # OpenACS
    /etc/openacs/openacs.sh
    
    # dotLRN
    /etc/dotlrn/dotlrn.sh
    
    
    
  2. (optional) To control the instance using daemontools, please install the daemontools debian packages and follow the instructions on the file:

     
    # OpenACS
    /usr/share/doc/openacs/README.daemontools
    
    # dotLRN
    /usr/share/doc/dotlrn/README.daemontools
     

To-dos

Next Steps, After Basic Installation (above)

 

People

Active contributors

  • Héctor Romojaro 
  • Stefan Sobernig
  • Avni M. Khatri
  • Carl R. Blesius


Packages status


Packages maintained by Debian Tcl/Tk Maintainers

 

Packages co-maintained by OCT & Debian Tcl/Tk Maintainers

 

 

 

Prodding

Please, for getting in contact and reporting issues, consider ...

Official Test Servers

Created by Gustaf Neumann, last modified by Gustaf Neumann 19 Oct 2017, at 11:53 AM

Currently none

{done} OpenACS 5.3.x releases

Created by Rocael Hernández Rizzardini, last modified by Gustaf Neumann 19 Oct 2017, at 11:53 AM

OpenACS 5.3.x Releases


Update: OpenACS 5.3.0a1 is available for download https://openacs.org/projects/openacs/download/one-revision?revision_id=494139 or by checking out openacs-5-3-0a1 tag from CVS. Work continues on the oacs-5-3 branch in CVS
 

The main goal is to have acs-core to pass all the automated tests (PG 8.1.x & Oracle 9i).

We plan to branch for oacs-5-3 in September 2006. 

Many bug stomp where we actually create, fix, update tests for acs-core has been done. 

Bug-stomp: 21-22 sept. 06. Focus on have all the actual test pass for acs-core (no more new test), plus start classifying the bugs in the bug-tracker. Based on the results of this bug-stomp we'll decide when to branch and what should be included (bug-fixes) in next release.

 

Check the Official Test Servers


 

 

User interface mockups

Created by Dave Bauer, last modified by Benjamin Brink 30 Jun 2017, at 05:09 PM

NameContent TypeLast ModifiedBy UserSize (Bytes)
file-upload-mockups.pdfapplication/pdf2017-06-30 17:09:01+02Benjamin Brink161631

Activity Graph

Created by Gustaf Neumann, last modified by Benjamin Brink 30 Jun 2017, at 07:12 AM

You must login to see the activity-graph

Collaboration Graph

Created by Gustaf Neumann, last modified by Benjamin Brink 30 Jun 2017, at 07:10 AM

You must login to see the collab-graph

GETable resources, that should be POSTable resources

Created by Michael Aram, last modified by Benjamin Brink 30 Jun 2017, at 07:05 AM

TODO: These OpenACS-URLs are available via GET requests, but as the associated actions are either not safe or not idempotent (or both), they should be made available only via POST instead...

This is more of a problem nowadays as it was earlier, as current browsers (like Chrome or Safari) tend to fetch resources even before the user hits enter in the address bar (i.e. one cannot easily prevent that an unwanted action is taken while entering a similar URL).

In particular the actual (Jan 2014) versions of Safari on Mac OS X 10.9.1 automatically pre-fetches URLs for an url path, when sub-pages were visited in the past, and a user clicks in the url bar (as soon as it shows possible completions). One can e.g. shut down "automatically" the OpenACS server by on /acs-admin/, since Safari might "prefetch" /acs-admin/server-restart.

This page is only a TODO list, that should become a bug report later...

 

  • /acs-admin/users/become
  • /acs-admin/server-restart

 

Next Page
previous October 2024
Sun Mon Tue Wed Thu Fri Sat
29 30 1 (1) 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31 1 2

Popular tags

17 , 5.10 , 5.10.0 , 5.10.1 , 5.9.0 , 5.9.1 , ad_form , ADP , ajax , aolserver , asynchronous , bgdelivery , bootstrap , bugtracker , CentOS , COMET , compatibility , CSP , CSRF , cvs , debian , docker , docker-compose , emacs , engineering-standards , exec , fedora , FreeBSD , guidelines , host-node-map
No registered users in community xowiki
in last 30 minutes
Contributors

OpenACS.org