- Koha - lists.katipo.co.nz

Bug?
by Tom Albrecht 28 Jun '02

28 Jun '02

Hi all... I'm new to the list, and I've been searching through the archives for information on the following bug, and didn't see anything, so I decided to post it. Please don't flame me. In many of the perl files, the following code exists... print mktablerow(5,$toggle,$results->[$i]{'printername'},$results->[$i]{'printqueue'},$results->[$i]{'printtype'}, mklink("$script_name?op=add_form&searchfield=".$results->[$i]{'printername'},'Edit'), mklink("$script_name?op=delete_confirm&searchfield=".$results->[$i]{'printername'},'Delete','')); Now, when I ran these perl functions "out of the box" I was gettig 500 server errors... digging through the apache logs, I see the following. Too many arguments for C4::Output::mklink at /home/httpd/cgi-bin/koha/admin/printers.pl line 227, near "'')" Execution of /home/httpd/cgi-bin/koha/admin/printers.pl aborted due to compilation errors. [Thu Jun 27 23:44:22 2002] [error] [client 66.92.231.155] Premature end of script headers: /home/httpd/cgi-bin/koha/admin/printers.pl Odd, I think to myself, so I look at the two calls to "mklink" and I see that they do, in fact, have a different number of parameters. Now, since the final parameter in the "delete" call is blank, I tried deleting the last parameter, and it works (well, at least it displays). Is this a legitimate bug, or did I totally screw something up? Tom Albrecht III West Chester, PA United States of America

2 1

From the Kaitiaki
by pate＠bigfun.whirlycott.com 28 Jun '02

28 Jun '02

28 June, 2002 To the Koha community; Namaskar, This week's note is a short one. Not because we haven't done much, but because we're all getting pretty busy. I'm currently talking to a couple of organizations about getting some more visibility for Koha. I don't want to tip my hand just yet, but I'm hopeful that we'll see Koha beginning to make appearances in the bigger Open Source world 'Real Soon Now'. We're also starting to see some more feedback from other library centric Open Source projects. It looks like the idea of some inter-project cooperation is gaining ground. One interesting area that came up was in helping one another in securing financing (sponsorship, hired work, or grants all come to mind) -- this will be an important area for Koha moving forward. Free Software doesn't come without a price tag, the price is just hidden better than with other software. Much of Koha is developed by volunteers in their 'spare' time. If there were funding available for given tasks, it would give the developers more time to work on Koha (because they'd need to spend less time making a living). If you're interested in helping this way, please take a look at <http://koha.org/installation/support.html> for some potential vendors. 1.2 We're still hard at work on 1.2.1. In fact, Steve Tonnesen has produced three Release Candidates this week alone. He's also made the job easier by automating this process, so expect to see Release Candidates for every future release -- it's another way we're trying to improve our process. Other big features for 1.2.1 include: * a much improved installer (it only requires 1 ip address, and creates a branch and a printer during install now) * more work on the Z39.50 programs * sample data that can be installed to test a new koha system Many thanks to Paul and Steve who've both jumped in and are making the 1.2 series really shine. Translations The first question people seem to ask when volunteering to do translations of Koha is, "Where do I start?". Since we're still on the verge of having the application readily translatable, this question deserves a thoughtful answer. There are a number of things that could be translated and provide value to the project. These newsletters, if translated, could help advertise Koha to people who don't currently know about it. The Manual could be translated to help users and developers who don't understand english. I think one of the best documents to translate would be the INSTALL document. If we could get this done in multiple languages, it would be much easier to get Koha into the hands of the people who will help us make it suitible for international use. IRC Meeting Due to some scheduling conflicts, this weeks irc meeting was postponed. We're going to shoot for 7/11 (7/4 is a big holiday in the US, so that won't work either). The proposed agenda is currently: * CVS * 1.2 schedule * 1.4 plans * thoughts on templating * translations * documentation housekeeping * community (Koha, and the larger OSS4lib, and the larger library * new koha website Community The Koha community is continuing to grow. More libraries are trying Koha out, and many of them are sticking with it. We've added more people to the developers list, several of whom are concentration on testing new Koha releases. Another exciting advance is the new <www.koha.org> website. Rachel and her team at Katipo have done a wonderful job. I'd like to hear back from people who are currently using or investigating Koha. If you've got stories, requests, or suggestions, please feel free to drop me a line at: kaitiaki(a)koha.org Dhanyabad, -pate Pat Eyler Kaitiaki of the Koha Project ps. This weeks language is Bengal. Hopefully my usage isn't too far off. Thanks Md. Aftabuddin, for helping out.

1 0

upgrade script
by Tonnesen Steve 27 Jun '02

27 Jun '02

I managed to put together an upgrade script today that will be going out with the 1.2.1 release. The upgrade script (koha.upgrade) will make backups of your koha data, and all of the koha scripts and html files before installing the new files and making any necessary changes to the database. The upgrade script also indicates changes that may need to be made to the Apache configuration. I suspect there aren't a whole pile of production Koha systems out there yet, apart from Katipo's clients and my schools. If you _are_ using Koha in a production environment, I'd really appreciate hearing from you before the 1.2.1 release goes out. Steve.

1 0

Koha install problem summary, final I hope
by Md. Aftabuddin 25 Jun '02

25 Jun '02

On Sat, 22 Jun 2002, Pete Dubler wrote: > Below is a summary list of the problems I am experiencing with my new > fresh install of Koha 1.2.1 on my new server running RH 7.1 > > Each problem is started with "***" subtopics of that problem start with > "###" > > I will be using my koha system to do two things: > 1-Track all of the science resources on my charter K-12 school campus. > Teachers will be able to search for items using keywords and then check > them out to themselves for use in their classrooms. I would like to be > able for them to know who has an item check out so they can go get it > directly from that person. > > 2-Bring up our new library for the whole school on koha, using the same > server. > > I need to be "on-the-air" by July 5 as we move all our inventory into > our new building and receive new big shipments the week of July 8. > > The good news is that I have all of the networking stuff worked out and > have koha (lib) and opac (lookup) running across my home network. Now > if I can just get all of this volunteer work done for the school without > burning down my house, from all of the computers in my home office, and > starting the next wildfire in Colorado... > > Thanks for any and all help you can provide. Special thanks to Chris, > CJ, Md, and Pat for their help to date. > > Pete Dubler > for Ridgeview Classical Schools > Fort Collins, Colorado > > *** Acquisitions: I still can't get the "simple" acquisitions version to > load. But, I can force myself into it by using a link like: > http://lib/cgi-bin/koha/acqui.simple/addbooks.pl > (lib is the name of this virtual server underwhich koha is running). I > have tried using mysql with the command: > > update systempreferences set value='simple' where > variable='acquisitions'; > quit; The command is insert into systempreferences values('acquisitions','simple'); quit; > > with no success. (stopped mysqld, restarted httpd, started mysqld, > flushed netscape caches). I have webmin and first set the > systempreferences table to be modifiable in everyway by root. Advice? > > > *** Addbooks: When I go to add a book (using the armstrong method > outlined above), I understand that there are three screens that one has > to complete . I complete the first 'Section One: Copyright Information' > and press 'add new bibliography', then it brings up the second 'Section > Two: Publication Information for Test Book by Tommy Tester', which I > complete and press 'add new bibliography'. It then returns me to a > blank first screen, 'Section One: Copyright Information'. What's with > that? > Solution is below, after circulation. > *** Circulation: Comes up without the "Choose a branch" and "Choose a > printer" pulldowns. So per earlier advice, I tried to add a branch and > printer to my database. Below is what happened. > you have to enter atleast one record for printer and branches table insert into printers values('xxx','yyy','zzz'); insert into branches (branchcode,branchname, issuing ) values('abc','name of the branch','1'); ====note===replace 'abc' and 'name of the branch' with suitable words you ====prefer. replacement of 'abc' can be maximum of four charecters. ====memorise the the replaced word with 'abc'.It will be required for the ====three page book insertion. for addbooks : modify the file addbools.pl find the word SWTE and change with the word you memorised above in Circulation reply. In three places you have to change. > ### Parameters:Library Branches: I cannot add a new branch > successfully. When I try by filling out the form and pressing "OK", I > just get a blank page. I do not know what goes in the "Issuing" field, > so I have once left it blank and another time just put 'ok' in it. > Advice? > where do you get the above page ? > Things I know: > * Koha is my database and according to mysqlshow and webadmin, it > is there. > * mysqld is running. > * (I also know other things, in case you were wondering, but they > are not relevant to this situation ;^) > > ### Parameters: Printers: I was able to add a printer named "LaserJet" > on the lpt queue of the type local. > > *** Adding Members: I am unable to add members because I do not know > the valid range for library card numbers. Anyone able to provide me a > pointer here? (eg man page to refer to) > add another record in the systempreferences table insert into systempreferences values('autoMemberNum','1'); > *** Adding Members: How hard would it be to modify this screen to > reduce the number of fields since I really only need names and card > numbers? This would mean telling the database that the other 'required > fields' are not required. > Md. Aftabuddin

1 0

Re: [Koha] importing MARC records
by Alan Millar 25 Jun '02

25 Jun '02

> From: micheas <micheas(a)micheas.dyns.net> > FreeBSD does not have an equivalent of linux's 'su -c' Equivalent? You're right the FreeBSD "su" command does not have the same option to run an arbitrary command as an argument, but there are other ways to solve the problem. Worst case, the z3950-daemon-shell can be SUID with the appropriate file owner. Not the ideal solution, but it is functionally equivalent. I think this falls in the "keep looking" category. > Are any of the environment names set by the shell script passed to > the perl script that runs the daemon by name (ie do I have to keep > your variable names?) No, you don't have to keep them. Do they need to be changed? If they aren't descriptive or explanatory enough, let's change them in the current script also. > Is there any reason to not have apache call the script? (ie does > anything have to be done as root?) Yes, there is a reason not to. For one, the Linux "su -c" does need to be root. Also, the script should be run once, not everytime someone makes a search request. I don't think Apache was designed to be an arbitrary launcher, so it would probably be a lot *more* work to shoe-horn it into Apache. And the search daemon isn't really Apache related. I have some command-line text-mode add-ons for Koha, which may show up in the release later, which use the Z39.50 search facilities. They don't have anything to do with Apache, and neither does the search daemon. <rant> Only bad applications are "purely" web-based. Good applications have a major amount of web facing to them, but also have parts that are abstracted from it so they are useful in other ways also, such as batch automation. "I don't *want* to click [Submit] 483 times..." </rant> > Does it make sense to try changing the perl script instead of > rewriting the shell scripts for each os? No. The shell scripts should handle each OS's various quirks, precisely so the Perl script *doesn't* have to change for each OS. If you look closely, after all the comments and overhead are stripped out, the two Z39.50 scripts do only two lines of actual work: The -launch script uses "su" to change the user ID, and the -shell script sets PERL5LIB before running the daemon. That's the only actual work done in the scripts. Everything else in there now is either comments or fluff. Anything else needed for another OS should be encapsulated in the script likewise. So a "rewrite" of the scripts should be two or three lines of code. > Telnet terminals -- HERE BE DRAGONS -- these maybe problematic under > FreeBSD. Actually, this is non-issue. The name "Telnet terminals" is misleading. It really just means "text mode". There is absolutely nothing special about Telnet. It's a handy name because people know that when you use telnet, you get a text-mode session. You can use SSH and the program will be exactly the same. Thanks for your work in identifying issues. - Alan ---- Alan Millar --==> am12(a)bolis.com <==--

2 2

delaying irc meeting
by Pat Eyler 25 Jun '02

25 Jun '02

Today's irc meeting is being postponed until next week due to some end of year (financial year that is) requirements at katipo. A new meeting will be scheduled soon. thanks, -pate

1 0

Re: [Koha] 1.2.0 Problems
by User genjimoto 24 Jun '02

24 Jun '02

> On Fri, 21 Jun 2002, ed sharpe wrote: > > Ed, this would be a wonderful place to get to. It will take time (and > some $$$) to do so though. > (or someone to pay us to pay staff to do do it). oh.. Where do i get a koha testing job? > We'll also need to build > a test harness that we can use to verify that the install went as >planned. Test harness? > Once those are handled, it will be important to account for >differences in > the way some tools get installed. (How many ways can apace be >installed > on a server?) > > Given all of the difficulties, I hope that this is one area that emerging > koha support companies can/will take on. I also hope it is an area where > libraries (or other interested parties) will be willing to step up and > commit resources. A koha support business... hmm.. how would i create one? > > > > what needs to be done is to determine which environments this should be I > > suppose. > > > > We could build a wishlist, but since we're talking about volunteers, I > think we're going to end up supporting whatever people are willing to work > on (probably Red Hat and Debian at first), or people are willing to pay > people to work on (I'm not sure what systems fall into this category). > > > -pate > > > ed sharpe archivist for smecc > > ----- Original Message ----- > > From: "Pat Eyler" <pate(a)eylerfamily.org> > > To: <COURYHOUSE(a)aol.com> > > Cc: <koha(a)lists.katipo.co.nz>; <Koha-devel(a)lists.sourceforge.net> > > Sent: Friday, June 21, 2002 7:20 AM > > Subject: Re: [Koha] 1.2.0 Problems > > > > > > > On Fri, 21 Jun 2002 COURYHOUSE(a)aol.com wrote: > > > > > > > I think there needs to be tighter Quality control on the releases. > > > > > > This sounds like a good challenge for us to take up. We're working on > > > quality control, believe it or not ;). the 1.2 release series mark the > > > first non-katipo releases, which mean that there will be a bit of a > > > learning curve for us all. Hopefully as we crest theat curve, you'll be > > > seeing things improve (note for example the 1.2.1 release, coming soon, > > > that is undergoing additional testing prior to its release). > > > > > > Beyond this, it would be nice if people who where willing to test > > > pre-releases would sign up on the devel list. We announce the releases > > > and make release candidate (RC) tarballs to that list (The 1.2.0 release > > > had three RC tarballs before we got to the release.) > > > > > > If anyone else has thoughts about how we can improve the quality of > > > upcoming releases, I'd love to hear them. > > > > > > -pate > > > > > > > > > > > > > > Ed Sharpe archivist for SMECC > > > > > > > > > > > > > Subj:Re: [Koha] 1.2.0 Problems > > > > > Date:6/20/2002 4:34:41 PM US Mountain Standard Time > > > > > From:<A HREF="mailto:pate@eylerfamily.org">pate(a)eylerfamily.org</A> > > > > > To:<A HREF="mailto:broot@gslis.utexas.edu">broot(a)gslis.utexas.edu</A> > > > > > CC:<A > > HREF="mailto:koha@lists.katipo.co.nz">koha(a)lists.katipo.co.nz</A>, <A > > HREF="mailto:Koha-devel@lists.sourceforge.net">Koha- devel(a)lists.sourceforge. > > net</A> > > > > > Sent from the Internet > > > > > > > > > > > > > > > > > > > > On Thu, 20 Jun 2002, Shane Williams wrote: > > > > > > > > > > > I've been watching Koha's progress for a couple of years now. I > > tried > > > > > > 1.04, had some install troubles (with CDK in particular) and put it > > on > > > > > > the backburner. > > > > > > > > > > Thanks for sticking with Koha. > > > > > > > > > > > > > > > > > In any case, I decided 1.20 was a good point to reassess things. > > > > > > Things are looking much better (thank you so much for the web > > > > > > interface, now I don't have to monkey with CDK). That said, I've > > had > > > > > > a number of problems with 1.20 as well. Looking at the recent list > > > > > > archive I can see that others are having trouble with 1.2.0 as well. > > > > > > > > > > > > > > > > Yep, there are some issues with 1.2.0, a 1.2.1 release to fix the > > things > > > > > we've seen should be out shortly. > > > > > > > > > > > I just wanted to lay out a few of the problems I've had (some may be > > > > > > repititions of other's posts). > > > > > > > > > > > > 1) Several links to koha.some.where/cgi-bin/koha/etc. that failed > > > > > > based on the example <VirtualHost> entries. My solution was to > > change > > > > > > my ScriptAlias entry in httpd.conf to: > > > > > > > > > > > > ScriptAlias /cgi-bin/koha/ /home/httpd/koha/cgi-bin/ > > > > > > instead of: > > > > > > ScriptAlias /cgi-bin/ /home/httpd/koha/cgi-bin/ > > > > > > > > > > > > > > > > > > 2) On the members/index.html there's a link to > > members/results-add.html, > > > > > > but no such file exists. > > > > > > > > > > > > > > > > > > 3) The other problem, which Pete mentioned in his "koha install > > problems > > > > > > on RH 7.2 MORE DATA" is that all but one of the scripts in > > > > > > koha/cgi-bin/admin/ have compilation problems. For instance, > > running > > > > > > perl -cw branches.pl leads to: > > > > > > > > > > > > Scalar value @biblioitems[$x] better written as $biblioitems [$x] at > > > > > > /usr/lib/perl5/site_perl/5.6.0/i386-linux/C4/Reserves2.pm line 189, > > > > > > <KC> line 6. > > > > > > "my" variable $sth masks earlier declaration in same scope at > > > > > > branches.pl line 192, <KC> line 6. > > > > > > Too many arguments for C4::Output::mklink at branches.pl line 262, > > > > > > near "'')" > > > > > > branches.pl had compilation errors. > > > > > > > > > > > > > > > > > > 4) A few other notes. In the INSTALL file, there are a few > > confusing > > > > > > spots. One is that database name in all the mysql commands is Koha, > > > > > > but in the sample koha.conf file it's koha. Also, at least with > > perl > > > > > > 5.005 the -I option must come before the script name, so the > > command: > > > > > > > > > > > > perl scripts/updater/updatedatabase -I /pathtoC4 > > > > > > should probably read (and why not point to the pathtoC4 dir): > > > > > > > > > > > > perl -I modules/ scripts/updater/updatedatabase > > > > > > > > > > > > > > > > > > All in all though, things are looking good. Once the admin scripts > > > > > > get fixed up, I'll start showing it off to the folks here at the > > > > > > Library and Information Science School. Thanks for all the hard > > work. > > > > > > > > > > > > > > > > Great! Please let us know how things go. And what we can do to help > > make > > > > > the presentation go more smoothly. > > > > > > > > > > -pate > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Koha mailing list > > > Koha(a)lists.katipo.co.nz > > > http://lists.katipo.co.nz/mailman/listinfo/koha > > > > > > > > > > > _______________________________________________ > Koha mailing list > Koha(a)lists.katipo.co.nz > http://lists.katipo.co.nz/mailman/listinfo/koha > >

2 1

translations of Koha
by COURYHOUSE＠aol.com 24 Jun '02

24 Jun '02

How is the translation process being done? Is there one central message file? It would be ackward to have many versions in many languages having to be kept up to date.. if the text messages are not in just a central message file now might be the time to think about doing it thus. Ed Sharpe archivist for SMECC

5 6

Re: [Koha] importing MARC records
by COURYHOUSE＠aol.com 24 Jun '02

24 Jun '02

Just have the script work for all op sys. Have script check for type of op sys and then jump to script section that correctly addresses the op sys the script is running on thus it could be a one shot solution for free bsd or LINUX.. Ed Sharpe archivist for SMECC > Subj: Re: [Koha] importing MARC records > Date: 6/23/02 11:39:39 PM US Mountain Standard Time > From: am12(a)bolis.com (Alan Millar) > Sender: koha-admin(a)lists.katipo.co.nz > To: koha(a)lists.katipo.co.nz > > > > > > From: micheas <micheas(a)micheas.dyns.net> > > > FreeBSD does not have an equivalent of linux's 'su -c' > > Equivalent? You're right the FreeBSD "su" command does not have > the same option to run an arbitrary command as an argument, but there > are other ways to solve the problem. Worst case, the z3950-daemon-shell > can be SUID with the appropriate file owner. Not the ideal solution, > but it is functionally equivalent. I think this falls in the "keep looking" > category. > > > Are any of the environment names set by the shell script passed to > > the perl script that runs the daemon by name (ie do I have to keep > > your variable names?) > > No, you don't have to keep them. Do they need to be changed? If they > aren't descriptive or explanatory enough, let's change them in the > current script also. > > > Is there any reason to not have apache call the script? (ie does > > anything have to be done as root?) > > Yes, there is a reason not to. For one, the Linux "su -c" does need > to be root. Also, the script should be run once, not everytime > someone makes a search request. I don't think Apache was designed > to be an arbitrary launcher, so it would probably be a lot *more* work > to shoe-horn it into Apache. And the search daemon isn't really > Apache related. I have some command-line text-mode add-ons for Koha, which > may show up in the release later, which use the Z39.50 search facilities. > They don't have anything to do with Apache, and neither does the search > daemon. > > <rant> > Only bad applications are "purely" web-based. Good applications > have a major amount of web facing to them, but also have parts > that are abstracted from it so they are useful in other ways also, > such as batch automation. "I don't *want* to click [Submit] 483 times..." > </rant> > > > Does it make sense to try changing the perl script instead of > > rewriting the shell scripts for each os? > > No. The shell scripts should handle each OS's various quirks, precisely > so the Perl script *doesn't* have to change for each OS. > > If you look closely, after all the comments and overhead are stripped > out, the two Z39.50 scripts do only two lines of actual work: The -launch > script uses "su" to change the user ID, and the -shell script sets > PERL5LIB before running the daemon. That's the only actual work > done in the scripts. Everything else in there now is either comments > or fluff. Anything else needed for another OS should be encapsulated > in the script likewise. So a "rewrite" of the scripts should be two > or three lines of code. > > > Telnet terminals -- HERE BE DRAGONS -- these maybe problematic under > > FreeBSD. > > Actually, this is non-issue. The name "Telnet terminals" is > misleading. It really just means "text mode". There is absolutely > nothing special about Telnet. It's a handy name because people > know that when you use telnet, you get a text-mode session. > You can use SSH and the program will be exactly the same. > > Thanks for your work in identifying issues. > > - Alan > > ---- > Alan Millar --==> am12(a)bolis.com <==-- > _______________________________________________ > Koha mailing list > Koha(a)lists.katipo.co.nz > http://lists.katipo.co.nz/mailman/listinfo/koha > > >

1 0

Re: [Koha] Re: [Koha-devel] the test bed is ready! - Mitel
by COURYHOUSE＠aol.com 24 Jun '02

24 Jun '02

Thanks Steve, I will wait till tomorrow to download then. Ed Sharpe

1 0