- Koha - lists.katipo.co.nz

Koha Versions and User Guide
by Srinivas 21 Jun '07

21 Jun '07

Dear all, I join this group recently,I want to know all versions of Koha since from begining with releasing date I got the information from Koha 2.2.4 to 2.2.9 and want to know all versions.If anybody is having the list plese forward it to me.Is there any user guide for Koha 2.2.8 ?can anybody suggest me where will i get this information.with worm regards,srinivasINDIA

1 0

What perl editor is best for Koha
by Mulu Gebreegziabher 21 Jun '07

21 Jun '07

Dear all, I would appreciate if anyone can suggest me what Perl editor I have to use to modify KOHA templates and scripts. Mulu G.

3 2

Koha in Peru
by Luis Maguina Silva 21 Jun '07

21 Jun '07

Hello community: My name is Luis Maguiña. I\'m a librarian and GNU/Linux user. I work at San Marcos University (Peru, South America). We began a project. The aim: change ILS that we use actually, because we have many problems with it. We had tests and we decided use Koha. I began the project in 2006 (October). Humanities Faculty use Koha for catalogue, step by step we want use other modules. I want to collaborate with Koha, I think it\'s the major manner that we can give back to community by a gift and improve koha. I\'m a librarian, I use Debian GNU/Linux and I know Perl, PHP, Java. I work with computers and use GNU/Linux since 1993. Luis Maguiña Linux user number 386737 No compres productos con DRM (Digital Rights Management), ni procesadores con TPM (Trusted Platform Module).... La información debe fluir ___________________________________________________________________ Si desea recibir, semanalmente, el Boletín Electrónico de la PUCP, ingrese a: http://www.pucp.edu.pe/boletin/

2 1

Koha Day Report
by Joshua M. Ferraro 21 Jun '07

21 Jun '07

Hi everyone, Well, our first Koha day went off swimingly, got lots of project stuff accomplished, met some new people, and had loads of fun. But starting at 9:00am on a Sunday is just nutty for the US team, so we've decided to give ourselves a break and pick it up at noon next week :-). Feel free to join us this Sunday starting at 12:00pm EST. So ... it's really amazing what can be accomplished in a day, here are the highlights: We met some great new folks: Frederic from France, Luis from Peru, gganno the librarian from Mali Africa, bureado, lloyd from the UK, and jamesa. Mason investigated automatic testing with Selenium, which will really be helpful for QA testing. Also spent some time on bugzilla, cleaning some stuff up. Russ hacked on the mailman pages on the koha website, making them prettier and had some productive discussions with Tina about improvements to the koha.org site. Plan is to continue the discussions week after next. Chris actually blogged about his Koha day: http://wiki.koha.org/doku.php?id=meetingnotes07july02 If you were watching CVS you'll notice chris committed a bunch of test scripts; and if you were watching the wiki, there's quite a bit of technical documentation added as well. Randy took a look at the koha.org site and talked about improvements to be made from a project image standpoint; he also spent some time evaluating forum software and concluded that phpbb is probably the way to go Tina and Sara spent some time doing usability testing on the koha.org site and the koha interfaces. Also played around with some new project -specific graphics, mostly related to the koha.org website Finally, I worked on the 3.0 roadmap and read the Producing Open Source book, trying to glean some ideas for improving the project's release theory. i also worked a bit on the translation site, having some issues with the latest release's translation script I plan to hack further on next week. -- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE President, Technology migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf(a)liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS

2 1

Marc Framework Question
by Olugbenga Adara 20 Jun '07

20 Jun '07

Hello, I am setting up koha for the Nigerian Institute of Social and Economic Research in Ibadan Nigeria. Their cataloguing will be done by direct data entry (over 30000 items) I prefer to use marc but the fields of the default framework that are displayed are to many for efficient data entry. What is just needed are fields for Author Additional Author Author's affiliation (this is used to identify authors in certain institutions, e.g. WHO, World Bank etc) Title Place of Publication Year Publisher ISBN Physical Description Classmark (Dewey) barcode Date received For the major data entry, i plan to use others means to create text file, then use marcmaker to make mark and then upload into the system. but i also need a framework for day to day cataloguing. i will appreciate any suggetion or pointers thanks NB. i've tried setting certain tags to not display but this tags are just to many and some still display nevertheless. im using koha 2.2.9 on mysql5 (suse10.1) Olugbenga Adara MCP Consultant, 3om Services, 75, Lebanon Street, Dugbe, Ibadan, Nigeria. Tel: 234-2-2412090 Mobile: 234-803-3220288 ____________________________________________________________________________________ Luggage? GPS? Comic books? Check out fitting gifts for grads at Yahoo! Search http://search.yahoo.com/search?fr=oni_on_mail&p=graduation+gifts&cs=bz

3 2

Re: Re: [Koha] Dealing with bad MARC records
by Steven F.Baljkas 20 Jun '07

20 Jun '07

Wednesday, June 20, 2007 1:55 CDT Hi, Kevin, That's great that you got a good answer back from LAC and that you found a much better solution to your problem than what I had proposed. Kudos to you! Cheers, Steven F. Baljkas library tech at large volunteer cataloguer Koha neophyte Winnipeg, MB, Canada ============================================================ From: Kevin O'Rourke <lists(a)caboose.org.uk> Date: 2007/06/19 Tue AM 09:15:19 CDT To: "Steven F. Baljkas" <baljkas(a)mts.net> CC: Koha Mailing List <koha(a)lists.katipo.co.nz> Subject: Re: [Koha] Dealing with bad MARC records > P.S. Sorry that LAC's records are fouling things up for you. I've encountered those 5|| fields, too. I think they were meant to be normative 500's and something 'exotic' happened in someone's cataloguing editor. > If you don't mind taking the time when you have your solution worked out, you can report those kinds of boo-boo's to LAC (using the AMICUS no. for reference) and they will try to correct them. That way, everything improves for everyone. > I got a really nice reply from LAC where they explained that their records come from a wide variety of systems, some beyond their control. To quote: "The fill character is allowable in MARC coding and was widely used in the early years of MARC, but most libraries try not to use it, and your system, quite rightly, is rejecting it. ... The record in question was created in 1981. The field in question should be a 500 general note field." I've modified my program, it now: - loads records with non-numeric MARC fields - maps some fields to others (for example, 5|| to 500) - strips out any remaining non-numeric fields on saving This should keep everything nice and simple for our librarians. Kevin -- Kevin O'Rourke ICT Coordinator, National Teachers' Institute, Kaduna, Nigeria 062 316972 _______________________________________________ Koha mailing list Koha(a)lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha ============================================================

1 0

Re: [Koha] Dealing with bad MARC records
by Steven F.Baljkas 19 Jun '07

19 Jun '07

Monday, June 18, 2007 17:30 CDT Hi, Kevin, Well, it's good to be able to wake up after a whole day sick and be able to do something useful for someone ... I've actually encountered the problem you're having, too. What I did as a quick fix was to convert the file into tagged MARC -- MARCEdit allowed me to do this; if it doesn't work for you let me know -- and then opened the tagged file in MS Word. Using MS Word however, I could ask it to find the weird non-numeric field designator and change it to something distinctively numeric. I had to do that because MARCEdit's global search and replace functions also wouldn't work for non-numeric fields either (at least not for me). Also note: in this case, you wouldn't want to change the 5|| into 500 because you might have 500 (General Note) fields you'd want, but maybe something like 582 (doesn't exist formally) or 59x (whatever of the 590s you haven't designated/planned any use for otherwise). If you don't have access to MS Word or you have other problems, give me a shout back off listserv. Despite my health, I should have a few free hours this week and as long as the programs work to do things automatically, I could convert the files for you easily enough. Do let the listserv know how things worked out, Kevin. In the meantime, hope this helps (at least as a work-around). Cheers, Steven F. Baljkas library tech at large Koha neophyte volunteer cataloguer Winnipeg, MB, Canada P.S. Sorry that LAC's records are fouling things up for you. I've encountered those 5|| fields, too. I think they were meant to be normative 500's and something 'exotic' happened in someone's cataloguing editor. If you don't mind taking the time when you have your solution worked out, you can report those kinds of boo-boo's to LAC (using the AMICUS no. for reference) and they will try to correct them. That way, everything improves for everyone. -- SFB ============================================================ From: Kevin O'Rourke <lists(a)caboose.org.uk> Date: 2007/06/18 Mon AM 03:58:20 CDT To: Koha Mailing List <koha(a)lists.katipo.co.nz> Subject: [Koha] Dealing with bad MARC records This question is not directly related to Koha itself, but to preparing MARC records for import. Some of the records we've been downloading from Libraries and Archives Canada contain a "5||" (two pipe characters) tag with information about translation. As far as I can tell this is not valid MARC. I developed a little Java program to pre-process records before importing into Koha, using the marc4j library to read MARC. This library refuses to read records containing non-numeric tags, causing us problems. Can anyone recommend any tools for ensuring that a MARC record contains only valid MARC? I could use MarcEdit to 'break' the files, edit out the bad tags and then re'make' them but this is a bit complicated, time-consuming and error-prone. -- Kevin O'Rourke ICT Coordinator, National Teachers' Institute, Kaduna, Nigeria 062 316972 _______________________________________________ Koha mailing list Koha(a)lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha ============================================================

2 2

Bug: memberentry.pl Does Not Auto-calc Expiry and Joining Date
by Bo Schafers 19 Jun '07

19 Jun '07

Hi, While transferring our membership database I noticed that memberentry.pl does not save Joining date (leave blank for today): Expiry date (leave blank for auto calc): I've loaded our dates by importing the member data into MySql from a CSV file. However when adding member manually the dates are not auto-calced as seems to be intended by design. Perhaps I've overlooked something, but if this is indeed a bug I'll be happy to add it Bugzilla. Natuarally I'm secretly hoping for someone to provide me with a quick magical fix and then claim the swooning credit from our head librarian. But then life usually isn't like that :-) TIA Bo

2 2

Re: [Koha] Dealing with bad MARC records
by BWS Johnson 19 Jun '07

19 Jun '07

Salvete! > Using MS Word >however, I could ask it to find the weird non-numeric field designator and change it to something >distinctively numeric. > Hmmm. Word adds a whole bunch of junk when it does anything whatsoever. It's part of its proprietary doesn't play well with others routine. May I suggest a slightly more deprecated approach through Notepad? >The trouble with any manual process like that is that our librarians >will skip it. I'm already struggling to get them to follow the minimal >workflow I introduced, they have a tendency to take short cuts that end >up with bad or incomplete records in our catalogue. It's difficult to >persuade them that it's not quantity but quality of records that's >important. > >In this case, when my program didn't work, they decided to just import >the records straight into Koha (without asking me). Koha couldn't read >the records, so they decided to enter them manually but couldn't be >bothered typing anything more than a few words from the title, >misspelled and with incorrect capitalisation. > Ah! I see the problem. >;) You need the angry mob argument. As in, when you don't catalogue these properly, and thus can't find a darn thing later (or worse, frustrate one of your Patrons) they will come hunting for you. Indeed, the coworkers will start the slaughter if they can't issue something when the need arises. It would be very easily demonstrated if you pulled a very prolific author and showed them what happens. For instance, I pull Martin, Ann M. since I'm a public with one heck of a chunk of the Baby - Sitter's Club. They'll see that Matin, Ann Martin, Anne Martin, Ann M all are not acceptable since they produce different (wrong!) results. Basically, they have to realise that it's a larger pain in the rear later if they're lazy now, which can of course be a hard argument with folks that live in the moment. If they still don't get it, then you needs snitch on them to a higher authority with firing power. Out of morbid curiousity, do these bad fields originate from a certain catalogue? Perhaps its feasible to avoid the problem entirely by locating a catalogue to query that doesn't have crummy fields in the first place. Cheers, Brooke @ Hinsdale MA

1 0

Z39.50 search Internal Server Error
by Greg Vickers 18 Jun '07

18 Jun '07

Hi all, Since the upgrade to 2.2.9, a new problem has arisen with our z39.50 search. Logging onto the Intranet, clicking on Catalog, Add Biblio, Create Empty, select tab 1, type anything in the Title field, click z39.50 search, and the z39.50 window comes up with an Internal Server Error. The Apache koha-error.log file contains: x.x.x.x - - [18/Jun/2007:20:56:43 +1000] "POST /cgi-bin/koha/acqui.simple/addbiblio.pl HTTP/1.1" 200 152692 Can't load '/usr/local/lib/perl/5.8.4/auto/Net/Z3950/ZOOM/ZOOM.so' for module Net::Z3950::ZOOM: libssl.so.0.9.7: cannot open shared object file: No such file or directory at /usr/lib/perl/5.8/XSLoader.pm line 70. at /usr/local/lib/perl/5.8.4/Net/Z3950/ZOOM.pm line 12 Compilation failed in require at /usr/local/lib/perl/5.8.4/ZOOM.pm line 6. BEGIN failed--compilation aborted at /usr/local/lib/perl/5.8.4/ZOOM.pm line 6. Compilation failed in require at /usr/local/koha/intranet/cgi-bin/z3950/search.pl line 30. BEGIN failed--compilation aborted at /usr/local/koha/intranet/cgi-bin/z3950/search.pl line 30. [Mon Jun 18 20:56:48 2007] [error] [client 210.49.141.186] Premature end of script headers: /usr/local/koha/intranet/cgi-bin/z3950/search.pl Now ZOOM is installed and all files mentioned in the error log are present. What am I missing? Thanks, Greg

1 0