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

installer from cvs broken?
by Benedykt P. Barszcz 03 May '04

03 May '04

Hi list, here is the error I get when instlling from CVS ./installer script. Is it my fault or a bug? Benedict MARC FIELD DEFINITIONS You can import MARC settings for: 1 MARC21 2 UNIMARC N none NOTE: If you choose N, nothing will be added, and you must create them all yourself. Only choose N if you want to use a MARC format not listed here, such as DANMARC. We would like to hear from you if you do. Choose MARC definition [1]: ERROR 1136 at line 15: Column count doesn't match value count at row 1

3 3

Question about Acquisitions and 'Biblios in koha'
by T & J Kotula 03 May '04

03 May '04

Why is it when I hit 'Go' in .../acqui.simple/addbooks.pl (after typing in an ISBN) I never get any biblios listed in the "Biblios in koha" table, even though the biblio with that ISBN is in the bibioitems table. However it works fine when I type in the title. Looks like a bug to me. Am I missing something? I'm running Koha2.0.0. PS. My Koha.biblio table does not contain ISBN column. Tomasz Kotula

4 4

Re: [Koha-devel] Question about Acquisitions and 'Biblios in koha'
by Roger Hiles 01 May '04

01 May '04

British and American editions occasionally differ enough to warrant entirely separate typesetting, but often to save money the same text is shared between British and American publishers. Two allow the British and America editions to be distinguished for marketing and inventory purposes, both a British and American ISBN are sometimes included in the same work. The "International" part of the ISBN is that it's supposed to be a unique identifier that can be used everywhere to identify a particular edition from a particular publisher. >From: "Stephen Hedges" <shedges(a)skemotah.com> >To: "Roger Horne" <roger(a)hrothgar.co.uk> >CC: "koha-devel" <koha-devel(a)lists.sourceforge.net> >Subject: Re: [Koha-devel] Question about Acquisitions and 'Biblios in koha' >Date: Fri, 30 Apr 2004 17:07:17 -0400 (EDT) > >Roger, I don't think I've ever seen anything like what you describe. (I >always assumed the 'I' in 'ISBN' really meant "international!") Is this >fairly common outside the US? > >MARC records let you repeat the ISBN tag. Koha doesn't. > >Stephen > >Roger Horne said: ><snip> > > Purely out of interest, what are Koha and other systems meant to do with >a > > book that lists on its back cover separate ISBNs for different countries > > eg > > "An Introduction to the History of Printing Types", Dowding, The British > > Library & Oak Knoll Press, has "0712345779 (UK) and 1884718434 (US)" > > printed > > on the outside. > > > > Roger > > -- > > Roger Horne, 11 New Square, Lincoln's Inn, London WC2A 3QB > > http://hrothgar.co.uk/ > > mailto:roger@hrothgar.co.uk > >-- >Stephen Hedges >Skemotah Solutions, USA >www.skemotah.com -- shedges(a)skemotah.com > > >------------------------------------------------------- >This SF.Net email is sponsored by: Oracle 10g >Get certified on the hottest thing ever to hit the market... Oracle 10g. >Take an Oracle 10g class now, and we'll give you the exam FREE. >http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click >_______________________________________________ >Koha-devel mailing list >Koha-devel(a)lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/koha-devel _________________________________________________________________ FREE pop-up blocking with the new MSN Toolbar get it now! http://toolbar.msn.com/go/onm00200415ave/direct/01/

2 1

RE: [Koha] Koha 2.0
by Stephen Hedges 30 Apr '04

30 Apr '04

Thanks for the screen shots, Bernadette. It looks like you may have found a bug in the Koha templates, so I'm copying this reply to the developers list. Stephen Bernadette Cassidy said: > Hi Stephen, > > Thank you for your reply. I'm attaching screen shots to show what happens when I try to add an item. You'll notice on page 3 & 4 at the top left corner of the screen there's a message which reads > <includes/comment-style.css> or similar. > > Kind regards, > Bernadette > > -----Original Message----- > From: Stephen Hedges [mailto:shedges@skemotah.com] > Sent: Saturday, 17 April 2004 12:12 a.m. > To: Bernadette Cassidy > Cc: koha(a)lists.katipo.co.nz > Subject: Re: [Koha] Koha 2.0 > > Bernadette Cassidy said: >> Hi everyone, >> We've recently upgraded to 2.0 and have experienced difficulty with > the >> Acquisitions module and Catalogue maintenance, i.e we're not able to > add >> items, update & modify biblios etc, I was wondering if other libraries had experienced similar difficulties and have possible > solutions/answers >> etc. >> Many thanks, >> Bernadette > > Bernadette, can you give us more details? What exactly happens when you try to add an item, for instance? It sounds like you may not have your parameters set correctly. > > -- > Stephen Hedges > Skemotah Solutions, USA > www.skemotah.com -- shedges(a)skemotah.com > -- Stephen Hedges Skemotah Solutions, USA www.skemotah.com -- shedges(a)skemotah.com

1 0

encoding of z3950 imported records
by Zbigniew Bomert OP 30 Apr '04

30 Apr '04

Hi, First, thank you all for this software; I am happy trying to use Koha. Lately, Benedykt Barszcz reported a problem with encoding of records imported through z3950. This is a general problem. 1. In fact, the records a imported in ISO-8859-1 encoding. They are converted from marc8/ANSEL or ISO5426/ISO6937 to ISO-8859-1 in the subroutine 'char_decode' in Biblio.pm. This will not work for libraries with books in languages of different charsets. The universal solution would be to store data in utf-8. Then all localized templates schuld be translated to utf-8 encoding. 2. In 'char_decode' a string is converted to ISO-8859-1 separetly for UNIMARC and MARC21. LoC uses MARC21 with ANSEL encoding, european libraries use mostely UNIMARC with ISO5426 encoding - but it's not always the case. Polish National Library's z3950 server in fact responds with MARC21 records in ISO5426 encoding. Happily, it seems to me, that both encodings don't overlap, so it is safe to make char-decoding for both at ones. For polish chars the code could look like this: s/(\xe2|\xc2)c/\xc4\x87/gm ; s/(\xe2|\xc2)C/\xc4\x86/gm ; s/(\xe2|\xc2)n/\xc5\x84/gm ; s/(\xe2|\xc2)N/\xc5\x83/gm ; s/(\xe2|\xc2)o/\xc3\xb3/gm ; s/(\xe2|\xc2)O/\xc3\x93/gm ; s/(\xe2|\xc2)s/\xc5\x9b/gm ; s/(\xe2|\xc2)S/\xc5\x9a/gm ; s/(\xe2|\xc2)z/\xc5\xba/gm ; s/(\xe2|\xc2)Z/\xc5\xb9/gm ; #ogonek s/(\xf1|\xce)a/\xc4\x85/gm ; s/(\xf1|\xce)A/\xc4\x84/gm ; s/(\xf1|\xce)e/\xc4\x99/gm ; s/(\xf1|\xce)E/\xc4\x98/gm ; # łŁ s/(\xb1|\xf8)/\xc5\x82/gm ; s/(\xa1|\xe8)/\xc5\x82/gm ; #żŻ s/(\xe7|\xc7)z/\xc5\xbc/gm ; s/(\xe7|\xc7)Z/\xc5\xbb/gm ; For letters with acute: s/(\xe2|\xc2)a/\xc3\xa1/gm ; s/(\xe2|\xc2)A/\xc3\x81/gm ; s/(\xe2|\xc2)e/\xc3\xa9/gm ; s/(\xe2|\xc2)E/\xc3\x89/gm ; and so on. 3. To see correct chars in search result one should also add char-decoding of title and author in cgi-bin/z3950/search.pl After those changes I can import correctly records from National Library, and even polish records from LoC. Zbigniew Bomert OP

3 2

Z3950 Server Unimarc
by Serge Renaux 22 Apr '04

22 Apr '04

HI, I would be interested to work on z3950 server working on Unimarc. What can i do to get informations or help about it ? Regards Serge

2 1

Re: [Koha] uninstalling
by Roger Horne 21 Apr '04

21 Apr '04

On Thu 15 Apr, I wrote: >[snip] > Clicking on the title produced a partial display of the Marc entries: > > 020 -INTERNATIONAL STANDARD BOOK NUMBER > a International Standard Book Number 0406948291 > > 852 -LOCATION/CALL NUMBER > k Call number prefix (NR) TB > > [snip] > [followed by a box containing] > > homebranch > RH > > "TB" stands for text book so the 852 line would seem to be wrong. (If I go > to edit I am given a drop down box for that line with text book, law report > etc.) Further experiment shows that the error in the 852(k) line is *introduced* by the Item Type Admin page (admin/itemtypes.pl ). Yesterday I got the daemon to work at least partially and it found the biblio for the Perl Cookbook at the Library of Congress and added it. But the 852k line was still TB (ie text book). So I added another "type", BS (for brussells sprout --- not I admit something usually found in libraries) and searched for the Cookbook again. When I tried to edit it (aqui.simple/addbiblio.pl ) the 852 line contained text book and the drop down menu now included the item brussells sprout. And that expression appears in table itemtypes. But seeing how TB gets into the display is way beyond me. A couple of tables show the Perl Cookbook: select biblionumber,author,title from biblio; +--------------+--------------------+----------------------------------------+ | biblionumber | author | title | +--------------+--------------------+----------------------------------------+ | 1 | Gammie | Tolley Yellow Tax Handbook | | 2 | Michael Thomas | Stamp Duty Land Tax | | 3 | Longrigg Higgins | Family Breakdown and Trusts | | 4 | DuBois, Paul, | MySQL Cookbook / | | 5 | Petersen, Theo. | Web development with Apache and Perl / | | 6 | Christiansen, Tom. | Perl cookbook / | +--------------+--------------------+----------------------------------------+ 6 rows in set (0.00 sec) mysql> select biblionumber,itemtype,isbn from biblioitems; +------------------+----------+------------+ | biblionumber | itemtype | isbn | +--------------+----------+------------+ | 1 | NULL | 0406939985 | | 2 | TB | 0521545153 | | 3 | TB | 0406948291 | | 4 | NULL | 0596001452 | | 5 | NULL | 1930110065 | | 6 | NULL | 1565922433 | +------------------+----------+------------+ 6 rows in set (0.00 sec) The 852 line still shows as TB although the itemtype line in the table is NULL. It has somehow found its way into marc_subfield_table: select subfieldid,bibid,tag,subfieldcode,subfieldvalue from marc_subfield__table where bibid='6'; +------------+-------+-----+--------------+------------------------+ | subfieldid | bibid | tag | subfieldcode | subfieldvalue | +------------+-------+-----+----+----------------------------------+ | 89 | 6 | 010 | a | 99176053 | | 90 | 6 | 020 | a | 1565922433 | | 91 | 6 | 035 | a | (DLC) 99176053 | | 92 | 6 | 035 | a | (OCoLC)39872119 | | 93 | 6 | 852 | k | TB | | 94 | 6 | 100 | a | Christiansen, Tom. | | 95 | 6 | 245 | a | Perl cookbook / | | 96 | 6 | 260 | c | c1998. | | 97 | 6 | 300 | a | xxxiv, 757 p. ; | | 98 | 6 | 300 | c | 24 cm. | | 99 | 6 | 650 | a | Perl (Computer program language) | | 100 | 6 | 650 | a | Perl (Computer program language) | | 101 | 6 | 090 | c | 6 | | 102 | 6 | 090 | d | 6 | | 103 | 6 | 952 | b | RH | | 104 | 6 | 952 | d | RH | | 105 | 6 | 952 | u | 5 | +------------+-------+-----+--------------+------------------------+ 17 rows in set (0.00 sec) Have 852 and 952 got mixed up somewhere? (RH, ie Roger Horne, is what I would have expected to see in "location" on a search.) But it turns out to be more complicated ... On a simple search the location of the Perl Cookbook shows correctly as Roger Horne (although it doesn't in a Marc search). But the location of the Mysql Cookbook doesn't show as Roger Horne in a simple search but as a blank (but shows as TB in a full search). There are very small differences in the marc_subfield_table but nothing that would appear to cause this: +------------+-------+-----+--------------+----------------------------------------+ | subfieldid | bibid | tag | subfieldcode | subfieldvalue | +------------+-------+-----+--------------+----------------------------------------+ | 69 | 5 | 010 | a | 2002281940 | | 70 | 5 | 020 | a | 1930110065 | | 71 | 5 | 035 | a | (OCoLC)ocm49871541 | | 72 | 5 | 852 | k | TB | | 73 | 5 | 100 | a | Petersen, Theo. | | 74 | 5 | 245 | a | Web development with Apache and Perl / | | 75 | 5 | 260 | c | c2002. | | 76 | 5 | 300 | a | xviii, 410 p. : | | 77 | 5 | 300 | b | ill. ; | | 78 | 5 | 300 | c | 24 cm. | | 79 | 5 | 650 | a | Perl (Computer program language) | | 80 | 5 | 650 | a | Web site development. | | 81 | 5 | 650 | a | Open source software. | | 82 | 5 | 650 | a | Open source software. | | 83 | 5 | 090 | c | 5 | | 84 | 5 | 090 | d | 5 | | 85 | 5 | 952 | u | 3 | | 86 | 5 | 952 | b | RH | | 87 | 5 | 952 | d | RH | | 88 | 5 | 952 | u | 4 | Roger -- Roger Horne, 11 New Square, Lincoln's Inn, London WC2A 3QB mailto:roger@number7.demon.co.uk

6 7

virus from poland
by paul POULAIN 19 Apr '04

19 Apr '04

Hi there, Today, I recieve between 10 & 20 mails per hour, that "say" they come from poland (almost all), and are sent on my koha-fr.org mailbox (paul_koha-fr.org) I think one of the polish guy involved in Koha, has got something bad in it's winshit. Here are some of the "sender" addresses : 3dartures1__wp mz.t__wp biuro.om__pttk.torun klub__ktk-przygoda.torun webmaster__petrus biuro__wedrowiec.krakow info__gniecki.prv madzia791__wp pracaulotki__wp (.pl removed in every adress & @ replaced by __) If someone know all the false "senders", then, it's probably the person infected. NB : the IP of the sender (the only true information) is always : 212.160.112.160 So, if one of the reader has it now, then it's him ! -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)

1 0

Re:[Koha-devel] Re: [Koha] uninstalling
by lstamm＠telus.net 18 Apr '04

18 Apr '04

Roger Horne <roger(a)hrothgar.co.uk> writes: <snip> > The 852 line still shows as TB although the itemtype line in the > table is NULL. It has somehow found its way into > marc_subfield_table: I think at least part of your problems are due to having NULL values in the itemtypes field. If you have anything else in this field other than the one of the values in the itemtypes table, all sorts of miscellaneous errors seem to happen. The first step in configuring Koha is to add values to the itemtypes table, and then make sure every catalogue item you enter has a valid itemtype in the 852 k field. > And I chose the budget based entry system. Unless you have a valid reason for using the budget based system (such as wanting to keep track of how much book value each person has contributed to your collection), I would suggest using the simple acquisition module instead. As the name suggests, it's simpler. :) Regards, -- Larry Stamm PO Box 561 McBride, BC V0J 2E0 Canada http://www.larrystamm.com

1 0

CVS symlinking
by Benedykt P. Barszcz 17 Apr '04

17 Apr '04

Hi group, I am trying to symbolically link the CVS tree with koha 2.0 but no success. Apache complains: [Sat Apr 17 17:23:39 2004] [error] [client 127.0.0.1] Symbolic link not allowed: /usr/local/koha/intranet/cgi-bin [Sat Apr 17 17:23:42 2004] [error] [client 127.0.0.1] Symbolic link not allowed: /usr/local/koha/intranet/cgi-bin Httpd.conf file has this: # KOHA's OPAC Configuration <VirtualHost localhost.localdomain:80> ServerAdmin kb2qzv(a)localhost.localdomain DocumentRoot /usr/local/koha/opac/htdocs ServerName localhost.localdomain ScriptAlias /cgi-bin/koha/ /usr/local/koha/opac/cgi-bin/ ErrorLog /usr/local/koha/log/opac-error_log TransferLog /usr/local/koha/log/opac-access_log SetEnv PERL5LIB "/usr/local/koha/intranet/modules" SetEnv KOHA_CONF "/etc/koha.conf" <Directory /usr/local/koha> Options Indexes FollowSymLinks </Directory> The above is just for the OPAC, the same is true for the INTRANET. Symbolic link is set to my cvs directory. I changed file ownership to apache.apache for the whole tree of the kohaCVS, and chmod -R 755, too. Any hints? Benedict

2 1