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

Koha and mod perl
by Gaetan Boisson 02 Jun '15

02 Jun '15

Hello all, has anyone set up mod perl on a koha instance? And if so, are there any bugs or issues doing this? It seems we tried it some time ago, and this page says there are issues, but doesn't give more details: http://wiki.koha-community.org/wiki/Koha_Tuning We have been testing it today and i haven't seen serious issues so far. From the wiki it seems the latest tests were made 4 years ago, so it's possible things have changed in Koha and mod_perl. It's something worth trying at any rate, because the mod perl documentation claims "400% to 2000%" performance boosts. It definitely feels *much* faster on our test instance right now. -- Gaetan Boisson Chef de projet bibliothécaire BibLibre 06 52 42 51 29 108 avenue Breteuil 13006 Marseille gaetan.boisson(a)biblibre.com

4 5

Packaging of Koha dependencies
by Robin Sheat 02 Jun '15

02 Jun '15

With my package manager hat on, I want to introduce some general guidelines for adding dependencies to the Koha project, because some recent approaches have been problematic and sucked up a lot more time than they should have. Apologies in advance for the giant wall of text. It's late afternoon on a Friday. First, the easy case: * If the dependency you want to add is in wheezy and jessie (being aware of versions) already, then that's fine. We try not to introduce these within a monthly release unless there's a good reason, but for something going into a new major release, that's totally OK. Otherwise: * Figure out the minimum version that'll work. Don't just add the latest version because that's what you grabbed out of CPAN. If it works with a more commonly distributed version then you've saved many people a lot of time by declaring that (not just me, but anyone trying to use it on other distributions too.) A bit more guidance on that here: http://mail.librecat.org/pipermail/librecat-dev/2015-May/000380.html * If you can reasonably avoid adding a dependency, do it. It's not always possible, but some things don't need to be there because it saves a few minutes of coding. If it saves you hours, then it's probably reasonable to add it. * Small, standalone modules will in most cases be easy to deal with. Things with many complex dependencies will not. The latter may cause backporting the module to be impossible, in which case it just won't happen. * Point it out to me early, not right before it's going to be released. On one hand, I can tell you then if it's going to be impossible. On the other, all the testers and QA people will have access to the dependency if it's already in the repo when it comes time for signing off, making their lives that much easier. If I hear that we need a package once it's gone through everything (and too often it's QA that points this out to me, that's really bad), your patch _will_ be delayed and may miss a release. * Check the copyright. I'm not going to redistribute a module just because it's in CPAN. As far as I can tell, being in CPAN doesn't cause a default license to be applied, so if the module doesn't have something that says that it can be redistributed, the default position is that it is illegal to redistribute it. * All modules that I create are submitted into Debian. If they don't get into Debian, then they don't get into Koha. Debian is pretty strict, so in turn I have to be pretty strict. The reason for this is, in part, that it means that the amount of modules I have to care about won't (hopefully) just keep getting bigger, there's a chance it'll go down too over time. * Most modules that are unpackaged have issues that prevent them going into debian. These are found by running the "lintian" tool over a package. Usually they're quick and easy. Sometimes there are a lot of them. If there are a lot of them, I'm going to delegate the fixing of them to the people who want this module in. I'm happy to coach you through this process and handle the basic things, but I don't always have time to spend days wrangling your dependency into a good state. * I wrote a guide to help you get started here: http://wiki.koha-community.org/wiki/Building_Debian_Dependencies * If you don't help out with this when necessary, your dependency is likely to go to the bottom of my packaging queue. If you do, it'll probably be near the top :) * To get a feel for something being easy to package, do: dh-make-perl --pkg-perl --build --cpan Module::Name with the lintian config set up from that wiki page. If you get only a few lintian errors (and some you'll see in every case), and you get a .deb file out then end, that's a good sign. Even better if from there you tidy it up, commit it to alioth, and ask me on the relevant bug to have a look over it for you :) There's a fair bit of stuff here, but essentially the purpose boils down to three points: 1. my time is limited and some of this is taking away from real client work that is needed for Catalyst to be able to sponsor me to do this in the first place, 2. I don't want to be a bottleneck that slows down your work getting into Koha, and 3. the more people that have some experience with this stuff, the more people can help things get done. 1. You can also get your name in lights as a contributor to the Debian project this way. I hope you got this far! Thanks, -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5FA7 4B49 1E4D CAA4 4C38 8505 77F5 B724 F871 3BDF

3 4

Installing from scratch... one more package hosted please?
by Mark Tompsett 02 Jun '15

02 Jun '15

Greetings, Backstory: I felt like trying a base git install from scratch, just to see what the time was like. I torrent downloaded a net install ISO of Debian 8 (Jessie), set it up in VirtualBox, git cloned the Koha source, bit-bz, and qa-test-tools, and ran the install process on the Koha source. I discovered that if you forget to give permissions on the DB, but create the user and password, that the failure of set NAMES ‘utf8’ is totally not indicative of the real problem. I think there’s a patch idea in there somewhere. Once the Koha was installed, I then attempted to get the qa test tools working. And that led me to installing dh-make-perl just to get libtest-perl-critic-progressive-perl_0.03-1_all.deb installed. Inquiry: Can we please host libtest-perl-critic-progressive-perl_0.03-1_all.deb and/or get it somehow pushed up to Debian? GPML, Mark Tompsett

2 1

Koha 3.16.11 released
by Mason James 31 May '15

31 May '15

Hi Folks, The Koha release team are proud to announce the release of Koha 3.16.11. This is a bugfix/maintenance release As always, the best option is to upgrade using the debian packages, at debian.koha-community.org, Otherwise you can download the tarball at download.koha-community.org Full release notes are here http://koha-community.org/koha-3-16-11-released/ cheers, Mason

1 0

Sort by title. Based only on Title or also on Title-cover ?
by Tajoli Zeno 29 May '15

29 May '15

Hi, reading from etc/zebradb/marc_defs/marc21/biblios/biblio-koha-indexdefs.xml I see that from 245 $a are crerated two indexes: Title and Title-cover: <index_subfields tag="245" subfields="a"> <target_index>Title-cover:w</target_index> <target_index>Title-cover:p</target_index> <target_index>Title-cover:s</target_index> <target_index>Title:w</target_index> <target_index>Title:p</target_index> <target_index>Title:s</target_index> </index_subfields> Sort by title (A-Z) and (Z-A) in opac are based only on 'Title' Zebra index or also on Title-cover ? It is not clear for me. Bye Zeno Tajoli

2 1

search speed
by Gaetan Boisson 29 May '15

29 May '15

Hello again all, looking at speed issues there is one thing that i don't understand, and i feel some well versed developpers might have a better idea of what is happening. If you query zebra directly on the server, it's blazingly fast, no matter how big your database and how many results you get. (At least the difference is negligible, and we still get very low response times.) But if you do a search in Koha that brings 20 000 results, it's usualy 4 times faster (maybe more, sorry i don't have precise metrics here) than a search that brings up 1 000 000 results. Is it consistent with your experience? If it is, what would be the reason for this? My understanding is that the search code asks zebra for the first n records to display on the first page, and that facets are based on a number of result way below 20 000 anyway, so the total number of results shouldn't really make a difference. -- Gaetan Boisson Chef de projet bibliothécaire BibLibre 06 52 42 51 29 108 avenue Breteuil 13006 Marseille gaetan.boisson(a)biblibre.com

6 7

getFrameworkLanguages
by Mark Tompsett 28 May '15

28 May '15

Greetings, Indranil Das Gupta found this painful to see typo in getFrameworkLanguages: 'native_descrition'=>$language_set->{language_native_description}. I told him, tweaking C4/Languages requires writing a test (good rule of thumb). So, I wake up, and discover no tests were yet written, and I was itching for a sign off. So, I attempt and discover the hole is deeper than initially thought. In fact, Indranil Das Gupta pointed out to me that it doesn't seem to be used anywhere. mtompset@debian:~/kohaclone$ git grep getFrameworkLanguages C4/Languages.pm: memoize_memcached('getFrameworkLanguages' , memcached => C4::Context->memcached); Part of an export -- C4/Languages.pm: &getFrameworkLanguages More exporting -- C4/Languages.pm: @EXPORT_OK = qw(getFrameworkLanguages getTranslatedLanguages getAllLanguages getLanguages get_bidi regex_lang_subtags language_get_description accept_language getlanguage); POD stuff -- C4/Languages.pm:=head2 getFrameworkLanguages POD stuff example -- C4/Languages.pm: my $languages = getFrameworkLanguages(); Actual function head -- C4/Languages.pm:sub getFrameworkLanguages { As you can tell I didn't comment on one piece: that memoize_memcached line. Is there another thing to trace to figure out if it is used in the memoize logic somewhere, or is it safe to remove this function? Feedback appreciated. What bug 14284 becomes is dependent on feedback. http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14284 GPML, Mark Tompsett

5 5

Call for Dev Meeting June 3
by Tomas Cohen Arazi 28 May '15

28 May '15

Hi everyone, starting the 3.22 cycle i'd like to keep a 3-week frecquency for dev meetings. Lots of big stuff is being worked by different people/teams so having a regular/deterministic schedule for the meetings might be handy to keep communicated. Next meeting will be held next wednestady, with the already used two-session schema. The agenda will look short at first sight, but we all know it is not :-D http://wiki.koha-community.org/wiki/Development_IRC_meeting_3_June_2015 =Short= Day: June 3 2015 Time: - Part 1: 15:00 UTC - Part 1: 22:00 UTC All comments are welcome. -- Tomás Cohen Arazi Prosecretaría de Informática Universidad Nacional de Córdoba ✆ +54 351 5353750 ext 13168 GPG: B76C 6E7C 2D80 551A C765 E225 0A27 2EA1 B2F3 C15F

1 0

Re: [Koha-devel] search speed
by Paul A 28 May '15

28 May '15

At 07:52 AM 5/28/2015 -0300, Tomas Cohen Arazi wrote: >El 28/5/2015 4:43 a. m., "Fridolin SOMERS" <fridolin.somers(a)biblibre.com> >escribiÃ³: > > > > Could this mean one should not get records from Zebra but directly from > database ? If getting the id of search results without getting the full > record is possible. > >It is possible. But we should evaluate the trade-off from preparing the >record for display too. Because for indexing we do lots of stuff to the >record, stuff that should be done on rendering time with such a change. Interesting. The rendering is only on 20 records, while the search is on tens or hundreds of thousands of records. It would obviously be a major exercise, but the trade-off would be enormous *if* it avoids the overload on the single core of the CPU (multi-threading across cores is, from what I was able to found out, just an impossible dream.) Facets are a search enhancement with enormous potential, but when the time required increases from a few tenths of a second to 20 seconds+, we felt we could not put it into production -- our users tend to want "instant gratification." Best -- Paul > > > > Le 27/05/2015 21:02, Paul A a Ã©crit : > >> > >> At 08:29 PM 5/27/2015 +0200, Gaetan Boisson wrote: > >>> > >>> Well as i said, the time is not the same depending on the number of > >>> results, but in both cases, the number of results is anyway much > >>> higher than the number of records taken into consideration for facets. > >>> > >>> Your investigation indicates that: > >>> > >>> In ZOOM->record, the time is spent in > >>> Â my $_rec = Net::Z3950::ZOOM::resultset_record($this->_rs(), $which); > >>> > >>> Maybe it's worth having a deeper look in this. > >> > >> > >> I looked into this to some extent in January this year; facets in 3.18 > >> <http://navalmarinearchive.com/z_koha/search_speed_data.html> appeared > >> to be a limiting factor as it "swamped" one CPU core (and NYProf showed > >> this to be from ZOOM - see > >> <http://navalmarinearchive.com/z_koha/nytprof_318_s/index.html> > >> > >> Regards -- Paul > >> > >> > >>> Le 27/05/2015 12:56, Jonathan Druart a ÃÂ©crit : > >>>> > >>>> Gaetan, > >>>> have a look at the metrics on bug 13665. > >>>> > >>>> 2015-05-27 11:45 GMT+01:00 Gaetan Boisson <gaetan.boisson(a)biblibre.com>: > >>>>> > >>>>> Â Hello again all, > >>>>> > >>>>> looking at speed issues there is one thing that i don't understand, > >>>>> and i > >>>>> feel some well versed developpers might have a better idea of what is > >>>>> happening. > >>>>> > >>>>> If you query zebra directly on the server, it's blazingly fast, no > >>>>> matter > >>>>> how big your database and how many results you get. (At least the > >>>>> difference > >>>>> is negligible, and we still get very low response times.) > >>>>> > >>>>> But if you do a search in Koha that brings 20 000 results, it's > >>>>> usualy 4 > >>>>> times faster (maybe more, sorry i don't have precise metrics here) > >>>>> than a > >>>>> search that brings up 1 000 000 results. > >>>>> > >>>>> Is it consistent with your experience? > >>>>> > >>>>> If it is, what would be the reason for this? My understanding is > >>>>> that the > >>>>> search code asks zebra for the first n records to display on the > >>>>> first page, > >>>>> and that facets are based on a number of result way below 20 000 > >>>>> anyway, so > >>>>> the total number of results shouldn't really make a difference. > >>>>> > >>>>> -- > >>>>> Gaetan Boisson > >>>>> Chef de projet bibliothÃÂ©caire > >>>>> BibLibre > >>>>> 06 52 42 51 29 > >>>>> 108 avenue Breteuil 13006 Marseille > >>>>> gaetan.boisson(a)biblibre.com

1 0

Install Koha 3.20 with Single Command at Ubuntu 14.04 LTS
by DP Tripathi 28 May '15

28 May '15

Dear All, Greetings! Now, Install Koha 3.20 with one single command at Ubuntu 14.04 LTS Just follow the instructions. I assume that you have installed Ubuntu 14.04 LTS in your system and it is connected with Internet. Step 1: First download the file at www.librarianguide.co.in/install_koha.sh Step 2: Wherever you keep the file, just give permission with following command. I assume the file is at /home/library root@nitr/home/library# chmod +x install_koha.sh (press enter) root@nitr/home/library# ./install_koha.sh (press enter) It will start installation. Just follow the instruction and provide necessary inputs. Step 3: After installation of everything it will open window with nano editor. Just change the port in Intranet (8000), save (ctrl+x). Now, it will open Firefox automatically with Koha Web Installer. User Name: koha_library Password: Note down the password from (/etc/koha/sites/library/koha-conf.xml) file. The password will be at the bottom of file in <config> section. Enjoy Koha! Thanks, DP Tripathi NIT Rourkela

4 3