hi patrick,

i've come across some free time tonight and have tried (and failed) to
reproduce the problem.  using a clean lenny chroot, i've tried the
following:

* install otrs2 + deps + mysql, dist-upgrade, upgrade dbconfig, upgrade otrs2
* install otrs2 + deps + mysql, upgrade otrs2
* install otrs2 + deps + postgres, upgrade otrs2

in all cases, i saw the upgrade path successfully find and execute the
sql statements.  i can not verify whether or not the statements themselves
were successful, but afaict dbconfig is executing them.  in fact, even in
the log you provided:

_dbc_apply_upgrades() 2.3.
applying upgrade sql for 2.2.7-2lenny1 -> 2.3.
_dbc_apply_upgrades() 2.4.
applying upgrade sql for 2.2.7-2lenny1 -> 2.4.

and i see the same.  to make sure that this was indeed executing the
underlying commands i uncommented the "set -x" in /u/s/dbc/dpkg/common
and see that it was attempting to execute them (this is from the third
test mentioned above):

_dbc_apply_upgrades() 2.3.
applying upgrade sql for 2.2.7-2lenny1 -> 2.3.
su -s /bin/sh otrs -c "env HOME='/tmp/dbconfig-common.psql_home.RmUvDX' 
PGPASSFILE='/tmp/dbconfig-common.psql_home.RmUvDX/.pgpass' PGSSLMODE='prefer' 
psql --set "ON_ERROR_STOP=1" -q -h localhost -U 'otrs' otrs2" 2>&1.
_dbc_apply_upgrades() 2.4.
applying upgrade sql for 2.2.7-2lenny1 -> 2.4.
su -s /bin/sh otrs -c "env HOME='/tmp/dbconfig-common.psql_home.ZHjgPm' 
PGPASSFILE='/tmp/dbconfig-common.psql_home.ZHjgPm/.pgpass' PGSSLMODE='prefer' 
psql --set "ON_ERROR_STOP=1" -q -h localhost -U 'otrs' otrs2" 2>&1.


furthermore, i did a fourth test where before upgrading a created my own
upgrade file:

r...@rangda:/# cat /usr/share/dbconfig-common/data/otrs2/upgrade/pgsql/2.3.5
create table sean (id int, id_two int);

and i performed the upgrade, it was detected, and after the upgrade:

r...@rangda:/# su - postgres -c "psql otrs2 -c 'select * from sean'";
 id | id_two 
 ----+--------
 (0 rows)


so i am failing to find a problem here.  perhaps there is some bug in the
upgrade sql that causes it to fail?  or perhaps it's mysql specific?


since i'm not able to reproduce it, i'm going to reduce the severity.  if
you suspect that it is in fact a problem with the upgrade sql, feel free
to take the bug back :)


        sean

Attachment: signature.asc
Description: Digital signature

Reply via email to