- Koha - lists.katipo.co.nz

UUID and Text:Bidi install
by Tom Hanstra 23 May '16

23 May '16

I'm working on an installation of Koha 3.22 on a new server. I don't have access to Debian and need to install on a version of RHEL. Most everything goes well, but I'm having a lot of trouble with two Perl dependencies: UUID - Perl does not seem to be able to find the right dependencies necessary to install the UUID module. The complaint is the following: # Bailing out. Can't continue. # # ** No interface found. # # It's likely the UUID prerequisite library isn't installed. But no combination of packages and prerequisite libraries seem to get me past this. Does anyone have ideas? And what will not work if I bypass installing UUID? -------------- Text::BIdi My CPAN fully thinks Text::Bidi is up to date: cpan install Text::Bidi Reading '/root/.cpan/Metadata' Database was generated on Thu, 19 May 2016 09:53:48 GMT Text::Bidi is up to date (2.11). But the Koha install script says it is missing on upgrade. Why? Where is it looking for the current version that is different from where CPAN installed it? -------------- Any assistance with either of these would be helpful as I debug this. -- *Tom Hanstra* *Sr. Systems Administrator* hanstra(a)nd.edu <http://library.nd.edu/>

3 5

Re: [Koha] problem installing Koha (Tim Auld)
by Auldstampguy 23 May '16

23 May '16

You may be past this point in your installation process, but I found the follow article very helpful when I installed Koha. Regards, Tim Auld Hastings, Minnesota https://www.digitalocean.com/community/tutorials/how-to-install-koha-librar…

2 1

Search target Z39.50 for copy cataloguing
by Decka David 23 May '16

23 May '16

I spend some time studying koha about its features, functionalities etc which I really love it. Now I have setup and customized the koha library, however I am trying to use the feature of search Z39.50 and assist in doing copy cataloguing as a test. I have tried several times with the default setup as well as creating new search targets in Koha 3.20 and I could not reach the target server. Is there something I might missed out during installation? Do I need to register my library to a free target server? Am I in a region not supported by this feature? please could someone clarify. Thank you for the advices. Decka David Papua New Guinea

2 1

Re: [Koha] OPAC searches fail with ICU indexing enabled
by David Cook 23 May '16

23 May '16

Hi Andreas, This problem looks a little familiar. I have a few questions. You find 335 records using yaz-client. Are you able to view those records using "show" in yaz-client? Also where are you seeing the following error: > Error: > :8: parser error : Input is not proper UTF-8, indicate encoding ! > Bytes: 0xCF 0x3C 0x2F 0x74 Î¿Ï‚ Î¤Î¹Î¼ÏŒÎ¸ÎµÎ¿Î½ Î‘Î„-Ï€ÏÎ¿Ï‚ > Î¤Î¹Î¼ÏŒÎ¸ÎµÎ¿Î½ Î’Î„-Ï€ÏÎ¿Ï‚ Î¤Î¯Ï„Î¿Î½-Ï€ ^ Is that in a file in your /var/log/koha/imp directory? Also, those instructions at https://wiki.koha-community.org/wiki/Correcting_Search_of_Arabic_records look a bit suboptimal... Are you using packages? Did you run the following? sudo koha-restart-zebra {yourinstance} sudo koha-rebuild-zebra -f {yourinstance} That parser error doesn't look super helpful... using Windows-1251 0xCF is Ï, 3C is <, / is 2F. With UTF-8, χ is 0xce 0xa7 and ό is 0xce 0x8c. So there isn't a clear relation there. If I had to guess, I'd say that Zebra thinks it's using ICU and UTF-8 but the data is still stored as Latin-1. Failing that... I have some other more in-depth troubleshooting ideas. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Office: 02 9212 0899 Direct: 02 8005 0595 > -----Original Message----- > Message: 7 > Date: Wed, 11 May 2016 18:12:51 +0300 > From: Andreas Roussos <arouss1980(a)gmail.com> > To: koha(a)lists.katipo.co.nz > Subject: [Koha] OPAC searches fail with ICU indexing enabled > Message-ID: > <CAK0RUrtVcZZ0jOqgmvPxrcXWw4g_qqQ3_MD5OqHYHkz_sfdcGQ > @mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > Dear list, > > We're running Koha 3.20.04 on Ubuntu 14.04, and recently enabled > ICU indexing as per the instructions on the wiki > (https://wiki.koha- > community.org/wiki/Correcting_Search_of_Arabic_records) > > Most searches work fine, but queries for certain Greek characters in OPAC > (for example "[χ.ό.]"), return the following message: > > Error: > :8: parser error : Input is not proper UTF-8, indicate encoding ! > Bytes: 0xCF 0x3C 0x2F 0x74 Î¿Ï‚ Î¤Î¹Î¼ÏŒÎ¸ÎµÎ¿Î½ Î‘Î„-Ï€ÏÎ¿Ï‚ > Î¤Î¹Î¼ÏŒÎ¸ÎµÎ¿Î½ Î’Î„-Ï€ÏÎ¿Ï‚ Î¤Î¯Ï„Î¿Î½-Ï€ ^ > > If I use the command-line zebra client to perform the same search, > I get 335 hits: > > $ yaz-client -c /etc/koha/zebradb/ccl.properties > unix:/var/run/koha/imp/bibliosocket > Connecting...OK. > Sent initrequest. > Connection accepted by v3 target. > ID : 81 > Name : Zebra Information Server/GFS/YAZ > Version: 4.2.30 98864b44c654645bc16b2c54f822dc2e45a93031 > Options: search present delSet triggerResourceCtrl scan sort > extendedServices namedResultSets > Elapsed: 0.000743 > Z> base biblios > Z> f [χ.ό.] > Sent searchRequest. > Received SearchResponse. > Search was a success. > Number of hits: 335, setno 1 > SearchResult-1: term=χο cnt=335 > records returned: 0 > Elapsed: 0.014453 > > So, it looks as if Zebra can actually perform the search but somehow > the results cannot be displayed in OPAC. > > Does anyone have any clues as to why this is happening? > > Kind regards, > Andreas > > > ------------------------------

2 4

Koha instance in subdirectory and not subdomain
by schnydszch 22 May '16

22 May '16

Hi all! Have anyone tried serving Koha instance in subdirectory (e.g. domain.com/sub) and not in subdomain (e.g. sub.domain.com) It seems there is a need to tweak in the apache server settings, but I've tried researching but to no avail. I tried "redirect" but it seems that is not possible (?). Asking this first if it's possible or someone has already tried before wasting another day on this. :) Thanks and cheers to all! -- View this message in context: http://koha.1045719.n5.nabble.com/Koha-instance-in-subdirectory-and-not-sub… Sent from the Koha-general mailing list archive at Nabble.com.

1 0

problem installing Koha
by tommaso spazzali 21 May '16

21 May '16

Hello, I'm a newbie Koha User I'm trying to install the default package on a Ubuntu server 16.04 LTS (as suggested here https://wiki.koha-community.org/wiki/Ubuntu) Version installed is: koha-common 3.22.06 and Mysql:5.7.12 Apparently I suceeded in localizing the application http://www.koha.it/traduzione-it but at step 3 of the seutp (op=importdatastructure) I get the error: mysql: [Warning] Using a password on the command line interface can be insecure. ERROR 1171 (42000) at line 1385: All parts of a PRIMARY KEY must be NOT NULL; if you need NULL in a key, use UNIQUE instead do you have any suggestion? thanks a lot tommaso

3 2

Stopping koha-common (and others) for backup and other system tasks
by John Sterbenz 20 May '16

20 May '16

Good day, all! Now that I've finally gotten our campus backup solution working with my koha server, I'm getting ready to advance my installation beyond the relatively basic, out-of-the-box stage in which I've kept it since going with a "soft live" launch in January. This got me thinking. In the land of my former system (it had a lot of I's in it), the record processing component of the software was stopped during times of backup or during times when changes could be made to methods/modules/etc. that would send results to the processing program, like a system upgrade. This starting and stopping was never done directly by a user, of course--rather, it was scripted into the options of the user interface. Thus, the questions: Should koha-common be stopped before backups are performed? Before any type of software upgrade? Are there other programs that need to be stopped as well, like the indexer (we're still using the "old method")? If anything should be stopped, is there an order in which they should be stopped (and, I imagine, restarted--in reverse order)? Backups by default (utilizing Tivoli, for those morbidly curious) are run with static serialization (a file must not change during its backup, or the backup of that file will fail). Dynamic serialization backups (in which files CAN change as they're being written to the backup device) are available, but I'm not particularly confident in the configuration of those on the backup server side given a few incidents with the old server, which was set up for this type of backup. Because we're no longer running circulation and very little will be done on the server outside of monthly Serials Solutions record loads and payment tracking, I expect no problems here, but it's worth mentioning. A followup--Will static serialization suffice for backup, or should dynamic serialization be invoked, especially if none of the processes associated with koha are stopped prior to backup running? I'm appreciative of any feedback anyone can provide for these questions. Thank you for your time and consideration! John -- -=<*>=- -=<*>=- -=<*>=- -=<*>=- -=<*>=- -=<*>=- -=<*>=- -=<*>=- -=<*>=- John E. Sterbenz, Jr. Associate Librarian Manager, Technical Services, Collections, and Library Automation 701 Tappan Street, Rm. K3359 Kresge Business Administration Library The University of Michigan Ann Arbor, Michigan, USA 48109-1234 TEL: (734) 764-5746 FAX: (734) 764-4162

1 0

Facets
by Tom Hanstra 20 May '16

20 May '16

I'm not sure I understand how facets work. I'm testing V3.22 (both .04 and .06) and have found that running with the default of using facets from zebra: <use_zebra_facets>1</use_zebra_facets> Does not present the facets on searches. However, if I change that to 0, which I assume then does not use Zebra facets but instead gets the facets from somewhere else, then the facets appear. Questions: - With this set to 0, where do the facets come from? - Why might the default of setting facets from Zebra not work? Did I miss something on my Zebra compilation or indexing? My first thought is just to leave this set to 0 since that works and 1 does not. But I do want to understand the tradeoffs and why it is working as it is. Thanks, Tom -- *Tom Hanstra* *Sr. Systems Administrator* hanstra(a)nd.edu <http://library.nd.edu/>

3 5

Koha Support
by Paul, Shishir (British Council) 20 May '16

20 May '16

Dear Concern Please help me to change system generate patron number as it starts from 7002002345 which I want to starts from five numeric digits. Could you please help me regarding this issue? Thanks Shishir Shishir Paul I Library Coordinator British Council I 5 Fuller Road I Dhaka I Bangladesh T +880 (2) 9666 773377 I F +880 (2) 8613375 I BCTN (Internal) 8212 4614 shishir.paul(a)bd.britishcouncil.org<mailto:shishir.paul@bd.britishcouncil.org> www.britishcouncil.org.bd<http://www.britishcouncil.org.bd/> Facebook: British Council Bangladesh The British Council is the United Kingdom's international organisation for cultural relations and educational opportunities. A registered charity: 209131 (England and Wales) SC037733 (Scotland). This message is for the use of the intended recipient(s) only and may contain confidential information. If you have received this message in error, please notify the sender and delete it. The British Council accepts no liability for loss or damage caused by viruses and other malware and you are advised to carry out a virus and malware check on any attachments contained in this message.

1 0

Re: [Koha] UUID and Text:Bidi install
by Paul A 20 May '16

20 May '16

At 02:45 PM 5/19/2016 -0300, Tomas Cohen Arazi wrote: >Probably you are pulling from cpam some library versions that require newer >Perl. >It is probable that 16.05 will officialy support Debian Jessie (and not >Wheezy), which includes Perl 5.20, so you should expect that older Perl >versions might not suit Koha's needs. This might (maybe? possibly? not proven) be one of the reasons I have not yet been able to migrate Koha to Ubuntu 16.04 LTS (which defaults to Perl 5.22). Has anyone else used Ubuntu 16.04? Best -- Paul >But I'm not sure about the accuracy of this statement. > > >2016-05-19 12:53 GMT-03:00 Tom Hanstra <hanstra(a)nd.edu>: > > > Pretty much RHEL6, but it is actually Amazon Web Services' base AMI. > > > > Perl version: > > > > # perl --version > > > > This is perl 5, version 16, subversion 3 (v5.16.3) built for > > x86_64-linux-thread-multi > > (with 25 registered patches, see perl -V for more detail) > > > > Copyright 1987-2012, Larry Wall > > > > Perl may be copied only under the terms of either the Artistic License or > > the > > GNU General Public License, which may be found in the Perl 5 source kit. > > > > Complete documentation for Perl, including FAQ lists, should be found on > > this system using "man perl" or "perldoc perl". If you have access to the > > Internet, point your browser at http://www.perl.org/, the Perl Home Page. > > > > > > > > On Thu, May 19, 2016 at 11:19 AM, Tomas Cohen Arazi <tomascohen(a)gmail.com> > > wrote: > > > >> perl --version > > > > > > > > > > > > -- > > *Tom Hanstra* > > *Sr. Systems Administrator* > > hanstra(a)nd.edu > > > > <http://library.nd.edu/> > > > > > >-- >TomÃ¡s Cohen Arazi >Theke Solutions (http://theke.io) >â +54 9351 3513384 >GPG: B2F3C15F >_______________________________________________ >Koha mailing list http://koha-community.org >Koha(a)lists.katipo.co.nz >https://lists.katipo.co.nz/mailman/listinfo/koha --- Maritime heritage and history, preservation and conservation, research and education through the written word and the arts. <http://NavalMarineArchive.com> and <http://UltraMarine.ca>

2 1