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

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