- Koha - lists.katipo.co.nz

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

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

24 Jun '02

Where is the best place to download the latest 1.2.x fixed most current to test? Ed

2 1

the test bed is ready! - Mitel
by COURYHOUSE＠aol.com 24 Jun '02

24 Jun '02

OK threw together a spare 'machine from hell' from refuse in the garage and back porch. Mitel loading as we type. will need the latest bug fixes I suppose Monday will let it rip! Ed!

1 0

New Koha website
by Rachel Hamilton-Williams 24 Jun '02

24 Jun '02

Kia Ora, I've just sent the new Koha website live (http://www.koha.org) and now would love if you all could give it the once over. I'm pretty sure that there are enough typos and grammatical errors for everyone to find one :-) Please let me know if there is anything obviously "missing" or if things aren't called what you'd expect, aren't located where you expect etc. I've just had one of those head slapping moments - we need a search, anything else? Cheers Rachel _____________________________________________________________ Rachel Hamilton-Williams Katipo Communications WEBMISTRESS ph 021 389 128 or +64 04 934 1285 mailto:rachel@katipo.co.nz PO Box 12487, Wellington http://www.katipo.co.nz New Zealand Koha Open Source Library System http://www.koha.org

1 0

importing MARC records
by micheas 23 Jun '02

23 Jun '02

Hi all. I have Koha working on FreeBSD, mostly. Thanks for all your work. One thing that I don't have working is the ability to import MARC records using the web front end. I want to be able to: grab a book in our library (we have a few thousand). Enter the ISBN and have the record populated from the library of congress, or some other wais server. Finally entering any notes by hand. All of my test entries are still in queue. My only thoughts: I have ipfw as a statefull firewall. If there is an oddball port being used this might be a problem. But there is no evidence that I see in the logs. (my logging is pretty light so some things fail quietly) The whole admin directory has taken extra steps to install, and still is mostly broken. so this may be part of it. Thanks Micheas

2 3

FreeBSD Dependencies
by micheas 23 Jun '02

23 Jun '02

Hi all, Here is a list in one place of everything I know that needs installed to use Koha on FreeBSD. Corrections and comments are appreciated. Micheas -------------------------------------------------------------------- # From ports(cd to the directory then "make install"): $PORTSDIR/net/yaz $PORTSDIR/www/apache13 # other versions of apache should # work, however I have not tested them. Please # report any successes. Especially with regards to # apache2 $PORTSDIR/lang/perl5 # mod_perl is NOT advised if you use Net::Z3950 # due to bugs in the Net::Z3050 module. $PORTSDIR/devel/cdk # if you plan on using telnet # terminals -- see note below. # From CPAN ("perl -MCPAN -e shell") install: Date::Manip DBI Set::Scalar DBD::mysql # or whatever database system you use CDK # if you want to support telnet. --see note below AuthenDBI # if you want to use Database based # authentication -- Untested Net::Z3950 # needed for remote MARC record lookup. Telnet terminals -- HERE BE DRAGONS -- these maybe problematic under FreeBSD. There is a movement to remove telnetd form the base distribution. So any problem will probably get worse not better. :-( The reason for this is that it is viewed as extremely insecure protocol that passes passwords in "plain text". Think twice and consider porting to ssh if you have any security concerns. The port could be pretty straight forward. The shell scripts for starting Z3950 queue do not work on FreeBSD. I will post them when I get them working.

1 0

problem
by Md. Aftabuddin 22 Jun '02

22 Jun '02

If you want to modify biblio record the aditional authors get duplicated. Md. Aftabuddin

1 0