- Koha - lists.katipo.co.nz

Holds Queue and floating collections
by Chad Roseburg 26 May '16

26 May '16

For those of you that allow your collections to float: What strategies do you have *- or -* in what ways do you use settings like StaticHoldsQueueWeight to prevent holds from pooling at one or two libraries? We have collections at smaller libraries getting cannibalized by larger communities. Floating books collect at certain libraries after being returned -- they have very little room on their shelves while the smaller libraries have diminishing collections. We are thinking of using the StaticHoldsQueueWeight setting. Has this helped your libraries? Thank you! -- Chad Roseburg Asst. Director / IT Automation Dept. North Central Regional Library

1 0

Koha 3.22.7 security release
by Julian Maurice 25 May '16

25 May '16

The Koha community is proud to announce the release of Koha 3.22.7. This is a security release and contains many bugfixes. The full release notes are available at https://koha-community.org/koha-3-22-7-security-release/ -- Julian Maurice <julian.maurice(a)biblibre.com> BibLibre

1 0

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