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

Z39.50 marc21 to unimarc
by Andrea Furin 16 Feb '16

16 Feb '16

Hi. I need to import Z39.50 marc21 results in a unimarc database: is it possible? Tia andrea f.

3 2

koha 3.14.13 released
by Fridolin SOMERS 03 Nov '15

03 Nov '15

The Koha community is proud to announce the release of 3.14.13. This is a security and maintenance release and contains 2 security bugfixes. As always you can download the release from http://download.koha-community.org. Have a look at release post : http://koha-community.org/koha-3-14-13-released "Get the pie while it's hot". Regards, -- Fridolin SOMERS Biblibre - Pôles support et système fridolin.somers(a)biblibre.com

1 4

Improving Plack intranet performances (circulation module)
by Julian FIOL 20 Aug '15

20 Aug '15

Hi everyone, Using Devel::NYTProf on a Plack config, I noticed that when we checkout an item in the circulation page, there is a really long time spent creating the database schema. By adding the import of *Koha::Schema* in the *intranet.psgi* file, we can see a significant improvement of the time spent loading the circulation page. Please find here <http://www.slideshare.net/JulianFiol/koha-circulation-checkout-improvement> (in full screen) the proof of what I'm saying. I have also added the manipulations to do into the Plack <http://wiki.koha-community.org/wiki/Plack#Improving_Plack_performance> wiki. Regards, Julian FIOL

5 5

Moose vs Moo
by Paul Poulain 04 Jun '15

04 Jun '15

Hi the list, Just reading Frédéric thoughts about Moose & Moo written on bug 11190. For those who missed the IRC dev meeting yesterday, this bug was discussed yesterday : http://meetings.koha-community.org/2015/development_irc_meeting_15_april_20… I don't know which decision we must take, but I strongly think that we must all read Frédéric arguments. Maybe Moo/Moose was a good decision, maybe not. Anyway, there are not so many scripts using Moo/Moose, so we can stil change our minds. Next steps ? I'd like to have more informations. For example: * arguments in favor of Moo ? * is the argument "the overhead is cancelled by Plack persistency" valid & is it removing this argument in favor of Moo ? * I'd like to have more details about "too many important features are lost" with Moo ? *Comment # 36 <http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11190#c36> on bug 11190 <http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11190> from Frédéric Demians <mailto:frederic@tamil.fr> * Few personal notes about Moose vs Moo (just seen IRC dev meeting logs): There is an overhead using Moose for small short lived programs. But for long- running cronjob/maintenance scripts, there isn't any problem using Moose. For Koha WUI scripts, Moose start time is a problem as long as Koha operates in CGI mode. As soon as there is persistence (Plack), it isn't a problem anymore. This issue of runtime penaly due to using a large and complex library, doing a lot of stuff behind the scene, is not different with Moose and DBIx::Class I don't say DBIx::Class is bad. Moose it bad too => So let's go with Moose! I'd say both libraries share a lot of good things. I think that Moose has various advantages over other OO frameworks. It's complete, very well documented, widely used, a standard, carefully packaged for all major Linux distro. All books about the so-called "modern-Perl movement" deals with using Moose as OO. There is the Perl's famous moto: There's more than one way to do it. Applied to OO, this could conduct to chaos. There are so many ways to do OO in Perl. Code become unreadable and unreliable. Moose forces to adopt a proper and consistent OO approach. Moo try to solve a non-issue (library weight, startup time) in modern execution environments at high price: too many important features are lost. -- Paul Poulain, Associé-gérant / co-owner BibLibre, Services en logiciels libres pour les bibliothèques BibLibre, Open Source software and services for libraries

3 2

make test in new installation fails
by Hector Castro 03 Jun '15

03 Jun '15

Hi Koha fellows I was doing a new installation and "make test" FAIL me. Launchs at the end of the test make: *** [test_dynamic] Error 255 and some test give me this: t/NorwegianPatronDB.t ............... strictures.pm extra testing active but couldn't load all modules. Missing were: indirect multidimensional Extra testing is auto-enabled in checkouts only, so if you're the author of a strictures using module you need to run: cpan indirect multidimensional bareword::filehandles Someone can tell me if i did something wrong or this is a bug?. make install worked well. Regards -- Atte, Hector Castro

2 1

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