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

Koha on CD
by Tonnesen Steve 11 Sep '02

11 Sep '02

I've created a bootable CD that boots linux with Koha installed directly off the CD. I'm hoping this might be useful for: 1. Demo'ing Koha at trade shows and the like 2. Demo'ing Koha to librarians at their library 3. Interested parties who are not familiar with installing Linux 4. Actually running a production server with data stored on a hard drive and all other files running off of the CD. Some of the 'gotchas' with KohaCD: 1. Requires a computer that is CD-bootable 2. Requires a second computer networked to the first for actually running a browser to access Koha. It's technically possible to put X and Mozilla on the CD but that's a task I'm not up to at the moment. I've created a page on the wiki documenting some of this. Steve.

1 0

1.2.3RC11: Minor comments
by rbrown64＠csc.com.au 11 Sep '02

11 Sep '02

Minor comments from a quick look at the code. A number of the files have a large number of trailing blanks - as though they've been editted with a line editor that leaves files as fixed width. Please consider trimming trailing blanks for the release - when they push the line length over 80-bytes as they do in a number of cases they make it harder to read. find . -name '*.p[lm]*' -print | xargs egrep -l ' *$' /dev/null Within modules/C4/Search.pm the code to escape apostrophes should be doing a global replace. $search->{'keyword'}=~ s/'/\\'/; should be $search->{'keyword'}=~ s/'/\\'/g; For smaller search SQL the search subroutines could deduplicate key words so that 'The cat sat on the mat' doesn't look for 'the' twice. It would make sense to generalize the 'NZ' <=> 'New Zealand' abbreviation expansion. I'm not sure whether the current implementation adequately uses the restrictions on other keywords. (ie whether 'New Zealand Birds' gets you everything with NZ in it). The code after the call to modules/C4/Search.pm:itemcount in the following files is quite similar. intranet-cgi/acqui/newbasket2.pl intranet-cgi/subjectsearch.pl opac-cgi/subjectsearch.pl Consider providing an alternative method in Search.pm that gives the formatted counts for On Loan, Levin, Foxton ... as a string with a parameter for the extra stuff in newbasket2 (Lost, Mending, In Transiit (sp?) if ($transit > 0){ $stuff[5]=$stuff[5]."In Transiit"; if ($transit >1 ){ $stuff[5]=$stuff[5]." ($transit)"; } $stuff[5].=" "; } I would have been tempted to write this as if ($translit > 0) { $stuff[5] .= 'In Transiit ' . (($transit > 1) ? "($transit) " : ''); } or even $stuff[5] .= 'In Transiit ' . (($transit > 1) ? "($transit) " : '') if $translit > 0; but the latter is a bit write only. The CheckDigit Excel spreadsheet http://developer.koha.org/HLT2.xls is inaccessable. "Forbidden You don't have permission to access /HLT2.xls on this server." The best reference I've seen on check digits is Error Detecting Decimal Digits, Neal R Wagner and Paul S Putter, Comm. ACM Jan 1989 Vol 32 No 1 pg 106-110. Hope this is useful. Regards,

1 0

call for contributions
by Pat Eyler 10 Sep '02

10 Sep '02

Hello all, I'm putting together this weeks 'From the Kaitiaki' note right now. I'd appreciate it if you could send me a quick blurb on anything you'd like to me to put into the newsletter. thanks, -pate Pat Eyler Kaitiaki/manager migrant Linux sys admin the Koha project ruby, shell, and perl geek http://www.koha.org http://pate.eylerfamily.org

1 0

RE: Koha
by Pat Eyler 10 Sep '02

10 Sep '02

On Tue, 10 Sep 2002, Anthony W. Youngman wrote: > Hi Pat, > > sorry to take a while to get back. I've been marshalling my thoughts > somewhat (I'd asked Brian for a contact e-addy and wasn't quite expecting > him to forward my details to you, not that I'm unhappy he did...). Actually, I asked him for your email address when he said that you were trying to get in touch with me. > > Were Dynix a Pick licencee? The name sounds familiar, but I'm not sure > whether that's why. I'm pleased to know you know MV - shame you don't seem > such a fanatic as me :-) Dynix used Unidata (at least while I was there, I'd assume that they're now UniVerse users). > > "Custom database". Where I saw it - in your FAQ, namely "What record formats > does Koha support?". Hmm, that's not terribly clear (although it's aimed at librarians, not developers). It would better read, "We're currently using a custom database schema to organize our records in a MySQL database.", or something like that. > > Which is why I thought Pick might be an excellent fit for Koha - seeing as a > library database is heavily text oriented, and Pick is 100% text based ... > :-) Looking at the MARC layout, it seems an even better fit. Obviously, > seeing as you know MV, you'll know what I'm getting at, but I'd store one > MARC record per Pick record. Together with hefty indexing, I'd expect that > to blow MySQL out of the water for speed of retrieval. Unfortunately, what > with the speed of disks and the amount of RAM modern computers have, being > 500% faster probably doesn't count for much :-( > > I know the biggest impediment to switching to an underlying MV database is > "it's different", and I well understand your concerns, but surely it can't > be that hard... :-) bearing in mind so many Pick sites have users writing > very functional code ... :-) although I heartily concur with you wanting > programmers to keep in control of things! I've cleaned up too many messes in > my time created by people who didn't understand the basics :-( Oh well, > that's life. > > By the way, MaVerick will sit on top of MySQL - when we get a working TCL in > place (it might well be here by now) we should be able to define DICTs and > read Koha files directly in MaVerick ... so it might well be possible to > make the back ends interchangeable. But to argue that using MaVerick would > make a massive speed difference on a 16Mb 486 wouldn't cut much ice, even > though it's true :-) > > I'll look at oss4lib and see what's there, and I'll hunt up my code. But if > you want to pick up some interesting stuff on how Pick does (and MaVerick > will) handle fast native text retrieval, go to www.oliver.com, into mailing > lists, files, and look at a couple of papers that are there. One is called > "Litwin", I think, and the other is called dynamic_hash_coding. Well, you keep working on MaVerick, we'll keep working on Koha, and maybe at some point things will merit another look. In the meantime, do get involved with OSS4Lib, it's a good list and, who knows, you might end up convincing a few people that MV is in fact the way to go. BTW, I'm CC:ing the koha-devel list just so that the discussion can hit a few more eyes and ears. -pate > > Cheers, > Wol > > -----Original Message----- > From: Pat Eyler [mailto:pate@eylerfamily.org] > Sent: 08 September 2002 00:55 > To: Anthony W. Youngman > Subject: Re: Koha > > > On Sat, 7 Sep 2002, Anthony W. Youngman wrote: > > > In message <Pine.LNX.4.44.0209052116510.1556-100000(a)petrol.whirlycott.co > > m>, Pat Eyler <pate(a)eylerfamily.org> writes > > >Anthony, > > >Brian Profitt said that I should drop you a line about Koha. He > mentioned > > >that you had some ideas that could benefit the project. What's on your > > >mind? > > > > > > This transmission is intended for the named recipient only. It may contain > private and confidential information. If this has come to you in error you > must not act on anything disclosed in it, nor must you copy it, modify it, > disseminate it in any way, or show it to anyone. Please e-mail the sender to > inform us of the transmission error or telephone ECA International > immediately and delete the e-mail from your information system. > Telephone numbers for ECA International offices are: Sydney +61 (0)2 9911 > 7799, Hong Kong + 852 2121 2388, London +44 (0)20 7351 5000 and New York +1 > 212 582 2333. > >

1 0

[Bug 92] Koha may not work with non-Apache webservers
by bugzilla-daemon＠wilbur.katipo.co.nz 10 Sep '02

10 Sep '02

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=92 ------- Additional Comments From a.c.li(a)ieee.org 2002-09-10 18:55 ------- Created an attachment (id=7) Update to the INSTALL file ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 92] New: Koha may not work with non-Apache webservers
by bugzilla-daemon＠wilbur.katipo.co.nz 10 Sep '02

10 Sep '02

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=92 Summary: Koha may not work with non-Apache webservers Product: Koha Version: CVS Platform: All OS/Version: All Status: NEW Severity: trivial Priority: P2 Component: Installation AssignedTo: tonnesen(a)cmsd.bc.ca ReportedBy: a.c.li(a)ieee.org QAContact: koha-devel(a)lists.sourceforge.net The SSI "INCLUDE VIRTUAL" directive used by Koha does not work with Roxen. The INSTALL file should probably be updated to reflect this fact. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 91] installer.pl does not work with CVS version
by bugzilla-daemon＠wilbur.katipo.co.nz 10 Sep '02

10 Sep '02

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=91 ------- Additional Comments From a.c.li(a)ieee.org 2002-09-10 18:35 ------- Created an attachment (id=6) Proposed patch to fix/workaround the reported problems ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 91] New: installer.pl does not work with CVS version
by bugzilla-daemon＠wilbur.katipo.co.nz 10 Sep '02

10 Sep '02

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=91 Summary: installer.pl does not work with CVS version Product: Koha Version: CVS Platform: PC Status: NEW Severity: normal Priority: P2 Component: Installation AssignedTo: tonnesen(a)cmsd.bc.ca ReportedBy: a.c.li(a)ieee.org QAContact: koha-devel(a)lists.sourceforge.net The installer.pl script does not work with CVS, esp. since the CVS version has a very different directory structure. The following problems seems to be in the installer.pl in CVS: - Check for rootness is duplicated - Some mkdir calls have their arguments reversed (Perl will complain) - It cannot handle the CVS directory structure - It will think that itself is installed even if installation had been aborted - Cannot handle unusual mysql locations ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 90] New: delbibitem.pl missing?
by bugzilla-daemon＠wilbur.katipo.co.nz 09 Sep '02

09 Sep '02

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=90 Summary: delbibitem.pl missing? Product: Koha Version: 1.2.3 Platform: PC OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Catalogue AssignedTo: chris(a)katipo.co.nz ReportedBy: tonnesen(a)cmsd.bc.ca QAContact: koha-devel(a)lists.sourceforge.net There's a button to delete a biblioitem on the moredetail.pl page, but there is no delbibitem.pl script. Is this script really lost? ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

about MARC format
by paul POULAIN 09 Sep '02

09 Sep '02

This mail is primarily for Steve and continues an IRC conversation we had on friday, but I think it could interest other koha developers and readers of this ml. The problem : We have 2 problems with MARC-DB structure : The 1st, which is solved, was that repeatable tags we not rightly stored in our structure : thus, it was hard to differenciate lines. The problem will be solved by adding a "tag number" field in the DB. Should be cvsed soon... The 2nd, which is still to solve, is multiple-items support. We plan to support many MARC (MARC21, UNIMARC...) by having a parameter table. But the BIG problem is that koha "items" are managed completly differently in MARC21 and in UNIMARC. In fact, in true-UNIMARC they are not supported... In france, they are supported by a "almost-official" document, the "995 tag", which defines the 995 tag as the koha-item field. So, when there are more than 1 item of a given biblio, how to manage them in MARC-DB. Quite impossible with actual DB structure. I've had a simple idea during the we, which, I'm almost sure, is the best one : In our MARC sructure, we have a old-DB-"biblio" field that links the old DB and the MARC one. We should add a "koha-item" field in the DB that links a old-DB item and a "MARC-item". In the MARC-API, we should add a MARCadditem, MARCmoditem and MARCdelitem sub. I'll try this very soon, unless someone (steve ?) points me an error. -- Paul

1 1