- Koha-devel - lists.koha-community.org

Re: [Koha-devel] Major surprise - "automatic" upgrade
by Paul 30 Apr '13

30 Apr '13

At 12:08 PM 4/30/2013 +1200, Chris Cormack wrote: [big snip] >But as Jared says it will not do this without you entering your >database user and password, and explicitly clicking to tell it to >upgrade. It will give you the page, but it won't upgrade until you >tell it. > >The only automatic thing is it telling you you need to upgrade your database Thanks Chris (and Jared, Marcel and Mason.) That was my understanding and it functioned as expected: it "upgraded the *database* from 3.8.5 to 3.8.10" the first time after I ran './cleanup_database.pl --zebraqueue -v' -- at this point I could not log in on the staff page as "paul" (or any other staff-user), had to log in as "koha" and got: Web installer Step 3 We are upgrading from Koha 3.08.05.000 to 3.08.10.000, you must update your database Update report : Upgrade to 3.08.06.000 (3.8.6 release) done / .. / Upgrade to 3.08.10.000 (3.8.9 release) done Everything went OK, update done. Continue to log in to Koha The "worrisome mystery" is why the "upgrading from Koha 3.08.05.000 to 3.08.10.000" took place at all! Let me be clear, it took place without my knowledge and without my "informed" consent. I say "informed" because, when I ran './cleanup_database.pl --zebraqueue -v' I was obviously logged in as user=koha, but the '-v' verbose gave me no warning whatsoever that it had found either the tarred 3.8.10 on the root of the server or the untarred 3.8.10 at /home/paul/ -- but equally obviously user=koha has the necessary permissions to carry out the "system upgrade." It is obvious that the 'cleanup' Perl script provoked the system upgrade which took a couple of hours (no CLI messages whatsoever), as the database upgrade took just a couple of seconds. This is reproducible: I restored the 3.8.5 from backup, and can confirm the update to 3.8.10. after running './cleanup_database.pl --zebraqueue -v'. The other elements of the same script - logs, mail, import and sessions do not provoke the system upgrade. I will now restore the backup again, delete the tarred and untarred 3.8.10s and expect no upgrade :=) The mystery remains ... Thanks and regards all round, Paul --- Maritime heritage and history, preservation and conservation, research and education through the written word and the arts. <http://NavalMarineArchive.com> and <http://UltraMarine.ca>

2 1

zebraidx segfault
by Waylon Robertson 30 Apr '13

30 Apr '13

zebraidx[11218]: segfault at 8000000d ip b65cb24e sp bfa28040 error 4 in libc-2.7.so[b6559000+155000] this occurs while im trying to do a full reindex / reset.... so the reindexing does not reach completion. help please! anyone got a clue? Linux manzoma-prod 2.6.26-2-686 #1 SMP Sun Mar 4 22:19:19 UTC 2012 i686 GNU/Linux total used free shared buffers cached Mem: 2022 1973 49 0 17 1830 just in case its relevant.

4 3

Re: [Koha-devel] Major surprise - "automatic" upgrade
by Mason James 30 Apr '13

30 Apr '13

On 2013-04-30, at 11:16 AM, Mason James wrote: On 2013-04-30, at 9:38 AM, Paul wrote: > Hi Jared, > > At 10:41 AM 4/28/2013 -0400, you wrote: >> Paul, >> >> I've looked at the code in cleanup_database.pl (and search.pl), and can't see any obvious reason to "redirect to Installer." >> >> So -- what has happened? Â Can I dump the cleaned db back into production? What are the specific changes 3.8.5 to 3.8.10 that required "updating"? >> >> >> The redirect is because you had a newer version of the code than the database was run on. > > Thanks for your reply, but this is worrisome. I had at {server}/ a tarred 3.8.10. I had at {server}/home/paul/ an untarred 3.8.10 (for .dif purposes.) > >> Koha doesn't have any support for automatic upgrades, so I guess you must have untarred 3.8.10 at some point. > > [see above] O.K. it's not "automatic" but it did in fact run automatically without my permission. I ran: for the record Paul, Koha is *designed* to do this very thing it forces the web-update page, if the database is older than the codebase (as yours is) this is a 'feature' to stop stupid humans from corrupting their Koha databases, when attempting to run mismatched codebases and db versions

3 2

Re: [Koha-devel] Major surprise - "automatic" upgrade
by Paul 30 Apr '13

30 Apr '13

Hi Jared, At 10:41 AM 4/28/2013 -0400, you wrote: >Paul, > >I've looked at the code in <http://cleanup_database.pl>cleanup_database.pl >(and <http://search.pl>search.pl), and can't see any obvious reason to >"redirect to Installer." > >So -- what has happened? Â Can I dump the cleaned db back into production? >What are the specific changes 3.8.5 to 3.8.10 that required "updating"? > > >The redirect is because you had a newer version of the code than the >database was run on. Thanks for your reply, but this is worrisome. I had at {server}/ a tarred 3.8.10. I had at {server}/home/paul/ an untarred 3.8.10 (for .dif purposes.) >Koha doesn't have any support for automatic upgrades, so I guess you must >have untarred 3.8.10 at some point. [see above] O.K. it's not "automatic" but it did in fact run automatically without my permission. I ran: './cleanup_database.pl --zebraqueue -v' and Koha *updated* from 3.8.5 to some variant of 3.8.10. Note the '-v' -- but it sat there running with nothing "verbose." >You can take a look at the release notes for the versions between 3.8.5 >and 3.8.10:Â ><http://git.koha-community.org/gitweb/?p=koha.git;a=tree;f=misc/release_note…>http://git.koha-community.org/gitweb/?p=koha.git;a=tree;f=misc/release_note… I can find no mention of 'db' or 'database' >Based on the "Update report" you shared, it doesn't look like there were >any actual database changes in between versions 3.8.5 and 3.8.10, but I >couldn't say that with certainty without checking (you can take a look at >the release notes linked above, and by reviewing the >installer/data/mysql/<http://updatedatabase.pl>updatedatabase.pl file on >the 3.8.10 installation). I have looked at it, but question why it would be triggered? >The update is trigged whenever you have an older version of the database >than the code, By what? And "the code" in what? The relevant code in cleanup_database.pl is "$sth2 = $dbh->prepare("DELETE FROM zebraqueue WHERE id=?");" a simple MySQL directive. Why does 'cleanup_database.pl' even look for '<http://updatedatabase.pl>updatedatabase<http://updatedatabase.pl>.pl' and|or "other/more recent" versions of "the code"? The bottom line is "why does a simple .pl using TRUNCATE lead to an upgrade"? >Most likely downgrading to 3.8.5 would not cause any problems at all, "Downgrading" is new to me. Do you mean "restore system from backup"? Best - Paul >even if there were database changes, but it's always a good idea to check. > >Regards, >Jared > >-- >Jared Camins-Esakov >Bibliographer, C & P Bibliography Services, LLC >(phone) +1 (917) 727-3445 >(e-mail) <mailto:jcamins@cpbibliography.com>jcamins(a)cpbibliography.com >(web) <http://www.cpbibliography.com/>http://www.cpbibliography.com/

2 1

Fwd: Canadian Library Association Information Request
by Paul Poulain 30 Apr '13

30 Apr '13

Hi Koha-devel, We recieved through our website the following message. As I suspect BibLibre was not the only one to get it, did someone answer ? (and what kind of answer) ? -------- Message original -------- Sujet: [site biblibre] Canadian Library Association Information Request Date : Wed, 17 Apr 2013 15:29:57 +0200 De : cla.accessibility.project(a)gmail.com Pour : commercial(a)biblibre.com Robin Gallagher a envoyé un message via le formulaire de contact sur http://www.biblibre.com/fr/contact. Dear BibLibre Representative: I am contacting you on behalf of the Canadian Library Association's Government Library and Information Management Professionals Network. Canadian federal government departments have been ordered to modify their websites and web applications to comply with the Web Content Accessibility Guidelines (WCAG) 2.0 by July 2013. Within the federal library community, there has been some concern about compliance of library management systems to this standard. As a result, the Canadian Library Association (CLA) is conducting a survey of major vendors of library and information management systems on the compliance of their products to either the Web Content Accessibility Guidelines (version 2.0) and/or Section 508 of the US Rehabilitation Act, as well as plans they may have to update their products to comply. The information collected in this project will be published to the Network blog and communicated to the CLA membership. Could you direct me to the member of your organization best suited to answer a few questions about how your systems meet -- or intend to meet -- accessibility standards? Many thanks, Robin Gallagher Project Manager, CLA Accessibility & Library Management Systems Project Email: cla.accessibility.project(a)gmail.com Report as inappropriate: http://www.biblibre.com/en/mollom/report/session/1304178e5e9c410b0b

3 3

Please create a page for Koha Live DVD read me file
by Vimal Kumar V. 29 Apr '13

29 Apr '13

Dear Friend, Please create a wiki page for Koha Live DVD read me file. And find the content for the link in the following page. https://docs.google.com/document/d/1EABuloyweEEX76e6Tvr0MGuWbSG_4UQB3-mizIL… I could not create a page because of a technical issue here. Please add the content of the attached file in the page. Regards, -- Vimal Kumar V. Mahatma Gandhi University Library Kottayam, Kerala- 686 560 Web: http://www.vimalkumar.info Blog: http://linuxhalwa.blogspot.com http://kohageek.blogspot.in --------------------------------------------------------------------------- "I forget what I was taught. I only remember what I have learnt" -Patrick White

3 3

Major surprise - "automatic" upgrade
by Paul 28 Apr '13

28 Apr '13

Can someone please help me understand what on earth has happened? Tarball Koha 3.8.5 on 64-bit Ubuntu 12.04.2 (sandbox, thank goodness, exact mirror of our production box opac.navalmarinearchive.com) Yesterday, to avoid downtime on the production box, I used the sandbox for a "manual" cleanup of the mirror db using cleanup_database.pl intending to dump the "cleaned" db back into production. Import, mail. sessions and logs went as expected, but: koha@hardy:/usr/share/koha/bin/cronjobs$ ./cleanup_database.pl --zebraqueue -v Zebraqueue purge triggered for 30 days seemed to hang so I left it overnight, and this morning got: 131575 records were deleted. Done with zebraqueue purge. A fresh MySQL dump showed that this had worked (dump size down by more than 50%) But - OPAC was "down for maintenance" and logging into admin from a workstation gave me "Web installer Step 3 We are upgrading from Koha 3.08.05.000 to 3.08.10.000, you must update your database." So (maybe idiotically) I clicked the "update" and got: Updating database structure Update report : Upgrade to 3.08.06.000 (3.8.6 release) done Upgrade to 3.08.07.000 (3.8.7 release) done Upgrade to 3.08.08.000 (3.8.8 release) done Upgrade to 3.08.09.000 (3.8.9 release) done Upgrade to 3.08.10.000 (3.8.9 release) done Everything went OK, update done. Continue to log in to Koha Now, "About Koha" reports Koha version: 3.08.10.000 !!!!!!! There is a copy of koha-3.08.10.tar.gz at root on this box (I was thinking of experimenting, but never even got around to untarring it): paul@hardy:/$ find / -iname '*3.08.10*' /koha-3.08.10.tar.gz paul@hardy:/$ There appears to be nothing in syslog, but Koha has definitely "upgraded something" and koha-error_log shows a whole bunch of errors, starting with the requirement for db update: [Sun Apr 28 12:31:16 2013] [error] [client "me"] [Sun Apr 28 12:31:16 2013] search.pl: Database update needed, redirecting to Installer. Database is 3.0805000 and Koha is 3.0810000 at /usr/share/koha/lib/C4/Auth.pm line 593. and continuing with a whole bunch of "languages" along the lines of: [Sun Apr 28 12:31:17 2013] [error] [client "me"] [Sun Apr 28 12:31:17 2013] install.pl: Use of uninitialized value $current_language in string eq at /usr/share/koha/lib/C4/Languages.pm line 317. which probably relate just to the database structure. The log shows no trace of untarring koha-3.08.10.tar.gz and, quite frankly, given that all the log entries span 1 min. 44 secs, I just don't believe that the sandbox (a fairly slow, early 64-bit box) could have done a complete version upgrade. I've looked at the code in cleanup_database.pl (and search.pl), and can't see any obvious reason to "redirect to Installer." So -- what has happened? Can I dump the cleaned db back into production? What are the specific changes 3.8.5 to 3.8.10 that required "updating"? Before I go blundering around like a bull in a chinashop, I'd really appreciate some assistance. Thanks and best regards, Paul --- Maritime heritage and history, preservation and conservation, research and education through the written word and the arts. <http://NavalMarineArchive.com> and <http://UltraMarine.ca>

2 1

String freeze for Koha 3.12
by Jared Camins-Esakov 26 Apr '13

26 Apr '13

Hello. The string freeze for Koha 3.12 will begin on May 1, next Wednesday. Any patches with string changes need to be written, signed off, and QAed before then. The absolute deadline for anything other than security fixes is 6am EST on Wednesday, May 1*. Regards, Jared Camins-Esakov [*] http://www.timeanddate.com/worldclock/fixedtime.html?msg=Koha+3.12+string+f… -- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins(a)cpbibliography.com (web) http://www.cpbibliography.com/

1 0

Encoding issues
by Marcel de Rooy 25 Apr '13

25 Apr '13

Hi all, With the push of bug 6554 http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6554 in master, there is some interest in fixing some remaining encoding issues as a side-effect. I just opened a wiki page to get a complete picture. It is just a draft and needs further extension. It is here: http://wiki.koha-community.org/wiki/Handling_UTF8_in_development Your assistence is appreciated! Thx Marcel PS There is a discussion going on to revert bug 6554 for the 3.12.x branch. I would support that too. On master we have sufficient time to catch the remaining side-effects in a some further corners of Koha.

1 0

Old bugs to check
by MJ Ray 25 Apr '13

25 Apr '13

Would you check some of these rather old bugs to suggest what to do, please? Maybe some can be RESOLVED FIXED by now or need a question. Please leave your reply on the bug web page - I might not see replies to this mail. Ideally, tell irc.oftc.net #koha know that you're looking at a bug. http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6396 Irregular serials cannot be received http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5541 links show title twice if 856$y and 856$3 populated http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5779 can't add funds to budget that has past http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3578 different_IP auth is too strict for many services http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6262 overdues warning label http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2533 Send OPAC user record change requests to branch email address http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5968 News display on opac-main.pl is particular about browser language settings http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6266 Ordering from staged file gives perl error when no budget defined http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6341 Request for multiple calendar support option http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5272 can't import just patron attributes http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3451 No facets for tags search http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5535 users tags not appearing until approved http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5198 HOLDPLACED being logged in patron messages http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2465 availability of a reserved book http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5807 Add collection code to circulation rules http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2384 Add location group as search limit in OPAC http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5512 Display Published Date with Received Date http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4281 reports dictionary limited to only 1 field http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5938 Maximum number of issues across a family group -- Email robot driven by MJ Ray (slef), member of www.software.coop, http://koha-community.org supporter, web and library systems developer. Available for hire (including development) at http://www.software.coop/

1 0