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 How reproducible: 100 % Steps to Reproduce: 1. Do a yum upgrade 2. Try to open a new ticket in OTRS Actual results: Software error: Can't use an undefined value as a HASH reference at /var/www/otrs//Kernel/System/Ticket.pm line 3029. Additional info: 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 authentication ... [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' Traceback (6369): Module: Kernel::System::Ticket::IndexAccelerator::RuntimeDB::GetOverTimeTickets (v1.36) Line: 291 Module: Kernel::Modules::AgentTicketQueue::Run (v1.23) Line: 116 Module: Kernel::System::Web::InterfaceAgent::Run (v1.17.2.1) Line: 671 Module: ModPerl::ROOT::ModPerl::Registry::var_www_otrs_bin_cgi_2dbin_index_2epl::handler (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 line 3029.\n
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 updates. 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 for. 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.