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

To define default 9xx fields for Unimarc setup in all languages
by Zeno Tajoli 26 Jul '10

26 Jul '10

Hi to all I sent this mail to different Koha-mailing list because the topic is quite wide. If you are also on koha-dev list, replaty to this list. Instead replay on koha general list. I send the mail also to koha-france because many user of Unimarc are French. But I don't know French, please replay to koha general list or to koha-dev. Today the complete Unimarc setups are the English and French, As I know Italian, Ukrain, Russian and Poland setups are direct translation of English or Frence setup But on local fields English and French are not compatible. Many 9xx fields need to be the same in different languages because the indexes definitions in the file etc/zebradb/marc_defs/unimarc/biblios/record.abs are based on specific 9xx values. And the file record.abs is only one for all Unimarc setup So my proposal, for 3.2 and also [if possible ] for 3.0.x We re-write English setup in 9xx fields and we use it a minimun and a standard that ALL unimarc setups need to follow. It means that we need same change also to French setup. I want to discuss with everyone about this topic. I will write all the patch to fix the situation. So my proposal: Fields: 001 Local number -> biblio.biblionumber 090$a Local number -> biblioitems.biblioitemnumber 099$c date of creation -> biblio.datecreated 099$d Date/time last modified -> biblio.timestamp 995$0 Withdrawn status -> items.wthdrawn 995$2 Lost status -> items.itemlost 995$3 Use restrictions -> items.restricted 995$5 Date acquired -> items.dateaccessioned 995$6 Copy number -> items.copynumber 995$7 URI -> items.uri 995$8 Koha collection -> items.ccode 995$9 Internal item number -> items.itemnumber 995$a Homebranch (free text) ->items.homebranch 995$b Homebranch (coded) 995$d Holding branch (free text) -> items.holdingbranch 995$d Holding branch (coded) 995$e Shelving location-> items.location 995$f Barcode -> items.barcode 995$j Inventory number -> items.stocknumber [only 3.2] 995$k Call number -> items.itemcallnumber, 995$l Numbering (volume or other part) -> items.materials 995$m Date of loan or deposit -> items.datelastborrowed 995$n Expiration of loan date -> items.onloan 995$o Circulation type (not for loan) -> items.notforloan 995$r Type of item and material -> items.itype 995$v Serial Enumeration / chronology -> items.enumchron [only serials] 995$u Copy note -> items.itemnotes 942$0 Koha issues (borrowed), all copies -> biblioitems.totalissues 942$2 Source of classification or shelving scheme -> biblioitems.cn_source 942$6 Koha normalized classification for sorting -> biblioitems.cn_sort 942$c Koha [default] item type -> biblioitems.itemtype 942$s Serial record flag -> biblio.serial 1)Fields 001 and 090$a, BIB Identifier in two places As French setup, to ahve a correct Unimarc we need BIB id in two places: 001 -> biblio.biblionumber 090 $9 -> biblioitems.biblioitemnumber biblio.biblionumber and biblioitems.biblioitemnumber must be numerir, we need to stress this fact in data conversions 2)Field 995 as item field with those subfields: This proposal is full compatible with French Unimarc setup and it has also the items subfields that are mandatory for circulation, inventory, acquisitions and serials. 3)Field 942 as biblio/item field. This field is new for all unimarc setup, in english unimarc setup there is 990 but 990 is similar, not identical. I select 942 instead of 990 because 990 is present in French setup with a specific meaning. I ask to French people to accept to put biblioitems.totalissues in 942$0, it is the base of the popularity index. Now the base of popularity index is in 995$s. This proposal is only a minimum, if you think there are others 9xx fields/subfields that MUST be present in every setup, please replay. If you want to discuss it, please replay. Bye to all Zeno Tajoli Zeno Tajoli CILEA - Segrate (MI) tajoliAT_SPAM_no_prendiATcilea.it (Indirizzo mascherato anti-spam; sostituisci quanto tra AT con @)

2 1

Default MARC dialect
by Magnus Enger 22 Jul '10

22 Jul '10

Hi all! During my quest to add support for NORMARC (the Norwegian dialect of MARC) to Koha, I have come across several places[1] where UNIMARC is treated as the default if MARC21 is not specified. Here is an example from the subroutine GetMarcNotes in C4/Biblio.pm: 1268 if ( $marcflavour eq "MARC21" ) { 1269 $scope = '5..'; 1270 } else { # assume unimarc if not marc21 1271 $scope = '3..'; 1272 } When $marcflavour is "NORMARC" this fails, because NORMARC is more similar to MARC21 than to UNIMARC. I can think of two solutions to this: 1. Add NORMARC to the conditional: if ( $marcflavour eq "MARC21" || $marcflavour eq "NORMARC" ) { $scope = '5..'; } else { # assume unimarc if not marc21 $scope = '3..'; } 2. Reverse the logic: if ( $marcflavour eq "UNIMARC" ) { $scope = '3..'; } else { # assume marc21 if not unimarc $scope = '5..'; } I would prefer the second solution, because - in all the places I have found this situation it would be resolved by this solution, because NORMARC is so similar to MARC21 - as far as I know there are more MARC dialects that resemble MARC21 than there are dialects that resemble UNIMARC, so this solution would perhaps make it easier to add more dialects in the future If anyone has a completely different solution or pro/con arguments they would like to add I'm all ears! Regards, Magnus Enger libriotech.no PS. Just for the record: I'm no fan of NORMARC and would prefer if Norwegian libraries started using MARC21, but for Koha to be accepted in Norway it needs to support NORMARC... Notes: [1] http://wiki.github.com/MagnusEnger/KohaNor/existing-files

3 3

git bisect
by Colin Campbell 20 Jul '10

20 Jul '10

A handy introduction to using git bisect to track down bugs: > http://www.effectiveperlprogramming.com/blog/date/2010/07 C. -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 208 366 1295 (phone) +44 (0) 7759 633626 (mobile) colin.campbell(a)ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com

1 0

system preference question (anonymous preferences)
by Nicole Engard 19 Jul '10

19 Jul '10

There are 2 system preferences in my most recent version of HEAD: - AnonSuggestions -- Set to anonymous borrowernumber to enable Anonymous suggestions - AnonymousPatron -- Set the identifier (borrowernumber) of the 'Mister anonymous' patron. Used for Suggestion and reading history privacy Does this mean that AnonSuggestions is not used? I personally think we need both and that Anon should be for suggestions and AnonymousPatron for reading history. Can someone please clarify these for me? Thanks Nicole

3 6

New Debian packages and new Debian packages maintainer.
by Robin Sheat 19 Jul '10

19 Jul '10

Hi folks, I've taken over maintenance of the Debian Koha packages, and just did my first upload to them. These packages track the git master branch, and I'll be updating them every so often, hopefully about once a week or so. Perhaps more if I get the whole process into one script. Anyway, if you've been using these packages, Debian will probably start complaining that the signature has changed. The key that I'm using has the details: pub 1024D/A99CEB6D 2004-09-26 [vervaldatum: 2012-09-21] Vingerafdruk van de Sleutel = 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D uid Robin Sheat <robin(a)kallisti.net.nz> uid Robin Sheat <robin(a)ufies.org> uid Robin Sheat (work) <robin(a)catalyst.net.nz> uid Robin Sheat <robin.sheat(a)member.fsf.org> sub 2048g/DF7647FD 2004-09-26 [vervaldatum: 2012-09-21] To tell Debian it's OK to use, run: wget -O- http://debian.koha-community.org/koha/gpg.asc | sudo apt-key add - (all on one line.) Don't forget to file bugs if you discover any issues with the packages, I'm slowly learning how this whole packaging process works. -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204

1 0

Fwd: RE: rebuild_zebra and a limit at 700 000 biblios
by Paul Poulain 16 Jul '10

16 Jul '10

Scott, I already have : register: /home/koha/var/lib/zebradb/biblios/register:40G shadow: /home/koha/var/lib/zebradb/biblios/shadow:40G or I'm looking at the wrong file... double check ... unless i'm blind (or really too tired), I have 40G, so that should be enough :\ -------- Message original -------- Sujet: RE: [Koha-devel] rebuild_zebra and a limit at 700 000 biblios Date : Thu, 15 Jul 2010 17:17:16 -0400 De : Scott Kushner <skushner(a)mtpl.org> Pour : Paul Poulain <paul.poulain(a)biblibre.com> Paul, I think you have to increase your memory buffer in biblios.cfg to 8G or more. I had that problem. # Lock File Area lockDir: /root/koha-dev/var/lock/zebradb/biblios perm.anonymous:ar perm.root:rw passwd: /root/koha-dev/etc/zebradb/etc/passwd register: /root/koha-dev/var/lib/zebradb/biblios/register:8G shadow: /root/koha-dev/var/lib/zebradb/biblios/shadow:8G # Temp File area for result sets setTmpDir: /root/koha-dev/var/lib/zebradb/biblios/tmp # Temp File area for index program keyTmpDir: /root/koha-dev/var/lib/zebradb/biblios/key # Approx. Memory usage during indexing memMax: 150M rank:rank-1 truncmax: 1000000000 Scott Kushner Information Technologies Middletown Public Library -----Original Message----- From: koha-devel-bounces(a)lists.koha-community.org [mailto:koha-devel-bounces@lists.koha-community.org] On Behalf Of Paul Poulain Sent: Thursday, July 15, 2010 5:11 PM To: koha-devel(a)lists.koha-community.org Subject: [Koha-devel] rebuild_zebra and a limit at 700 000 biblios Hello, We have a database of 726k biblios and 1.2M items. When we rebuild_zebra, everything is OK on the export. Then, the rebuild_zebra seems OK as well, except that only 702k biblios are indexed. We don't have any error, everything seems OK. Does anyone have seen this problem ? Logs : exporting biblio ==================== Records exported: 726210 <snip> 06:43:19-08/07 zebraidx(314) [log] Records: 700000 i/u/d 700000/0/0 06:43:29-08/07 zebraidx(314) [log] Records: 701000 i/u/d 701000/0/0 06:43:38-08/07 zebraidx(314) [log] Records: 702000 i/u/d 702000/0/0 07:42:38-08/07 zebraidx(314) [log] Merge 0% <snip> 07:00:52-08/07 zebraidx(314) [log] Merge 95.4% completed; 48 seconds remaining 07:01:02-08/07 zebraidx(314) [log] Merge 96.4% completed; 37 seconds remaining 07:01:12-08/07 zebraidx(314) [log] Merge 97.4% completed; 26 seconds remaining 07:01:22-08/07 zebraidx(314) [log] Merge 98.7% completed; 13 seconds remaining 07:01:32-08/07 zebraidx(314) [log] Merge 99.9% completed; 0 seconds remaining 07:01:38-08/07 zebraidx(314) [log] Iterations: isam/dict 301420236/21553295 07:01:38-08/07 zebraidx(314) [log] Dict: inserts/updates/deletions: 21553295/0/0 07:01:42-08/07 zebraidx(314) [log] Records: 702954 i/u/d 702954/0/0 07:01:42-08/07 zebraidx(314) [log] zebra_stop: 20557.86 6312.50 1447.43 Search works on every biblio, except ones after 702955. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 _______________________________________________ Koha-devel mailing list Koha-devel(a)lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel

5 4

rebuild_zebra and a limit at 700 000 biblios
by Paul Poulain 15 Jul '10

15 Jul '10

Hello, We have a database of 726k biblios and 1.2M items. When we rebuild_zebra, everything is OK on the export. Then, the rebuild_zebra seems OK as well, except that only 702k biblios are indexed. We don't have any error, everything seems OK. Does anyone have seen this problem ? Logs : exporting biblio ==================== Records exported: 726210 <snip> 06:43:19-08/07 zebraidx(314) [log] Records: 700000 i/u/d 700000/0/0 06:43:29-08/07 zebraidx(314) [log] Records: 701000 i/u/d 701000/0/0 06:43:38-08/07 zebraidx(314) [log] Records: 702000 i/u/d 702000/0/0 07:42:38-08/07 zebraidx(314) [log] Merge 0% <snip> 07:00:52-08/07 zebraidx(314) [log] Merge 95.4% completed; 48 seconds remaining 07:01:02-08/07 zebraidx(314) [log] Merge 96.4% completed; 37 seconds remaining 07:01:12-08/07 zebraidx(314) [log] Merge 97.4% completed; 26 seconds remaining 07:01:22-08/07 zebraidx(314) [log] Merge 98.7% completed; 13 seconds remaining 07:01:32-08/07 zebraidx(314) [log] Merge 99.9% completed; 0 seconds remaining 07:01:38-08/07 zebraidx(314) [log] Iterations: isam/dict 301420236/21553295 07:01:38-08/07 zebraidx(314) [log] Dict: inserts/updates/deletions: 21553295/0/0 07:01:42-08/07 zebraidx(314) [log] Records: 702954 i/u/d 702954/0/0 07:01:42-08/07 zebraidx(314) [log] zebra_stop: 20557.86 6312.50 1447.43 Search works on every biblio, except ones after 702955. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

3 2

Image/Graphics Magick confusion
by Colin Campbell 15 Jul '10

15 Jul '10

Hi, just noticed that the debian package lists and scripts in install-misc install libimage-magick-perl but the koha dependency is for Graphics::Magick (libgraphics-magick-perl). Willing to generate a patch for that but wondered if there are any advantages in using Graphics Magick rather than Image Magick (as imagemagick has the advantage that the perl module can be installed from CPAN ) Colin -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 208 366 1295 (phone) +44 (0) 7759 633626 (mobile) colin.campbell(a)ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com

3 4

Official Koha Newsletter : Volume 1, Issue 7: July 2010
by Nicole Engard 15 Jul '10

15 Jul '10

Read this newsletter online with live links: http://koha-community.org/koha-newsletter-volume-1issue-7-july-2010/ Official Koha Newsletter (ISSN 2153-8328) Volume 1, Issue 7: July 2010 Table of Contents * Tips & Tricks o Search in Koha o Amazon Content Not Appearing? * Koha in Libraries o Koha Users Forum launched in Nigeria o Archive & Access Project * Koha Events o Second Koha Open Day in London o KohaCon 2010 Program Available Tips & Tricks Search in Koha by Marilen Aretius Corciovei For people used to web searches and database oriented application Koha way of dealing with searches (since v.3) might seem a bit alien. This is a small set of notes related to some not very obvious questions which I had to answer in order to do some configurations which seemed trivial at the beginning. I am not saying this is wrong or ineffective, just different and different means time to learn. I’m writing this to help you reduce this time. [Read Part 1 & Part 2.] Amazon Content Not Working? by Nicole C. Engard Question: Why is Amazon’s enhanced content not appearing? Answer: Amazon uses your server time in its API requests and so if your system time is off you will not be able to use Amazon content. Update your server time and make sure all of your Amazon preferences are turned on, this should solve the problem. Koha in Libraries Koha Users Forum launched in Nigeria by Olugbenga Adara Projektlink Konsult Limited, the premier Koha support company in Nigeria hosted the first ever Koha Users Forum at its premises in Ibadan, Nigeria on Monday June 21, 2010. The event, which had 22 participants from 12 different institutions using Koha in Nigeria, featured tutorials, tips and tricks and discussions on challenges and solutions to problems encountered by the participants while running Koha. More details are available here. Archive & Access Project by Savitra Sirohi The Archive and Access project aims to set up a consortium of archives and libraries in India with the purpose of catalog sharing and eventual sharing of full text digitized resources. The project is supported by the Jamsetji Tata Trust and housed at the Centre or the Study of Culture and Society, Bangalore. This will be a union catalog, powered by Koha, of historical collections of libraries and archives from different parts of the India. This is an ongoing process, with the regular introduction of new institutions to the catalog. The project wishes to solicit contributions from libraries, organizations, historians and other scholars for this catalog. Those interested in participating can contact project members at: publicarchivesindia(a)gmail.com and more information can be found on the official page. Koha Events Second Koha Open Day in London by Andrea Chandler The Kings Fund and CAMLIS are pleased to announce that we will be holding another free open day for people interested in finding more about implementing or switching to Koha. All Koha users are also welcome. The event will be held in the afternoon of Friday 10th of September at CAMLIS, from 2pm-5pm. At the moment we don’t have a strict schedule but we hope to include some short presentations with discussion, followed by hands-on experience in small groups at the library computers. There will be some time for existing Koha users to chat with each other. If any user is interested in giving a 10 minute presentation or demonstration of some aspect of Koha, please contact one of us. Places for this event are limited so please book early by contacting Matthew Hale at the King’s Fund: m.hale(a)kingsfund.org.uk. If there is sufficient interest we will repeat it at a later date, so do register your interest even if you can’t necessarily make this day. KohaCon 2010 Program Available by Nicole C. Engard As we get closer to the next annual KohaCon (this year in NZ – where it all started) it’s time to check out the program for the event! We are still gathering speaker bios and program description updates, but the preliminary program is available on the conference site. Newsletter edited by Nicole C. Engard, Koha Documentation Manager. Please send future story ideas to me.

1 0

Moving system preference serialization into the database
by Chris Nighswonger 13 Jul '10

13 Jul '10

While doing some beginning work on a local syspref editor to fit in with the new system preference interface, I have run into the file permission "problem" of writing to files inside Koha's template directory structure. This is due to the fact that the system preferences are serialized in yaml format and stored in *.pref files within the template directory structure. While the problem of writing to files is one which needs to be addressed, it is not one that we have time to address before the 3.2 stable release. As regards the system preference issue in particular, the problem may be better resolved by moving the serialization into a table in the database. As it stands presently, part of the system preference data is kept in the database in the systempreferences table while the other part is kept in the *.pref files. Moving the serialization into the database will have the benefits of keeping the data in one location as well as overcoming the file writing issues. So, are there any serious objections to making this change? Kind Regards, Chris

7 16