The 4.6.3-5.0 upgrade requires not only manual loading of SQL files, but also execution of Tcl after-install callbacks to allow an administrator to login to complete the upgrade process.

Manual upgrade of:

acs-kernel datamodel
acs-service-contract datamodel

Manual loading of:
acs-authentication datamodel
acs-lang datamodel

In addition acs-land and acs-authenication packages need to be installed and enabled, and acs-lang needs to be mounted for admins to login.

It looks like some code somewhere will need to perform these steps. Any suggestions?

First a coding style issue :)  You should always curly-bracket your conditional expressions because otherwise the byte-code isn't saved and the expression is recompiled every time the code's run. (Well, it doesn't matter in this case but ... :)

Upgrading the acs-kernel datamodel by hand won't update the APM version number, will it?  If that's in the script then I bet I can say that it won't be updating the APM version number for acs-bootstrap-installer ... can't you just check that?  The user's going to have to visit the APM to get the version number updated, no, even though there are no upgrade datatmodel files?

Or am I all wet ...

I am attempting to upgrade aufrecht.org to 5.0.  My steps are as follows (with dead ends omitted):
1) Inspect the live system by going to /acs-admin/apm, and discover that the kernel is 4.6.1.
2) Make a copy of the live database (postgresql), which is PostGreSQL 7.2
3) On a development machine, run pg_7.2to7.3_upgrade_helper.pl on the dmp file.
4) Restore the dmp file to a PostGreSQL 7.3.4 database.
5) Download the OpenACS 4.6.3 tarball and unpack it
6) tweak the config.tcl file to have correct values
7) Start aolserver using the 4.6.3 tarball as the homedir and the restored database as the db
8) Go to the APM and click Install
9) Select only the kernel for Upgrade.  Select both
      sql/postgresql/upgrade/upgrade-4.6.1-4.6.2.sql
    sql/postgresql/upgrade/upgrade-4.6.2-4.6.3.sql
10)      Failed to install ACS Kernel, version 4.6.3. The following error was generated:

          Database operation "0or1row" failed (exception NSDB, "Query was not a statement returning rows.") ERROR: pg_atoi: zero-length string SQL: select apm_package_version__new( NULL, 'acs-kernel', '4.6.3', 'http://openacs.org/repository/download/apm/acs-kernel-4.6.3.apm', 'Routines and data models providing the foundation for OpenACS-based Web services.', NULL, NULL, '2002-10-27', 'OpenACS', 'http://openacs.org/', 't', 't' );

I realized that my original plan was doomed, because you can't run OpenACS 4.6.1 on PostgreSQL 7.3.  In other words, if you want to upgrade from OpenACS 4.6.1/Pg 7.2, you have to upgrade OpenACS to pg 4.6.3, and then upgrade the postgres database to 7.3, and then switch to using postgres 7.3 to run the upgraded database, all in that order.  You cannot upgrade from 4.6.1/pg 7.2 to 4.6.3/7.3 via 4.6.1/pg 7.3, because that combination is not valid.

So:
1) Inspect the live system by going to /acs-admin/apm, and discover that the kernel is 4.6.1.
2) Make a copy of the live database (postgresql), which is PostGreSQL 7.2
3) On a development machine, restore the dmp file of the production db
4) Download the OpenACS 4.6.3 tarball and unpack it
5) Start aolserver using the 4.6.3 tarball as the homedir and the restored database as the db (still 7.2!)
6) Go to the APM and click Install
7) Select only the kernel for Upgrade.  Select both
      sql/postgresql/upgrade/upgrade-4.6.1-4.6.2.sql
    sql/postgresql/upgrade/upgrade-4.6.2-4.6.3.sql
8)      Failed to install ACS Kernel, version 4.6.3. The following error was generated:

Installed ACS Kernel, version 4.6.3.

# Installing data model for ACS Kernel 4.6.3...

    * Loading data model /var/lib/aolserver/openacs-4.6.3/packages/acs-kernel/sql/postgresql/upgrade/upgrade-4.6.1-4.6.2.sql...

CREATE
COMMENT
COMMENT
COMMENT
ALTER
UPDATE 47
COMMENT
DROP
DROP
CREATE
CREATE
CREATE
CREATE
CREATE
CREATE
DROP
DROP
CREATE
CREATE
DROP
DROP
CREATE
CREATE
DROP
DROP
CREATE
CREATE
HTTP/1.0 200 OK
Server: AOLserver/3.3.1+ad13
Content-Type: text/html; charset=iso-8859-1
MIME-Version: 1.0
Date: Sat, 13 Dec 2003 19:46:41 GMT
Content-Length: 3211
Connection: close






          Request Error




psql:upgrade-4.6.1-4.6.2.sql:237: ERROR:  view "acs_privilege_descendant_map_view" does not exist
psql:upgrade-4.6.1-4.6.2.sql:244: ERROR:  Attempt to insert rule "_RETacs_privilege_descendant_ma" failed: already exists

Here are my results so far. My problem seems to be in acs-lang.  The log file is showing error messages for queries but when I try the same query in psql it runs fine.

Steps

1.Inspect at acs-admin/apm found acs-kernal to be version 4.6.2
2.made a dump of the database
3.Upgraded the code for acs-kernal to 4.6.3
4.upgraded the kernal from the apm
5.made a dump of the database
6.loaded the dump into pg 7.3 – I did not need to run the upgrade_helper script because my hosting provider (zill.net) has set the 7.2 character limit to 64 so it did not truncate the function names.
7.Sanity check the import by looking at number of users or objects
8.Made a copy of the code
9.Used this cvs command to get the code cvs -z3 -d :pserver:anonymous@openacs.org:/cvsroot co -r oacs-5-0 acs-core
My 5.0 code is now in the directory /home/aristoi/openacs-4
10.$cd openacs-4/packages/acs-kernel/sql/postgresql/
11.psql -f postgresql.sql – This generated a lot of already exist errors and some create functions
12.cd upgrade/
13. psql -f upgrade-4.6.3-4.6.4.sql
14.psql -f upgrade-4.6.4-4.6.5.sql
15.psql -f upgrade-4.6.5-4.6.6.sql
16.psql -f upgrade-4.6-4.6.1.sql  - This was a mistake I am already at 4.6.3
17.psql -f upgrade-4.7d-4.7.2d.sql
18.psql -f upgrade-4.7.2d-5.0d.sql
19.psql -f upgrade-5.0d-5.0d2.sql
20.psql -f upgrade-5.0d2-5.0d3.sql
21. psql -f upgrade-5.0d6-5.0d7.sql
22.psql -f upgrade-5.0d7-5.0d9.sql
psql:upgrade-5.0d7-5.0d9.sql:12: NOTICE:  rule _RETURN on view apm_file_info depends on table apm_package_files
psql:upgrade-5.0d7-5.0d9.sql:12: NOTICE:  view apm_file_info depends on rule _RETURN on view apm_file_info
psql:upgrade-5.0d7-5.0d9.sql:12: ERROR:  Cannot drop table apm_package_files because other objects depend on it
24)psql -f upgrade-5.0d11-5.0d12.sql
25)psql -f upgrade-5.0.0a4-5.0.0a5.sql
26)psql -f upgrade-5.0.0b1-5.0.0b2.sql
27)psql -f upgrade-5.0.0b2-5.0.0b3.sql
28)psql -f upgrade-5.0.0b3-5.0.0b4.sql
psql:upgrade-5.0.0b3-5.0.0b4.sql:788: ERROR:  Cannot change number of columns in view
psql:upgrade-5.0.0b3-5.0.0b4.sql:802: ERROR:  Cannot change number of columns in view
29) cd ~/openacs-4/packages/acs-service-contract/sql/postgresql/upgrade/
30)psql -f upgrade-4.7d2-4.7d3.sql
31)cd ~/openacs-4/packages/acs-authentication/sql/postgresq
32)psql -f acs-authentication-create.sql
33) cd ~/openacs-4/packages/acs-lang/sql/postgresql/
34) psql -f acs-lang-create.sql
BEGIN
psql:ad-locales.sql:44: NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index 'ad_locale_abbrev_pk' for table 'ad_locales'
psql:ad-locales.sql:44: NOTICE:  CREATE TABLE / UNIQUE will create implicit index 'ad_locale_name_unq' for table 'ad_locales'
psql:ad-locales.sql:44: ERROR:  Relation 'ad_locales' already exists
psql:ad-locales.sql:56: ERROR:  current transaction is aborted, queries ignored until end of transaction block
psql:ad-locales.sql:60: ERROR:  current transaction is aborted, queries
many more of theseLooking in my dump file I see that yes ad_locals does exist so I probably installed it at some point. I will try running the upgrade scripts.
33)cd upgrade/
34)psql -f upgrade-4.1-4.7d2.sql
35)psql -f upgrade-4.7d2-4.7d3.sql psql -f upgrade-4.7d2-4.7d3.sql
36)psql -f upgrade-4.7d3-4.7d4.sql
37)psql -f upgrade-4.7d4-4.7d5.sql
38)psql -f upgrade-4.7d6-4.7d7.sql
psql:upgrade-4.7d6-4.7d7.sql:3: ERROR:  Cannot drop table ad_locales because other objects depend on it
      Use DROP ... CASCADE to drop the dependent objects too
psql:upgrade-4.7d6-4.7d7.sql:28: NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index 'ad_locale_abbrev_pk' for table 'ad_locales'
psql:upgrade-4.7d6-4.7d7.sql:28: NOTICE:  CREATE TABLE / UNIQUE will create implicit index 'ad_locale_name_unq for table 'ad_locales'
psql:upgrade-4.7d6-4.7d7.sql:28: ERROR:  Relation 'ad_locales' already exists
psql:upgrade-4.7d6-4.7d7.sql:29: ERROR:  Cannot insert a duplicate key into unique index ad_locale_name_unq
DROP TABLE
39)psql -f upgrade-4.7d7-4.7d8.sql
Same errors as 4.7d6 to d7 above
40)psql -f upgrade-4.7d8-4.7d9.sql
41)psql -f upgrade-4.7d9-5.0d1.sql
42) created zzz-postload.tcl according to Dave;s instructions here. http://openacs.org/projects/openacs/5.0/upgrade-463-50

43)Added ns_param  tdom                ${bindir}/tdom.so to the ns_section "ns/server/${
44)Restarted server
45)error on trying to show a page
Error: tclop: invalid return code from filter proc 'invalid command name "parameter::get"': must be filter_ok, filter_return, or filter_break
Error durring load is
13/Dec/2003:22:56:11][18708.1024][-main-] Debug: PgBindCmd: sql =
      select locale
    from  ad_locales
        where  enabled_p = 't'

[13/Dec/2003:22:56:11][18708.1024][-main-] Error: Ns_PgExec: result status: 7 message: ERROR:  Attribute 'enabled_p' not found

[13/Dec/2003:22:56:11][18708.1024][-main-] Error: Error sourcing /home/aristoi/openacs-4/packages/acs-templating/tcl/acs-templating-init.tcl:
Database operation "select" failed (exception NSDB, "Query was not a statement returning rows.")
But when I try the query in psql it works fine.

Joel, I suspect the acs_privilege_descendant_map view needs to be dropped as well (I think the problem is that the end result is to have acs_privilege_descendant_map as a table and acs_privilege_descendant_map_view fails to create since the truncated name collides with one on the original view).

Joel, I looked at where acs_privilege_descendant_map gets turned into a table (instead of a view), its in upgrade-4.6-4.6.1.sql so I think you somehow missed that update which might explain why this is not working...

Figured out why the upgrade script stopped working - I left out an argument to the script.

I found my previous problem. PGHOST was not set correctly and it was still pointing to my old database.

Now my issue is here:

[14/Dec/2003:22:58:18][12594.1024][-main-] Debug: PgBindCmd: query with bind variables sub\
stituted =

      select apm_package__new(
        NULL,
        'Authentication',
        'acs-authentication',
        'apm_package',
        now(),
        null,
        null,
        NULL
      );


WARNING:  Error occurred while executing PL/pgSQL function apm_package__singleton_p
WARNING:  line 5 at select into variables
[14/Dec/2003:22:58:18][12594.1024][-main-] Error: Ns_PgExec: result status: 7 message: ERR\
OR:  pg_atoi: error in "t": can't parse "t"

Caroline, the apm_package__singleton_p proc was wrong in the upgrade script, I updated the upgrade-5.0.0b3-5.0.0b4.sql to fix it (I had already fixed the create script) so you might want to replace it with a correct one or suffer the consequences down the road :)

Also, I applied a couple patches to the upgrade scripts so anyone trying to work through upgrading might want to do a cvs update...

In my case I had to import acs-lang messages for locale en_US so my openacs-5/tcl/ zzz-postload.tcl contains:

if {![apm_package_installed_p acs-lang]} {
    apm_package_install -enable -mount_path acs-lang [acs_root_dir]/packages/acs-lang/acs-lang.info
    lang::catalog::import -locales [list "en_US"]
}

if {![apm_package_installed_p acs-authentication]} {
    apm_package_install -enable [acs_root_dir]/packages/acs-authentication/acs-authentication.info
    apm_parameter_register "UsePasswordWidgetForUsername" \
     "Should we hide what the user types in the username
      field, the way we do with the password field? Set
      this to 1 if you are us ing sensitive information
      such as social security number for username." \
     acs-kernel 0 number \
     security 1 1
    parameter::set_value -package_id [ad_acs_kernel_id] -parameter UsePasswordWidgetForUsername -value 0
}

Nevermind that, its in acs-kernel, upgrade-5.0d2-5.0d3.sql.

Caroline,
looks your acs-lang message catalog isn't imported properly.
Try create file foo.tcl with one line:

lang::catalog::import -locales [list "en_US"]

and put in under openacs-5/www directory.

Next go to address http://yourserver.com/foo and it should import missing messages.
I had the same problem, as you and this is a reason I put line

lang::catalog::import -locales [list "en_US"]

into Dave's zzz-postload.tcl file

Thanks Robert,

I had seen your earlier post and put it in my zzz file but missed the error it threw.  When I put it into its own tcl file I was able to track down the problem.

I had thought I had dropped acs-lang and recreated it but due to a bug in the message-catalog-drop.sql I hadn't deleted and recreated the lang_messages table.  It looks great now.

I submitted a bug report on message-catalog-drop.

Progress report: I have upgraded a 4.6.0 database to 4.6.3 and from PG 7.2 to 7.3, apparently successfully.  I am now trying to upgrade to 5.0, following Caroline's path in this thread.
1) It's fairly unpleasant to have to run each of the ~20 upgrade files manually.  How will we know when this is stable enough to run automatically from the APM?

2) What is the correct order of upgrade scripts to run for 4.6.3 to 5.0?  Do we need any of the 4.6.4 through 4.7 files?

upgrade-4.2-4.5.sql
upgrade-4.5.1-4.5.2.sql
upgrade-4.5.1-4.6.sql
upgrade-4.5-4.5.1.sql
upgrade-4.6.1-4.6.2.sql
upgrade-4.6.1-4.7d.sql
upgrade-4.6.2-4.6.3.sql
upgrade-4.6.3-4.6.4.sql
upgrade-4.6.4-4.6.5.sql
upgrade-4.6-4.6.1.sql
upgrade-4.6.5-4.6.6.sql
upgrade-4.7.2d-5.0d.sql
upgrade-4.7d-4.7.2d.sql
upgrade-5.0.0a4-5.0.0a5.sql
upgrade-5.0.0b1-5.0.0b2.sql
upgrade-5.0.0b2-5.0.0b3.sql
upgrade-5.0.0b3-5.0.0b4.sql
upgrade-5.0d11-5.0d12.sql
upgrade-5.0d2-5.0d3.sql
upgrade-5.0d-5.0d2.sql
upgrade-5.0d6-5.0d7.sql
upgrade-5.0d7-5.0d9.sql

3) I ran

psql -f upgrade-4.6.3-4.6.4.sql
psql -f upgrade-4.6.4-4.6.5.sql
psql -f upgrade-4.6.5-4.6.6.sql

The first two worked fine but the third hung until I hit control-c:

psql -f upgrade-4.6.5-4.6.6.sql aufrecht-dev
UPDATE 1
psql:upgrade-4.6.5-4.6.6.sql:11: ERROR:  users_user_id_fk referential integrity violation - key referenced from users not found in persons

Cancel request sent
psql:upgrade-4.6.5-4.6.6.sql:12: WARNING:  Error occurred while executing PL/pgSQL function acs_objects_context_id_up_tr
psql:upgrade-4.6.5-4.6.6.sql:12: WARNING:  line 11 at SQL statement
psql:upgrade-4.6.5-4.6.6.sql:12: ERROR:  Query was cancelled.

In my upgrade experience, several upgrade scripts generated errors, but none seemed to be too dangerous -- mostly either attempts to add already existing columns, or to insert duplicate keys.

These are the calls I ran (verbatim).

cd
pg_dump kurup > mydb.dmp
dropdb dev-kurup
createdb dev-kurup
psql -f mydb.dmp dev-kurup
cd web/dev-kurup/packages/acs-kernel/sql/postgresql/upgrade/
psql dev-kurup < upgrade-4.6.4-4.6.5.sql 
psql dev-kurup < upgrade-4.6.5-4.6.6.sql 
psql dev-kurup < upgrade-4.7d-4.7.2d.sql 
psql dev-kurup < upgrade-4.7.2d-5.0d.sql 
psql dev-kurup < upgrade-5.0d-5.0d2.sql 
psql dev-kurup < upgrade-5.0d2-5.0d3.sql 
psql dev-kurup < upgrade-5.0d6-5.0d7.sql 
psql dev-kurup < upgrade-5.0d7-5.0d9.sql 
psql dev-kurup < upgrade-5.0d11-5.0d12.sql 
psql dev-kurup < upgrade-5.0.0a4-5.0.0a5.sql 
psql dev-kurup < upgrade-5.0.0b1-5.0.0b2.sql 
psql dev-kurup < upgrade-5.0.0b2-5.0.0b3.sql 
psql dev-kurup < upgrade-5.0.0b3-5.0.0b4.sql 
cd ../../../../acs-service-contract/sql/postgresql/upgrade/
psql dev-kurup < upgrade-4.7d2-4.7d3.sql 
cd ../../../../acs-authentication/sql/postgresql/
psql dev-kurup < acs-authentication-create.sql 
cd ../../../acs-lang/sql/postgresql/
psql dev-kurup < acs-lang-create.sql 
dev-kurup-start.sh

My site was already around 4.6.4, so I didn't run the 4.6.3-4.6.4 upgrade script.

I just loaded up my before-upgrade DB and got this:

testkurup=# select * from persons where person_id=0;
 person_id | first_names  | last_name
-----------+--------------+-----------
         0 | Unregistered | Visitor
(1 row)
 
testkurup=# select * from parties where party_id=0;
 party_id | email | url
----------+-------+-----
        0 |       |
(1 row)

So, I think you're right - you need to start around 4.6-4.6.1 where the party with party_id 0 gets created.

Just found a problem with the upgrade. apm_package_version__delete and apm_package_version__copy were changed around 5.0d9, but the changes didn't get into an upgrade script. I've committed the changes to the upgrade script on the 5.0 branch, but if you've already upgraded, you need to 'create or replace' those 2 functions.

Sorry to flood this thread, but found another one. Running the auth_driver_get_param_values test (in acs-authentication) fails with this error:

ERROR:  duplicate key violates unique constraint "auth_driver_params_authority_id_key"
 
SQL:             
            insert into auth_driver_params (authority_id, impl_id, key, value)
            values ('12797', '12891', 'SnapshotURL', '0639DC91D')

My auth_driver_params table has a unique constraint on (authority_id, impl_id) whereas the version in 5.0 has a pk constraint on (authority_id, impl_id, key). The change is here. I only discovered this error by running the automated test - the system works fine otherwise.

I think this change happened between 5.0d4 and 5.0d5, but there's no upgrade script with that name. Here's the change that needs to be made:

alter table auth_driver_params drop constraint auth_driver_params_authority_id_key;
alter table auth_driver_params add constraint auth_driver_params_pk primary key (authority_id,impl_id,key)

Is it OK for me to create an upgrade-5.0d4-5.0d5 script?

Done. I named the upgrade script 5.0.0a1-5.0.0a2 since there was an oracle upgrade script with that name that had the same changes. I also noticed that there was an upgrade script for oracle which reloaded the apm_package_version__delete and apm_package_version__copy scripts. So the only remaining issue is to make sure that acs-reference and ref-timezones get installed. This isn't a crucial issue, at least not as crucial as making sure that acs-lang and acs-auth get loaded, so I think we can just add a note to DaveB's document to load ref-timezones (which requires acs-reference).

Hazi,

Did you also load upgrade-5.0.0a1-5.0.0a2.sql? It's important, as mentioned in my post above, but it can be loaded out-of-order, if needed.

I put in another 20 hours this weekend, and managed to get my personal site to a workably 5.0 condition.  A fair amount of that time was wrestling with CVS branches and merging and whatnot.  In the two months that I've been working on it, I've repeated some steps of the process up to 20 or 30 times, so I finally caved and wrote up a script to make trial and error debugging easier.  I put it in /contrib/misc - it does most of the steps that I'm aware of in a basic upgrade.  http://cvs.openacs.org/cvs/openacs-4/contrib/misc/upgrade_4.6_to_5.0.sh?only_with_tag=HEAD

I put some time aside this weekend to do the 4.6.3 -> 5.0.0 upgrade on my peronal site. I got pretty far (note to anyone else atempting this: look at and use the script -> upgrade with documentation alone does not work at all).

Was able to get through a lot of errors, but not this one: When I try to login (step 8: If you can login, visit /acs-admin/apm and upgrade acs-kernel and acs-service-contract and uncheck the data model scripts) I get a request error and this is was the error.log says:

[21/Mar/2004:09:04:39][30040.5126][-conn2-] Error: GET http://blesius.org/register/?return%5furl=%2f
referred by "http://blesius.org/"
no value given for parameter "key" to "_"
    while executing
"_ acs-subsite.Log_In"
    invoked from within
"list [_ acs-subsite.Log_In] ok"
    invoked from within
"list [list [_ acs-subsite.Log_In] ok]"
    invoked from within
"set login_button [list [list [_ acs-subsite.Log_In] ok]]"
    ("uplevel" body line 77)
    invoked from within
"uplevel {
          # Present a login box
#
# Expects:
#   subsite_id - optional, defaults to nearest subsite
#   return_url - optional, defaults to Your..."
    (procedure "code::tcl::/web/crb/packages/acs-subsite/lib/login" line 2)
    invoked from within
"code::tcl::$__adp_stub"
    invoked from within
"if { [file exists $__adp_stub.tcl] } {

      # ensure that data source preparation procedure exists and is up-to-date
      adp_init tcl $__adp_stub
..."
    ("uplevel" body line 3)
    invoked from within
"uplevel {

    if { [file exists $__adp_stub.tcl] } {

      # ensure that data source preparation procedure exists and is up-to-date
      adp_init t..."
    (procedure "adp_prepare" line 2)
    invoked from within
"adp_prepare "
    (procedure "template::adp_parse" line 30)
    invoked from within
"template::adp_parse [template::util::url_to_file "/packages/acs-subsite/lib/login" "$__adp_stub"] [list return_url "${return_url}" no_frame_p "1" auth..."
    invoked from within
"append __adp_output [template::adp_parse [template::util::url_to_file "/packages/acs-subsite/lib/login" "$__adp_stub"] [list return_url "${return_url}..."
    ("uplevel" body line 17)
    invoked from within
"uplevel {
          set __adp_output ""

    set __adp_master [template::util::url_to_file "[ad_parameter -package_id [ad_conn subsite_id] DefaultMaster ..."
    (procedure "template::code::adp::/web/crb/packages/acs-subsite/www/regis..." line 2)
    invoked from within
"template::code::${template_extension}::$__adp_stub"
    (procedure "template::adp_parse" line 68)
    invoked from within
"template::adp_parse [file root [ad_conn file]] {}"
    (procedure "adp_parse_ad_conn_file" line 7)
    invoked from within
"$handler"
    ("uplevel" body line 2)
    invoked from within
"uplevel $code"
    invoked from within
"ad_try {
                $handler
            } ad_script_abort val {
                # do nothing
            }"
    invoked from within
"rp_serve_concrete_file [ad_conn file]"
    (procedure "rp_serve_abstract_file" line 60)
    invoked from within
"rp_serve_abstract_file "$root/$path""
    ("uplevel" body line 2)
    invoked from within
"uplevel $code"
    invoked from within
"ad_try {
        rp_serve_abstract_file "$root/$path"
        set tcl_url2file([ad_conn url]) [ad_conn file]
        set tcl_url2path_info([ad_conn url]) [ad_conn path_inf..."

Suggestions?

It is hard to visit /acs-lang/admin/load-catalog-files when I can not login.

I already tried what Robert mentioned above (loading /foo.tcl with lang::catalog::import -locales [list "en_US"] in it).

Just to make sure I removed the "-locales [list "en_US"]" part so it more closely resembles /acs-lang/admin/load-catalog-files and tried it again. No luck, same error on registration.

actually, I guess you would have to handle the substitution variables as well (I should have looked at the proc before I
wrote that I guess).

Thanks, but I aborted the upgrade and restored from backups.

Going to put the two postgres versions up on different ports in parallel so I can tool with it as I have time.

Here is an improved script from Jeff (for posterity)

rename _ original_
proc _ {{key {}} {vars {}}} {
  if {[string is space $key]} {
    return NULL_KEY
  }
    return [uplevel [list original_ $key $vars]]
}

Round two, coming soon to a forum near you.

I managed to work past my problem, using Robert Gaszewski's amendment in his post above (Dec 15 2003 11:59:44).

I have found more files that need to be deleted when upgrading from 4.6.3 (some for duplicate proc definitions on initialisation):

• acs-templating/resources/lists
• acs-templating/tcl/list-procs.tcl
• acs-lang/tcl/lang-procs*
• acs-templating/resources/forms/standard-lars.adp
That last file was preventing me from logging in on my system. Now I'm going to try and upgrade some of the packages on my system.

From what I have seen so far, any older files lying around the file system in the core directories result from files moving, being split up or renamed, and they probably shouldn't be there. They are the files with the old dates (if you just copied the new OpenACS on top of your old installation).

Chris, did you install tDOM?

I have managed to get to 5.0.0 (from 4.6.3) on my test server at least. Not sure whether I want to go to 5.0.4 - not sure there's any reason for me to upgrade.

Some things to note:

• I couldn't find a link to /acs-admin/apm/ on the acs-admin page, just a link to /acs-admin/install/, which appears to have different options.
• I had to untick the 4.6.2-4.6.3 upgrade sql script when updating acs-messaging to v5.0.0.
The "install tarball over the top of existing directory" advice in the docs (if you aren't using CVS) isn't the most subtle of approaches, and I did some pruning as above. Probably the best thing to do would be prune the directories that have replacement files first (effectively doing what CVS does). Ideally you'd use CVS.

Thanks for that comment, having upgraded to 5.0.4, blogger is no longer displaying html entries as text.

I am now having problems putting links in general comments on my test server, is this a known bug?:

Problem with Your Input
We had a problem processing your entry:

    * The attribute 'href' is not allowed for a tags

Not allowing href.

I had the same problem.....

Kernel Parameters
Antispam
AllowedAttribute

Add href.  I also added src and target.

I fixed this problem by manually loading the 1.3-1.5 and 1.5-1.6 scripts in the sql/postgresql/upgrade directory.

Here are the steps that I took to upgrade on Oracle.
http://openacs.org/forums/message-view?message_id=201394