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

Koha General IRC Meeting 14 January 2015 at 10:00 UTC
by Renvoize, Martin 14 Jan '15

14 Jan '15

General reminder, there is a Koha general meeting on IRC at 10:00 UTC today. Cheers Martin Renvoize Software Engineer, PTFS Europe Ltd Content Management and Library Solutions Skype: Landline: 0203 286 8685 Mobile: 07725985636 http://www.ptfs-europe.com

1 0

Call for development news: January 2015
by kohanews 14 Jan '15

14 Jan '15

Koha Development community ~ If you have any bugs or projects you'd like us to highlight or promote in the January newsletter, please let us know. Maybe it'll attract some additional eyes, testers and sign-offs. k o h a news AT gmail dot com Thank you! -- Chad Roseburg Joanne Dillon Editors, Koha Newsletter

1 0

Call for news: January 2015
by kohanews 14 Jan '15

14 Jan '15

Fellow Koha users ~ We're collecting news for the January newsletter. Send anything noteworthy to: k o h a news AT gmail dot com News criteria: --------------------------- * News items can be of any length. * Anything and everything Koha. * Submit by the 26th. If you are working on an interesting project or development related to Koha, please let us know and we'll include it in the development section. -- Chad Roseburg Joanne Dillon Editors, Koha Newsletter

1 0

Re: [Koha-devel] 3.18 search speed
by Paul A 09 Jan '15

09 Jan '15

I wrote a few days ago that 3.18.2 appeared slow vis-à-vis our production 3.8.5: 3.8.5 3.18.2 ================================= Time to search catalogue for 's' <http://opac.navalmarinearchive.com/cgi-bin/koha/opac-search.pl?idx=&q=s> <2 secs 19 secs LAN It was suggested that I use the package rather than the tarball, and that I use NYTProf for analysis rather than ncap. I have done so and have "Profile of /usr/share/koha/opac/cgi-bin/opac/opac-search.pl for 21.3s (of 21.3s), executing 248515 subroutine calls in 592 source files and 58 string evals." The very obvious "slow" element (19.7 secs of a total of 21.3 secs) is: # spent 19.7s within Net::Z3950::ZOOM::resultset_record which was called 27 times, avg 728ms/call: # 27 times (19.7s+0s) by ZOOM::ResultSet::record at <file://///Hood/homes/paul/nytprof/ZOOM-pm-65-line.html#739>line 739 of ZOOM.pm, avg 728ms/call sub Net::Z3950::ZOOM::resultset_record; # xsub as a comparison, a mirror image of our production 3.8.5 on a *very* old box (same mysql db and same Net::Z3950::ZOOM version 1.26): # spent 73.2ms within Net::Z3950::ZOOM::resultset_record which was called 120 times, avg 610µs/call: # 120 times (73.2ms+0s) by ZOOM::ResultSet::record at <file://///Hardy/homes/paul/nytprof2/ZOOM-pm-62-line.html#739>line 739 of ZOOM.pm, avg 610µs/call sub Net::Z3950::ZOOM::resultset_record; # xsub Thoughts anyone? I can obviously supply more info from NYTProf as required e.g. both boxes reported 12 calls to Net::Z3950::ZOOM::event, with Koha 3.18 taking 237ms whereas the *very* old box needed 338ms (that's well below the difference I would expect from the hardware.) Note also that 3.8 only needed 168568 subroutine calls in 313 source files and 37 string evals. compared to 248515, 592 and 58 for 3.18 for the exact same search. The results are identical -- perhaps minor variances in the "relevance" ordering. Best -- 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>

1 0

Any bugs you want worked on?
by Chris Cormack 07 Jan '15

07 Jan '15

Hi all In a few weeks the next batch of bright young things will be participating in the catalyst open source academy. http://www.catalyst.net.nz/show-and-tell/open-source-academy Every year a team of 14-17 year olds does some work on Koha, fixing bugs, testing, etc. So in the preparation to the academy I encourage you all to tag any bugs you would like them to look at as 'academy' in bugzilla. Thanks for your help Chris -- Sent from my Android device with K-9 Mail. Please excuse my brevity.

8 8

3.18 search speed
by Paul A 07 Jan '15

07 Jan '15

I'm really looking for some help here, please, my brain (whatever is left!) is swimming in Perl code. I'm getting the notion that maybe the db conversion (3.08 => 3.18, which reported all done) missed something, or that after two years of use, there's possibly something corrupt. If not, there's maybe a "config file" that's missing somewhere with some fine detail. All perl modules are present (except 3.18 tells me that Readonly::XS (1.02) is not installed, but I have 1.05), permissions have been verified, ps -u koha shows the daemon and zebrasrv running, mysqlcheck is clean, etc. Wireshark/pcap gives (repeatable): http://koha-admin318/cgi-bin/koha/catalogue/search.pl?q=t slow (~20 secs) and finds all results absolutely perfectly but http://koha-admin318/cgi-bin/koha/cataloguing/addbooks.pl?q=t is fast (~0.7 secs) and finds all the same results plus 73 records in reservoir. Maybe addbooks.pl doesn't need this $limit (or whatever) that search.pl requires, although the results are identical So, tried Perl debug (I don't know how to input the cookie data for admin staff, so this is the opac search, times identical): koha@hood:/usr/share/koha/opac/cgi-bin/opac$ perl -d -w ./opac-search.pl ?q=t Loading DB routines from perl5db.pl version 1.39_10 C4::Tags::CODE(0xa633720)(/usr/share/koha/lib/C4/Tags.pm:73): 73: $ext_dict and $Lingua::Ispell::path = $ext_dict; DB<1> c =====> Romps instantaneously through 16 "Use of uninitialized value" warnings (snipped, basically in "value in string eq", $ENV{"SERVER_PORT"} and "value in concatenation (.) or string" in Auth.pm; $index, $_ and first mention of $limit in Search.pm) up to Use of uninitialized value $limit in concatenation (.) or string at /usr/share/koha/lib/C4/Search.pm line 1769. at /usr/share/koha/lib/C4/Search.pm line 1769. C4::Search::buildQuery('ARRAY(0xa7aaea0)', 'ARRAY(0xa7b5b58)', 'ARRAY(0xa7aaf60)', 'ARRAY(0xa7b5e58)', 'ARRAY(0xa7aa1b0)', 0, 'en') called at opac-search.pl line 473 =====> stops, no screen action, here for ~19 seconds, then resumes... Use of uninitialized value $expanded_facet in string eq at /usr/share/koha/lib/C4/Search.pm line 527. at /usr/share/koha/lib/C4/Search.pm line 527. C4::Search::__ANON__[/usr/share/koha/lib/C4/Search.pm:627](1, 25397) called at /usr/share/koha/lib/C4/Search.pm line 2567 C4::Search::_ZOOM_event_loop('ARRAY(0x72799a8)', 'ARRAY(0x72799f0)', 'CODE(0xb0b5878)') called at /usr/share/koha/lib/C4/Search.pm line 628 C4::Search::getRecords('(rk=(Title-cover,ext,r1="s" or ti,ext,r2="s" or Title-cover,p...', 's', 'ARRAY(0xa7aa1b0)', 'ARRAY(0xa7aad80)', 20, 0, undef, 'HASH(0xa8e8990)', 'HASH(0x7b80a90)', ...) called at opac-search.pl line 552 eval {...} called at opac-search.pl line 551 =====> and romps instantaneously through (snip, basically $priority (in Reserves.pm), $expanded_facet, $transfertwhen and plain vanilla "value in hash element" in Search.pm) 770 lines of "Use of uninitialized value" warnings, then completes: Status: 200 OK Set-Cookie: CGISESSID=d62edfbbd23aa65c2acea0f49974cb31; path=/; HttpOnly /... expected HTML, css, scripts, etc .../ </body> </html> The complete list of uninitialized values from $ perl -Mdiagnostics=-traceonly ./opac-search.pl ?q=t runs about 180 lines but I can supply it if required. I can possibly ghost 3.8.5 (also tarball) onto this machine, but I'd really like to get 3.18 up and running. I recognize that this install is tarball, but it's too late now to make radical changes, it's a big server with a lot of other databases and websites. Nothing new compared to our existing production box, except Ubuntu 14.04.1 LTS and Koha 3.18 Help, pointers, suggestions warmly welcomed. Thanks -- Paul

4 12

Documentation review
by Robin Sheat 06 Jan '15

06 Jan '15

I've redone the documentation about the packages. Currently it's untested, that may be a job for tomorrow. However, it'd be good to get a couple more opinions before I publish them. The audience for these is "people who have a reasonable idea of how to get around in Linux", so it's not supposed to be a total newbie guide. I'm aiming for it to have enough information for someone to know what's going on, but not so much that it becomes hard to follow, especially in the "Installation Process" section. The informational bit at the bottom can be wordier. As such, I'm mostly interested to know: * Do the instructions work (though, as I haven't tested them myself yet, I wouldn't be surprised to find an error or three in them), * are there common scenarios that it doesn't account for, and * is there useful/important information that's missing. You can find my new draft here: http://wiki.koha-community.org/wiki/Talk:Koha_on_Debian -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5FA7 4B49 1E4D CAA4 4C38 8505 77F5 B724 F871 3BDF

3 2

Koha Community Newsletter: December 2014
by kohanews 05 Jan '15

05 Jan '15

Fellow Koha users: The Koha Community Newsletter for December 2014 is here: http://koha-community.org/koha-community-newsletter-december-2014/ Many thanks to the folks who submitted articles and news to this month's newsletter. Please feel free to email us with any corrections or suggestions. Thanks! Chad Roseburg Joanne Dillon Editors, Koha Community Newsletter

1 0

Upgrading the server that runs bugzilla, (and other things)
by Chris Cormack 02 Jan '15

02 Jan '15

Hi all I'm about to upgrade my server which runs bugs.koha-community.org and download.koha-comunity.org (as well as the dashboard and a few other things). So things might disappear for a little bit, ill send another email when it's all done Chris

2 2

Inquiry regarding replication
by Mark Tompsett 02 Jan '15

02 Jan '15

Greetings, I was playing around with MySQL replication recently, and was wondering if anyone actually used it as part of their Koha setup. And if so, what purpose? Why was I playing with it? I was pondering how to handle loss of internet access to a remote host (e.g. Asia undersea cable gets cut and the Philippines is cut off from their hosted data in Amsterdam). Any ideas? GPML, Mark Tompsett

2 1