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

AWS access requires signing
by Krishnan M 15 Jun '09

15 Jun '09

Hello, I received the following reminder since i subscribed to AWS for book covers in Koha. Does this mean code changes are needed? i haven't had time to take a look myself, but the deadline is not very far for non-trivial changes and testing Regards,krishnan Product Advertising API ReminderMonday, 15 June, 2009 8:38 AMFrom:"Amazon.com" <no-reply(a)amazon.com>To:"library(a)mpatta.com" <library(a)mpatta.com>Dear Product Advertising API Developer,We wanted to remind you that all Product Advertising API developers will be required to authenticate all calls to the Product Advertising API by August 15, 2009. We noticed that requests with your AWS Access Key ID are not being signed and, while you have more than 60 days until the date on which authentication is required, we are, as a courtesy, sending you this email to remind you of the new authentication requirement. Please remember that calls to the Product Advertising API that are not signed will not be processed after August 15, 2009.We’d also like to take this opportunity to point out the resources available to help you make this change to your applications:The Developer Guide has details on what signed requests are and how to construct signed requests.Sample Code for Signed Requests is available in Java, C# and Perl.Our technical staff and other customers are available to answer questions on our Community Forums.More resources can be found at the Product Advertising API home page.Thank you for advertising our products and we look forward to sharing the revenue from these sales. The Product Advertising API Team> To manage your e-mail preferences, please update your communication preferences.© 2009 Amazon.com. All rights reserved. Amazon.com is a registered trademark of Amazon.com, Inc. Amazon.com, 1200 12th Ave. S., Suite 1200, Seattle, WA 98144-2734, USA. Own a website.Get an unlimited package.Pay next to nothing.*Go to http://in.business.yahoo.com/

1 0

RFC : More granular rules for Reserves
by Nahuel ANGELINETTI 15 Jun '09

15 Jun '09

Hi all, We are trying to find the great way to do more granular rules for reserves. I think the faster way is to patch the actual reserves system, but we are not sure of our solutions is the better one, so we are asking you for comments. The reserves will be edited via smart-rules.pl, this will allow to have rules by branch, category(of borrowers), and item type. * Which branch to use? Our first question was this, we decided to use circcontrol syspref, it seems to be the best choice. * Then, comes the question how to manage if the circcontrol's value is item's holding or home branch and the holding doesn't specify the item to reserve but the record reserved. The solution we propose, is to check if the borrower have remaining reserve rights to one of all the libraries which have an item of this record, if yes, so we allow the reserve. Next step, is the check-in of the item, at each check-in, we will check the reserve queue for the record, and the remaining reserves rights of the user in this library, if it's true, we allow the librarian to put the document in the "waiting to checkout" queue. The problem we see with this way to do, is if the user checkout any of his other reserves, the rights at the check-in times won't be the same as when he did the reserve. So he will have more rights than he had, and he will be able to do more reserves than allowed(if no library is specified). Can we consider we don't care? Or perhaps someone have another idea? Or perhaps we can force the user to choose one of the items if circcontrol value isn't one of the item's branch? Waiting for your comments, bests, -- Nahuel ANGELINETTI

5 12

FW: [KOHA-Consort] Article on KOHA in consortia
by Irma Birchall 14 Jun '09

14 Jun '09

_____ From: koha-consort-bounces(a)incolsa.net [mailto:koha-consort-bounces@incolsa.net] On Behalf Of Valerie Horton Sent: Saturday, 13 June 2009 8:13 AM To: 'koha-consort(a)incolsa.net' Subject: [KOHA-Consort] Article on KOHA in consortia KOHA Users, I'm working on an article on KOHA in consortium to be submitted to Collaborative Librarianship [an open-source journal http://www.collaborativelibrarianship.org.] I have identified several US consortium willing to contribute information, but I'd love to include information from the rest of the world. If there is anyone on this list that would be interested, please let me know. Thanks, Valerie Horton Valerie Horton, Executive Director Colorado Library Consortium (CLiC) 7400 E. Arapahoe Dr. #105 Centennial, CO 80112 vhorton(a)clicweb.org 303-422-1150 or 888-206-2695 www.clicweb.org Want to know what your colleagues are up to? <http://www.coloradolibraries.org> www.coloradolibraries.org

1 0

Avoid $sth->finish
by Joe Atzberger 10 Jun '09

10 Jun '09

Kohackers -- I want to mention this because I've seen a lot of recent patches still using the old style of code calling $sth->finish() explicitly. I know a lot of the codebase still does this internally, but for Koha such usage is almost always wrong. If this were just my personal contention, I would couch this in terms of an RFC to deprecate the usage. But we don't get a choice here: DBI is telling us "don't do it". Please refer to the DBI perldoc<http://search.cpan.org/%7Etimb/DBI-1.608/DBI.pm#finish> : The finish method is rarely needed, and frequently overused, but can sometimes be helpful in a few very specific situations to allow the server to free up resources (such as sort buffers). When all the data has been fetched from a SELECT statement, the driver should automatically call finish for you. So you should *not* normally need to call it explicitly *except* when you know that you've not fetched all the data from a statement handle. The most common example is when you only want to fetch one row, but in that case the selectrow_* methods are usually better anyway. *Adding calls to finish after each fetch loop is a common mistake, don't do it, it can mask genuine problems like uncaught fetch errors.* That last sentence is the most concrete and important (hence my bolding). Moral of the story: don't do it. Or if you think you have to, at least comment why, like: $sth->finish(); # FIXME: leaving data unfetched, should rework query -- Joe Atzberger LibLime - Open Source Library Solutions

4 3

Re: [Koha-devel] [Koha] Problems installing HTTP::OAI from CPAN for Koha 3.0.2
by Ricardo Dias Marques 09 Jun '09

09 Jun '09

Hi Galen (and list), Because it seems that this discussion is tending towards Perl code / Perl dependencies, I'm "Cc"ing the koha-developers list, In future followups, I think that I'll remove the "regular" Koha mailing list from the Cc list, for this discussion. My comments / questions are below: On Mon, Jun 8, 2009, Galen Charlton<galen.charlton(a)liblime.com> wrote: > For what it's worth, I was just able to successfully install HTTP::OAI > from CPAN on a clean Debian Lenny box. Based on the test suite errors > you're seeing, I suspect there's a glitch with XML::LibXML or one of > the other XML processing dependencies of HTTP::OAI on your box. Thanks for the feedback. Unfortunately, I tried today (9-Jun-2009) to install several (many) other XML-related packages that are in the SLES 11 DVD, but it didn't seem to make any difference. For what it's worth, I found out that "HTTP::OAI", in several of its ".pm" (Perl Module) files, require some XML::LibXML "submodules" (I don't know the correct word for that). For instance, the METS.pm file - located at HTTP-OAI-3.21/lib/HTTP/OAI/Metadata/METS.pm - requires the "XML::LibXML::XPathContext" module. If I try to install "XML::LibXML::XPathContext" from CPAN, then I get an error related to utf-16 (Unicode encoding) and umlauts (see "t/09xpath.t" line below): ---------------------------------------- myhost:~/HTTP-OAI-3.21/lib/HTTP/OAI/Metadata # cpan cpan shell -- CPAN exploration and modules installation (v1.94) ReadLine support enabled cpan[1]> install XML::LibXML::XPathContext CPAN: Storable loaded ok (v2.18) Going to read '/root/.cpan/Metadata' Database was generated on Mon, 08 Jun 2009 11:26:58 GMT CPAN: YAML loaded ok (v0.68) Going to read 37 yaml files from /root/.cpan/build/ CPAN: Time::HiRes loaded ok (v1.9711) ............................................................................DONE Restored the state of 37 (in 0.9044 secs) Running install for module 'XML::LibXML::XPathContext' Running make for P/PA/PAJAS/XML-LibXML-1.69.tar.gz Has already been unwrapped into directory /root/.cpan/build/XML-LibXML-1.69-R2RtfP Has already been made Running make test PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t t/01basic.t ................... 1/3 Compiled against libxml2 version: 20701 Running libxml2 version: 20701 t/01basic.t ................... ok t/02parse.t ................... ok t/03doc.t ..................... ok t/04node.t .................... ok t/05text.t .................... ok t/06elements.t ................ ok t/07dtd.t ..................... ok t/08findnodes.t ............... ok t/09xpath.t ................... 1/57 # Test 54 got: "\xFE\xFF" (t/09xpath.t at line 142) # Expected: "utf-16 test with umlauts: \xE4\xF6\xFC\xC4\xD6\xDC\xDF" # t/09xpath.t line 142 is: skip( # Test 57 got: "\xFE\xFF" (t/09xpath.t at line 156) # Expected: "utf-16 test with umlauts: \xE4\xF6\xFC\xC4\xD6\xDC\xDF" # t/09xpath.t line 156 is: skip( t/09xpath.t ................... Failed 2/57 subtests t/10ns.t ...................... ok [snipped most output...] t/80registryleak.t ............ ok t/90threads.t ................. ok Test Summary Report ------------------- t/09xpath.t (Wstat: 0 Tests: 57 Failed: 2) Failed tests: 54, 57 Files=37, Tests=1954, 6 wallclock secs ( 0.16 usr 0.37 sys + 3.92 cusr 1.89 csys = 6.34 CPU) Result: FAIL Failed 1/37 test programs. 2/1954 subtests failed. make: *** [test_dynamic] Error 255 PAJAS/XML-LibXML-1.69.tar.gz /usr/bin/make test -- NOT OK //hint// to see the cpan-testers results for installing this module, try: reports PAJAS/XML-LibXML-1.69.tar.gz Running make install make test had returned bad status, won't install without force Failed during this command: PAJAS/XML-LibXML-1.69.tar.gz : make_test NO ---------------------------------------- I *do* have XML::LibXML installed, from the "perl-XML-LibXML" software package in the SLES 11 DVD that I installed using the yast tool: ---------------------------------------- myhost:~/HTTP-OAI-3.21/lib/HTTP/OAI/Metadata # rpm -qa | grep -i xml-libxml perl-XML-LibXML-1.66-1.14 perl-XML-LibXML-Common-0.13-70.7 myhost:~/HTTP-OAI-3.21/lib/HTTP/OAI/Metadata # perl -MXML::LibXML -e 'print $XML::LibXML::VERSION, "\n"' 1.66 ---------------------------------------- If I try to install the "XML::LibXML" Perl module from CPAN, then it tries to install version 1.69 (instead of the existing 1.66) of the same module, but it fails with the same error regarding utf-16 and umlauts: ---------------------------------------- cpan[1]> install XML::LibXML CPAN: Storable loaded ok (v2.18) Going to read '/root/.cpan/Metadata' Database was generated on Mon, 08 Jun 2009 11:26:58 GMT CPAN: YAML loaded ok (v0.68) Going to read 37 yaml files from /root/.cpan/build/ CPAN: Time::HiRes loaded ok (v1.9711) ............................................................................DONE Restored the state of 37 (in 0.9181 secs) Running install for module 'XML::LibXML' Running make for P/PA/PAJAS/XML-LibXML-1.69.tar.gz Has already been unwrapped into directory /root/.cpan/build/XML-LibXML-1.69-R2RtfP Has already been made Running make test PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t t/01basic.t ................... 1/3 Compiled against libxml2 version: 20701 Running libxml2 version: 20701 t/01basic.t ................... ok t/02parse.t ................... ok t/03doc.t ..................... ok t/04node.t .................... ok t/05text.t .................... ok t/06elements.t ................ ok t/07dtd.t ..................... ok t/08findnodes.t ............... ok t/09xpath.t ................... 1/57 # Test 54 got: "\xFE\xFF" (t/09xpath.t at line 142) # Expected: "utf-16 test with umlauts: \xE4\xF6\xFC\xC4\xD6\xDC\xDF" # t/09xpath.t line 142 is: skip( # Test 57 got: "\xFE\xFF" (t/09xpath.t at line 156) # Expected: "utf-16 test with umlauts: \xE4\xF6\xFC\xC4\xD6\xDC\xDF" # t/09xpath.t line 156 is: skip( t/09xpath.t ................... Failed 2/57 subtests t/10ns.t ...................... ok [snipped most output...] Test Summary Report ------------------- t/09xpath.t (Wstat: 0 Tests: 57 Failed: 2) Failed tests: 54, 57 Files=37, Tests=1954, 6 wallclock secs ( 0.17 usr 0.36 sys + 3.80 cusr 2.05 csys = 6.38 CPU) Result: FAIL Failed 1/37 test programs. 2/1954 subtests failed. make: *** [test_dynamic] Error 255 PAJAS/XML-LibXML-1.69.tar.gz /usr/bin/make test -- NOT OK //hint// to see the cpan-testers results for installing this module, try: reports PAJAS/XML-LibXML-1.69.tar.gz Running make install make test had returned bad status, won't install without force Failed during this command: PAJAS/XML-LibXML-1.69.tar.gz : make_test NO ---------------------------------------- Any additional hints, please? :-/ Thanks again! Cheers, Ricardo

1 0

General project IRC meeting - 1 July 2009
by Galen Charlton 09 Jun '09

09 Jun '09

Hi, The next general meeting of the Koha project will be held on the #koha IRC channel at 19:00 UTC+0. The following standing agenda items will be discussed: 1. Koha 3.2 update 2. Koha 3.0.x update 3. Actions from the previous IRC meeting To suggest additional agenda items, please go to the wiki page for this meeting located at <http://wiki.koha.org/doku.php?id=meetingnotes09jul01>. Regards, Galen -- Galen Charlton VP, Research & Development, LibLime galen.charlton(a)liblime.com p: 1-888-564-2457 x709 skype: gmcharlt

1 0

Koha-3.0.2 Stable release
by LAURENT Henri-Damien 08 Jun '09

08 Jun '09

Hi, we are very happy to announce Koha3.0.2 Stable has been released on http://download.koha.org/ Its name is koha-3.00.02.tar.gz You can download file and signatures You can check the integrity of the package; either by verifying the provided GPG signature (.sig) or by comparing the MD5 checksum: c3fee4abbb29c88f97a5f7db5fe9eebf koha-3.00.02.tar.gz I have also tagged this in Git as "version 3.00.02 final" v3.00.02-final You can download. An extract of release notes is pasted below This release is bugfix only release, and doesnot include new features which would require some database changes. It does add some databases changes though but only to FIX bugs. The next release scheduled in July will include features which are now in master but not ported yet to stable because of database change required. That is to say mainly many content enhancement were not integrated Librarything, Syndetics, Baker&Taylor, Babeltheque, and BranchTransferLimits. But we are willing to make them into the next release which will come out as soon as possible in July. Cheers -- Henri-Damien LAURENT Koha 3.0.2 Release : This release of Koha 3.0.2 includes the following general improvements over the previous release fixes : xslt support for UNIMARC added UNIMARC support for search available items only and weight field better IE7 support for intranet Show Summary in opac results opac-browser Serial subscription report translations improved 178 commits for bug fixes are listed into the release notes.

2 3

Only available language, in a Koha 3.0.2 git installation, is "English" (en)
by Ricardo Dias Marques 08 Jun '09

08 Jun '09

Hi all, For the first time, I have tried to install Koha in Debian (Debian 5.0, a.k.a Debian Lenny). I had some problems with it, but I think that I managed to solve them. The installation was done from git (so it's a "dev" installation, as opposed to a "single" or a "standard" one). As I usually do, this is an UNIMARC and NoZebra setup. The first surprise was when I ran the "Koha Web Installer", right in "Step 1": the only language that appears in the dropdown list is "en" (English). The text above the dropdown reads "Please pick your language from the following list. If your language is not listed, please inform your systems administrator". The "Koha version" (in the "Intranet" > "Home" > "About Koha" > "Server Information" tab) is "3.00.02.012" (so, I think, that's essentially Koha 3.0.2). Apache version is 2.2.9 MySQL version is 5.0.51a Perl version is 5.10 After running the Web Installer, in the "Intranet" area (running on the 8080 port) , the only language that appears for the "System Preference" opaclanguages is also "English(en)". May I have missed something? I have other installations, running Koha 3.0.1 on openSUSE, and there I get the full list of available languages. Thanks in advance for any help, comments and/or pointers. Cheers, Ricardo Dias Marques lists AT ricmarques DOT net Installation Guide for Installing Koha 3 on openSUSE 11 http://wiki.koha.org/doku.php?id=opensuse_11.0

2 2

Future of koha-maintenance.git ?
by Zeno Tajoli 04 Jun '09

04 Jun '09

Hi to all, now we have the new stable versione, Koha 3.0.2 But I don't understood exactly the future of koha-maintenance.git and the path to version 3.0.3. We will continue to use koha-maintenance.git in the near future ? Will koha-maintenance.git update to present stable version (there same fix only in stable) ? The fixes for 3.0.3 will be on koha-maintenance.git or on branch 3.0.x ? I think we can use all 3 branch in this way: -- master branch: experimental version, it will become 3.2, not stable, many problems -- koha-maintenance: branch to test fix on the stable version, quite stable with problems but also with bugfix -- 3.0.x: stable branch, only translation fix and very few bugfixes At the end of fixing time, fix of koha-maintenance go to 3.0.x Probably from october 2009 master will be quite stable and we start to bugfix it prior of 3.2 release (with Release Candidates?) What do you think about it ? Bye Zeno Tajoli Zeno Tajoli CILEA - Segrate (MI) tajoliAT_SPAM_no_prendiATcilea.it (Indirizzo mascherato anti-spam; sostituisci quanto tra AT con @)

2 1

mail to patches@koha.org not coming through
by Joe Atzberger 04 Jun '09

04 Jun '09

The patches I send from our development server to patches(a)koha.org stopped going through yesterday. I still get the CC from git, but the originals seem to be stuck in moderation. Would the administrator for the patches list please advise what I can do to remedy the problem? -- Joe Atzberger LibLime - Open Source Library Solutions

4 6