Red Hat Bugzilla – Bug 235939
otrs-2.1.5-1.fc5.noarch update breaks previous installation of otrs-2.0.4-3.fc5.noarch
Last modified: 2007-11-30 17:12:01 EST
Description of problem:
Latest update that has been released with Fedora Core 5 extras breaks my
installation of OTRS.
Version-Release number of selected component (if applicable):
previous version - 2.0.4-3.fc5
updated version - 2.1.5-1.fc5
Steps to Reproduce:
1. Do a yum upgrade
2. Try to open a new ticket in OTRS
Can't use an undefined value as a HASH reference at
/var/www/otrs//Kernel/System/Ticket.pm line 3029.
Some Apache log excerpts:
1) When I login to OTRS (the main page gets displayed correctly and no errors
are visible afterwards):
==> error_log <==
[Tue Apr 10 23:35:13 2007] [notice] Digest: generating secret for digest
[Tue Apr 10 23:35:13 2007] [notice] Digest: done
[Tue Apr 10 23:35:13 2007] [notice] mod_python: Creating 4 session mutexes based
on 256 max processes and 0 max threads.
[Tue Apr 10 23:35:13 2007] [notice] Apache configured -- resuming normal operations
[Tue Apr 10 23:35:34 2007] -e: DBD::mysql::st execute failed: Unknown column
'q.calendar_name' in 'field list' at /var/www/otrs//Kernel/System/DB.pm line 436.
ERROR: OTRS-CGI-10 Perl: 5.8.8 OS: linux Time: Tue Apr 10 23:35:34 2007
Message: Unknown column 'q.calendar_name' in 'field list', SQL: 'SELECT st.id,
st.escalation_start_time, q.escalation_time, st.ticket_priority_id, q.name,
q.calendar_name FROM queue q, ticket st WHERE q.escalation_time != 0 AND
st.ticket_state_id IN ( 1, 4, 6, 7, 8 ) AND q.id = st.queue_id AND
q.group_id IN ( 4, 1, 3, 2, 9, 8, 12 ) AND st.ticket_lock_id IN ( 1, 3 ) ORDER
BY st.ticket_priority_id DESC, st.escalation_start_time ASC LIMIT 40'
Module: Kernel::Modules::AgentTicketQueue::Run (v1.23) Line: 116
Module: Kernel::System::Web::InterfaceAgent::Run (v126.96.36.199) Line: 671
(v) Line: 47
Module: (eval) (v1.81) Line: 203
Module: ModPerl::RegistryCooker::run (v1.81) Line: 203
Module: ModPerl::RegistryCooker::default_handler (v1.81) Line: 169
Module: ModPerl::Registry::handler (v1.99) Line: 30
[Tue Apr 10 23:35:34 2007] -e: DBD::mysql::st fetchrow_array failed: fetch()
without execute() at /var/www/otrs//Kernel/System/DB.pm line 473.
2) After I try to create a new Phone ticket:
==> ssl_error_log <==
[Tue Apr 10 23:35:55 2007] [error] [Tue Apr 10 23:35:55 2007] -e: Can't use an
undefined value as a HASH reference at /var/www/otrs//Kernel/System/Ticket.pm
Did you follow the directions in /usr/share/doc/otrs-2.1.5/UPGRADING ?
No, but I doubt any user/sysadmin expects that an official update that doesn't
traverse distribution release versions would break a working installation and
require manual intervention. This kind of beats the purpose of e.g. nightly yum
Most packages in core and extras don't have such problems, post-install scripts
usually take care of making sure the installation works after the update.
So such situation isn't expected and is likely to be seen as a bug by any user.
If you think RPM should be making database calls You think wrong. I'm sorry
your OTRS installation broke a little bit but thats what the UPGRADING files are
When upstream changes the database and doesn't include an automated upgrade
that's their decision. Feel free to query them for a fix but the fact is I
don't run the OTRS user with the ability to alter its db schema. Therefore
there is no technical way for this request to happen short of asking upstream
never to change the scheme ever.