Forum OpenACS Development: 5.0 is done.

Posted by Joel Aufrecht on
Version 5.0.0 is released.  The oacs-5-0 branch will be merged to HEAD shortly and the branch guidelines at will be updated.  A release plan for 5.1 is forthcoming; further releases in 5.0.x should be for bug fixes only.
2: Re: 5.0 is done. (response to 1)
Posted by Joel Aufrecht on
Oh, and the tarball includes all the core modules.  The CVS tag is openacs-5-0-0-final.  To get more packages, go to Admin > Install Software (/acs-admin/install) and click under "Install from Repository" to download and install new packages directly from
3: Re: 5.0 is done. (response to 1)
Posted by Jade Rubick on
Thanks to everyone for all their work on this. This is a great release!
4: Re: 5.0 is done. (response to 1)
Posted by C. R. Oldham on
Yahoo--yes let me also say "great job" and buy everyone involved a virtual beer. 😊
5: Re: 5.0 is done. (response to 1)
Posted by Don Baccus on
Damnit I'm getting tired of these virtual beers!  When is CR going to show up at a social and buy us real ones! :)
16: Virtual Beer (response to 5)
Posted by Steve Manning on
Don will this help to solve the problem?


Network Working Group                                         S. MANNING
Request for Comments: xxxx                                       
                                                           24th Jan 2004

   A Standard for the Transmission of Virtual Beer over IP

Status of this Memo

   This memo describes an experimental method for the encapsulation of
   Virtual Beer in IP datagrams.  This specification would be referred 
   to as VBTP. This is an experimental, not recommended standard.  
   Distribution of this memo is unlimited.

Overview and Rational

   On many occasions within community projects virtual beers are offered
   as a form of gratuity often as a expression of thanks for a job well 
   done. Unfortunately no transport method exists which allows the 
   aforementioned beer to be delivered. This RFC aims to correct this 
   shortcoming. The protocol deals with the transmission of the beer 
   only. Transmission of the bottle and cap is outside of the scope of 
   this document.

Transmission Format

   The first requirement is to convert the molecular structure of the 
   liquid beer into a binary representation. Some form of chemical 
   analysis is required. It is proposed that a database of the chemical 
   makeup of well known beer brands is maintained. This avoids the 
   requirement to analyse each individual beer transmitted which should
   greatly improve throughput. In the UK the Campaign for Real Ale 
   ( have been approached with a view to setting up a
   national standard database to enable the transmission of real ale 
   by VBTP.

   The structure of the beer is packaged into a series of IP datagrams.
   The number of datagrams transmitted is determined by the size and 
   number of bottles being transmitted. The datagrams are received on 
   the VBTP port by a virtual beer gateway server (VBGS). This device 
   resembles a cross between a cisco router and an espresso coffee maker.
   Upon receipt of the appropriate number of datagrams the VBGS 
   constructs the beer from source molecules and deposits it in a bottle.
   It then caps the bottle before ringing a bell to indicate a delivery.


   The obvious problem with transmission by VBTP is that of licensing 
   from the breweries. One solution would be to organise some form of 
   licensing perhaps using DRM to control transmission and payment.

Security Considerations

   Security is not generally a problem in normal operation, but special
   measures must be taken (such as data encryption) to avoid interception
   of the VBTP packets by underage persons.

Author's Address

   Steve Manning
   Chestnut Way
   East Goscote

   Phone: +44 (0)116 2605457


6: Re: 5.0 is done. (response to 1)
Posted by Jon Griffin on
There seems to be a problem with the cvs co. I am getting aborted on openacs-4 .... many files and it appears that it is only trying to import acs-lang. Here is my cvs commandline

cvs -z3 co -d openacs-5-0-0 -r openacs-5-0-0-final acs-core
7: Re: 5.0 is done. (response to 1)
Posted by Cathy Sarisky on
I did a cvs checkout (5-0-0-final) yesterday and appeared to get a full system, but I'm doubting it's actually 5.0.0 final, since I'm seeing bugs that would certainly be blocking in several packages.  Anyone else seeing similar?  I'm switching over to the tarball to see if that fixes the problem.
8: Re: 5.0 is done. (response to 7)
Posted by Joel Aufrecht on
5-0-0-final should apply only to the core modules. Are you seeing critical bugs in core modules? If so, please log them. If you check out 5-0-0-final from cvs or untar the tarball, you get only the core packages. If you then update with cvs up -Pd (prune removed dirs, add new dirs), you will get everything from the oacs-5-0 branch. This includes all packages and all contrib (basically everything but .LRN). You can't do cvs up if you got the tarball, but you can Install From Repository, and the repository on was built yesterday from oacs-5-0.

Only the core got a real release management process. I am compiling a list of broken packages which I will turn into bugs (Pri 1/Sev 1 - does not install - for individual packages). So far, about 10% of packages don't install from auto-installer due to broken dependency data, and another 20% or 30% break on install or don't work.

Next steps:

  • I've updated the CVS Checkout instructions. We need to figure out the rules for developing packages (for example, all work on contrib modules should only happen in HEAD, what are the criteria for releasing 'standard' packages and who does the code work and the Release Management work, etc).
  • We need to test out all of the existing packages against stock 5.0.0. Everyone is welcome to play with the new Demo Server, and if you want an admin account to test package installs just let me know.
10: Re: 5.0 is done. (response to 8)
Posted by Joel Aufrecht on
The respository has two channels, 5-0 and 5-1, which is really HEAD.  Which channel your server uses is automatic, based on your kernel version.  A server using the 5.0.0 tarball uses channel 5-0.  Due to a bug in the code generating the repository, the 5-0 channel actually had HEAD code.  Lars fixed the bug and I rebuilt the repository on a few hours ago so "Install from Repository" should produce much better results now.
9: Re: 5.0 is done. (response to 1)
Posted by Bruno Mattarollo on
Congratulations to everyone that made this possible!!! I have been running the beta for a while on my PowerBook and on an Xserve, it looks very neat! Will start playing around with external authentication (finally) :)


11: Re: 5.0 is done. (response to 1)
Posted by Cathy Sarisky on
Joel -

Phew!  That makes much more sense. :)  I'll reinstall.

12: Re: 5.0 is done. (response to 1)
Posted by Jon Griffin on
On an upgraded 5.0 from 4.6.3, It appears that there is a bug in acs-admin/install/install/ when trying to update from OACS server.

error "Unterminated element" at position 672
        <br />
        <input type=submit value="Search" name="t">
      </f <--Error-- orm>
<hr noshade>    
    <address><a href="">"
    while executing
"dom parse -simple [lindex $args 1]"
    (procedure "xml_parse" line 4)
    invoked from within
"xml_parse -persist $manifest"
    (procedure "apm_get_package_repository" line 30)
    invoked from within
"apm_get_package_repository -repository_url $repository_url -array repository"
    ("uplevel" body line 30)
    invoked from within
"uplevel {

13: Re: 5.0 is done. (response to 1)
Posted by Jon Griffin on
In case anyone else makes this mistake, you must use the apm to update any core packages before you can use the upgrade from OACS option.
14: Re: 5.0 is done. (response to 13)
Posted by Randy O'Meara on
Hmmm. Where is developer-support? It isn't included or installed with the release tarball. And it isn't available (doesn't appear in the list of installable packages) in the repository.

Ditto for acs-mail-lite...

15: Re: 5.0 is done. (response to 14)
Posted by Joel Aufrecht on
Both acs-mail-lite-0.1d.apm and acs-developer-support-5.0d3.apm are in the repository. It looks like the automatic installer refuses to see them - this could be a bug in the installer or there could be something wrong with the package. This leads to a number of other packages being uninstallable. A workaround is to download them directly and install from local, and then go back to using the repository.
17: Re: 5.0 is done. (response to 1)
Posted by Ola Hansson on

I just tried to install Curriculum via the remote repository, in my case to see if I was able to recreate bug #1414 which you reported (thanks!) ... I was indeed able to recreate it, but the package installation worked when done from local (oacs-5-0-0-final) files.

It looks as though the remote installer either gets the wrong idea about the kernel version or that the repository you rebuilt actually didn't get rebuilt after all, because the service and application versions that are listed when I click on the "install new ..." links all point toward the 5.1 channel even though I'm on oacs-5-0-0-final.

And there's been enough changes to the Workflow package (on which Curriculum depends) on HEAD to account for bug #1414.

Or perhaps Lars fixed more than just the creation of the repository and things will "just work" TM when 5.0.1 is out?


18: Re: 5.0 is done. (response to 1)
Posted by Randy O'Meara on
Thank you, Joel.

It would be good if one could see the repository files  available for download since (unless you resort to CVS) you must know the filename in order to download and install locally.

The repository page at shows no available files, and the repository channel url at results in the file not found page.


19: Re: 5.0 is done. (response to 18)
Posted by Joel Aufrecht on
What needs to happen next is that the file /packages/acs-admin/www/apm/build-repository.tcl on HEAD needs to be modified to produce an index.html file in addition to the manifest.xml that it makes. This would be a nice worker-bee task - the page already has all the code to parse all the .info files and build xml so it's just extending it a bit.

The file should display package key, package-name, current version, owner, summary, and possibly description in an html table. It should sort by package name, not key. Ideally it would also group things into Core, Application, Contrib, and .LRN, but that information isn't stored in the .info files (yet).

Any volunteers? If someone else writes the code I'm happy to test it.