From martin.renvoize at ptfs-europe.com  Tue Dec  1 12:13:40 2020
From: martin.renvoize at ptfs-europe.com (Renvoize, Martin)
Date: Tue, 1 Dec 2020 11:13:40 +0000
Subject: [Koha-devel] Happy Advent
Message-ID: <CAB7SL8AhnrOyUuP6Sb085N8PV_XEpOauptGmxPs8EwAjfkbwNw@mail.gmail.com>

Hi All,

As a long term follower of the perl advent <http://www.perladvent.org/2020/>
calendar series, it's been on my mind for a few years now to emulate it for
the Koha world..

As such, I've badgered a few devs for a bit of help and low and behold..
I'm proud to announce our very own:
https://koha-community.gitlab.io/KohaAdvent

Many thanks to my "volunteers" helping to bring this together at the last
minute and especially Tomas for writing the first article to get us
underway.

The theme will be plugins, integrations and api's from the perspective of
development.

Have a great xmas everyone,


*Martin Renvoize, MPhys (Hons)*

<https://www.ptfs-europe.com>

Development Team Manager

Community Release Manager (19.11, 20.05)


*Phone:* +44 (0) 1483 378728

*Mobile:* +44 (0) 7725 985 636

*Email:* martin.renvoize at ptfs-europe.com

www.ptfs-europe.com






Registered in the United Kingdom No. 06416372   VAT Reg No. 925 7211 30

The information contained in this email message may be privileged,
confidential and protected from disclosure. If you are not the intended
recipient, any dissemination, distribution or copying is strictly
prohibited. If you think that you have received this email message in
error, please email the sender at info at ptfs-europe.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20201201/2a953a72/attachment.htm>

From dcook at prosentient.com.au  Tue Dec  1 23:39:43 2020
From: dcook at prosentient.com.au (dcook at prosentient.com.au)
Date: Wed, 2 Dec 2020 09:39:43 +1100
Subject: [Koha-devel] Happy Advent
In-Reply-To: <CAB7SL8AhnrOyUuP6Sb085N8PV_XEpOauptGmxPs8EwAjfkbwNw@mail.gmail.com>
References: <CAB7SL8AhnrOyUuP6Sb085N8PV_XEpOauptGmxPs8EwAjfkbwNw@mail.gmail.com>
Message-ID: <0a1b01d6c832$dcca6520$965f2f60$@prosentient.com.au>

Sounds great, Martin!

 

David Cook

Software Engineer

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

 

Office: 02 9212 0899

Online: 02 8005 0595

 

From: Koha-devel <koha-devel-bounces at lists.koha-community.org> On Behalf Of Renvoize, Martin
Sent: Tuesday, 1 December 2020 10:14 PM
To: Koha Devel <koha-devel at lists.koha-community.org>; Koha <koha at lists.katipo.co.nz>
Subject: [Koha-devel] Happy Advent

 

Hi All, 

 

As a long term follower of the perl advent <http://www.perladvent.org/2020/>  calendar series, it's been on my mind for a few years now to emulate it for the Koha world..

 

As such, I've badgered a few devs for a bit of help and low and behold.. I'm proud to announce our very own: https://koha-community.gitlab.io/KohaAdvent

 

Many thanks to my "volunteers" helping to bring this together at the last minute and especially Tomas for writing the first article to get us underway.

 

The theme will be plugins, integrations and api's from the perspective of development.

 

Have a great xmas everyone,

 

	

 


Martin Renvoize, MPhys (Hons)

 <https://www.ptfs-europe.com/> 


Development Team Manager

Community Release Manager (19.11, 20.05)

	

Phone: +44 (0) 1483 378728

Mobile: +44 (0) 7725 985 636


Email:  <mailto:martin.renvoize at ptfs-europe.com> martin.renvoize at ptfs-europe.com

 <https://www.ptfs-europe.com> www.ptfs-europe.com

		
		

 

	

 

	

 


Registered in the United Kingdom No. 06416372   VAT Reg No. 925 7211 30

 

The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this email message in error, please email the sender at info at ptfs-europe.com <mailto:info at ptfs-europe.com> 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20201202/0a264aa6/attachment.htm>

From dcook at prosentient.com.au  Wed Dec  2 02:42:18 2020
From: dcook at prosentient.com.au (dcook at prosentient.com.au)
Date: Wed, 2 Dec 2020 12:42:18 +1100
Subject: [Koha-devel] Koha Plugin Hooks (Naming,etc)
Message-ID: <0a4b01d6c84c$5f0151c0$1d03f540$@prosentient.com.au>

Hi all,

 

I propose that new Koha Plugin Hooks start with a prefix of "hook_". If you
look at https://wiki.koha-community.org/wiki/Koha_Plugin_Hooks or the
Kitchen Sink plugin, it's impossible to tell what methods are "hooks" and
what are part of the basic plugin core API. 

 

Also, if a hook is going to modify a template directly
(https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27114 and
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27120), I think we
should probably come up with some agreements on how that's best to work, so
we don't end up with N different approaches for the same intention. 

 

I think that https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26890
raises some interesting issues about how it's not easy to modify Koha's HTML
output using plugins. Perhaps we should have a little analysis of some key
pages and identify hooks, or do something a bit more complex/comprehensive.
(Of course, I already have too many other things I'm working on do a POC for
this right now.)

 

David Cook

Software Engineer

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

 

Office: 02 9212 0899

Online: 02 8005 0595

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20201202/7b0a0643/attachment.htm>

From dcook at prosentient.com.au  Thu Dec  3 02:01:19 2020
From: dcook at prosentient.com.au (dcook at prosentient.com.au)
Date: Thu, 3 Dec 2020 12:01:19 +1100
Subject: [Koha-devel] koha-zebra --stop doesn't work?
Message-ID: <0afe01d6c90f$cfc9f560$6f5de020$@prosentient.com.au>

Hi all,

 

Is it just me or does "koha-zebra --stop" not actually stop Zebra?

 

David Cook

Software Engineer

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

 

Office: 02 9212 0899

Online: 02 8005 0595

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20201203/c3e82dc8/attachment.htm>

From mtj at kohaaloha.com  Thu Dec  3 03:27:51 2020
From: mtj at kohaaloha.com (Mason James)
Date: Thu, 3 Dec 2020 15:27:51 +1300
Subject: [Koha-devel] koha-zebra --stop doesn't work?
In-Reply-To: <0afe01d6c90f$cfc9f560$6f5de020$@prosentient.com.au>
References: <0afe01d6c90f$cfc9f560$6f5de020$@prosentient.com.au>
Message-ID: <80b4ef70-9a33-02d7-a4e4-aafe510f47e1@kohaaloha.com>

for me, it successfully stops the zebrasrv process


try the following to stop zebraidx

koha-indexer --stop $koha_instance


On 3/12/20 2:01 pm, dcook at prosentient.com.au wrote:
>
> Hi all,
>
> Is it just me or does “koha-zebra --stop" not actually stop Zebra?
>
> David Cook
>
> Software Engineer
>
> Prosentient Systems
>
> 72/330 Wattle St
>
> Ultimo, NSW 2007
>
> Australia
>
> Office: 02 9212 0899
>
> Online: 02 8005 0595
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/


From dcook at prosentient.com.au  Thu Dec  3 03:32:45 2020
From: dcook at prosentient.com.au (dcook at prosentient.com.au)
Date: Thu, 3 Dec 2020 13:32:45 +1100
Subject: [Koha-devel] Thoughts on Search Syntax (Zebra but maybe
 Elasticsearch)
Message-ID: <0b1c01d6c91c$95a5b2e0$c0f118a0$@prosentient.com.au>

Hi all,

 

I ran into a problem today where the search query 'Emperor penguin
(Aptenodytes forsteri) foraging ecology' (without single quotes) was
creating a "CCL parsing error" in Zebra. I had QueryAutoTruncate enabled so
QueryWeightFields was automatically disabled.

 

Solutions include:

1.	Wrap the search query in double quotes

a.	"Emperor penguin (Aptenodytes forsteri) foraging ecology"

2.	Escape the parentheses with a backslash

a.	Emperor penguin \(Aptenodytes forsteri\) foraging ecology

3.	Turn off QueryAutoTruncate

a.	This lets the weighted query code thoroughly mangle the query which
includes wrapping it in double quotes.
b.	Note though that this option also makes it so that a search wrapped
in double quotes (like Solution 1) becomes a CCL parsing error

 

I think many of us know that Koha's Zebra-based query building is terrible,
but changing it obviously has consequences and we have so many different
search preference permutations that it makes it difficult to regression test
search changes.

 

We could start showing users when they have searches with syntax errors. but
then we all will probably start getting a lot of calls. Although I was
thinking that when showing that there was a syntax error with their query,
we could also provide a little "cheat sheet" with the basics of Zebra's CCL
syntax. (Of course, that's really only relevant when we're passing queries
straight through to Zebra and not butchering them first in Koha.)

 

We could try to fix search, but then who has the time/money for that? Why
fix something that is not (seemingly) broken?

 

I am wondering what other people think. 

 

Personally, I'm thinking that we should not allow complex queries in the
OPAC "Search" box. We treat that box (as we always should have) as the
operand to the index chosen in the "Library catalogue" drop down list.
However. that would be a breaking change for anyone that has bookmarked any
OPAC searches with complex search queries. I suppose that we could create a
new System Preference like "SimplifySearch" and just enable that for new
Koha installations though. Maybe one day we could then remove that system
preference and just make it "The Way". 

 

After all, I think that the *majority* of people are going to be performing
fairly straight forward searches in the OPAC "Search" box. They're not going
to be doing things like '(kw,phr,rtrn:"David writes verbose emails") OR (
(ti,phr,ext:"I think David's ideas have some merit") AND (su:Emails) )'. 

 

Relevant bugs:

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27088

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27139

 

David Cook

Software Engineer

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

 

Office: 02 9212 0899

Online: 02 8005 0595

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20201203/84f89ec7/attachment.htm>

From dcook at prosentient.com.au  Thu Dec  3 03:33:34 2020
From: dcook at prosentient.com.au (dcook at prosentient.com.au)
Date: Thu, 3 Dec 2020 13:33:34 +1100
Subject: [Koha-devel] koha-zebra --stop doesn't work?
In-Reply-To: <80b4ef70-9a33-02d7-a4e4-aafe510f47e1@kohaaloha.com>
References: <0afe01d6c90f$cfc9f560$6f5de020$@prosentient.com.au>
 <80b4ef70-9a33-02d7-a4e4-aafe510f47e1@kohaaloha.com>
Message-ID: <0b2101d6c91c$b257e3e0$1707aba0$@prosentient.com.au>

Hmm then it must just be me, because "koha-zebra --stop $koha_instance" is
definitely not stopping zebrasrv on my servers...

Mind you "kill" doesn't either without a -9..

David Cook
Software Engineer
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia

Office: 02 9212 0899
Online: 02 8005 0595

-----Original Message-----
From: Mason James <mtj at kohaaloha.com> 
Sent: Thursday, 3 December 2020 1:28 PM
To: dcook at prosentient.com.au; 'Koha Devel'
<koha-devel at lists.koha-community.org>
Subject: Re: [Koha-devel] koha-zebra --stop doesn't work?

for me, it successfully stops the zebrasrv process


try the following to stop zebraidx

koha-indexer --stop $koha_instance


On 3/12/20 2:01 pm, dcook at prosentient.com.au wrote:
>
> Hi all,
>
> Is it just me or does "koha-zebra --stop" not actually stop Zebra?
>
> David Cook
>
> Software Engineer
>
> Prosentient Systems
>
> 72/330 Wattle St
>
> Ultimo, NSW 2007
>
> Australia
>
> Office: 02 9212 0899
>
> Online: 02 8005 0595
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/ git : 
> http://git.koha-community.org/ bugs : http://bugs.koha-community.org/




From dcook at prosentient.com.au  Thu Dec  3 05:33:45 2020
From: dcook at prosentient.com.au (dcook at prosentient.com.au)
Date: Thu, 3 Dec 2020 15:33:45 +1100
Subject: [Koha-devel] koha-zebra --stop doesn't work?
In-Reply-To: <0b2101d6c91c$b257e3e0$1707aba0$@prosentient.com.au>
References: <0afe01d6c90f$cfc9f560$6f5de020$@prosentient.com.au>
 <80b4ef70-9a33-02d7-a4e4-aafe510f47e1@kohaaloha.com>
 <0b2101d6c91c$b257e3e0$1707aba0$@prosentient.com.au>
Message-ID: <0b3001d6c92d$7cd407b0$767c1710$@prosentient.com.au>

So I just tried "koha-zebra --restart kohadev" after making a change to log levels to include request in koha-conf.xml in koha-testing-docker and it's a mess:

root at kohadevbox:koha(bug_12430)$ ps -efww | grep "zebrasrv"
kohadev+   808     1  0 02:04 ?        00:00:00 daemon --name=kohadev-koha-zebra --pidfiles=/var/run/koha/kohadev/ --errlog=/var/log/koha/kohadev/zebra-error.log --output=/var/log/koha/kohadev/zebra-output.log --verbose=1 --respawn --del
ay=30 --user=kohadev-koha.kohadev-koha -- /usr/bin/zebrasrv -v none,fatal,warn -k 1024 -f /etc/koha/sites/kohadev/koha-conf.xml
kohadev+   840   808  0 02:04 ?        00:00:00 [zebrasrv] <defunct>
kohadev+  5183     1  0 04:28 ?        00:00:00 /usr/bin/zebrasrv -v none,fatal,warn -k 1024 -f /etc/koha/sites/kohadev/koha-conf.xml
root      5373  3959  0 04:31 pts/1    00:00:00 grep zebrasrv

Using "kill -9", I kill off all those.

I run "koha-zebra --start kohadev":

root at kohadevbox:koha(bug_12430)$ ps -efww | grep "zebrasrv"
kohadev+  5418     1  0 04:31 ?        00:00:00 daemon --name=kohadev-koha-zebra --pidfiles=/var/run/koha/kohadev/ --errlog=/var/log/koha/kohadev/zebra-error.log --output=/var/log/koha/kohadev/zebra-output.log --verbose=1 --respawn --del
ay=30 --user=kohadev-koha.kohadev-koha -- /usr/bin/zebrasrv -v none,fatal,warn,request -k 1024 -f /etc/koha/sites/kohadev/koha-conf.xml
kohadev+  5422  5418  0 04:31 ?        00:00:00 /usr/bin/zebrasrv -v none,fatal,warn,request -k 1024 -f /etc/koha/sites/kohadev/koha-conf.xml
root      5424  3959  0 04:31 pts/1    00:00:00 grep zebrasrv

That's much better now.

Just opened https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27140

David Cook
Software Engineer
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia

Office: 02 9212 0899
Online: 02 8005 0595

-----Original Message-----
From: Koha-devel <koha-devel-bounces at lists.koha-community.org> On Behalf Of dcook at prosentient.com.au
Sent: Thursday, 3 December 2020 1:34 PM
To: 'Mason James' <mtj at kohaaloha.com>; 'Koha Devel' <koha-devel at lists.koha-community.org>
Subject: Re: [Koha-devel] koha-zebra --stop doesn't work?

Hmm then it must just be me, because "koha-zebra --stop $koha_instance" is definitely not stopping zebrasrv on my servers...

Mind you "kill" doesn't either without a -9..

David Cook
Software Engineer
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia

Office: 02 9212 0899
Online: 02 8005 0595

-----Original Message-----
From: Mason James <mtj at kohaaloha.com>
Sent: Thursday, 3 December 2020 1:28 PM
To: dcook at prosentient.com.au; 'Koha Devel'
<koha-devel at lists.koha-community.org>
Subject: Re: [Koha-devel] koha-zebra --stop doesn't work?

for me, it successfully stops the zebrasrv process


try the following to stop zebraidx

koha-indexer --stop $koha_instance


On 3/12/20 2:01 pm, dcook at prosentient.com.au wrote:
>
> Hi all,
>
> Is it just me or does "koha-zebra --stop" not actually stop Zebra?
>
> David Cook
>
> Software Engineer
>
> Prosentient Systems
>
> 72/330 Wattle St
>
> Ultimo, NSW 2007
>
> Australia
>
> Office: 02 9212 0899
>
> Online: 02 8005 0595
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/ git : 
> http://git.koha-community.org/ bugs : http://bugs.koha-community.org/



_______________________________________________
Koha-devel mailing list
Koha-devel at lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/



From tomascohen at gmail.com  Thu Dec  3 15:04:46 2020
From: tomascohen at gmail.com (Tomas Cohen Arazi)
Date: Thu, 3 Dec 2020 11:04:46 -0300
Subject: [Koha-devel] koha-zebra --stop doesn't work?
In-Reply-To: <0b3001d6c92d$7cd407b0$767c1710$@prosentient.com.au>
References: <0afe01d6c90f$cfc9f560$6f5de020$@prosentient.com.au>
 <80b4ef70-9a33-02d7-a4e4-aafe510f47e1@kohaaloha.com>
 <0b2101d6c91c$b257e3e0$1707aba0$@prosentient.com.au>
 <0b3001d6c92d$7cd407b0$767c1710$@prosentient.com.au>
Message-ID: <CABZfb=XbRmke5Cm2a87t2d-H2C46T2byaELwfewsmww0AS_9Og@mail.gmail.com>

You don't just violently kill a process. You send it the signal so it
closes its open connections, etc.
Of course killing it with -9 will yield an empty ps -ef.

It would be interesting to see if those defunct processes cleanup after
some reasonable time.

What OS are you using? (in KTD it would mean what image, default is
master-stretch, I use master-buster to develop/QA).


El jue, 3 dic 2020 a las 1:34, <dcook at prosentient.com.au> escribió:

> So I just tried "koha-zebra --restart kohadev" after making a change to
> log levels to include request in koha-conf.xml in koha-testing-docker and
> it's a mess:
>
> root at kohadevbox:koha(bug_12430)$ ps -efww | grep "zebrasrv"
> kohadev+   808     1  0 02:04 ?        00:00:00 daemon
> --name=kohadev-koha-zebra --pidfiles=/var/run/koha/kohadev/
> --errlog=/var/log/koha/kohadev/zebra-error.log
> --output=/var/log/koha/kohadev/zebra-output.log --verbose=1 --respawn --del
> ay=30 --user=kohadev-koha.kohadev-koha -- /usr/bin/zebrasrv -v
> none,fatal,warn -k 1024 -f /etc/koha/sites/kohadev/koha-conf.xml
> kohadev+   840   808  0 02:04 ?        00:00:00 [zebrasrv] <defunct>
> kohadev+  5183     1  0 04:28 ?        00:00:00 /usr/bin/zebrasrv -v
> none,fatal,warn -k 1024 -f /etc/koha/sites/kohadev/koha-conf.xml
> root      5373  3959  0 04:31 pts/1    00:00:00 grep zebrasrv
>
> Using "kill -9", I kill off all those.
>
> I run "koha-zebra --start kohadev":
>
> root at kohadevbox:koha(bug_12430)$ ps -efww | grep "zebrasrv"
> kohadev+  5418     1  0 04:31 ?        00:00:00 daemon
> --name=kohadev-koha-zebra --pidfiles=/var/run/koha/kohadev/
> --errlog=/var/log/koha/kohadev/zebra-error.log
> --output=/var/log/koha/kohadev/zebra-output.log --verbose=1 --respawn --del
> ay=30 --user=kohadev-koha.kohadev-koha -- /usr/bin/zebrasrv -v
> none,fatal,warn,request -k 1024 -f /etc/koha/sites/kohadev/koha-conf.xml
> kohadev+  5422  5418  0 04:31 ?        00:00:00 /usr/bin/zebrasrv -v
> none,fatal,warn,request -k 1024 -f /etc/koha/sites/kohadev/koha-conf.xml
> root      5424  3959  0 04:31 pts/1    00:00:00 grep zebrasrv
>
> That's much better now.
>
> Just opened
> https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27140
>
> David Cook
> Software Engineer
> Prosentient Systems
> 72/330 Wattle St
> Ultimo, NSW 2007
> Australia
>
> Office: 02 9212 0899
> Online: 02 8005 0595
>
> -----Original Message-----
> From: Koha-devel <koha-devel-bounces at lists.koha-community.org> On Behalf
> Of dcook at prosentient.com.au
> Sent: Thursday, 3 December 2020 1:34 PM
> To: 'Mason James' <mtj at kohaaloha.com>; 'Koha Devel' <
> koha-devel at lists.koha-community.org>
> Subject: Re: [Koha-devel] koha-zebra --stop doesn't work?
>
> Hmm then it must just be me, because "koha-zebra --stop $koha_instance" is
> definitely not stopping zebrasrv on my servers...
>
> Mind you "kill" doesn't either without a -9..
>
> David Cook
> Software Engineer
> Prosentient Systems
> 72/330 Wattle St
> Ultimo, NSW 2007
> Australia
>
> Office: 02 9212 0899
> Online: 02 8005 0595
>
> -----Original Message-----
> From: Mason James <mtj at kohaaloha.com>
> Sent: Thursday, 3 December 2020 1:28 PM
> To: dcook at prosentient.com.au; 'Koha Devel'
> <koha-devel at lists.koha-community.org>
> Subject: Re: [Koha-devel] koha-zebra --stop doesn't work?
>
> for me, it successfully stops the zebrasrv process
>
>
> try the following to stop zebraidx
>
> koha-indexer --stop $koha_instance
>
>
> On 3/12/20 2:01 pm, dcook at prosentient.com.au wrote:
> >
> > Hi all,
> >
> > Is it just me or does "koha-zebra --stop" not actually stop Zebra?
> >
> > David Cook
> >
> > Software Engineer
> >
> > Prosentient Systems
> >
> > 72/330 Wattle St
> >
> > Ultimo, NSW 2007
> >
> > Australia
> >
> > Office: 02 9212 0899
> >
> > Online: 02 8005 0595
> >
> >
> > _______________________________________________
> > Koha-devel mailing list
> > Koha-devel at lists.koha-community.org
> > https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> > website : http://www.koha-community.org/ git :
> > http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
>
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/ git :
> http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>


-- 
Tomás Cohen Arazi
Theke Solutions (http://theke.io)
✆ +54 9351 3513384
GPG: B2F3C15F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20201203/9e75d449/attachment.htm>

From dcook at prosentient.com.au  Fri Dec  4 04:47:14 2020
From: dcook at prosentient.com.au (dcook at prosentient.com.au)
Date: Fri, 4 Dec 2020 14:47:14 +1100
Subject: [Koha-devel] koha-zebra --stop doesn't work?
In-Reply-To: <CABZfb=XbRmke5Cm2a87t2d-H2C46T2byaELwfewsmww0AS_9Og@mail.gmail.com>
References: <0afe01d6c90f$cfc9f560$6f5de020$@prosentient.com.au>
 <80b4ef70-9a33-02d7-a4e4-aafe510f47e1@kohaaloha.com>
 <0b2101d6c91c$b257e3e0$1707aba0$@prosentient.com.au>
 <0b3001d6c92d$7cd407b0$767c1710$@prosentient.com.au>
 <CABZfb=XbRmke5Cm2a87t2d-H2C46T2byaELwfewsmww0AS_9Og@mail.gmail.com>
Message-ID: <0c0201d6c9f0$27c1e1c0$7745a540$@prosentient.com.au>

Hi Tomas,

 

I think that you misunderstand my email, but that’s my fault for not including enough information. The SIGKILL (ie kill -9) is irrelevant. Please see https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27140 for much more information.

 

Basically, it boils down to zebrasrv not propagating signals (SIGTERM, SIGKILL, whatever) to its children. (And no the defunct zombie process won’t be cleaned up until its child process exits.)

 

Funny enough, I don’t actually see any way to resolve this situation without patching zebrasrv or using SIGKILL (ie kill -9) to stop all relevant zebrasrv processes. 

 

David Cook

Software Engineer

Prosentient Systems

Suite 7.03

6a Glen St

Milsons Point NSW 2061

Australia

 

Office: 02 9212 0899

Online: 02 8005 0595

 

From: Koha-devel <koha-devel-bounces at lists.koha-community.org> On Behalf Of Tomas Cohen Arazi
Sent: Friday, 4 December 2020 1:05 AM
To: Koha Devel <koha-devel at lists.koha-community.org>
Subject: Re: [Koha-devel] koha-zebra --stop doesn't work?

 

You don't just violently kill a process. You send it the signal so it closes its open connections, etc.

Of course killing it with -9 will yield an empty ps -ef.

 

It would be interesting to see if those defunct processes cleanup after some reasonable time.

 

What OS are you using? (in KTD it would mean what image, default is master-stretch, I use master-buster to develop/QA).

 

 

El jue, 3 dic 2020 a las 1:34, <dcook at prosentient.com.au <mailto:dcook at prosentient.com.au> > escribió:

So I just tried "koha-zebra --restart kohadev" after making a change to log levels to include request in koha-conf.xml in koha-testing-docker and it's a mess:

root at kohadevbox:koha(bug_12430)$ ps -efww | grep "zebrasrv"
kohadev+   808     1  0 02:04 ?        00:00:00 daemon --name=kohadev-koha-zebra --pidfiles=/var/run/koha/kohadev/ --errlog=/var/log/koha/kohadev/zebra-error.log --output=/var/log/koha/kohadev/zebra-output.log --verbose=1 --respawn --del
ay=30 --user=kohadev-koha.kohadev-koha -- /usr/bin/zebrasrv -v none,fatal,warn -k 1024 -f /etc/koha/sites/kohadev/koha-conf.xml
kohadev+   840   808  0 02:04 ?        00:00:00 [zebrasrv] <defunct>
kohadev+  5183     1  0 04:28 ?        00:00:00 /usr/bin/zebrasrv -v none,fatal,warn -k 1024 -f /etc/koha/sites/kohadev/koha-conf.xml
root      5373  3959  0 04:31 pts/1    00:00:00 grep zebrasrv

Using "kill -9", I kill off all those.

I run "koha-zebra --start kohadev":

root at kohadevbox:koha(bug_12430)$ ps -efww | grep "zebrasrv"
kohadev+  5418     1  0 04:31 ?        00:00:00 daemon --name=kohadev-koha-zebra --pidfiles=/var/run/koha/kohadev/ --errlog=/var/log/koha/kohadev/zebra-error.log --output=/var/log/koha/kohadev/zebra-output.log --verbose=1 --respawn --del
ay=30 --user=kohadev-koha.kohadev-koha -- /usr/bin/zebrasrv -v none,fatal,warn,request -k 1024 -f /etc/koha/sites/kohadev/koha-conf.xml
kohadev+  5422  5418  0 04:31 ?        00:00:00 /usr/bin/zebrasrv -v none,fatal,warn,request -k 1024 -f /etc/koha/sites/kohadev/koha-conf.xml
root      5424  3959  0 04:31 pts/1    00:00:00 grep zebrasrv

That's much better now.

Just opened https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27140

David Cook
Software Engineer
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia

Office: 02 9212 0899
Online: 02 8005 0595

-----Original Message-----
From: Koha-devel <koha-devel-bounces at lists.koha-community.org <mailto:koha-devel-bounces at lists.koha-community.org> > On Behalf Of dcook at prosentient.com.au <mailto:dcook at prosentient.com.au> 
Sent: Thursday, 3 December 2020 1:34 PM
To: 'Mason James' <mtj at kohaaloha.com <mailto:mtj at kohaaloha.com> >; 'Koha Devel' <koha-devel at lists.koha-community.org <mailto:koha-devel at lists.koha-community.org> >
Subject: Re: [Koha-devel] koha-zebra --stop doesn't work?

Hmm then it must just be me, because "koha-zebra --stop $koha_instance" is definitely not stopping zebrasrv on my servers...

Mind you "kill" doesn't either without a -9..

David Cook
Software Engineer
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia

Office: 02 9212 0899
Online: 02 8005 0595

-----Original Message-----
From: Mason James <mtj at kohaaloha.com <mailto:mtj at kohaaloha.com> >
Sent: Thursday, 3 December 2020 1:28 PM
To: dcook at prosentient.com.au <mailto:dcook at prosentient.com.au> ; 'Koha Devel'
<koha-devel at lists.koha-community.org <mailto:koha-devel at lists.koha-community.org> >
Subject: Re: [Koha-devel] koha-zebra --stop doesn't work?

for me, it successfully stops the zebrasrv process


try the following to stop zebraidx

koha-indexer --stop $koha_instance


On 3/12/20 2:01 pm, dcook at prosentient.com.au <mailto:dcook at prosentient.com.au>  wrote:
>
> Hi all,
>
> Is it just me or does "koha-zebra --stop" not actually stop Zebra?
>
> David Cook
>
> Software Engineer
>
> Prosentient Systems
>
> 72/330 Wattle St
>
> Ultimo, NSW 2007
>
> Australia
>
> Office: 02 9212 0899
>
> Online: 02 8005 0595
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org <mailto:Koha-devel at lists.koha-community.org> 
> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/ git : 
> http://git.koha-community.org/ bugs : http://bugs.koha-community.org/



_______________________________________________
Koha-devel mailing list
Koha-devel at lists.koha-community.org <mailto:Koha-devel at lists.koha-community.org> 
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/


_______________________________________________
Koha-devel mailing list
Koha-devel at lists.koha-community.org <mailto:Koha-devel at lists.koha-community.org> 
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/




 

-- 

Tomás Cohen Arazi

Theke Solutions (http://theke.io <http://theke.io/> )
✆ +54 9351 3513384
GPG: B2F3C15F

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20201204/dc08f618/attachment-0001.htm>

From dcook at prosentient.com.au  Mon Dec  7 05:51:25 2020
From: dcook at prosentient.com.au (dcook at prosentient.com.au)
Date: Mon, 7 Dec 2020 15:51:25 +1100
Subject: [Koha-devel] The logic of BiblioAddsAuthorities and
 AutoCreateAuthorities...
Message-ID: <0d1b01d6cc54$9e033da0$da09b8e0$@prosentient.com.au>

Hi all,

Here's the current state of BiblioAddsAuthorities and AutoCreateAuthorities:

1. You can manually input text into an authority controlled field if
BiblioAddsAuthorities is enabled.
2. Automatic linking between bib records and authority records *only*
happens if BiblioAddsAuthorities is enabled.
3. AutoCreateAuthorities will automatically generate authorities if
BiblioAddsAuthorities is enabled.

I think that this all makes sense when manually inputting records, but it
doesn't make sense when you're using automation like Z39.50, Staged MARC
Upload, or other bulk tools. In those cases, you might want automatic
linking between bibs and authorities (with or without automatic authority
creation), but you might still want authority controlled fields to be
read-only when manually working with records.

I am wondering if anyone else has any insight into this. 

In my mind, BiblioAddsAuthorities should probably be "BiblioAddsAuthorities"
and "BiblioAutolinkAuthorities". 

Or maybe the "read-only" flag could be on MARC frameworks... 

I'm waiting to see what some librarians say, but keen to gather ideas.

David Cook
Software Engineer
Prosentient Systems
Suite 7.03
6a Glen St
Milsons Point NSW 2061
Australia

Office: 02 9212 0899
Online: 02 8005 0595




From asnell at tridentcf.com  Thu Dec 10 22:06:55 2020
From: asnell at tridentcf.com (Anthony Snell)
Date: Thu, 10 Dec 2020 21:06:55 +0000
Subject: [Koha-devel] purchasing GoDaddy Servers
Message-ID: <MN2PR15MB30375043FD4FB920A6107FACDDCB0@MN2PR15MB3037.namprd15.prod.outlook.com>

These is some strange information I got from GoDaddy today they have current customers on certain servers to that CAN'T be upgrade to the newer versions of Ubuntu and require users to purchase new servers to host Koha on!!!

[Anthony Snell]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20201210/56d3a8dc/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 9208 bytes
Desc: image001.jpg
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20201210/56d3a8dc/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Godaddy.pdf
Type: application/pdf
Size: 46694 bytes
Desc: Godaddy.pdf
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20201210/56d3a8dc/attachment-0001.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Anthony Snell.vcf
Type: text/x-vcard
Size: 1661 bytes
Desc: Anthony Snell.vcf
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20201210/56d3a8dc/attachment-0001.vcf>

From dcook at prosentient.com.au  Fri Dec 11 05:32:08 2020
From: dcook at prosentient.com.au (dcook at prosentient.com.au)
Date: Fri, 11 Dec 2020 15:32:08 +1100
Subject: [Koha-devel] LinkBibHeadingsToAuthorities not working as expected
Message-ID: <032b01d6cf76$968fb7e0$c3af27a0$@prosentient.com.au>

Hi all,

 

I'm still investigating, but it seems to me that the C4::Linker::Default in
C4::Biblio::LinkBibHeadingsToAuthorities isn't searching accurately using
C4::Heading::authorities. 

 

I'm looking at C4::AuthoritiesMarc::SearchAuthorities and at a glance it
looks OK, but in practice I think that my search queries are getting way too
many results. 

 

By hand, if I try the following query:

Match-heading,phr,ext,do-not-truncate="e"

 

I get a huge number of results, which is odd, since that should be an
"exact" match.

 

I've opened https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27198
because I need to improve the diagnostics available for a Zebra authorities
database, but yeah. not good. Hopefully I'll know more soon.

 

David Cook

Software Engineer

Prosentient Systems

Suite 7.03

6a Glen St

Milsons Point NSW 2061

Australia

 

Office: 02 9212 0899

Online: 02 8005 0595

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20201211/9c8c234b/attachment.htm>

From dcook at prosentient.com.au  Fri Dec 11 05:49:42 2020
From: dcook at prosentient.com.au (dcook at prosentient.com.au)
Date: Fri, 11 Dec 2020 15:49:42 +1100
Subject: [Koha-devel] LinkBibHeadingsToAuthorities not working as
 expected
In-Reply-To: <032b01d6cf76$968fb7e0$c3af27a0$@prosentient.com.au>
References: <032b01d6cf76$968fb7e0$c3af27a0$@prosentient.com.au>
Message-ID: <033501d6cf79$0a30c890$1e9259b0$@prosentient.com.au>

Then again. I can't reproduce this problem on koha-testing-docker, but I can
on a prod Koha running Zebra 2.1.4 with. a very strange
/etc/koha/zebradb/etc/default.idx file.

 

David Cook

Software Engineer

Prosentient Systems

Suite 7.03

6a Glen St

Milsons Point NSW 2061

Australia

 

Office: 02 9212 0899

Online: 02 8005 0595

 

From: Koha-devel <koha-devel-bounces at lists.koha-community.org> On Behalf Of
dcook at prosentient.com.au
Sent: Friday, 11 December 2020 3:32 PM
To: 'Koha Devel' <koha-devel at lists.koha-community.org>
Subject: [Koha-devel] LinkBibHeadingsToAuthorities not working as expected

 

Hi all,

 

I'm still investigating, but it seems to me that the C4::Linker::Default in
C4::Biblio::LinkBibHeadingsToAuthorities isn't searching accurately using
C4::Heading::authorities. 

 

I'm looking at C4::AuthoritiesMarc::SearchAuthorities and at a glance it
looks OK, but in practice I think that my search queries are getting way too
many results. 

 

By hand, if I try the following query:

Match-heading,phr,ext,do-not-truncate="e"

 

I get a huge number of results, which is odd, since that should be an
"exact" match.

 

I've opened https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27198
because I need to improve the diagnostics available for a Zebra authorities
database, but yeah. not good. Hopefully I'll know more soon.

 

David Cook

Software Engineer

Prosentient Systems

Suite 7.03

6a Glen St

Milsons Point NSW 2061

Australia

 

Office: 02 9212 0899

Online: 02 8005 0595

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20201211/f4073f3b/attachment.htm>

From dcook at prosentient.com.au  Fri Dec 11 06:22:14 2020
From: dcook at prosentient.com.au (dcook at prosentient.com.au)
Date: Fri, 11 Dec 2020 16:22:14 +1100
Subject: [Koha-devel] LinkBibHeadingsToAuthorities not working as
 expected
In-Reply-To: <033501d6cf79$0a30c890$1e9259b0$@prosentient.com.au>
References: <032b01d6cf76$968fb7e0$c3af27a0$@prosentient.com.au>
 <033501d6cf79$0a30c890$1e9259b0$@prosentient.com.au>
Message-ID: <034401d6cf7d$95a3a600$c0eaf200$@prosentient.com.au>

Ugh yeah no. I'm reproducing it with koha-testing-docker too.

 

Looks like yet another ICU bug.

 

David Cook

Software Engineer

Prosentient Systems

Suite 7.03

6a Glen St

Milsons Point NSW 2061

Australia

 

Office: 02 9212 0899

Online: 02 8005 0595

 

From: Koha-devel <koha-devel-bounces at lists.koha-community.org> On Behalf Of
dcook at prosentient.com.au
Sent: Friday, 11 December 2020 3:50 PM
To: 'Koha Devel' <koha-devel at lists.koha-community.org>
Subject: Re: [Koha-devel] LinkBibHeadingsToAuthorities not working as
expected

 

Then again. I can't reproduce this problem on koha-testing-docker, but I can
on a prod Koha running Zebra 2.1.4 with. a very strange
/etc/koha/zebradb/etc/default.idx file.

 

David Cook

Software Engineer

Prosentient Systems

Suite 7.03

6a Glen St

Milsons Point NSW 2061

Australia

 

Office: 02 9212 0899

Online: 02 8005 0595

 

From: Koha-devel <koha-devel-bounces at lists.koha-community.org
<mailto:koha-devel-bounces at lists.koha-community.org> > On Behalf Of
dcook at prosentient.com.au <mailto:dcook at prosentient.com.au> 
Sent: Friday, 11 December 2020 3:32 PM
To: 'Koha Devel' <koha-devel at lists.koha-community.org
<mailto:koha-devel at lists.koha-community.org> >
Subject: [Koha-devel] LinkBibHeadingsToAuthorities not working as expected

 

Hi all,

 

I'm still investigating, but it seems to me that the C4::Linker::Default in
C4::Biblio::LinkBibHeadingsToAuthorities isn't searching accurately using
C4::Heading::authorities. 

 

I'm looking at C4::AuthoritiesMarc::SearchAuthorities and at a glance it
looks OK, but in practice I think that my search queries are getting way too
many results. 

 

By hand, if I try the following query:

Match-heading,phr,ext,do-not-truncate="e"

 

I get a huge number of results, which is odd, since that should be an
"exact" match.

 

I've opened https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27198
because I need to improve the diagnostics available for a Zebra authorities
database, but yeah. not good. Hopefully I'll know more soon.

 

David Cook

Software Engineer

Prosentient Systems

Suite 7.03

6a Glen St

Milsons Point NSW 2061

Australia

 

Office: 02 9212 0899

Online: 02 8005 0595

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20201211/e9521b47/attachment.htm>

From dcook at prosentient.com.au  Fri Dec 11 06:31:00 2020
From: dcook at prosentient.com.au (dcook at prosentient.com.au)
Date: Fri, 11 Dec 2020 16:31:00 +1100
Subject: [Koha-devel] LinkBibHeadingsToAuthorities not working as
 expected
In-Reply-To: <034401d6cf7d$95a3a600$c0eaf200$@prosentient.com.au>
References: <032b01d6cf76$968fb7e0$c3af27a0$@prosentient.com.au>
 <033501d6cf79$0a30c890$1e9259b0$@prosentient.com.au>
 <034401d6cf7d$95a3a600$c0eaf200$@prosentient.com.au>
Message-ID: <035001d6cf7e$cf724610$6e56d230$@prosentient.com.au>

Using koha-testing-docker set up for ICU and with my fix from
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27198:

 

querytype ccl2rpn

set_cclfile /etc/koha/zebradb/ccl.properties

format xml

elements zebra::snippet

 

Z> f Match-heading,phr,ext,do-not-truncate="the Q"

Sent searchRequest.

Received SearchResponse.

Search was a success.

Number of hits: 34, setno 24

SearchResult-1: term=the cnt=34

records returned: 0

Elapsed: 0.000315

Z> show

Sent presentRequest (1+1).

Records: 1

Record type: XML

<record xmlns="http://www.indexdata.com/zebra/">

  <snippet name="Match-heading" type="p"
fields="Match">Xenophon<s>the</s>Historian</snippet>

</record>nextResultSetPosition = 2

Elapsed: 0.003864

 

So that's special. admittedly that's Zebra 2.0.59.

 

On Zebra 2.1.4 with ICU:

 

Z> f Match-heading,phr,ext,do-not-truncate="the Q"

Sent searchRequest.

Received SearchResponse.

Search was a success.

Number of hits: 0, setno 2

SearchResult-1: term=the  cnt=5383, term=Q cnt=10

records returned: 0

Elapsed: 0.009691

Z> f Match-heading,phr,ext,do-not-truncate="the"

Sent searchRequest.

Received SearchResponse.

Search was a success.

Number of hits: 85, setno 3

SearchResult-1: term=the cnt=85

records returned: 0

Elapsed: 0.002209

 

However, 85 results is still too many. It should be 0 results.

 

I can't add the diagnostics from
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27198 right now
though. so will have to get back to this one another day probably.

 

But maybe someone else using Zebra with ICU can look into this problem too.

 

It's leading to lots of duplicate authorities it seems.

 

David Cook

Software Engineer

Prosentient Systems

Suite 7.03

6a Glen St

Milsons Point NSW 2061

Australia

 

Office: 02 9212 0899

Online: 02 8005 0595

 

From: Koha-devel <koha-devel-bounces at lists.koha-community.org> On Behalf Of
dcook at prosentient.com.au
Sent: Friday, 11 December 2020 4:22 PM
To: 'Koha Devel' <koha-devel at lists.koha-community.org>
Subject: Re: [Koha-devel] LinkBibHeadingsToAuthorities not working as
expected

 

Ugh yeah no. I'm reproducing it with koha-testing-docker too.

 

Looks like yet another ICU bug.

 

David Cook

Software Engineer

Prosentient Systems

Suite 7.03

6a Glen St

Milsons Point NSW 2061

Australia

 

Office: 02 9212 0899

Online: 02 8005 0595

 

From: Koha-devel <koha-devel-bounces at lists.koha-community.org
<mailto:koha-devel-bounces at lists.koha-community.org> > On Behalf Of
dcook at prosentient.com.au <mailto:dcook at prosentient.com.au> 
Sent: Friday, 11 December 2020 3:50 PM
To: 'Koha Devel' <koha-devel at lists.koha-community.org
<mailto:koha-devel at lists.koha-community.org> >
Subject: Re: [Koha-devel] LinkBibHeadingsToAuthorities not working as
expected

 

Then again. I can't reproduce this problem on koha-testing-docker, but I can
on a prod Koha running Zebra 2.1.4 with. a very strange
/etc/koha/zebradb/etc/default.idx file.

 

David Cook

Software Engineer

Prosentient Systems

Suite 7.03

6a Glen St

Milsons Point NSW 2061

Australia

 

Office: 02 9212 0899

Online: 02 8005 0595

 

From: Koha-devel <koha-devel-bounces at lists.koha-community.org
<mailto:koha-devel-bounces at lists.koha-community.org> > On Behalf Of
dcook at prosentient.com.au <mailto:dcook at prosentient.com.au> 
Sent: Friday, 11 December 2020 3:32 PM
To: 'Koha Devel' <koha-devel at lists.koha-community.org
<mailto:koha-devel at lists.koha-community.org> >
Subject: [Koha-devel] LinkBibHeadingsToAuthorities not working as expected

 

Hi all,

 

I'm still investigating, but it seems to me that the C4::Linker::Default in
C4::Biblio::LinkBibHeadingsToAuthorities isn't searching accurately using
C4::Heading::authorities. 

 

I'm looking at C4::AuthoritiesMarc::SearchAuthorities and at a glance it
looks OK, but in practice I think that my search queries are getting way too
many results. 

 

By hand, if I try the following query:

Match-heading,phr,ext,do-not-truncate="e"

 

I get a huge number of results, which is odd, since that should be an
"exact" match.

 

I've opened https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27198
because I need to improve the diagnostics available for a Zebra authorities
database, but yeah. not good. Hopefully I'll know more soon.

 

David Cook

Software Engineer

Prosentient Systems

Suite 7.03

6a Glen St

Milsons Point NSW 2061

Australia

 

Office: 02 9212 0899

Online: 02 8005 0595

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20201211/bfc59a8a/attachment-0001.htm>

From dcook at prosentient.com.au  Fri Dec 11 06:56:51 2020
From: dcook at prosentient.com.au (dcook at prosentient.com.au)
Date: Fri, 11 Dec 2020 16:56:51 +1100
Subject: [Koha-devel] LinkBibHeadingsToAuthorities not working as
 expected
In-Reply-To: <035001d6cf7e$cf724610$6e56d230$@prosentient.com.au>
References: <032b01d6cf76$968fb7e0$c3af27a0$@prosentient.com.au>
 <033501d6cf79$0a30c890$1e9259b0$@prosentient.com.au>
 <034401d6cf7d$95a3a600$c0eaf200$@prosentient.com.au>
 <035001d6cf7e$cf724610$6e56d230$@prosentient.com.au>
Message-ID: <035a01d6cf82$6c09fba0$441df2e0$@prosentient.com.au>

This one is driving me a bit crazy, so I've logged an issue with Indexdata
and I'm hoping for the best: https://github.com/indexdata/idzebra/issues/24.


 

David Cook

Software Engineer

Prosentient Systems

Suite 7.03

6a Glen St

Milsons Point NSW 2061

Australia

 

Office: 02 9212 0899

Online: 02 8005 0595

 

From: Koha-devel <koha-devel-bounces at lists.koha-community.org> On Behalf Of
dcook at prosentient.com.au
Sent: Friday, 11 December 2020 4:31 PM
To: 'Koha Devel' <koha-devel at lists.koha-community.org>
Subject: Re: [Koha-devel] LinkBibHeadingsToAuthorities not working as
expected

 

Using koha-testing-docker set up for ICU and with my fix from
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27198:

 

querytype ccl2rpn

set_cclfile /etc/koha/zebradb/ccl.properties

format xml

elements zebra::snippet

 

Z> f Match-heading,phr,ext,do-not-truncate="the Q"

Sent searchRequest.

Received SearchResponse.

Search was a success.

Number of hits: 34, setno 24

SearchResult-1: term=the cnt=34

records returned: 0

Elapsed: 0.000315

Z> show

Sent presentRequest (1+1).

Records: 1

Record type: XML

<record xmlns="http://www.indexdata.com/zebra/">

  <snippet name="Match-heading" type="p"
fields="Match">Xenophon<s>the</s>Historian</snippet>

</record>nextResultSetPosition = 2

Elapsed: 0.003864

 

So that's special. admittedly that's Zebra 2.0.59.

 

On Zebra 2.1.4 with ICU:

 

Z> f Match-heading,phr,ext,do-not-truncate="the Q"

Sent searchRequest.

Received SearchResponse.

Search was a success.

Number of hits: 0, setno 2

SearchResult-1: term=the  cnt=5383, term=Q cnt=10

records returned: 0

Elapsed: 0.009691

Z> f Match-heading,phr,ext,do-not-truncate="the"

Sent searchRequest.

Received SearchResponse.

Search was a success.

Number of hits: 85, setno 3

SearchResult-1: term=the cnt=85

records returned: 0

Elapsed: 0.002209

 

However, 85 results is still too many. It should be 0 results.

 

I can't add the diagnostics from
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27198 right now
though. so will have to get back to this one another day probably.

 

But maybe someone else using Zebra with ICU can look into this problem too.

 

It's leading to lots of duplicate authorities it seems.

 

David Cook

Software Engineer

Prosentient Systems

Suite 7.03

6a Glen St

Milsons Point NSW 2061

Australia

 

Office: 02 9212 0899

Online: 02 8005 0595

 

From: Koha-devel <koha-devel-bounces at lists.koha-community.org
<mailto:koha-devel-bounces at lists.koha-community.org> > On Behalf Of
dcook at prosentient.com.au <mailto:dcook at prosentient.com.au> 
Sent: Friday, 11 December 2020 4:22 PM
To: 'Koha Devel' <koha-devel at lists.koha-community.org
<mailto:koha-devel at lists.koha-community.org> >
Subject: Re: [Koha-devel] LinkBibHeadingsToAuthorities not working as
expected

 

Ugh yeah no. I'm reproducing it with koha-testing-docker too.

 

Looks like yet another ICU bug.

 

David Cook

Software Engineer

Prosentient Systems

Suite 7.03

6a Glen St

Milsons Point NSW 2061

Australia

 

Office: 02 9212 0899

Online: 02 8005 0595

 

From: Koha-devel <koha-devel-bounces at lists.koha-community.org
<mailto:koha-devel-bounces at lists.koha-community.org> > On Behalf Of
dcook at prosentient.com.au <mailto:dcook at prosentient.com.au> 
Sent: Friday, 11 December 2020 3:50 PM
To: 'Koha Devel' <koha-devel at lists.koha-community.org
<mailto:koha-devel at lists.koha-community.org> >
Subject: Re: [Koha-devel] LinkBibHeadingsToAuthorities not working as
expected

 

Then again. I can't reproduce this problem on koha-testing-docker, but I can
on a prod Koha running Zebra 2.1.4 with. a very strange
/etc/koha/zebradb/etc/default.idx file.

 

David Cook

Software Engineer

Prosentient Systems

Suite 7.03

6a Glen St

Milsons Point NSW 2061

Australia

 

Office: 02 9212 0899

Online: 02 8005 0595

 

From: Koha-devel <koha-devel-bounces at lists.koha-community.org
<mailto:koha-devel-bounces at lists.koha-community.org> > On Behalf Of
dcook at prosentient.com.au <mailto:dcook at prosentient.com.au> 
Sent: Friday, 11 December 2020 3:32 PM
To: 'Koha Devel' <koha-devel at lists.koha-community.org
<mailto:koha-devel at lists.koha-community.org> >
Subject: [Koha-devel] LinkBibHeadingsToAuthorities not working as expected

 

Hi all,

 

I'm still investigating, but it seems to me that the C4::Linker::Default in
C4::Biblio::LinkBibHeadingsToAuthorities isn't searching accurately using
C4::Heading::authorities. 

 

I'm looking at C4::AuthoritiesMarc::SearchAuthorities and at a glance it
looks OK, but in practice I think that my search queries are getting way too
many results. 

 

By hand, if I try the following query:

Match-heading,phr,ext,do-not-truncate="e"

 

I get a huge number of results, which is odd, since that should be an
"exact" match.

 

I've opened https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27198
because I need to improve the diagnostics available for a Zebra authorities
database, but yeah. not good. Hopefully I'll know more soon.

 

David Cook

Software Engineer

Prosentient Systems

Suite 7.03

6a Glen St

Milsons Point NSW 2061

Australia

 

Office: 02 9212 0899

Online: 02 8005 0595

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20201211/73fee2e9/attachment.htm>

From jonathan.druart at bugs.koha-community.org  Fri Dec 11 12:24:47 2020
From: jonathan.druart at bugs.koha-community.org (Jonathan Druart)
Date: Fri, 11 Dec 2020 12:24:47 +0100
Subject: [Koha-devel] 21.05 and release-notes-needed workflow
Message-ID: <CAJzKNY6DpgLbnCY-02tnXes1O0uBStqOM4BLKj1HWJZRFrVOew@mail.gmail.com>

Hi devs,

There is a small adjustment about the "release-notes-needed" bugzilla
keyword for 21.05.
With the documentation team we decided that the "Text to go in the
release notes" field must be filled *before* the new enhancements and
features are pushed to master.

If you have patches that reach the "Passed QA" status and that the bug
report does not have release notes, I will add the
"release-notes-needed". The patches won't be reviewed and pushed until
release notes have been correctly added.

The point of this workflow is 1. to make sure we won't have new
enhancement/ft without release notes when the major release is done,
2. help the documentation team to write the manual and 3. introduce
the habit to write the release notes when the patches are submitted,
to help testers, QAers and RM.

Let us know if you have any questions!

Cheers,
Jonathan

From kohanews at gmail.com  Sun Dec 13 01:00:05 2020
From: kohanews at gmail.com (Koha Community Newsletter)
Date: Sun, 13 Dec 2020 01:00:05 +0100 (CET)
Subject: [Koha-devel] Call for news - Newsletter December 2020
Message-ID: <20201213000005.E27FB196019F@vmi71934.adminkuhn.ch>

Hi

I'm collecting news for the December 2020 Koha Community Newsletter. Please send anything noteworthy to:

kohanews (at) gmail (dot) com

News criteria:
* News items can be of any length.
* Images are fine.
* Anything and everything Koha.
* Submit by the 26th of the month.

For events:
* Please include dates for past events. If I can't find dates I may not add it.
* Announcements for future events with dates to be announced are fine, e. g. Kohacon.
* For past events, one month back is the cut-off.

If you are working on an interesting project or development related to Koha, please let me know and I'll include it in the development section.

Thank you!

Michael Kuhn
Editor, Koha Community Newsletter

From mik at adminkuhn.ch  Sun Dec 13 13:39:02 2020
From: mik at adminkuhn.ch (Michael Kuhn)
Date: Sun, 13 Dec 2020 13:39:02 +0100 (CET)
Subject: [Koha-devel] Call for news - Newsletter December 2020
Message-ID: <20201213123902.B92E9196019E@vmi71934.adminkuhn.ch>

Hi

I'm collecting news for the December 2020 Koha Community Newsletter. Please send anything noteworthy to:

kohanews (at) gmail (dot) com

News criteria:
* News items can be of any length.
* Images are fine.
* Anything and everything Koha.
* Submit by the 26th of the month.

For events:
* Please include dates for past events. If I can't find dates I may not add it.
* Announcements for future events with dates to be announced are fine, e. g. Kohacon.
* For past events, one month back is the cut-off.

If you are working on an interesting project or development related to Koha, please let me know and I'll include it in the development section.

Thank you!

Michael Kuhn
Editor, Koha Community Newsletter

From kohanews at gmail.com  Sun Dec 13 14:37:02 2020
From: kohanews at gmail.com (Koha Newsletter)
Date: Sun, 13 Dec 2020 14:37:02 +0100
Subject: [Koha-devel] Call for news - Newsletter December 2020
Message-ID: <CAEqgz_kTArwt9_6Zj=FSTfhcL4nYOR+ORxuScS3GHUeFX_Z+eg@mail.gmail.com>

Hi

I'm collecting news for the December 2020 Koha Community Newsletter.
Please send anything noteworthy to:

kohanews (at) gmail (dot) com

News criteria:
* News items can be of any length.
* Images are fine.
* Anything and everything Koha.
* Submit by the 26th of the month.

For events:
* Please include dates for past events. If I can't find dates I may not add it.
* Announcements for future events with dates to be announced are fine,
e. g. Kohacon.
* For past events, one month back is the cut-off.

If you are working on an interesting project or development related to
Koha, please let me know and I'll include it in the development
section.

Thank you!

Michael Kuhn
Editor, Koha Community Newsletter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20201213/e6579796/attachment.htm>

From dcook at prosentient.com.au  Mon Dec 14 00:15:49 2020
From: dcook at prosentient.com.au (dcook at prosentient.com.au)
Date: Mon, 14 Dec 2020 10:15:49 +1100
Subject: [Koha-devel] [Koha] Red Hat 8, installing dependencies
Message-ID: <043201d6d1a5$e5208110$af618330$@prosentient.com.au>

Hi Tasha,

It's great to hear that you're trying to install Koha! However, if I were you, I wouldn't bother with that old wiki page, as it's probably going to confuse more than help.

Typically, the Koha community supports Koha installations on Debian and Ubuntu operating systems, but there are some of us who run Koha on openSUSE, Red Hat, Fedora, etc. We are rare though. Wherever possible, it's best to use Debian/Ubuntu as you'll get the best, supported experience that way, but I know in a corporate environment that you're often limited to only using Red Hat Enterprise Linux. Part of the reason your email stood out to me is that I am in the process of migrating a non-Koha Perl application from RHEL 6 to RHEL 8, so I'm already in this headspace.

In all honesty, if I were you, I'd try to find a vendor that is willing - for a fee - to install Koha on your local RHEL 8 system. You can find more information at https://koha-community.org/support/paid-support/. We have installed Koha on RHEL for libraries with restricted corporate environments like you describe. I am sure there are vendors in Canada and the USA who have done it too who could help you out. Feel free to email me separately about that if you want to discuss that further.

--

If you are committed to doing it yourself without paid help, then it's important to think about Koha as a multi-component system: Linux OS, Apache httpd web server, MySQL database, Perl application, Zebra indexing engine. 

You've already got your Linux OS (RHEL 8), and you'll be able to use the Apache httpd web server and MySQL database from the Red Hat repositories. The difficulty will be with the Perl application (Koha proper) and Zebra. 

Looking at https://www.indexdata.com/resources/software/zebra/, there is a "Redhat" download option, but it does not look like the RHEL packages have been maintained. You could contact Indexdata to get them to publish new packages for RHEL 8. Alternatively, it looks like they do provide some for CentOS 8, which is *currently*  compatible with RHEL 8: http://ftp.indexdata.dk/pub/zebra/redhat/centos/8/README. I haven't used that but that would be my first step *before* trying to build Zebra from source. 

As for the Perl application (Koha proper), it's easier than ever to install dependencies thanks to the "cpanfile" provided with Koha. It provides a list of ~180 Perl dependencies, which you can install using a tool called "cpanminus" (https://metacpan.org/pod/App::cpanminus). Unfortunately for you, these dependencies need to be fetched over the Internet from the "CPAN" (Comprehensive Perl Archive Network). However, perhaps you'd be able to talk to your IT about setting up a local offline mirror of CPAN. You can use the "minicpan" tool for that: https://metacpan.org/pod/distribution/CPAN-Mini/bin/minicpan. I have used that tool before in restricted corporate environments for Perl applications. 

Now that sounds easier than it actually is. You mentioned that you had some trouble installing some packages like "ImageMagick-devel". You need "*-devel" packages when you're building code from course (like you'd be doing using "cpanminus" and the "cpanfile" via "minicpan"), as they provide interfaces to lower level software tools (e.g. "ImageMagic" without the -devel). Typically, you discover which "-devel" packages you need when particular Perl dependencies fail to install. 

If you're successful with all of this, then there is the task of setting up a Zebra "service" and Koha "cronjobs". 

This also all assumes that you're not use SELinux security on RHEL 8 as well. That is a layer of complexity that is too difficult to explain in this space.

--

Alternatively, you could try running Docker containers - since Docker should be available in RHEL 8, or Virtual Machines on your RHEL 8 machine, and have those containers or virtual machines run Koha on Debian/Ubuntu. But that adds a different layer of complexity.

--

Hopefully that was helpfully comprehensive rather than terrifyingly comprehensive ; ). For years, I have been thinking of putting together RPM packages that could be installed on Red Hat or openSUSE, but it would require more resources than I have available, so I've been in the gradual process of switching to only using Debian/Ubuntu for Koha wherever possible. 

But I appreciate that you might not have that option. Due to your limitations, I think your best bet is to get a paid support vendor to help you, but you can also try what I've suggested and try working through it here. You probably won't be able to receive much more than general assistance, since the majority of people use Debian/Ubuntu, but you can always try.

Bon courage!

David Cook
Software Engineer
Prosentient Systems
Suite 7.03
6a Glen St
Milsons Point NSW 2061
Australia

Office: 02 9212 0899
Online: 02 8005 0595

-----Original Message-----
Date: Sat, 12 Dec 2020 21:37:08 +0000
From: "Bales (US), Tasha R" <tasha.r.bales at boeing.com>
To: "koha at lists.katipo.co.nz" <koha at lists.katipo.co.nz>
Subject: [Koha] Red Hat 8, installing dependencies
Message-ID: <6d2acf16030d48a4b6f3885b47ae8b17 at boeing.com>
Content-Type: text/plain; charset="us-ascii"

Good afternoon,

I'm trying to install the latest version of Koha on Red Hat 8.1, using the Koha Wiki instructions<https://wiki.koha-community.org/wiki/Koha_on_Redhat_Enterprise_6> for Red Hat 6.  Perhaps you can help with a couple questions.

First, the Wiki contains a list of about 70 dependencies that should be installed before Koha. Since the Wiki article is dated, is there a method for determining whether this list is still accurate for Red Hat 8 and current Koha?  Or, would one just need to be on the lookout for inevitable errors and complaints about missing dependencies?

Next, I'm limited to working with a corporate repository-I cannot connect to the internet--but I was able to install all but 11 of the recommended packages, see below.  I don't necessarily know that all of these are critical requirements, but some of them seem significant when I Googled them for more info.  They are as follows:


*              cloog-ppl

*              ghostscript-devel (I have the non-devel package)

*              gnome-utils-libs (I don't think we need this)

*              ImageMagick

*              ImageMagick-devel

*              Imake (May not need this)

*              jasper-devel (We have jasper-libs)

*              lcms-devel

*              libXdmcp-devel

*              libxml2-python

*              ppl

If you can advise where I ought to look to gain an understanding of whether these missing packages are 1) true requirements for Koha 20.x, given I obtained them from an older Wiki article; 2) show-stoppers that will prevent using Koha, or certain features of Koha, if they are not present.

I appreciate and thank you in advance for any advice you may have.  I am doing a good amount of research on the web to try to answer my own questions, but I'm a bit out of my league.  Thanks for your time and consideration,


Tasha R. Bales




From ztajoli at gmail.com  Tue Dec 15 00:57:10 2020
From: ztajoli at gmail.com (Zeno Tajoli)
Date: Tue, 15 Dec 2020 00:57:10 +0100
Subject: [Koha-devel] Z39.50 daemon with ElasticSearch
Message-ID: <abff8105-92ad-7389-fc8c-98a461cca6a7@gmail.com>

Hi to,
I'm trying to use ElasticSearch everywhere with Koha 20.11
I'm working on Debian 10, EleasticSearch 6.8.13, Java openjdk 11 (Debian 
package)

The search on Opac and Intranet is OK.

Problems are on z39.50 server.
With bug 13937 a z39.50/SRU server is ready also with ES as search back-end.

But now the demonization of the script doesn't work.
If i do:
sudo koha-z3950-responder --start lib
and I do a check with:
yaz-client
Z> open 127.0.0.1:2100/biblios
Connecting...OK.
Sent initrequest.
Target closed connection
Z>

The result is 'closed connection', ZOOM error: 1004

But if do:
sudo koha-z3950-responder --stop lib
sudo koha-shell lib
/usr/bin/perl /usr/share/koha/bin/z3950_responder.pl -c 
/etc/koha/sites/lib/z3950 -l /var/log/koha/lib/z3950.log
koha at deb:~$ yaz-client
Z> open 127.0.0.1:2100/biblios
Connecting...OK.
Sent initrequest.
Connection accepted by v3 target.
ID     : 81
Name   : Koha/GFS/YAZ
Version: 20.11.00.000/5.30.3 2af59bc45cf4508d5c84f350ee99804c4354b3b3
Options: search present triggerResourceCtrl namedResultSets
Elapsed: 0.012131
Z> f css3
Sent searchRequest.
Received SearchResponse.
Search was a success.
Number of hits: 1, setno 1
records returned: 0
Elapsed: 0.915224
Z> show 1
Sent presentRequest (1+1).
Records: 1
[]Record type: USmarc
00357nam a22001217a 4500
005 20201208204443.0
008 201208b           ||||| |||| 00| 0 eng d
040    $c IFLA
100    $a Tajoli, Zeno
245    $a Node.js e CSS3
...

So the script 'z3950_responder.pl' is working, the transformation into 
daemon not.
Do you have any suggestion/check to fix this situation ?

Cheers
Zeno Tajoli


-- 
Zeno Tajoli
System Librarian

From fridolin.somers at biblibre.com  Tue Dec 15 08:51:13 2020
From: fridolin.somers at biblibre.com (Fridolin SOMERS)
Date: Tue, 15 Dec 2020 08:51:13 +0100
Subject: [Koha-devel] Z39.50 daemon with ElasticSearch
In-Reply-To: <abff8105-92ad-7389-fc8c-98a461cca6a7@gmail.com>
References: <abff8105-92ad-7389-fc8c-98a461cca6a7@gmail.com>
Message-ID: <b75f619f-228a-9df6-9faf-adc604793847@biblibre.com>

Hi,

We at Biblibre use one Koha per machine so whe created a SystemD unit :

[Unit]
Description=Koha Z39.50 Service

[Service]
Type=simple
User=koha
Environment="KOHA_CONF=/home/koha/etc/koha-conf.xml" 
"PERL5LIB=/home/koha/src"
ExecStart=/home/koha/src/misc/z3950_responder.pl --debug

[Install]
WantedBy=multi-user.target

Easy peazy

Le 15/12/2020 à 00:57, Zeno Tajoli a écrit :
> Hi to,
> I'm trying to use ElasticSearch everywhere with Koha 20.11
> I'm working on Debian 10, EleasticSearch 6.8.13, Java openjdk 11 (Debian 
> package)
> 
> The search on Opac and Intranet is OK.
> 
> Problems are on z39.50 server.
> With bug 13937 a z39.50/SRU server is ready also with ES as search 
> back-end.
> 
> But now the demonization of the script doesn't work.
> If i do:
> sudo koha-z3950-responder --start lib
> and I do a check with:
> yaz-client
> Z> open 127.0.0.1:2100/biblios
> Connecting...OK.
> Sent initrequest.
> Target closed connection
> Z>
> 
> The result is 'closed connection', ZOOM error: 1004
> 
> But if do:
> sudo koha-z3950-responder --stop lib
> sudo koha-shell lib
> /usr/bin/perl /usr/share/koha/bin/z3950_responder.pl -c 
> /etc/koha/sites/lib/z3950 -l /var/log/koha/lib/z3950.log
> koha at deb:~$ yaz-client
> Z> open 127.0.0.1:2100/biblios
> Connecting...OK.
> Sent initrequest.
> Connection accepted by v3 target.
> ID     : 81
> Name   : Koha/GFS/YAZ
> Version: 20.11.00.000/5.30.3 2af59bc45cf4508d5c84f350ee99804c4354b3b3
> Options: search present triggerResourceCtrl namedResultSets
> Elapsed: 0.012131
> Z> f css3
> Sent searchRequest.
> Received SearchResponse.
> Search was a success.
> Number of hits: 1, setno 1
> records returned: 0
> Elapsed: 0.915224
> Z> show 1
> Sent presentRequest (1+1).
> Records: 1
> []Record type: USmarc
> 00357nam a22001217a 4500
> 005 20201208204443.0
> 008 201208b           ||||| |||| 00| 0 eng d
> 040    $c IFLA
> 100    $a Tajoli, Zeno
> 245    $a Node.js e CSS3
> ...
> 
> So the script 'z3950_responder.pl' is working, the transformation into 
> daemon not.
> Do you have any suggestion/check to fix this situation ?
> 
> Cheers
> Zeno Tajoli
> 
> 

-- 
Fridolin SOMERS <fridolin.somers at biblibre.com>
Software and system maintainer 🦄
BibLibre, France

From ztajoli at gmail.com  Wed Dec 16 00:02:28 2020
From: ztajoli at gmail.com (Zeno Tajoli)
Date: Wed, 16 Dec 2020 00:02:28 +0100
Subject: [Koha-devel] Z39.50 daemon with ElasticSearch
In-Reply-To: <b75f619f-228a-9df6-9faf-adc604793847@biblibre.com>
References: <abff8105-92ad-7389-fc8c-98a461cca6a7@gmail.com>
 <b75f619f-228a-9df6-9faf-adc604793847@biblibre.com>
Message-ID: <8527eba7-d6c0-3d7d-366d-e85257e827e7@gmail.com>

Hi,

I use the suggestion of Fridolin and now I'm a working z39.50 with 
ElasticSearch on Koha 20.11

My SystemD unit  (etc/systemd/system/koha-z39-el.service):
[Unit]
Description=Koha Z39.50 Service

[Service]
Type=simple
User=lib-koha
Environment="KOHA_CONF=/etc/koha/sites/lib/koha-conf.xml" 
"PERL5LIB=/usr/share/koha/lib"
ExecStart=/usr/share/koha/bin/z3950_responder.pl 
--config-dir=/etc/koha/sites/lib/z3950-ES -l /var/log/koha/lib/z3950.log 
-u lib-koha -p /var/run/koha/lib/z3950-responder.pid --debug
	
[Install]
WantedBy=multi-user.target

I add/change those values:
User=<the Unix user related with instance>

ExecStart=/usr/share/koha/bin/z3950_responder.pl

--config-dir=/etc/koha/sites/lib/z3950-ES
#It can't use '-c'; I create a new specific dir for configurations

-l /var/log/koha/lib/z3950.log
#The log file

-u lib-koha
#The user to use

-p /var/run/koha/lib/z3950-responder.pid
#File for save pid

--debug
	
What do you think of the changes and adds ?

Cheers
Zeno Tajoli




Il 15/12/2020 08:51, Fridolin SOMERS ha scritto:
> Hi,
> 
> We at Biblibre use one Koha per machine so whe created a SystemD unit :
> 
> [Unit]
> Description=Koha Z39.50 Service
> 
> [Service]
> Type=simple
> User=koha
> Environment="KOHA_CONF=/home/koha/etc/koha-conf.xml" 
> "PERL5LIB=/home/koha/src"
> ExecStart=/home/koha/src/misc/z3950_responder.pl --debug
> 
> [Install]
> WantedBy=multi-user.target
> 
> Easy peazy
> 
> Le 15/12/2020 à 00:57, Zeno Tajoli a écrit :
>> Hi to,
>> I'm trying to use ElasticSearch everywhere with Koha 20.11
>> I'm working on Debian 10, EleasticSearch 6.8.13, Java openjdk 11 
>> (Debian package)
>>
>> The search on Opac and Intranet is OK.
>>
>> Problems are on z39.50 server.
>> With bug 13937 a z39.50/SRU server is ready also with ES as search 
>> back-end.
>>
>> But now the demonization of the script doesn't work.
>> If i do:
>> sudo koha-z3950-responder --start lib
>> and I do a check with:
>> yaz-client
>> Z> open 127.0.0.1:2100/biblios
>> Connecting...OK.
>> Sent initrequest.
>> Target closed connection
>> Z>
>>
>> The result is 'closed connection', ZOOM error: 1004
>>
>> But if do:
>> sudo koha-z3950-responder --stop lib
>> sudo koha-shell lib
>> /usr/bin/perl /usr/share/koha/bin/z3950_responder.pl -c 
>> /etc/koha/sites/lib/z3950 -l /var/log/koha/lib/z3950.log
>> koha at deb:~$ yaz-client
>> Z> open 127.0.0.1:2100/biblios
>> Connecting...OK.
>> Sent initrequest.
>> Connection accepted by v3 target.
>> ID     : 81
>> Name   : Koha/GFS/YAZ
>> Version: 20.11.00.000/5.30.3 2af59bc45cf4508d5c84f350ee99804c4354b3b3
>> Options: search present triggerResourceCtrl namedResultSets
>> Elapsed: 0.012131
>> Z> f css3
>> Sent searchRequest.
>> Received SearchResponse.
>> Search was a success.
>> Number of hits: 1, setno 1
>> records returned: 0
>> Elapsed: 0.915224
>> Z> show 1
>> Sent presentRequest (1+1).
>> Records: 1
>> []Record type: USmarc
>> 00357nam a22001217a 4500
>> 005 20201208204443.0
>> 008 201208b           ||||| |||| 00| 0 eng d
>> 040    $c IFLA
>> 100    $a Tajoli, Zeno
>> 245    $a Node.js e CSS3
>> ...
>>
>> So the script 'z3950_responder.pl' is working, the transformation into 
>> daemon not.
>> Do you have any suggestion/check to fix this situation ?
>>
>> Cheers
>> Zeno Tajoli
>>
>>
> 

-- 
Zeno Tajoli
System Librarian

From dcook at prosentient.com.au  Wed Dec 16 00:04:38 2020
From: dcook at prosentient.com.au (dcook at prosentient.com.au)
Date: Wed, 16 Dec 2020 10:04:38 +1100
Subject: [Koha-devel] Koha Command and Control
Message-ID: <059e01d6d336$a9c47e90$fd4d7bb0$@prosentient.com.au>

Hi all,

 

For a while, I've been thinking that it might be good to have an open source
"Koha Command and Control" for managing Koha instances. 

 

While managing 1 Koha is not too much work, it's considerably more difficult
to manage 10, 100, or 1000 Koha instances, especially across different
servers, geographic locations, timezones, etc. 

 

I am sure that most vendors have mechanisms in place for checking the system
preference values for all their instances (I have scripts for this sort of
thing), what about tracking Zebra queries that contain syntax errors (bug
27139)? 

 

I know that we have HEA for sharing a lot of data, but there is some data
(like search queries) that I don't think most libraries would want to share
with the community. But Koha administrators, especially vendors with a large
number of Koha instances, want to know when problems arise. 

 

I suppose that a person could just implement log file scanning for Zebra,
but I was thinking about something more structured, which could be analyzed
to provide data quality control. My thought is that we'd configure Koha to
push events to the "Koha Command and Control" (which would be configured by
the Koha system administrator - not librarian level). If Zebra logs a 'ZOOM
error 10014 "CCL parsing error"', we probably want to tell the Koha user
that we found no search results (nice user experience), but we want to flag
with a Koha administrator that there is a problem. If Koha administrators
(e.g. Koha vendors) start receiving a lot of these errors via the Koha CnC
(Command and Control), they're better placed to raise Bugzilla reports/write
patches. 

 

Anyway, it's just an idea. Probably too ambitious. But I think that it would
be wise for us to start thinking more about the *data* generated by Koha and
how we can use that data to improve Koha. I don't think we need machine
learning algorithms to do the data analysis (yet), but I think having
automated data collection, organisation, and reporting would be useful. 

 

I have to run but I'll keep thinking about it. I know I have more grand
ideas than I have time, but I could put some thought into what a system
might look like, and maybe throw something together locally first before
suggesting anyone else get on board.

 

David Cook

Software Engineer

Prosentient Systems

Suite 7.03

6a Glen St

Milsons Point NSW 2061

Australia

 

Office: 02 9212 0899

Online: 02 8005 0595

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20201216/43c7d626/attachment.htm>

From dcook at prosentient.com.au  Wed Dec 16 02:51:14 2020
From: dcook at prosentient.com.au (dcook at prosentient.com.au)
Date: Wed, 16 Dec 2020 12:51:14 +1100
Subject: [Koha-devel] Why does #wrap have padding?
Message-ID: <05c801d6d34d$efe71650$cfb542f0$@prosentient.com.au>

Hi all,

 

Does anyone know why #wrap in
koha-tmpl/opac-tmpl/bootstrap/css/src/_common.scss has padding-left: 40px
and padding-right: 40px?

 

It makes adding full-width headers/footers impossible without tricks and
compensations for changes to the padding with the responsive media queries.

 

You end up writing pages of CSS just for 1 banner. 

 

Or am I missing something?

 

David Cook

Software Engineer

Prosentient Systems

Suite 7.03

6a Glen St

Milsons Point NSW 2061

Australia

 

Office: 02 9212 0899

Online: 02 8005 0595

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20201216/c04a4f48/attachment.htm>

From fridolin.somers at biblibre.com  Wed Dec 16 09:53:40 2020
From: fridolin.somers at biblibre.com (Fridolin SOMERS)
Date: Wed, 16 Dec 2020 09:53:40 +0100
Subject: [Koha-devel] LinkBibHeadingsToAuthorities not working as
 expected
In-Reply-To: <035a01d6cf82$6c09fba0$441df2e0$@prosentient.com.au>
References: <032b01d6cf76$968fb7e0$c3af27a0$@prosentient.com.au>
 <033501d6cf79$0a30c890$1e9259b0$@prosentient.com.au>
 <034401d6cf7d$95a3a600$c0eaf200$@prosentient.com.au>
 <035001d6cf7e$cf724610$6e56d230$@prosentient.com.au>
 <035a01d6cf82$6c09fba0$441df2e0$@prosentient.com.au>
Message-ID: <72cee5d3-968a-663b-86a2-8914653b7642@biblibre.com>

Thanks a lot for your tests.

I will try on our Bionic env with Zebra 2.2.1

Le 11/12/2020 à 06:56, dcook at prosentient.com.au a écrit :
> This one is driving me a bit crazy, so I’ve logged an issue with 
> Indexdata and I’m hoping for the best: 
> https://github.com/indexdata/idzebra/issues/24 
> <https://github.com/indexdata/idzebra/issues/24>.
> 
> David Cook
> 
> Software Engineer
> 
> Prosentient Systems
> 
> Suite 7.03
> 
> 6a Glen St
> 
> Milsons Point NSW 2061
> 
> Australia
> 
> Office: 02 9212 0899
> 
> Online: 02 8005 0595
> 
> *From:*Koha-devel <koha-devel-bounces at lists.koha-community.org> *On 
> Behalf Of *dcook at prosentient.com.au
> *Sent:* Friday, 11 December 2020 4:31 PM
> *To:* 'Koha Devel' <koha-devel at lists.koha-community.org>
> *Subject:* Re: [Koha-devel] LinkBibHeadingsToAuthorities not working as 
> expected
> 
> Using koha-testing-docker set up for ICU and with my fix from 
> https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27198 
> <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27198>:
> 
> querytype ccl2rpn
> 
> set_cclfile /etc/koha/zebradb/ccl.properties
> 
> format xml
> 
> elements zebra::snippet
> 
> Z> f Match-heading,phr,ext,do-not-truncate="the Q"
> 
> Sent searchRequest.
> 
> Received SearchResponse.
> 
> Search was a success.
> 
> Number of hits: 34, setno 24
> 
> SearchResult-1: term=the cnt=34
> 
> records returned: 0
> 
> Elapsed: 0.000315
> 
> Z> show
> 
> Sent presentRequest (1+1).
> 
> Records: 1
> 
> Record type: XML
> 
> <record xmlns="http://www.indexdata.com/zebra/ 
> <http://www.indexdata.com/zebra/>">
> 
>    <snippet name="Match-heading" type="p" 
> fields="Match">Xenophon<s>the</s>Historian</snippet>
> 
> </record>nextResultSetPosition = 2
> 
> Elapsed: 0.003864
> 
> So that’s special… admittedly that’s Zebra 2.0.59…
> 
> On Zebra 2.1.4 with ICU:
> 
> Z> f Match-heading,phr,ext,do-not-truncate="the Q"
> 
> Sent searchRequest.
> 
> Received SearchResponse.
> 
> Search was a success.
> 
> Number of hits: 0, setno 2
> 
> SearchResult-1: term=the  cnt=5383, term=Q cnt=10
> 
> records returned: 0
> 
> Elapsed: 0.009691
> 
> Z> f Match-heading,phr,ext,do-not-truncate="the"
> 
> Sent searchRequest.
> 
> Received SearchResponse.
> 
> Search was a success.
> 
> Number of hits: 85, setno 3
> 
> SearchResult-1: term=the cnt=85
> 
> records returned: 0
> 
> Elapsed: 0.002209
> 
> However, 85 results is still too many. It should be 0 results.
> 
> I can’t add the diagnostics from 
> https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27198 
> <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27198> right 
> now though… so will have to get back to this one another day probably.
> 
> But maybe someone else using Zebra with ICU can look into this problem too.
> 
> It’s leading to lots of duplicate authorities it seems…
> 
> David Cook
> 
> Software Engineer
> 
> Prosentient Systems
> 
> Suite 7.03
> 
> 6a Glen St
> 
> Milsons Point NSW 2061
> 
> Australia
> 
> Office: 02 9212 0899
> 
> Online: 02 8005 0595
> 
> *From:*Koha-devel <koha-devel-bounces at lists.koha-community.org 
> <mailto:koha-devel-bounces at lists.koha-community.org>> *On Behalf Of 
> *dcook at prosentient.com.au <mailto:dcook at prosentient.com.au>
> *Sent:* Friday, 11 December 2020 4:22 PM
> *To:* 'Koha Devel' <koha-devel at lists.koha-community.org 
> <mailto:koha-devel at lists.koha-community.org>>
> *Subject:* Re: [Koha-devel] LinkBibHeadingsToAuthorities not working as 
> expected
> 
> Ugh yeah no… I’m reproducing it with koha-testing-docker too.
> 
> Looks like yet another ICU bug…
> 
> David Cook
> 
> Software Engineer
> 
> Prosentient Systems
> 
> Suite 7.03
> 
> 6a Glen St
> 
> Milsons Point NSW 2061
> 
> Australia
> 
> Office: 02 9212 0899
> 
> Online: 02 8005 0595
> 
> *From:*Koha-devel <koha-devel-bounces at lists.koha-community.org 
> <mailto:koha-devel-bounces at lists.koha-community.org>> *On Behalf Of 
> *dcook at prosentient.com.au <mailto:dcook at prosentient.com.au>
> *Sent:* Friday, 11 December 2020 3:50 PM
> *To:* 'Koha Devel' <koha-devel at lists.koha-community.org 
> <mailto:koha-devel at lists.koha-community.org>>
> *Subject:* Re: [Koha-devel] LinkBibHeadingsToAuthorities not working as 
> expected
> 
> Then again… I can’t reproduce this problem on koha-testing-docker, but I 
> can on a prod Koha running Zebra 2.1.4 with… a very strange 
> /etc/koha/zebradb/etc/default.idx file…
> 
> David Cook
> 
> Software Engineer
> 
> Prosentient Systems
> 
> Suite 7.03
> 
> 6a Glen St
> 
> Milsons Point NSW 2061
> 
> Australia
> 
> Office: 02 9212 0899
> 
> Online: 02 8005 0595
> 
> *From:*Koha-devel <koha-devel-bounces at lists.koha-community.org 
> <mailto:koha-devel-bounces at lists.koha-community.org>> *On Behalf Of 
> *dcook at prosentient.com.au <mailto:dcook at prosentient.com.au>
> *Sent:* Friday, 11 December 2020 3:32 PM
> *To:* 'Koha Devel' <koha-devel at lists.koha-community.org 
> <mailto:koha-devel at lists.koha-community.org>>
> *Subject:* [Koha-devel] LinkBibHeadingsToAuthorities not working as expected
> 
> Hi all,
> 
> I’m still investigating, but it seems to me that the C4::Linker::Default 
> in C4::Biblio::LinkBibHeadingsToAuthorities isn’t searching accurately 
> using C4::Heading::authorities.
> 
> I’m looking at C4::AuthoritiesMarc::SearchAuthorities and at a glance it 
> looks OK, but in practice I think that my search queries are getting way 
> too many results.
> 
> By hand, if I try the following query:
> 
> Match-heading,phr,ext,do-not-truncate="e"
> 
> I get a huge number of results, which is odd, since that should be an 
> “exact” match.
> 
> I’ve opened 
> https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27198 
> <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27198> 
> because I need to improve the diagnostics available for a Zebra 
> authorities database, but yeah… not good. Hopefully I’ll know more soon.
> 
> David Cook
> 
> Software Engineer
> 
> Prosentient Systems
> 
> Suite 7.03
> 
> 6a Glen St
> 
> Milsons Point NSW 2061
> 
> Australia
> 
> Office: 02 9212 0899
> 
> Online: 02 8005 0595
> 
> 
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
> 

-- 
Fridolin SOMERS <fridolin.somers at biblibre.com>
Software and system maintainer 🦄
BibLibre, France

From oleonard at myacpl.org  Wed Dec 16 13:22:09 2020
From: oleonard at myacpl.org (Owen Leonard)
Date: Wed, 16 Dec 2020 07:22:09 -0500
Subject: [Koha-devel] Why does #wrap have padding?
In-Reply-To: <05c801d6d34d$efe71650$cfb542f0$@prosentient.com.au>
References: <05c801d6d34d$efe71650$cfb542f0$@prosentient.com.au>
Message-ID: <CAO4qe2P7dmN0C7QS5vFafXTgSs2Zv3u-im5BMoDP=qMqRM8woA@mail.gmail.com>

> Does anyone know why #wrap in koha-tmpl/opac-tmpl/bootstrap/css/src/_common.scss has padding-left: 40px and padding-right: 40px?

Because the OPAC was designed to have 40 pixels of padding on either
side of the main content.

> It makes adding full-width headers/footers impossible without tricks and compensations for changes to the padding with the responsive media queries.

All CSS customizations require tricks and compensations to override!

  -- Owen

-- 
Web Developer
Athens County Public Libraries
(740) 737-6006
https://www.myacpl.org

From bibliwho at gmail.com  Wed Dec 16 16:01:47 2020
From: bibliwho at gmail.com (Cab Vinton)
Date: Wed, 16 Dec 2020 10:01:47 -0500
Subject: [Koha-devel] Koha Command and Control
In-Reply-To: <059e01d6d336$a9c47e90$fd4d7bb0$@prosentient.com.au>
References: <059e01d6d336$a9c47e90$fd4d7bb0$@prosentient.com.au>
Message-ID: <CABW43UThDM_YTiOaBOkzkpNfcK2KZk-OqDjKNM7btChG=bZcWA@mail.gmail.com>

This popped into my email ... Above my pay grade, but maybe of relevance?

https://newrelic.com/

All best,

Cab Vinton, Director
Plaistow Public Library

On Tue, Dec 15, 2020 at 6:04 PM <dcook at prosentient.com.au> wrote:
>
> Hi all,
>
>
>
> For a while, I’ve been thinking that it might be good to have an open source “Koha Command and Control” for managing Koha instances.
>
>
>
> While managing 1 Koha is not too much work, it’s considerably more difficult to manage 10, 100, or 1000 Koha instances, especially across different servers, geographic locations, timezones, etc.
>
>
>
> I am sure that most vendors have mechanisms in place for checking the system preference values for all their instances (I have scripts for this sort of thing), what about tracking Zebra queries that contain syntax errors (bug 27139)?
>
>
>
> I know that we have HEA for sharing a lot of data, but there is some data (like search queries) that I don’t think most libraries would want to share with the community. But Koha administrators, especially vendors with a large number of Koha instances, want to know when problems arise.
>
>
>
> I suppose that a person could just implement log file scanning for Zebra, but I was thinking about something more structured, which could be analyzed to provide data quality control. My thought is that we’d configure Koha to push events to the “Koha Command and Control” (which would be configured by the Koha system administrator – not librarian level). If Zebra logs a ‘ZOOM error 10014 "CCL parsing error"’, we probably want to tell the Koha user that we found no search results (nice user experience), but we want to flag with a Koha administrator that there is a problem. If Koha administrators (e.g. Koha vendors) start receiving a lot of these errors via the Koha CnC (Command and Control), they’re better placed to raise Bugzilla reports/write patches.
>
>
>
> Anyway, it’s just an idea. Probably too ambitious. But I think that it would be wise for us to start thinking more about the *data* generated by Koha and how we can use that data to improve Koha. I don’t think we need machine learning algorithms to do the data analysis (yet), but I think having automated data collection, organisation, and reporting would be useful.
>
>
>
> I have to run but I’ll keep thinking about it. I know I have more grand ideas than I have time, but I could put some thought into what a system might look like, and maybe throw something together locally first before suggesting anyone else get on board…
>
>
>
> David Cook
>
> Software Engineer
>
> Prosentient Systems
>
> Suite 7.03
>
> 6a Glen St
>
> Milsons Point NSW 2061
>
> Australia
>
>
>
> Office: 02 9212 0899
>
> Online: 02 8005 0595
>
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/

From arthur.suzuki at biblibre.com  Wed Dec 16 16:15:27 2020
From: arthur.suzuki at biblibre.com (Arthur)
Date: Wed, 16 Dec 2020 16:15:27 +0100
Subject: [Koha-devel] Koha Command and Control
In-Reply-To: <CABW43UThDM_YTiOaBOkzkpNfcK2KZk-OqDjKNM7btChG=bZcWA@mail.gmail.com>
References: <059e01d6d336$a9c47e90$fd4d7bb0$@prosentient.com.au>
 <CABW43UThDM_YTiOaBOkzkpNfcK2KZk-OqDjKNM7btChG=bZcWA@mail.gmail.com>
Message-ID: <daca1ab8-aa6b-4993-c333-7ef3511b7da1@biblibre.com>

Hi there,

for this kind of purpose I would recommend using Ansible scripts to ship
commands to several Koha's at once.

Using Ansible only needs an ssh connexion to each of your Koha servers,
no specific software or agent to install on the targets, then commands
are simple well-known bash.

It is also possible to group targets (manually) based on OS, web-server
software or other tweaks to deploy specific sets of commands to each of
your groups, this is very handy.

I personally don't use it because our environment is very heterogeneous,
making grouping difficult and prone to error (and then we would have a
lot of groups of a single instance...)

Best,

Arthur Suzuki

BibLibre Koha Support

On 16/12/2020 16:01, Cab Vinton wrote:
> This popped into my email ... Above my pay grade, but maybe of relevance?
>
> https://newrelic.com/
>
> All best,
>
> Cab Vinton, Director
> Plaistow Public Library
>
> On Tue, Dec 15, 2020 at 6:04 PM <dcook at prosentient.com.au> wrote:
>> Hi all,
>>
>>
>>
>> For a while, I’ve been thinking that it might be good to have an open source “Koha Command and Control” for managing Koha instances.
>>
>>
>>
>> While managing 1 Koha is not too much work, it’s considerably more difficult to manage 10, 100, or 1000 Koha instances, especially across different servers, geographic locations, timezones, etc.
>>
>>
>>
>> I am sure that most vendors have mechanisms in place for checking the system preference values for all their instances (I have scripts for this sort of thing), what about tracking Zebra queries that contain syntax errors (bug 27139)?
>>
>>
>>
>> I know that we have HEA for sharing a lot of data, but there is some data (like search queries) that I don’t think most libraries would want to share with the community. But Koha administrators, especially vendors with a large number of Koha instances, want to know when problems arise.
>>
>>
>>
>> I suppose that a person could just implement log file scanning for Zebra, but I was thinking about something more structured, which could be analyzed to provide data quality control. My thought is that we’d configure Koha to push events to the “Koha Command and Control” (which would be configured by the Koha system administrator – not librarian level). If Zebra logs a ‘ZOOM error 10014 "CCL parsing error"’, we probably want to tell the Koha user that we found no search results (nice user experience), but we want to flag with a Koha administrator that there is a problem. If Koha administrators (e.g. Koha vendors) start receiving a lot of these errors via the Koha CnC (Command and Control), they’re better placed to raise Bugzilla reports/write patches.
>>
>>
>>
>> Anyway, it’s just an idea. Probably too ambitious. But I think that it would be wise for us to start thinking more about the *data* generated by Koha and how we can use that data to improve Koha. I don’t think we need machine learning algorithms to do the data analysis (yet), but I think having automated data collection, organisation, and reporting would be useful.
>>
>>
>>
>> I have to run but I’ll keep thinking about it. I know I have more grand ideas than I have time, but I could put some thought into what a system might look like, and maybe throw something together locally first before suggesting anyone else get on board…
>>
>>
>>
>> David Cook
>>
>> Software Engineer
>>
>> Prosentient Systems
>>
>> Suite 7.03
>>
>> 6a Glen St
>>
>> Milsons Point NSW 2061
>>
>> Australia
>>
>>
>>
>> Office: 02 9212 0899
>>
>> Online: 02 8005 0595
>>
>>
>>
>> _______________________________________________
>> Koha-devel mailing list
>> Koha-devel at lists.koha-community.org
>> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>> website : http://www.koha-community.org/
>> git : http://git.koha-community.org/
>> bugs : http://bugs.koha-community.org/
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/


From fridolin.somers at biblibre.com  Wed Dec 16 16:25:07 2020
From: fridolin.somers at biblibre.com (Fridolin SOMERS)
Date: Wed, 16 Dec 2020 16:25:07 +0100
Subject: [Koha-devel] Strange characters
Message-ID: <39e35114-3335-491a-1e19-fee4e396918d@biblibre.com>

Hi,

I found some strange characters in sources :

https://git.koha-community.org/Koha-community/Koha/src/branch/master/tools/koha-news.pl#L7

It se a <?> :
Casta�eda, Carlos Sebastian

Do you see that ?

Is this non-UTF8 ?
Can we build a command to find them all ?
I've tried with 'grep -P' but impossible.

Best regards,

-- 
Fridolin SOMERS <fridolin.somers at biblibre.com>
Software and system maintainer 🦄
BibLibre, France

From didier.gautheron at biblibre.com  Wed Dec 16 17:02:54 2020
From: didier.gautheron at biblibre.com (Didier Gautheron)
Date: Wed, 16 Dec 2020 16:02:54 +0000
Subject: [Koha-devel] Strange characters
In-Reply-To: <39e35114-3335-491a-1e19-fee4e396918d@biblibre.com>
References: <39e35114-3335-491a-1e19-fee4e396918d@biblibre.com>
Message-ID: <b76fcf4cf551639bfa92e1612ca6a31d@biblibre.com>

Hi,

16 décembre 2020 16:23 "Fridolin SOMERS" <fridolin.somers at biblibre.com> a écrit:

> Hi,
> 
> I found some strange characters in sources :
> 
> https://git.koha-community.org/Koha-community/Koha/src/branch/master/tools/koha-news.pl#L7
> 
> It se a <?> :
> Casta?eda, Carlos Sebastian
> 
> Do you see that ?

It seems to be a valid UTF8:
ef bf bd
Character name REPLACEMENT CHARACTER
Likely from an old window file: ñ being the culprit.

> Is this non-UTF8 ?
> Can we build a command to find them all ?
> I've tried with 'grep -P' but impossible.
git grep �
find them, with false positive, or using iconv?
iconv -f utf8 -t utf8
should complain if there's invalid sequences
eg:
LANG=C iconv -f utf8 -t utf8 ./misc/cronjobs/automatic_renewals.pl > /dev/null
iconv: illegal input sequence at position 81

From dcook at prosentient.com.au  Wed Dec 16 23:23:07 2020
From: dcook at prosentient.com.au (dcook at prosentient.com.au)
Date: Thu, 17 Dec 2020 09:23:07 +1100
Subject: [Koha-devel] Why does #wrap have padding?
In-Reply-To: <CAO4qe2P7dmN0C7QS5vFafXTgSs2Zv3u-im5BMoDP=qMqRM8woA@mail.gmail.com>
References: <05c801d6d34d$efe71650$cfb542f0$@prosentient.com.au>
 <CAO4qe2P7dmN0C7QS5vFafXTgSs2Zv3u-im5BMoDP=qMqRM8woA@mail.gmail.com>
Message-ID: <066901d6d3fa$078304c0$16890e40$@prosentient.com.au>

Hi Owen,

But why was the OPAC designed to have 40 pixels of padding on either side of the main content? Why not just be full width? I notice when I'm on my phone that it doesn't have the padding, which leads to inconsistent presentation between desktop and mobile (without any customization). 

I should've phrased that better. What I meant was that some of the changes in the media queries seem inconsistent. It shouldn’t be necessary to change the padding and margins for a header/banner in 10 different media queries when we're using auto width already. It seems unnecessarily complicated for a simple thing. 

I notice Athens Country Public Library doesn't have any custom header or footer, so I can see how the padding looks OK. And I know it is tough to get everything right for all mobiles. On my phone, the ACPL search page actually crops the MyACPL logo and the custom search links run off the side of the page. 

If the answer is "it has 40 pixels just because", that's fine. I was just curious. I think I just miss the version of Koha where it was easier to add custom headers, but I'll figure something out. 

David Cook
Software Engineer
Prosentient Systems
Suite 7.03
6a Glen St
Milsons Point NSW 2061
Australia

Office: 02 9212 0899
Online: 02 8005 0595

-----Original Message-----
From: Owen Leonard <oleonard at myacpl.org> 
Sent: Wednesday, 16 December 2020 11:22 PM
To: David Cook <dcook at prosentient.com.au>
Cc: Koha Devel <koha-devel at lists.koha-community.org>
Subject: Re: Why does #wrap have padding?

> Does anyone know why #wrap in koha-tmpl/opac-tmpl/bootstrap/css/src/_common.scss has padding-left: 40px and padding-right: 40px?

Because the OPAC was designed to have 40 pixels of padding on either side of the main content.

> It makes adding full-width headers/footers impossible without tricks and compensations for changes to the padding with the responsive media queries.

All CSS customizations require tricks and compensations to override!

  -- Owen

--
Web Developer
Athens County Public Libraries
(740) 737-6006
https://www.myacpl.org



From dcook at prosentient.com.au  Wed Dec 16 23:31:34 2020
From: dcook at prosentient.com.au (dcook at prosentient.com.au)
Date: Thu, 17 Dec 2020 09:31:34 +1100
Subject: [Koha-devel] Koha Command and Control
In-Reply-To: <daca1ab8-aa6b-4993-c333-7ef3511b7da1@biblibre.com>
References: <059e01d6d336$a9c47e90$fd4d7bb0$@prosentient.com.au>
 <CABW43UThDM_YTiOaBOkzkpNfcK2KZk-OqDjKNM7btChG=bZcWA@mail.gmail.com>
 <daca1ab8-aa6b-4993-c333-7ef3511b7da1@biblibre.com>
Message-ID: <066a01d6d3fb$359445d0$a0bcd170$@prosentient.com.au>

Hi Arthur,

Thanks for your email. 

I use Ansible quite a bit already, so I see where you're coming from, but I was thinking of something more elegant. I was also thinking about something that would allow for more private data collection than Hea. 

Although when I put it that way... it could be interesting to update C4::UsageStats::ReportToCommunity() to actually take a list of URLs, and people could run up their own private Hea (https://gitlab.com/koha-community/hea-app). 

David Cook
Software Engineer
Prosentient Systems
Suite 7.03
6a Glen St
Milsons Point NSW 2061
Australia

Office: 02 9212 0899
Online: 02 8005 0595

-----Original Message-----
From: Koha-devel <koha-devel-bounces at lists.koha-community.org> On Behalf Of Arthur
Sent: Thursday, 17 December 2020 2:15 AM
To: koha-devel at lists.koha-community.org
Subject: Re: [Koha-devel] Koha Command and Control

Hi there,

for this kind of purpose I would recommend using Ansible scripts to ship commands to several Koha's at once.

Using Ansible only needs an ssh connexion to each of your Koha servers, no specific software or agent to install on the targets, then commands are simple well-known bash.

It is also possible to group targets (manually) based on OS, web-server software or other tweaks to deploy specific sets of commands to each of your groups, this is very handy.

I personally don't use it because our environment is very heterogeneous, making grouping difficult and prone to error (and then we would have a lot of groups of a single instance...)

Best,

Arthur Suzuki

BibLibre Koha Support

On 16/12/2020 16:01, Cab Vinton wrote:
> This popped into my email ... Above my pay grade, but maybe of relevance?
>
> https://newrelic.com/
>
> All best,
>
> Cab Vinton, Director
> Plaistow Public Library
>
> On Tue, Dec 15, 2020 at 6:04 PM <dcook at prosentient.com.au> wrote:
>> Hi all,
>>
>>
>>
>> For a while, I’ve been thinking that it might be good to have an open source “Koha Command and Control” for managing Koha instances.
>>
>>
>>
>> While managing 1 Koha is not too much work, it’s considerably more difficult to manage 10, 100, or 1000 Koha instances, especially across different servers, geographic locations, timezones, etc.
>>
>>
>>
>> I am sure that most vendors have mechanisms in place for checking the system preference values for all their instances (I have scripts for this sort of thing), what about tracking Zebra queries that contain syntax errors (bug 27139)?
>>
>>
>>
>> I know that we have HEA for sharing a lot of data, but there is some data (like search queries) that I don’t think most libraries would want to share with the community. But Koha administrators, especially vendors with a large number of Koha instances, want to know when problems arise.
>>
>>
>>
>> I suppose that a person could just implement log file scanning for Zebra, but I was thinking about something more structured, which could be analyzed to provide data quality control. My thought is that we’d configure Koha to push events to the “Koha Command and Control” (which would be configured by the Koha system administrator – not librarian level). If Zebra logs a ‘ZOOM error 10014 "CCL parsing error"’, we probably want to tell the Koha user that we found no search results (nice user experience), but we want to flag with a Koha administrator that there is a problem. If Koha administrators (e.g. Koha vendors) start receiving a lot of these errors via the Koha CnC (Command and Control), they’re better placed to raise Bugzilla reports/write patches.
>>
>>
>>
>> Anyway, it’s just an idea. Probably too ambitious. But I think that it would be wise for us to start thinking more about the *data* generated by Koha and how we can use that data to improve Koha. I don’t think we need machine learning algorithms to do the data analysis (yet), but I think having automated data collection, organisation, and reporting would be useful.
>>
>>
>>
>> I have to run but I’ll keep thinking about it. I know I have more 
>> grand ideas than I have time, but I could put some thought into what 
>> a system might look like, and maybe throw something together locally 
>> first before suggesting anyone else get on board…
>>
>>
>>
>> David Cook
>>
>> Software Engineer
>>
>> Prosentient Systems
>>
>> Suite 7.03
>>
>> 6a Glen St
>>
>> Milsons Point NSW 2061
>>
>> Australia
>>
>>
>>
>> Office: 02 9212 0899
>>
>> Online: 02 8005 0595
>>
>>
>>
>> _______________________________________________
>> Koha-devel mailing list
>> Koha-devel at lists.koha-community.org
>> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>> website : http://www.koha-community.org/ git : 
>> http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/ git : 
> http://git.koha-community.org/ bugs : http://bugs.koha-community.org/

_______________________________________________
Koha-devel mailing list
Koha-devel at lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/



From dcook at prosentient.com.au  Thu Dec 17 00:16:02 2020
From: dcook at prosentient.com.au (dcook at prosentient.com.au)
Date: Thu, 17 Dec 2020 10:16:02 +1100
Subject: [Koha-devel] Koha Command and Control
In-Reply-To: <CABW43UThDM_YTiOaBOkzkpNfcK2KZk-OqDjKNM7btChG=bZcWA@mail.gmail.com>
References: <059e01d6d336$a9c47e90$fd4d7bb0$@prosentient.com.au>
 <CABW43UThDM_YTiOaBOkzkpNfcK2KZk-OqDjKNM7btChG=bZcWA@mail.gmail.com>
Message-ID: <067101d6d401$6c5abcb0$45103610$@prosentient.com.au>

Hi Cab,

I was thinking a bit about how there is no point re-inventing the wheel. I've never heard of New Relic, but that reminds me about Prometheus (https://en.wikipedia.org/wiki/Prometheus_(software)).

I could write a Koha plugin to create an "exporter" for Prometheus.  Or even use something like https://github.com/fstab/grok_exporter to read Zebra logs. I think that would handle the data collection aspect in a more standardized way than I was originally thinking. 

I know many people would say that monitoring isn't part of the application, but a lot of applications these days have Prometheus exporters out of the box.

Hmm food for thought. 

As for the command aspect, an Admin API is the way to go with that. And if something can't be handled by the API, perhaps we should re-think how it's done. (Containers help with this. For instance, instead of updating a configuration file and restarting Apache, you would actually commit a change, use a deployment pipeline, and the container(s) would ultimately be replaced via automation.)  

Anyway, thanks for indulging me heh.

David Cook
Software Engineer
Prosentient Systems
Suite 7.03
6a Glen St
Milsons Point NSW 2061
Australia

Office: 02 9212 0899
Online: 02 8005 0595

-----Original Message-----
From: Koha-devel <koha-devel-bounces at lists.koha-community.org> On Behalf Of Cab Vinton
Sent: Thursday, 17 December 2020 2:02 AM
To: Koha Devel <koha-devel at lists.koha-community.org>
Subject: Re: [Koha-devel] Koha Command and Control

This popped into my email ... Above my pay grade, but maybe of relevance?

https://newrelic.com/

All best,

Cab Vinton, Director
Plaistow Public Library

On Tue, Dec 15, 2020 at 6:04 PM <dcook at prosentient.com.au> wrote:
>
> Hi all,
>
>
>
> For a while, I’ve been thinking that it might be good to have an open source “Koha Command and Control” for managing Koha instances.
>
>
>
> While managing 1 Koha is not too much work, it’s considerably more difficult to manage 10, 100, or 1000 Koha instances, especially across different servers, geographic locations, timezones, etc.
>
>
>
> I am sure that most vendors have mechanisms in place for checking the system preference values for all their instances (I have scripts for this sort of thing), what about tracking Zebra queries that contain syntax errors (bug 27139)?
>
>
>
> I know that we have HEA for sharing a lot of data, but there is some data (like search queries) that I don’t think most libraries would want to share with the community. But Koha administrators, especially vendors with a large number of Koha instances, want to know when problems arise.
>
>
>
> I suppose that a person could just implement log file scanning for Zebra, but I was thinking about something more structured, which could be analyzed to provide data quality control. My thought is that we’d configure Koha to push events to the “Koha Command and Control” (which would be configured by the Koha system administrator – not librarian level). If Zebra logs a ‘ZOOM error 10014 "CCL parsing error"’, we probably want to tell the Koha user that we found no search results (nice user experience), but we want to flag with a Koha administrator that there is a problem. If Koha administrators (e.g. Koha vendors) start receiving a lot of these errors via the Koha CnC (Command and Control), they’re better placed to raise Bugzilla reports/write patches.
>
>
>
> Anyway, it’s just an idea. Probably too ambitious. But I think that it would be wise for us to start thinking more about the *data* generated by Koha and how we can use that data to improve Koha. I don’t think we need machine learning algorithms to do the data analysis (yet), but I think having automated data collection, organisation, and reporting would be useful.
>
>
>
> I have to run but I’ll keep thinking about it. I know I have more 
> grand ideas than I have time, but I could put some thought into what a 
> system might look like, and maybe throw something together locally 
> first before suggesting anyone else get on board…
>
>
>
> David Cook
>
> Software Engineer
>
> Prosentient Systems
>
> Suite 7.03
>
> 6a Glen St
>
> Milsons Point NSW 2061
>
> Australia
>
>
>
> Office: 02 9212 0899
>
> Online: 02 8005 0595
>
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/ git : 
> http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
_______________________________________________
Koha-devel mailing list
Koha-devel at lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/



From dcook at prosentient.com.au  Thu Dec 17 00:43:50 2020
From: dcook at prosentient.com.au (dcook at prosentient.com.au)
Date: Thu, 17 Dec 2020 10:43:50 +1100
Subject: [Koha-devel] Load balancing Zebra
Message-ID: <067201d6d405$4e542270$eafc6750$@prosentient.com.au>

Hi Mengu,

 

Do you use the YAZ Proxy
(https://www.indexdata.com/resources/software/yazproxy/) at all for load
balancing Zebra?

 

How do you distribute updates to your different Zebra servers? I have a
vague memory that you index one of them and then copy the Zebra database
over periodically?

 

David Cook

Software Engineer

Prosentient Systems

Suite 7.03

6a Glen St

Milsons Point NSW 2061

Australia

 

Office: 02 9212 0899

Online: 02 8005 0595

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20201217/531f9f98/attachment.htm>

From dcook at prosentient.com.au  Thu Dec 17 03:30:33 2020
From: dcook at prosentient.com.au (dcook at prosentient.com.au)
Date: Thu, 17 Dec 2020 13:30:33 +1100
Subject: [Koha-devel] Strange characters
In-Reply-To: <b76fcf4cf551639bfa92e1612ca6a31d@biblibre.com>
References: <39e35114-3335-491a-1e19-fee4e396918d@biblibre.com>
 <b76fcf4cf551639bfa92e1612ca6a31d@biblibre.com>
Message-ID: <06c901d6d41c$99409e50$cbc1daf0$@prosentient.com.au>

So EF BF BD is the box with a question mark �. 

If you look at commit 100e6a9808ead4ee8d951da59ead1550e75bb4c3, you'll see the following:

-# Casta361eda, Carlos Sebastian - seba3c at yahoo.com.ar - Physics Library UNLP Argentina
+# Casta�eda, Carlos Sebastian - seba3c at yahoo.com.ar - Physics Library UNLP Argentina

361 is the octal for ñ. 

I wrote this Perl oneliner to find these:

find . -not -path '*/\.git/*' -type f -exec perl -lne 'print $ARGV if /\xef\xbf\xbd/' {} \; | sort -u

I found the following in 19.11:

./koha-tmpl/intranet-tmpl/lib/datatables/datatables.js
	Seemingly intentional...
./koha-tmpl/intranet-tmpl/lib/datatables/datatables.min.js
	Seemingly intentional
./koha-tmpl/intranet-tmpl/lib/yui/plugins/loading-min.js
	Looks like a typo in a name like koha-news.pl
./misc/migration_tools/buildEDITORS.pl
	Lots in a commented out section which should probably just be deleted...
./misc/release_notes/release_notes_19_11_02.html
	Input error in an organisation name?
./misc/release_notes/release_notes_19_11_02.md
	Input error in an organisation name?
./t/db_dependent/data/marc21/zebraexport/biblio/exported_records
	In record data?
./tools/koha-news.pl
	You already know this one

Using vim, you can just search for �. 

David Cook
Software Engineer
Prosentient Systems
Suite 7.03
6a Glen St
Milsons Point NSW 2061
Australia

Office: 02 9212 0899
Online: 02 8005 0595

-----Original Message-----
From: Koha-devel <koha-devel-bounces at lists.koha-community.org> On Behalf Of Didier Gautheron
Sent: Thursday, 17 December 2020 3:03 AM
To: koha-devel <koha-devel at lists.koha-community.org>
Subject: Re: [Koha-devel] Strange characters

Hi,

16 décembre 2020 16:23 "Fridolin SOMERS" <fridolin.somers at biblibre.com> a écrit:

> Hi,
> 
> I found some strange characters in sources :
> 
> https://git.koha-community.org/Koha-community/Koha/src/branch/master/t
> ools/koha-news.pl#L7
> 
> It se a <?> :
> Casta?eda, Carlos Sebastian
> 
> Do you see that ?

It seems to be a valid UTF8:
ef bf bd
Character name REPLACEMENT CHARACTER
Likely from an old window file: ñ being the culprit.

> Is this non-UTF8 ?
> Can we build a command to find them all ?
> I've tried with 'grep -P' but impossible.
git grep  
find them, with false positive, or using iconv?
iconv -f utf8 -t utf8
should complain if there's invalid sequences
eg:
LANG=C iconv -f utf8 -t utf8 ./misc/cronjobs/automatic_renewals.pl > /dev/null
iconv: illegal input sequence at position 81 _______________________________________________
Koha-devel mailing list
Koha-devel at lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/



From dcook at prosentient.com.au  Thu Dec 17 03:31:05 2020
From: dcook at prosentient.com.au (dcook at prosentient.com.au)
Date: Thu, 17 Dec 2020 13:31:05 +1100
Subject: [Koha-devel] LinkBibHeadingsToAuthorities not working as
 expected
In-Reply-To: <72cee5d3-968a-663b-86a2-8914653b7642@biblibre.com>
References: <032b01d6cf76$968fb7e0$c3af27a0$@prosentient.com.au>
 <033501d6cf79$0a30c890$1e9259b0$@prosentient.com.au>
 <034401d6cf7d$95a3a600$c0eaf200$@prosentient.com.au>
 <035001d6cf7e$cf724610$6e56d230$@prosentient.com.au>
 <035a01d6cf82$6c09fba0$441df2e0$@prosentient.com.au>
 <72cee5d3-968a-663b-86a2-8914653b7642@biblibre.com>
Message-ID: <06ca01d6d41c$ab84d3b0$028e7b10$@prosentient.com.au>

Thanks, Fridolin!

I've reported it to Indexdata but they say they can't reproduce the problem...

David Cook
Software Engineer
Prosentient Systems
Suite 7.03
6a Glen St
Milsons Point NSW 2061
Australia

Office: 02 9212 0899
Online: 02 8005 0595

-----Original Message-----
From: Koha-devel <koha-devel-bounces at lists.koha-community.org> On Behalf Of Fridolin SOMERS
Sent: Wednesday, 16 December 2020 7:54 PM
To: koha-devel at lists.koha-community.org
Subject: Re: [Koha-devel] LinkBibHeadingsToAuthorities not working as expected

Thanks a lot for your tests.

I will try on our Bionic env with Zebra 2.2.1

Le 11/12/2020 à 06:56, dcook at prosentient.com.au a écrit :
> This one is driving me a bit crazy, so I’ve logged an issue with 
> Indexdata and I’m hoping for the best:
> https://github.com/indexdata/idzebra/issues/24
> <https://github.com/indexdata/idzebra/issues/24>.
> 
> David Cook
> 
> Software Engineer
> 
> Prosentient Systems
> 
> Suite 7.03
> 
> 6a Glen St
> 
> Milsons Point NSW 2061
> 
> Australia
> 
> Office: 02 9212 0899
> 
> Online: 02 8005 0595
> 
> *From:*Koha-devel <koha-devel-bounces at lists.koha-community.org> *On 
> Behalf Of *dcook at prosentient.com.au
> *Sent:* Friday, 11 December 2020 4:31 PM
> *To:* 'Koha Devel' <koha-devel at lists.koha-community.org>
> *Subject:* Re: [Koha-devel] LinkBibHeadingsToAuthorities not working 
> as expected
> 
> Using koha-testing-docker set up for ICU and with my fix from
> https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27198
> <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27198>:
> 
> querytype ccl2rpn
> 
> set_cclfile /etc/koha/zebradb/ccl.properties
> 
> format xml
> 
> elements zebra::snippet
> 
> Z> f Match-heading,phr,ext,do-not-truncate="the Q"
> 
> Sent searchRequest.
> 
> Received SearchResponse.
> 
> Search was a success.
> 
> Number of hits: 34, setno 24
> 
> SearchResult-1: term=the cnt=34
> 
> records returned: 0
> 
> Elapsed: 0.000315
> 
> Z> show
> 
> Sent presentRequest (1+1).
> 
> Records: 1
> 
> Record type: XML
> 
> <record xmlns="http://www.indexdata.com/zebra/
> <http://www.indexdata.com/zebra/>">
> 
>    <snippet name="Match-heading" type="p" 
> fields="Match">Xenophon<s>the</s>Historian</snippet>
> 
> </record>nextResultSetPosition = 2
> 
> Elapsed: 0.003864
> 
> So that’s special… admittedly that’s Zebra 2.0.59…
> 
> On Zebra 2.1.4 with ICU:
> 
> Z> f Match-heading,phr,ext,do-not-truncate="the Q"
> 
> Sent searchRequest.
> 
> Received SearchResponse.
> 
> Search was a success.
> 
> Number of hits: 0, setno 2
> 
> SearchResult-1: term=the  cnt=5383, term=Q cnt=10
> 
> records returned: 0
> 
> Elapsed: 0.009691
> 
> Z> f Match-heading,phr,ext,do-not-truncate="the"
> 
> Sent searchRequest.
> 
> Received SearchResponse.
> 
> Search was a success.
> 
> Number of hits: 85, setno 3
> 
> SearchResult-1: term=the cnt=85
> 
> records returned: 0
> 
> Elapsed: 0.002209
> 
> However, 85 results is still too many. It should be 0 results.
> 
> I can’t add the diagnostics from
> https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27198
> <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27198> 
> right now though… so will have to get back to this one another day probably.
> 
> But maybe someone else using Zebra with ICU can look into this problem too.
> 
> It’s leading to lots of duplicate authorities it seems…
> 
> David Cook
> 
> Software Engineer
> 
> Prosentient Systems
> 
> Suite 7.03
> 
> 6a Glen St
> 
> Milsons Point NSW 2061
> 
> Australia
> 
> Office: 02 9212 0899
> 
> Online: 02 8005 0595
> 
> *From:*Koha-devel <koha-devel-bounces at lists.koha-community.org
> <mailto:koha-devel-bounces at lists.koha-community.org>> *On Behalf Of 
> *dcook at prosentient.com.au <mailto:dcook at prosentient.com.au>
> *Sent:* Friday, 11 December 2020 4:22 PM
> *To:* 'Koha Devel' <koha-devel at lists.koha-community.org
> <mailto:koha-devel at lists.koha-community.org>>
> *Subject:* Re: [Koha-devel] LinkBibHeadingsToAuthorities not working 
> as expected
> 
> Ugh yeah no… I’m reproducing it with koha-testing-docker too.
> 
> Looks like yet another ICU bug…
> 
> David Cook
> 
> Software Engineer
> 
> Prosentient Systems
> 
> Suite 7.03
> 
> 6a Glen St
> 
> Milsons Point NSW 2061
> 
> Australia
> 
> Office: 02 9212 0899
> 
> Online: 02 8005 0595
> 
> *From:*Koha-devel <koha-devel-bounces at lists.koha-community.org
> <mailto:koha-devel-bounces at lists.koha-community.org>> *On Behalf Of 
> *dcook at prosentient.com.au <mailto:dcook at prosentient.com.au>
> *Sent:* Friday, 11 December 2020 3:50 PM
> *To:* 'Koha Devel' <koha-devel at lists.koha-community.org
> <mailto:koha-devel at lists.koha-community.org>>
> *Subject:* Re: [Koha-devel] LinkBibHeadingsToAuthorities not working 
> as expected
> 
> Then again… I can’t reproduce this problem on koha-testing-docker, but 
> I can on a prod Koha running Zebra 2.1.4 with… a very strange 
> /etc/koha/zebradb/etc/default.idx file…
> 
> David Cook
> 
> Software Engineer
> 
> Prosentient Systems
> 
> Suite 7.03
> 
> 6a Glen St
> 
> Milsons Point NSW 2061
> 
> Australia
> 
> Office: 02 9212 0899
> 
> Online: 02 8005 0595
> 
> *From:*Koha-devel <koha-devel-bounces at lists.koha-community.org
> <mailto:koha-devel-bounces at lists.koha-community.org>> *On Behalf Of 
> *dcook at prosentient.com.au <mailto:dcook at prosentient.com.au>
> *Sent:* Friday, 11 December 2020 3:32 PM
> *To:* 'Koha Devel' <koha-devel at lists.koha-community.org
> <mailto:koha-devel at lists.koha-community.org>>
> *Subject:* [Koha-devel] LinkBibHeadingsToAuthorities not working as 
> expected
> 
> Hi all,
> 
> I’m still investigating, but it seems to me that the 
> C4::Linker::Default in C4::Biblio::LinkBibHeadingsToAuthorities isn’t 
> searching accurately using C4::Heading::authorities.
> 
> I’m looking at C4::AuthoritiesMarc::SearchAuthorities and at a glance 
> it looks OK, but in practice I think that my search queries are 
> getting way too many results.
> 
> By hand, if I try the following query:
> 
> Match-heading,phr,ext,do-not-truncate="e"
> 
> I get a huge number of results, which is odd, since that should be an 
> “exact” match.
> 
> I’ve opened
> https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27198
> <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27198>
> because I need to improve the diagnostics available for a Zebra 
> authorities database, but yeah… not good. Hopefully I’ll know more soon.
> 
> David Cook
> 
> Software Engineer
> 
> Prosentient Systems
> 
> Suite 7.03
> 
> 6a Glen St
> 
> Milsons Point NSW 2061
> 
> Australia
> 
> Office: 02 9212 0899
> 
> Online: 02 8005 0595
> 
> 
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/ git : 
> http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
> 

-- 
Fridolin SOMERS <fridolin.somers at biblibre.com>
Software and system maintainer 🦄
BibLibre, France
_______________________________________________
Koha-devel mailing list
Koha-devel at lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/



From fridolin.somers at biblibre.com  Thu Dec 17 09:50:15 2020
From: fridolin.somers at biblibre.com (Fridolin SOMERS)
Date: Thu, 17 Dec 2020 09:50:15 +0100
Subject: [Koha-devel] Koha Command and Control
In-Reply-To: <066a01d6d3fb$359445d0$a0bcd170$@prosentient.com.au>
References: <059e01d6d336$a9c47e90$fd4d7bb0$@prosentient.com.au>
 <CABW43UThDM_YTiOaBOkzkpNfcK2KZk-OqDjKNM7btChG=bZcWA@mail.gmail.com>
 <daca1ab8-aa6b-4993-c333-7ef3511b7da1@biblibre.com>
 <066a01d6d3fb$359445d0$a0bcd170$@prosentient.com.au>
Message-ID: <2bb75661-40d4-a09c-5365-c389cdc70f6d@biblibre.com>

Hi,

Indeed good idea.

Maybe we could add a Koha plugin hook to add datas to this HEA.
So poeple can add specific datas that may be private for the general HEA.

"One HEA to rule them all" ^^

Le 16/12/2020 à 23:31, dcook at prosentient.com.au a écrit :
> Hi Arthur,
> 
> Thanks for your email.
> 
> I use Ansible quite a bit already, so I see where you're coming from, but I was thinking of something more elegant. I was also thinking about something that would allow for more private data collection than Hea.
> 
> Although when I put it that way... it could be interesting to update C4::UsageStats::ReportToCommunity() to actually take a list of URLs, and people could run up their own private Hea (https://gitlab.com/koha-community/hea-app).
> 
> David Cook
> Software Engineer
> Prosentient Systems
> Suite 7.03
> 6a Glen St
> Milsons Point NSW 2061
> Australia
> 
> Office: 02 9212 0899
> Online: 02 8005 0595
> 
> -----Original Message-----
> From: Koha-devel <koha-devel-bounces at lists.koha-community.org> On Behalf Of Arthur
> Sent: Thursday, 17 December 2020 2:15 AM
> To: koha-devel at lists.koha-community.org
> Subject: Re: [Koha-devel] Koha Command and Control
> 
> Hi there,
> 
> for this kind of purpose I would recommend using Ansible scripts to ship commands to several Koha's at once.
> 
> Using Ansible only needs an ssh connexion to each of your Koha servers, no specific software or agent to install on the targets, then commands are simple well-known bash.
> 
> It is also possible to group targets (manually) based on OS, web-server software or other tweaks to deploy specific sets of commands to each of your groups, this is very handy.
> 
> I personally don't use it because our environment is very heterogeneous, making grouping difficult and prone to error (and then we would have a lot of groups of a single instance...)
> 
> Best,
> 
> Arthur Suzuki
> 
> BibLibre Koha Support
> 
> On 16/12/2020 16:01, Cab Vinton wrote:
>> This popped into my email ... Above my pay grade, but maybe of relevance?
>>
>> https://newrelic.com/
>>
>> All best,
>>
>> Cab Vinton, Director
>> Plaistow Public Library
>>
>> On Tue, Dec 15, 2020 at 6:04 PM <dcook at prosentient.com.au> wrote:
>>> Hi all,
>>>
>>>
>>>
>>> For a while, I’ve been thinking that it might be good to have an open source “Koha Command and Control” for managing Koha instances.
>>>
>>>
>>>
>>> While managing 1 Koha is not too much work, it’s considerably more difficult to manage 10, 100, or 1000 Koha instances, especially across different servers, geographic locations, timezones, etc.
>>>
>>>
>>>
>>> I am sure that most vendors have mechanisms in place for checking the system preference values for all their instances (I have scripts for this sort of thing), what about tracking Zebra queries that contain syntax errors (bug 27139)?
>>>
>>>
>>>
>>> I know that we have HEA for sharing a lot of data, but there is some data (like search queries) that I don’t think most libraries would want to share with the community. But Koha administrators, especially vendors with a large number of Koha instances, want to know when problems arise.
>>>
>>>
>>>
>>> I suppose that a person could just implement log file scanning for Zebra, but I was thinking about something more structured, which could be analyzed to provide data quality control. My thought is that we’d configure Koha to push events to the “Koha Command and Control” (which would be configured by the Koha system administrator – not librarian level). If Zebra logs a ‘ZOOM error 10014 "CCL parsing error"’, we probably want to tell the Koha user that we found no search results (nice user experience), but we want to flag with a Koha administrator that there is a problem. If Koha administrators (e.g. Koha vendors) start receiving a lot of these errors via the Koha CnC (Command and Control), they’re better placed to raise Bugzilla reports/write patches.
>>>
>>>
>>>
>>> Anyway, it’s just an idea. Probably too ambitious. But I think that it would be wise for us to start thinking more about the *data* generated by Koha and how we can use that data to improve Koha. I don’t think we need machine learning algorithms to do the data analysis (yet), but I think having automated data collection, organisation, and reporting would be useful.
>>>
>>>
>>>
>>> I have to run but I’ll keep thinking about it. I know I have more
>>> grand ideas than I have time, but I could put some thought into what
>>> a system might look like, and maybe throw something together locally
>>> first before suggesting anyone else get on board…
>>>
>>>
>>>
>>> David Cook
>>>
>>> Software Engineer
>>>
>>> Prosentient Systems
>>>
>>> Suite 7.03
>>>
>>> 6a Glen St
>>>
>>> Milsons Point NSW 2061
>>>
>>> Australia
>>>
>>>
>>>
>>> Office: 02 9212 0899
>>>
>>> Online: 02 8005 0595
>>>
>>>
>>>
>>> _______________________________________________
>>> Koha-devel mailing list
>>> Koha-devel at lists.koha-community.org
>>> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>>> website : http://www.koha-community.org/ git :
>>> http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
>> _______________________________________________
>> Koha-devel mailing list
>> Koha-devel at lists.koha-community.org
>> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>> website : http://www.koha-community.org/ git :
>> http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
> 
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
> 
> 
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
> 

-- 
Fridolin SOMERS <fridolin.somers at biblibre.com>
Software and system maintainer 🦄
BibLibre, France

From fridolin.somers at biblibre.com  Thu Dec 17 10:04:19 2020
From: fridolin.somers at biblibre.com (Fridolin SOMERS)
Date: Thu, 17 Dec 2020 10:04:19 +0100
Subject: [Koha-devel] Why does #wrap have padding?
In-Reply-To: <066901d6d3fa$078304c0$16890e40$@prosentient.com.au>
References: <05c801d6d34d$efe71650$cfb542f0$@prosentient.com.au>
 <CAO4qe2P7dmN0C7QS5vFafXTgSs2Zv3u-im5BMoDP=qMqRM8woA@mail.gmail.com>
 <066901d6d3fa$078304c0$16890e40$@prosentient.com.au>
Message-ID: <cab9eb86-003e-7578-0fcf-91a45c15023b@biblibre.com>

Hi,

In current master I think #wrap is renamed in #wrapper no ?

Since Bug 20168 (bootstrap 4.5).

If yes I think we can remove #wrap from SCSS config right ?

Best regards

Le 16/12/2020 à 23:23, dcook at prosentient.com.au a écrit :
> Hi Owen,
> 
> But why was the OPAC designed to have 40 pixels of padding on either side of the main content? Why not just be full width? I notice when I'm on my phone that it doesn't have the padding, which leads to inconsistent presentation between desktop and mobile (without any customization).
> 
> I should've phrased that better. What I meant was that some of the changes in the media queries seem inconsistent. It shouldn’t be necessary to change the padding and margins for a header/banner in 10 different media queries when we're using auto width already. It seems unnecessarily complicated for a simple thing.
> 
> I notice Athens Country Public Library doesn't have any custom header or footer, so I can see how the padding looks OK. And I know it is tough to get everything right for all mobiles. On my phone, the ACPL search page actually crops the MyACPL logo and the custom search links run off the side of the page.
> 
> If the answer is "it has 40 pixels just because", that's fine. I was just curious. I think I just miss the version of Koha where it was easier to add custom headers, but I'll figure something out.
> 
> David Cook
> Software Engineer
> Prosentient Systems
> Suite 7.03
> 6a Glen St
> Milsons Point NSW 2061
> Australia
> 
> Office: 02 9212 0899
> Online: 02 8005 0595
> 
> -----Original Message-----
> From: Owen Leonard <oleonard at myacpl.org>
> Sent: Wednesday, 16 December 2020 11:22 PM
> To: David Cook <dcook at prosentient.com.au>
> Cc: Koha Devel <koha-devel at lists.koha-community.org>
> Subject: Re: Why does #wrap have padding?
> 
>> Does anyone know why #wrap in koha-tmpl/opac-tmpl/bootstrap/css/src/_common.scss has padding-left: 40px and padding-right: 40px?
> 
> Because the OPAC was designed to have 40 pixels of padding on either side of the main content.
> 
>> It makes adding full-width headers/footers impossible without tricks and compensations for changes to the padding with the responsive media queries.
> 
> All CSS customizations require tricks and compensations to override!
> 
>    -- Owen
> 
> --
> Web Developer
> Athens County Public Libraries
> (740) 737-6006
> https://www.myacpl.org
> 
> 
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
> 

-- 
Fridolin SOMERS <fridolin.somers at biblibre.com>
Software and system maintainer 🦄
BibLibre, France

From agustinmoyano at theke.io  Thu Dec 17 15:08:43 2020
From: agustinmoyano at theke.io (Agustin Moyano)
Date: Thu, 17 Dec 2020 11:08:43 -0300
Subject: [Koha-devel] Koha Command and Control
In-Reply-To: <2bb75661-40d4-a09c-5365-c389cdc70f6d@biblibre.com>
References: <059e01d6d336$a9c47e90$fd4d7bb0$@prosentient.com.au>
 <CABW43UThDM_YTiOaBOkzkpNfcK2KZk-OqDjKNM7btChG=bZcWA@mail.gmail.com>
 <daca1ab8-aa6b-4993-c333-7ef3511b7da1@biblibre.com>
 <066a01d6d3fb$359445d0$a0bcd170$@prosentient.com.au>
 <2bb75661-40d4-a09c-5365-c389cdc70f6d@biblibre.com>
Message-ID: <CALdMRuHxn+1mYP3q32m0NVCWHzbcaLc1xzvKyYSSioPX0=OD9A@mail.gmail.com>

Hi everyone, if Koha is aiming to replace zebra with elastic search, I
think it would be best to use ELK Stack for log parsing and sending
notifications.

What do you think?

On Thu, Dec 17, 2020 at 5:48 AM Fridolin SOMERS <
fridolin.somers at biblibre.com> wrote:

> Hi,
>
> Indeed good idea.
>
> Maybe we could add a Koha plugin hook to add datas to this HEA.
> So poeple can add specific datas that may be private for the general HEA.
>
> "One HEA to rule them all" ^^
>
> Le 16/12/2020 à 23:31, dcook at prosentient.com.au a écrit :
> > Hi Arthur,
> >
> > Thanks for your email.
> >
> > I use Ansible quite a bit already, so I see where you're coming from,
> but I was thinking of something more elegant. I was also thinking about
> something that would allow for more private data collection than Hea.
> >
> > Although when I put it that way... it could be interesting to update
> C4::UsageStats::ReportToCommunity() to actually take a list of URLs, and
> people could run up their own private Hea (
> https://gitlab.com/koha-community/hea-app).
> >
> > David Cook
> > Software Engineer
> > Prosentient Systems
> > Suite 7.03
> > 6a Glen St
> > Milsons Point NSW 2061
> > Australia
> >
> > Office: 02 9212 0899
> > Online: 02 8005 0595
> >
> > -----Original Message-----
> > From: Koha-devel <koha-devel-bounces at lists.koha-community.org> On
> Behalf Of Arthur
> > Sent: Thursday, 17 December 2020 2:15 AM
> > To: koha-devel at lists.koha-community.org
> > Subject: Re: [Koha-devel] Koha Command and Control
> >
> > Hi there,
> >
> > for this kind of purpose I would recommend using Ansible scripts to ship
> commands to several Koha's at once.
> >
> > Using Ansible only needs an ssh connexion to each of your Koha servers,
> no specific software or agent to install on the targets, then commands are
> simple well-known bash.
> >
> > It is also possible to group targets (manually) based on OS, web-server
> software or other tweaks to deploy specific sets of commands to each of
> your groups, this is very handy.
> >
> > I personally don't use it because our environment is very heterogeneous,
> making grouping difficult and prone to error (and then we would have a lot
> of groups of a single instance...)
> >
> > Best,
> >
> > Arthur Suzuki
> >
> > BibLibre Koha Support
> >
> > On 16/12/2020 16:01, Cab Vinton wrote:
> >> This popped into my email ... Above my pay grade, but maybe of
> relevance?
> >>
> >> https://newrelic.com/
> >>
> >> All best,
> >>
> >> Cab Vinton, Director
> >> Plaistow Public Library
> >>
> >> On Tue, Dec 15, 2020 at 6:04 PM <dcook at prosentient.com.au> wrote:
> >>> Hi all,
> >>>
> >>>
> >>>
> >>> For a while, I’ve been thinking that it might be good to have an open
> source “Koha Command and Control” for managing Koha instances.
> >>>
> >>>
> >>>
> >>> While managing 1 Koha is not too much work, it’s considerably more
> difficult to manage 10, 100, or 1000 Koha instances, especially across
> different servers, geographic locations, timezones, etc.
> >>>
> >>>
> >>>
> >>> I am sure that most vendors have mechanisms in place for checking the
> system preference values for all their instances (I have scripts for this
> sort of thing), what about tracking Zebra queries that contain syntax
> errors (bug 27139)?
> >>>
> >>>
> >>>
> >>> I know that we have HEA for sharing a lot of data, but there is some
> data (like search queries) that I don’t think most libraries would want to
> share with the community. But Koha administrators, especially vendors with
> a large number of Koha instances, want to know when problems arise.
> >>>
> >>>
> >>>
> >>> I suppose that a person could just implement log file scanning for
> Zebra, but I was thinking about something more structured, which could be
> analyzed to provide data quality control. My thought is that we’d configure
> Koha to push events to the “Koha Command and Control” (which would be
> configured by the Koha system administrator – not librarian level). If
> Zebra logs a ‘ZOOM error 10014 "CCL parsing error"’, we probably want to
> tell the Koha user that we found no search results (nice user experience),
> but we want to flag with a Koha administrator that there is a problem. If
> Koha administrators (e.g. Koha vendors) start receiving a lot of these
> errors via the Koha CnC (Command and Control), they’re better placed to
> raise Bugzilla reports/write patches.
> >>>
> >>>
> >>>
> >>> Anyway, it’s just an idea. Probably too ambitious. But I think that it
> would be wise for us to start thinking more about the *data* generated by
> Koha and how we can use that data to improve Koha. I don’t think we need
> machine learning algorithms to do the data analysis (yet), but I think
> having automated data collection, organisation, and reporting would be
> useful.
> >>>
> >>>
> >>>
> >>> I have to run but I’ll keep thinking about it. I know I have more
> >>> grand ideas than I have time, but I could put some thought into what
> >>> a system might look like, and maybe throw something together locally
> >>> first before suggesting anyone else get on board…
> >>>
> >>>
> >>>
> >>> David Cook
> >>>
> >>> Software Engineer
> >>>
> >>> Prosentient Systems
> >>>
> >>> Suite 7.03
> >>>
> >>> 6a Glen St
> >>>
> >>> Milsons Point NSW 2061
> >>>
> >>> Australia
> >>>
> >>>
> >>>
> >>> Office: 02 9212 0899
> >>>
> >>> Online: 02 8005 0595
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Koha-devel mailing list
> >>> Koha-devel at lists.koha-community.org
> >>> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> >>> website : http://www.koha-community.org/ git :
> >>> http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
> >> _______________________________________________
> >> Koha-devel mailing list
> >> Koha-devel at lists.koha-community.org
> >> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> >> website : http://www.koha-community.org/ git :
> >> http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
> >
> > _______________________________________________
> > Koha-devel mailing list
> > Koha-devel at lists.koha-community.org
> > https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> > website : http://www.koha-community.org/ git :
> http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
> >
> >
> > _______________________________________________
> > Koha-devel mailing list
> > Koha-devel at lists.koha-community.org
> > https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> > website : http://www.koha-community.org/
> > git : http://git.koha-community.org/
> > bugs : http://bugs.koha-community.org/
> >
>
> --
> Fridolin SOMERS <fridolin.somers at biblibre.com>
> Software and system maintainer 🦄
> BibLibre, France
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20201217/896594ef/attachment.htm>

From tomascohen at gmail.com  Thu Dec 17 20:53:14 2020
From: tomascohen at gmail.com (Tomas Cohen Arazi)
Date: Thu, 17 Dec 2020 16:53:14 -0300
Subject: [Koha-devel] Misconfigured lists?
Message-ID: <CABZfb=WNRWFwL=3Om9guoQAXXqXYEm3efwzpBWGZFwYUGgmwhA@mail.gmail.com>

Hi all, is there a reason for the lists to have the 'Reply-to' set to the
original sender? This makes it very easy to inadvertently go private on
answering. The option is to choose to 'Reply to all', but this is really
sub optimal, as people might receive the message several times, and the
lists are configured to reject messages sent to more than X senders (I'm
not sure about X, I think it is set to 3).

I would propose to set the lists reply-to to the list itself.

-- 
Tomás Cohen Arazi
Theke Solutions (http://theke.io)
✆ +54 9351 3513384
GPG: B2F3C15F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20201217/ba416a63/attachment.htm>

From indradg at l2c2.co.in  Thu Dec 17 21:13:35 2020
From: indradg at l2c2.co.in (Indranil Das Gupta)
Date: Fri, 18 Dec 2020 01:43:35 +0530
Subject: [Koha-devel] Misconfigured lists?
In-Reply-To: <CABZfb=WNRWFwL=3Om9guoQAXXqXYEm3efwzpBWGZFwYUGgmwhA@mail.gmail.com>
References: <CABZfb=WNRWFwL=3Om9guoQAXXqXYEm3efwzpBWGZFwYUGgmwhA@mail.gmail.com>
Message-ID: <CAJ0y-Dd1ZhCY+ENFr+WFvQPMQHdF=dHFCAjbfWxv6vdoF0fVEg@mail.gmail.com>

The "reason" is probably that reply-to header munging is turned off by
default in GNU Mailman and we continue to use that.

>From the mailman 3 docs:

//The Mailman developers, and I believe the majority consensus is to do no
reply-to munging, under several principles. Primarily, most reply-to
munging is requested by people who do not have both a Reply and Reply
All button
on their mail reader. If you do not munge Reply-To, then these buttons will
work properly, but if you munge the header, it is impossible for these
buttons to work right, because both will reply to the list. This leads to
unfortunate accidents where a private message is accidentally posted to the
entire list.//

Older m/l etiquette (read 15 - 20 years back) were fairly strict about
reply-to header munging, top posting, thread hijacking, excessive quoting,
replying to the whole digest and so on :-)

Just my 2p.

-indranil

On Fri, 18 Dec, 2020, 1:23 am Tomas Cohen Arazi, <tomascohen at gmail.com>
wrote:

> Hi all, is there a reason for the lists to have the 'Reply-to' set to the
> original sender? This makes it very easy to inadvertently go private on
> answering. The option is to choose to 'Reply to all', but this is really
> sub optimal, as people might receive the message several times, and the
> lists are configured to reject messages sent to more than X senders (I'm
> not sure about X, I think it is set to 3).
>
> I would propose to set the lists reply-to to the list itself.
>
> --
> Tomás Cohen Arazi
> Theke Solutions (http://theke.io)
> ✆ +54 9351 3513384
> GPG: B2F3C15F
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20201218/e4eb5416/attachment-0001.htm>

From dcook at prosentient.com.au  Fri Dec 18 01:51:55 2020
From: dcook at prosentient.com.au (dcook at prosentient.com.au)
Date: Fri, 18 Dec 2020 11:51:55 +1100
Subject: [Koha-devel] Memory usage by Koha daemons (rebuild_zebra.pl,
 SIPServer.pm, etc)
Message-ID: <07d101d6d4d7$fb5a3ae0$f20eb0a0$@prosentient.com.au>

Hi all,

 

I was thinking about memory usage by Koha daemons in light of a koha
listserv post about Koha resource requirements.

 

I notice that rebuild_zebra.pl uses about 170MB when idle. While that's not
staggering on its own, that does add up. That's 1.7GB for 10 processes,
3.4GB for 20 processes, 5.1GB for 30 processes, and so on. You get the idea.


 

That reminds me that in early 2018 on our openSUSE Koha server, I actually
wrote a Koha indexer daemon that only uses 12MB of memory when idle. It
periodically checks the databases for every Koha instance on that server and
launches rebuild_zebra.pl as necessary (in non-daemon mode) and uses
advisory file locking to avoid running duplicate index jobs for an index.
The memory footprint is tiny. I can't recall the exact number of instances
that covered but a conservative estimate would be 60. That's 1 process using
12MB vs 60 processes collectively using 10.2GB of RAM. 

 

I've opened https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27267
to explore this further. In fact, as I was writing comments there, I
realized that an alternative would be to keep 1 process per Koha instance,
but to make that a very lightweight process which just checks if there is
Zebra indexing to do, and to launch rebuild_zebra.pl if there is. I suppose
there pros and cons to both centralized and decentralized models. We already
use decentralized so may as well stay that way and just optimize it.

 

I think that I could actually use some paid work time to do this too, so if
people are happy with this last approach, I'd go ahead and do it.

 

--

 

I notice that SIPServer.pm also uses about 165MB of RAM when it's idling.
That also adds up. However, I don't know how much of that is due to
Net::Server::PreFork and how much of it is our Koha code. I'd have to
explore that more, and since I don't run tonnes of SIP servers, it's not a
priority for me.

 

David Cook

Software Engineer

Prosentient Systems

Suite 7.03

6a Glen St

Milsons Point NSW 2061

Australia

 

Office: 02 9212 0899

Online: 02 8005 0595

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20201218/44a99e65/attachment.htm>

From dcook at prosentient.com.au  Fri Dec 18 02:17:43 2020
From: dcook at prosentient.com.au (dcook at prosentient.com.au)
Date: Fri, 18 Dec 2020 12:17:43 +1100
Subject: [Koha-devel] Koha Command and Control
In-Reply-To: <CALdMRuHxn+1mYP3q32m0NVCWHzbcaLc1xzvKyYSSioPX0=OD9A@mail.gmail.com>
References: <059e01d6d336$a9c47e90$fd4d7bb0$@prosentient.com.au>
 <CABW43UThDM_YTiOaBOkzkpNfcK2KZk-OqDjKNM7btChG=bZcWA@mail.gmail.com>
 <daca1ab8-aa6b-4993-c333-7ef3511b7da1@biblibre.com>
 <066a01d6d3fb$359445d0$a0bcd170$@prosentient.com.au>
 <2bb75661-40d4-a09c-5365-c389cdc70f6d@biblibre.com>
 <CALdMRuHxn+1mYP3q32m0NVCWHzbcaLc1xzvKyYSSioPX0=OD9A@mail.gmail.com>
Message-ID: <07e001d6d4db$967dee10$c379ca30$@prosentient.com.au>

I have been wondering that as well. We aren’t using Elasticsearch yet, but if we were it would certainly be an interesting option.

 

David Cook

Software Engineer

Prosentient Systems

Suite 7.03

6a Glen St

Milsons Point NSW 2061

Australia

 

Office: 02 9212 0899

Online: 02 8005 0595

 

From: Koha-devel <koha-devel-bounces at lists.koha-community.org> On Behalf Of Agustin Moyano
Sent: Friday, 18 December 2020 1:09 AM
To: Fridolin SOMERS <fridolin.somers at biblibre.com>
Cc: Koha Devel <koha-devel at lists.koha-community.org>
Subject: Re: [Koha-devel] Koha Command and Control

 

Hi everyone, if Koha is aiming to replace zebra with elastic search, I think it would be best to use ELK Stack for log parsing and sending notifications.

 

What do you think?

 

On Thu, Dec 17, 2020 at 5:48 AM Fridolin SOMERS <fridolin.somers at biblibre.com <mailto:fridolin.somers at biblibre.com> > wrote:

Hi,

Indeed good idea.

Maybe we could add a Koha plugin hook to add datas to this HEA.
So poeple can add specific datas that may be private for the general HEA.

"One HEA to rule them all" ^^

Le 16/12/2020 à 23:31, dcook at prosentient.com.au <mailto:dcook at prosentient.com.au>  a écrit :
> Hi Arthur,
> 
> Thanks for your email.
> 
> I use Ansible quite a bit already, so I see where you're coming from, but I was thinking of something more elegant. I was also thinking about something that would allow for more private data collection than Hea.
> 
> Although when I put it that way... it could be interesting to update C4::UsageStats::ReportToCommunity() to actually take a list of URLs, and people could run up their own private Hea (https://gitlab.com/koha-community/hea-app).
> 
> David Cook
> Software Engineer
> Prosentient Systems
> Suite 7.03
> 6a Glen St
> Milsons Point NSW 2061
> Australia
> 
> Office: 02 9212 0899
> Online: 02 8005 0595
> 
> -----Original Message-----
> From: Koha-devel <koha-devel-bounces at lists.koha-community.org <mailto:koha-devel-bounces at lists.koha-community.org> > On Behalf Of Arthur
> Sent: Thursday, 17 December 2020 2:15 AM
> To: koha-devel at lists.koha-community.org <mailto:koha-devel at lists.koha-community.org> 
> Subject: Re: [Koha-devel] Koha Command and Control
> 
> Hi there,
> 
> for this kind of purpose I would recommend using Ansible scripts to ship commands to several Koha's at once.
> 
> Using Ansible only needs an ssh connexion to each of your Koha servers, no specific software or agent to install on the targets, then commands are simple well-known bash.
> 
> It is also possible to group targets (manually) based on OS, web-server software or other tweaks to deploy specific sets of commands to each of your groups, this is very handy.
> 
> I personally don't use it because our environment is very heterogeneous, making grouping difficult and prone to error (and then we would have a lot of groups of a single instance...)
> 
> Best,
> 
> Arthur Suzuki
> 
> BibLibre Koha Support
> 
> On 16/12/2020 16:01, Cab Vinton wrote:
>> This popped into my email ... Above my pay grade, but maybe of relevance?
>>
>> https://newrelic.com/
>>
>> All best,
>>
>> Cab Vinton, Director
>> Plaistow Public Library
>>
>> On Tue, Dec 15, 2020 at 6:04 PM <dcook at prosentient.com.au <mailto:dcook at prosentient.com.au> > wrote:
>>> Hi all,
>>>
>>>
>>>
>>> For a while, I’ve been thinking that it might be good to have an open source “Koha Command and Control” for managing Koha instances.
>>>
>>>
>>>
>>> While managing 1 Koha is not too much work, it’s considerably more difficult to manage 10, 100, or 1000 Koha instances, especially across different servers, geographic locations, timezones, etc.
>>>
>>>
>>>
>>> I am sure that most vendors have mechanisms in place for checking the system preference values for all their instances (I have scripts for this sort of thing), what about tracking Zebra queries that contain syntax errors (bug 27139)?
>>>
>>>
>>>
>>> I know that we have HEA for sharing a lot of data, but there is some data (like search queries) that I don’t think most libraries would want to share with the community. But Koha administrators, especially vendors with a large number of Koha instances, want to know when problems arise.
>>>
>>>
>>>
>>> I suppose that a person could just implement log file scanning for Zebra, but I was thinking about something more structured, which could be analyzed to provide data quality control. My thought is that we’d configure Koha to push events to the “Koha Command and Control” (which would be configured by the Koha system administrator – not librarian level). If Zebra logs a ‘ZOOM error 10014 "CCL parsing error"’, we probably want to tell the Koha user that we found no search results (nice user experience), but we want to flag with a Koha administrator that there is a problem. If Koha administrators (e.g. Koha vendors) start receiving a lot of these errors via the Koha CnC (Command and Control), they’re better placed to raise Bugzilla reports/write patches.
>>>
>>>
>>>
>>> Anyway, it’s just an idea. Probably too ambitious. But I think that it would be wise for us to start thinking more about the *data* generated by Koha and how we can use that data to improve Koha. I don’t think we need machine learning algorithms to do the data analysis (yet), but I think having automated data collection, organisation, and reporting would be useful.
>>>
>>>
>>>
>>> I have to run but I’ll keep thinking about it. I know I have more
>>> grand ideas than I have time, but I could put some thought into what
>>> a system might look like, and maybe throw something together locally
>>> first before suggesting anyone else get on board…
>>>
>>>
>>>
>>> David Cook
>>>
>>> Software Engineer
>>>
>>> Prosentient Systems
>>>
>>> Suite 7.03
>>>
>>> 6a Glen St
>>>
>>> Milsons Point NSW 2061
>>>
>>> Australia
>>>
>>>
>>>
>>> Office: 02 9212 0899
>>>
>>> Online: 02 8005 0595
>>>
>>>
>>>
>>> _______________________________________________
>>> Koha-devel mailing list
>>> Koha-devel at lists.koha-community.org <mailto:Koha-devel at lists.koha-community.org> 
>>> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>>> website : http://www.koha-community.org/ git :
>>> http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
>> _______________________________________________
>> Koha-devel mailing list
>> Koha-devel at lists.koha-community.org <mailto:Koha-devel at lists.koha-community.org> 
>> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>> website : http://www.koha-community.org/ git :
>> http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
> 
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org <mailto:Koha-devel at lists.koha-community.org> 
> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
> 
> 
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org <mailto:Koha-devel at lists.koha-community.org> 
> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
> 

-- 
Fridolin SOMERS <fridolin.somers at biblibre.com <mailto:fridolin.somers at biblibre.com> >
Software and system maintainer 🦄
BibLibre, France
_______________________________________________
Koha-devel mailing list
Koha-devel at lists.koha-community.org <mailto:Koha-devel at lists.koha-community.org> 
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20201218/97fdef34/attachment-0001.htm>

From dcook at prosentient.com.au  Fri Dec 18 05:15:14 2020
From: dcook at prosentient.com.au (dcook at prosentient.com.au)
Date: Fri, 18 Dec 2020 15:15:14 +1100
Subject: [Koha-devel] Zebra ICU issues
Message-ID: <07ff01d6d4f4$62fdb070$28f91150$@prosentient.com.au>

Hi all,

Slowly making progress at https://github.com/indexdata/idzebra/issues/24. It looks like some of the issues I've found so far are due to us using tokenization "l" instead of "s". However, it looks to me like even the latest Zebra is buggy and doesn't properly index phrases in the "p" register. 

Hoping Indexdata can fix things up based on my investigation (or point me on the right path).

Note that my tests are being done in koha-testing-docker and I've used Zebra 2.0.59 and Zebra 2.2.2. 

David Cook
Software Engineer
Prosentient Systems
Suite 7.03
6a Glen St
Milsons Point NSW 2061
Australia

Office: 02 9212 0899
Online: 02 8005 0595

-----Original Message-----
From: Koha-devel <koha-devel-bounces at lists.koha-community.org> On Behalf Of dcook at prosentient.com.au
Sent: Thursday, 17 December 2020 1:31 PM
To: 'Fridolin SOMERS' <fridolin.somers at biblibre.com>; koha-devel at lists.koha-community.org
Subject: Re: [Koha-devel] LinkBibHeadingsToAuthorities not working as expected

Thanks, Fridolin!

I've reported it to Indexdata but they say they can't reproduce the problem...

David Cook
Software Engineer
Prosentient Systems
Suite 7.03
6a Glen St
Milsons Point NSW 2061
Australia

Office: 02 9212 0899
Online: 02 8005 0595

-----Original Message-----
From: Koha-devel <koha-devel-bounces at lists.koha-community.org> On Behalf Of Fridolin SOMERS
Sent: Wednesday, 16 December 2020 7:54 PM
To: koha-devel at lists.koha-community.org
Subject: Re: [Koha-devel] LinkBibHeadingsToAuthorities not working as expected

Thanks a lot for your tests.

I will try on our Bionic env with Zebra 2.2.1

Le 11/12/2020 à 06:56, dcook at prosentient.com.au a écrit :
> This one is driving me a bit crazy, so I’ve logged an issue with 
> Indexdata and I’m hoping for the best:
> https://github.com/indexdata/idzebra/issues/24
> <https://github.com/indexdata/idzebra/issues/24>.
> 
> David Cook
> 
> Software Engineer
> 
> Prosentient Systems
> 
> Suite 7.03
> 
> 6a Glen St
> 
> Milsons Point NSW 2061
> 
> Australia
> 
> Office: 02 9212 0899
> 
> Online: 02 8005 0595
> 
> *From:*Koha-devel <koha-devel-bounces at lists.koha-community.org> *On 
> Behalf Of *dcook at prosentient.com.au
> *Sent:* Friday, 11 December 2020 4:31 PM
> *To:* 'Koha Devel' <koha-devel at lists.koha-community.org>
> *Subject:* Re: [Koha-devel] LinkBibHeadingsToAuthorities not working 
> as expected
> 
> Using koha-testing-docker set up for ICU and with my fix from
> https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27198
> <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27198>:
> 
> querytype ccl2rpn
> 
> set_cclfile /etc/koha/zebradb/ccl.properties
> 
> format xml
> 
> elements zebra::snippet
> 
> Z> f Match-heading,phr,ext,do-not-truncate="the Q"
> 
> Sent searchRequest.
> 
> Received SearchResponse.
> 
> Search was a success.
> 
> Number of hits: 34, setno 24
> 
> SearchResult-1: term=the cnt=34
> 
> records returned: 0
> 
> Elapsed: 0.000315
> 
> Z> show
> 
> Sent presentRequest (1+1).
> 
> Records: 1
> 
> Record type: XML
> 
> <record xmlns="http://www.indexdata.com/zebra/
> <http://www.indexdata.com/zebra/>">
> 
>    <snippet name="Match-heading" type="p" 
> fields="Match">Xenophon<s>the</s>Historian</snippet>
> 
> </record>nextResultSetPosition = 2
> 
> Elapsed: 0.003864
> 
> So that’s special… admittedly that’s Zebra 2.0.59…
> 
> On Zebra 2.1.4 with ICU:
> 
> Z> f Match-heading,phr,ext,do-not-truncate="the Q"
> 
> Sent searchRequest.
> 
> Received SearchResponse.
> 
> Search was a success.
> 
> Number of hits: 0, setno 2
> 
> SearchResult-1: term=the  cnt=5383, term=Q cnt=10
> 
> records returned: 0
> 
> Elapsed: 0.009691
> 
> Z> f Match-heading,phr,ext,do-not-truncate="the"
> 
> Sent searchRequest.
> 
> Received SearchResponse.
> 
> Search was a success.
> 
> Number of hits: 85, setno 3
> 
> SearchResult-1: term=the cnt=85
> 
> records returned: 0
> 
> Elapsed: 0.002209
> 
> However, 85 results is still too many. It should be 0 results.
> 
> I can’t add the diagnostics from
> https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27198
> <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27198>
> right now though… so will have to get back to this one another day probably.
> 
> But maybe someone else using Zebra with ICU can look into this problem too.
> 
> It’s leading to lots of duplicate authorities it seems…
> 
> David Cook
> 
> Software Engineer
> 
> Prosentient Systems
> 
> Suite 7.03
> 
> 6a Glen St
> 
> Milsons Point NSW 2061
> 
> Australia
> 
> Office: 02 9212 0899
> 
> Online: 02 8005 0595
> 
> *From:*Koha-devel <koha-devel-bounces at lists.koha-community.org
> <mailto:koha-devel-bounces at lists.koha-community.org>> *On Behalf Of 
> *dcook at prosentient.com.au <mailto:dcook at prosentient.com.au>
> *Sent:* Friday, 11 December 2020 4:22 PM
> *To:* 'Koha Devel' <koha-devel at lists.koha-community.org
> <mailto:koha-devel at lists.koha-community.org>>
> *Subject:* Re: [Koha-devel] LinkBibHeadingsToAuthorities not working 
> as expected
> 
> Ugh yeah no… I’m reproducing it with koha-testing-docker too.
> 
> Looks like yet another ICU bug…
> 
> David Cook
> 
> Software Engineer
> 
> Prosentient Systems
> 
> Suite 7.03
> 
> 6a Glen St
> 
> Milsons Point NSW 2061
> 
> Australia
> 
> Office: 02 9212 0899
> 
> Online: 02 8005 0595
> 
> *From:*Koha-devel <koha-devel-bounces at lists.koha-community.org
> <mailto:koha-devel-bounces at lists.koha-community.org>> *On Behalf Of 
> *dcook at prosentient.com.au <mailto:dcook at prosentient.com.au>
> *Sent:* Friday, 11 December 2020 3:50 PM
> *To:* 'Koha Devel' <koha-devel at lists.koha-community.org
> <mailto:koha-devel at lists.koha-community.org>>
> *Subject:* Re: [Koha-devel] LinkBibHeadingsToAuthorities not working 
> as expected
> 
> Then again… I can’t reproduce this problem on koha-testing-docker, but 
> I can on a prod Koha running Zebra 2.1.4 with… a very strange 
> /etc/koha/zebradb/etc/default.idx file…
> 
> David Cook
> 
> Software Engineer
> 
> Prosentient Systems
> 
> Suite 7.03
> 
> 6a Glen St
> 
> Milsons Point NSW 2061
> 
> Australia
> 
> Office: 02 9212 0899
> 
> Online: 02 8005 0595
> 
> *From:*Koha-devel <koha-devel-bounces at lists.koha-community.org
> <mailto:koha-devel-bounces at lists.koha-community.org>> *On Behalf Of 
> *dcook at prosentient.com.au <mailto:dcook at prosentient.com.au>
> *Sent:* Friday, 11 December 2020 3:32 PM
> *To:* 'Koha Devel' <koha-devel at lists.koha-community.org
> <mailto:koha-devel at lists.koha-community.org>>
> *Subject:* [Koha-devel] LinkBibHeadingsToAuthorities not working as 
> expected
> 
> Hi all,
> 
> I’m still investigating, but it seems to me that the 
> C4::Linker::Default in C4::Biblio::LinkBibHeadingsToAuthorities isn’t 
> searching accurately using C4::Heading::authorities.
> 
> I’m looking at C4::AuthoritiesMarc::SearchAuthorities and at a glance 
> it looks OK, but in practice I think that my search queries are 
> getting way too many results.
> 
> By hand, if I try the following query:
> 
> Match-heading,phr,ext,do-not-truncate="e"
> 
> I get a huge number of results, which is odd, since that should be an 
> “exact” match.
> 
> I’ve opened
> https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27198
> <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27198>
> because I need to improve the diagnostics available for a Zebra 
> authorities database, but yeah… not good. Hopefully I’ll know more soon.
> 
> David Cook
> 
> Software Engineer
> 
> Prosentient Systems
> 
> Suite 7.03
> 
> 6a Glen St
> 
> Milsons Point NSW 2061
> 
> Australia
> 
> Office: 02 9212 0899
> 
> Online: 02 8005 0595
> 
> 
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/ git : 
> http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
> 

--
Fridolin SOMERS <fridolin.somers at biblibre.com> Software and system maintainer 🦄
BibLibre, France
_______________________________________________
Koha-devel mailing list
Koha-devel at lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/


_______________________________________________
Koha-devel mailing list
Koha-devel at lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/



From jonathan.druart at bugs.koha-community.org  Fri Dec 18 09:55:59 2020
From: jonathan.druart at bugs.koha-community.org (Jonathan Druart)
Date: Fri, 18 Dec 2020 09:55:59 +0100
Subject: [Koha-devel] Misconfigured lists?
In-Reply-To: <CAJ0y-Dd1ZhCY+ENFr+WFvQPMQHdF=dHFCAjbfWxv6vdoF0fVEg@mail.gmail.com>
References: <CABZfb=WNRWFwL=3Om9guoQAXXqXYEm3efwzpBWGZFwYUGgmwhA@mail.gmail.com>
 <CAJ0y-Dd1ZhCY+ENFr+WFvQPMQHdF=dHFCAjbfWxv6vdoF0fVEg@mail.gmail.com>
Message-ID: <CAJzKNY5H1Ee599s9qgaGRF1z3xUzUUdanTyg_sPZii8MtSkSBg@mail.gmail.com>

I confirm the setting for the following 2 options:
"""
Reply-To: header munging
Should any existing Reply-To: header found in the original message be
stripped? If so, this will be done regardless of whether an explict
Reply-To: header is added by Mailman or not. [X] No [ ] Yes
Where are replies to list messages directed? Poster is strongly
recommended for most mailing lists. [X] Poster [ ] This list [ ]
Explicit address
"""

The "Ceiling on acceptable number of recipients for a posting." is 10
however (and yes, I am pretty sure some emails have been rejected with
3 senders).

Cheers,
Jonathan

Le jeu. 17 déc. 2020 à 21:13, Indranil Das Gupta <indradg at l2c2.co.in> a écrit :
>
> The "reason" is probably that reply-to header munging is turned off by default in GNU Mailman and we continue to use that.
>
> From the mailman 3 docs:
>
> //The Mailman developers, and I believe the majority consensus is to do no reply-to munging, under several principles. Primarily, most reply-to munging is requested by people who do not have both a Reply and Reply All button on their mail reader. If you do not munge Reply-To, then these buttons will work properly, but if you munge the header, it is impossible for these buttons to work right, because both will reply to the list. This leads to unfortunate accidents where a private message is accidentally posted to the entire list.//
>
> Older m/l etiquette (read 15 - 20 years back) were fairly strict about reply-to header munging, top posting, thread hijacking, excessive quoting, replying to the whole digest and so on :-)
>
> Just my 2p.
>
> -indranil
>
> On Fri, 18 Dec, 2020, 1:23 am Tomas Cohen Arazi, <tomascohen at gmail.com> wrote:
>>
>> Hi all, is there a reason for the lists to have the 'Reply-to' set to the original sender? This makes it very easy to inadvertently go private on answering. The option is to choose to 'Reply to all', but this is really sub optimal, as people might receive the message several times, and the lists are configured to reject messages sent to more than X senders (I'm not sure about X, I think it is set to 3).
>>
>> I would propose to set the lists reply-to to the list itself.
>>
>> --
>> Tomás Cohen Arazi
>> Theke Solutions (http://theke.io)
>> ✆ +54 9351 3513384
>> GPG: B2F3C15F
>> _______________________________________________
>> Koha-devel mailing list
>> Koha-devel at lists.koha-community.org
>> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>> website : http://www.koha-community.org/
>> git : http://git.koha-community.org/
>> bugs : http://bugs.koha-community.org/
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/

From kohadevinim at devinim.com.tr  Sun Dec 20 19:25:09 2020
From: kohadevinim at devinim.com.tr (DevinimKoha)
Date: Sun, 20 Dec 2020 21:25:09 +0300
Subject: [Koha-devel] Load balancing Zebra
In-Reply-To: <067201d6d405$4e542270$eafc6750$@prosentient.com.au>
References: <067201d6d405$4e542270$eafc6750$@prosentient.com.au>
Message-ID: <e7739372-3837-5a92-f723-0c0eb9c6d073@devinim.com.tr>

Hi David,

No, we didn't use never, unfortunately. We've tried some transfers 
between servers using with rsync, but it didn't reach a satisfactory 
solution. Instead we generally used to rebuild zebra at late nigths with 
huge memory servers.

On 17.12.2020 02:43, dcook at prosentient.com.au wrote:
>
> Hi Mengu,
>
> Do you use the YAZ Proxy 
> (https://www.indexdata.com/resources/software/yazproxy/) at all for 
> load balancing Zebra?
>
> How do you distribute updates to your different Zebra servers? I have 
> a vague memory that you index one of them and then copy the Zebra 
> database over periodically?
>
> David Cook
>
> Software Engineer
>
> Prosentient Systems
>
> Suite 7.03
>
> 6a Glen St
>
> Milsons Point NSW 2061
>
> Australia
>
> Office: 02 9212 0899
>
> Online: 02 8005 0595
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20201220/0b0b70ba/attachment.htm>

From paul.a at navalmarinearchive.com  Sun Dec 20 19:58:13 2020
From: paul.a at navalmarinearchive.com (Paul A)
Date: Sun, 20 Dec 2020 13:58:13 -0500
Subject: [Koha-devel] Load balancing Zebra
In-Reply-To: <e7739372-3837-5a92-f723-0c0eb9c6d073@devinim.com.tr>
References: <067201d6d405$4e542270$eafc6750$@prosentient.com.au>
 <e7739372-3837-5a92-f723-0c0eb9c6d073@devinim.com.tr>
Message-ID: <163a6936-926b-1a9e-2cfd-d1b8294a7ca6@navalmarinearchive.com>

On 2020-12-20 1:25 p.m., DevinimKoha wrote:
> Hi David,
> 
> [snip]  Instead we generally used to rebuild zebra at late nigths with 
> huge memory servers.

RAM is most helpful, but I looked into this (a little while ago) and the 
biggest hiccup seemed to be that Zebra won't multi-thread at CPU level 
-- it uses 100%+ of a single core, and bogs down. I remember writing to 
one of their developers in Holland (Adam D.), but never heard back.

We have also found that RAID6 slows it down somewhat because of the 
write speed penalty.

With best wishes all around for 2021, and please stay safe,
Paul

> 
> On 17.12.2020 02:43, dcook at prosentient.com.au wrote:
>>
>> Hi Mengu,
>>
>> Do you use the YAZ Proxy 
>> (https://www.indexdata.com/resources/software/yazproxy/) at all for 
>> load balancing Zebra?
>>
>> How do you distribute updates to your different Zebra servers? I have 
>> a vague memory that you index one of them and then copy the Zebra 
>> database over periodically?
>>
>> David Cook
>>
>> Software Engineer
>>
>> Prosentient Systems
>>
>> Suite 7.03
>>
>> 6a Glen St
>>
>> Milsons Point NSW 2061
>>
>> Australia
>>
>> Office: 02 9212 0899
>>
>> Online: 02 8005 0595
>>
>>
>> _______________________________________________
>> Koha-devel mailing list
>> Koha-devel at lists.koha-community.org
>> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>> website : http://www.koha-community.org/
>> git : http://git.koha-community.org/
>> bugs : http://bugs.koha-community.org/
> 
> 
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
> 


From dcook at prosentient.com.au  Sun Dec 20 23:43:17 2020
From: dcook at prosentient.com.au (dcook at prosentient.com.au)
Date: Mon, 21 Dec 2020 09:43:17 +1100
Subject: [Koha-devel] Mail list footer
Message-ID: <000601d6d721$8261abe0$872503a0$@prosentient.com.au>

Hi all,

 

I just noticed that a lot of the links on the "Koha-devel mailing list"
footer are in HTTP instead of HTTPS. It's not a big drama since they all
redirect to HTTPS, but we may as well update those to HTTPS and skip the
extra web server request. 

 

Not 100% sure who manages this list. Maybe BibLibre?

 

David Cook

Software Engineer

Prosentient Systems

Suite 7.03

6a Glen St

Milsons Point NSW 2061

Australia

 

Office: 02 9212 0899

Online: 02 8005 0595

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20201221/e0a7818b/attachment.htm>

From jonathan.druart at bugs.koha-community.org  Mon Dec 21 09:50:24 2020
From: jonathan.druart at bugs.koha-community.org (Jonathan Druart)
Date: Mon, 21 Dec 2020 09:50:24 +0100
Subject: [Koha-devel] Mail list footer
In-Reply-To: <000601d6d721$8261abe0$872503a0$@prosentient.com.au>
References: <000601d6d721$8261abe0$872503a0$@prosentient.com.au>
Message-ID: <CAJzKNY7MXMWENT-PSxfzyP6jQc0ve_sur=sYwXO87k39uh0WTA@mail.gmail.com>

BibLibre hosts koha-devel, I have the admin password.
I modified the links.

Le dim. 20 déc. 2020 à 23:43, <dcook at prosentient.com.au> a écrit :
>
> Hi all,
>
>
>
> I just noticed that a lot of the links on the “Koha-devel mailing list” footer are in HTTP instead of HTTPS. It’s not a big drama since they all redirect to HTTPS, but we may as well update those to HTTPS and skip the extra web server request.
>
>
>
> Not 100% sure who manages this list. Maybe BibLibre?
>
>
>
> David Cook
>
> Software Engineer
>
> Prosentient Systems
>
> Suite 7.03
>
> 6a Glen St
>
> Milsons Point NSW 2061
>
> Australia
>
>
>
> Office: 02 9212 0899
>
> Online: 02 8005 0595
>
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/

From tomascohen at gmail.com  Mon Dec 21 21:29:58 2020
From: tomascohen at gmail.com (Tomas Cohen Arazi)
Date: Mon, 21 Dec 2020 17:29:58 -0300
Subject: [Koha-devel] A configurations table
Message-ID: <CABZfb=Wgz3=d-0tr64VvpGbaiy-Kw64nL-rap0pfk5r866RisQ@mail.gmail.com>

Hi all, I'm not sure I already mentioned this, but I proposed a new table
on bug 26129 [1]. The table is quite similar to 'systempreferences'. The
key difference is its companion classes are designed to allow per-branch,
per-itemtype and per-category options.

This is basically a generalization of the 'circulation_rules' table, and
also the 'systempreferences' one.

I originally envisioned it so I could set SMTP servers to libraries without
a library_to_smtp table. I abandoned the idea because it was too much for
what I was doing, but now I found:

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22457
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10589

which basically require this table and methods to calculate the effective
(boolean) based on library and patron category. And I wouldn't like to see
that implemented by reinventing the wheel.

The 'configurations' table IS reinventing the wheel, but in a way that can
be reused and with a reasonable programming API (i.e. you don't need to
create new tables for your per-<something> rules, just reuse this
internally).

We could think of (eventually) refactoring our system preferences to fit
here, or not, and just use it as the backend for some settings that require
this.

Cheers

[1] https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26129

-- 
Tomás Cohen Arazi
Theke Solutions (http://theke.io)
✆ +54 9351 3513384
GPG: B2F3C15F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20201221/5668c61f/attachment.htm>

From dcook at prosentient.com.au  Mon Dec 21 23:53:42 2020
From: dcook at prosentient.com.au (dcook at prosentient.com.au)
Date: Tue, 22 Dec 2020 09:53:42 +1100
Subject: [Koha-devel] A configurations table
In-Reply-To: <CABZfb=Wgz3=d-0tr64VvpGbaiy-Kw64nL-rap0pfk5r866RisQ@mail.gmail.com>
References: <CABZfb=Wgz3=d-0tr64VvpGbaiy-Kw64nL-rap0pfk5r866RisQ@mail.gmail.com>
Message-ID: <00ad01d6d7ec$21200a90$63601fb0$@prosentient.com.au>

I think that I’ve been the most vocal critic against it, but even I changed my mind a few months ago.

 

I don’t see any reason not to try it out. Jonathan has helped me realize that sometimes we (and especially me) talk things to death. If someone is willing to work on something, especially a new idea, I think that should be encouraged. 

 

Time to move it back to “Needs Signoff”?

 

David Cook

Software Engineer

Prosentient Systems

Suite 7.03

6a Glen St

Milsons Point NSW 2061

Australia

 

Office: 02 9212 0899

Online: 02 8005 0595

 

From: Koha-devel <koha-devel-bounces at lists.koha-community.org> On Behalf Of Tomas Cohen Arazi
Sent: Tuesday, 22 December 2020 7:30 AM
To: koha-devel <koha-devel at lists.koha-community.org>
Subject: [Koha-devel] A configurations table

 

Hi all, I'm not sure I already mentioned this, but I proposed a new table on bug 26129 [1]. The table is quite similar to 'systempreferences'. The key difference is its companion classes are designed to allow per-branch, per-itemtype and per-category options.

 

This is basically a generalization of the 'circulation_rules' table, and also the 'systempreferences' one.

 

I originally envisioned it so I could set SMTP servers to libraries without a library_to_smtp table. I abandoned the idea because it was too much for what I was doing, but now I found:

 

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22457

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10589

 

which basically require this table and methods to calculate the effective (boolean) based on library and patron category. And I wouldn't like to see that implemented by reinventing the wheel.

 

The 'configurations' table IS reinventing the wheel, but in a way that can be reused and with a reasonable programming API (i.e. you don't need to create new tables for your per-<something> rules, just reuse this internally).

 

We could think of (eventually) refactoring our system preferences to fit here, or not, and just use it as the backend for some settings that require this.

 

Cheers

 

[1] https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26129


 

-- 

Tomás Cohen Arazi

Theke Solutions (http://theke.io <http://theke.io/> )
✆ +54 9351 3513384
GPG: B2F3C15F

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20201222/d7e113d7/attachment.htm>

From dcook at prosentient.com.au  Tue Dec 22 07:58:14 2020
From: dcook at prosentient.com.au (dcook at prosentient.com.au)
Date: Tue, 22 Dec 2020 17:58:14 +1100
Subject: [Koha-devel] Is koha-translate -l not working in
 koha-testing-docker?
Message-ID: <00f301d6d82f$d1cace00$75606a00$@prosentient.com.au>

Hi all,

 

I tried “koha-translate -l” in koha-testing-docker and got no output.

 

I ran “koha-translate -v -i fr-CA” and everything looks like it installed
OK.

 

I ran “koha-translate -l” again and still no output. If I recall correctly,
it should be showing “fr-CA”, no?

 

http://localhost:8081/cgi-bin/koha/admin/preferences.pl?tab=i18n_l10n is
also showing “Français (fr-CA)”.

 

I am guessing checking the package installation rather than the gitified
installation, even though “koha-translate -i" installed to the gitified
location


 

David Cook

Software Engineer

Prosentient Systems

Suite 7.03

6a Glen St

Milsons Point NSW 2061

Australia

 

Office: 02 9212 0899

Online: 02 8005 0595

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20201222/81a6ec4c/attachment.htm>

From fridolin.somers at biblibre.com  Tue Dec 22 12:10:52 2020
From: fridolin.somers at biblibre.com (Fridolin SOMERS)
Date: Tue, 22 Dec 2020 12:10:52 +0100
Subject: [Koha-devel] LinkBibHeadingsToAuthorities not working as
 expected
In-Reply-To: <06ca01d6d41c$ab84d3b0$028e7b10$@prosentient.com.au>
References: <032b01d6cf76$968fb7e0$c3af27a0$@prosentient.com.au>
 <033501d6cf79$0a30c890$1e9259b0$@prosentient.com.au>
 <034401d6cf7d$95a3a600$c0eaf200$@prosentient.com.au>
 <035001d6cf7e$cf724610$6e56d230$@prosentient.com.au>
 <035a01d6cf82$6c09fba0$441df2e0$@prosentient.com.au>
 <72cee5d3-968a-663b-86a2-8914653b7642@biblibre.com>
 <06ca01d6d41c$ab84d3b0$028e7b10$@prosentient.com.au>
Message-ID: <bba3ac8a-b98d-15ad-6628-238a0087c90d@biblibre.com>

Hi,

I've pushed on
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18017

I copied from MARC21 the use of index_heading and index_match_heading 
that was crually missing.

I've seen and subscribed to :
https://github.com/indexdata/idzebra/issues/24

 > If you agree, I'll remove the token element from phrases-icu.xml and 
that would probably be case closed.
Whooo which change is this ?

Best regards

Le 17/12/2020 à 03:31, dcook at prosentient.com.au a écrit :
> Thanks, Fridolin!
> 
> I've reported it to Indexdata but they say they can't reproduce the problem...
> 
> David Cook
> Software Engineer
> Prosentient Systems
> Suite 7.03
> 6a Glen St
> Milsons Point NSW 2061
> Australia
> 
> Office: 02 9212 0899
> Online: 02 8005 0595
> 
> -----Original Message-----
> From: Koha-devel <koha-devel-bounces at lists.koha-community.org> On Behalf Of Fridolin SOMERS
> Sent: Wednesday, 16 December 2020 7:54 PM
> To: koha-devel at lists.koha-community.org
> Subject: Re: [Koha-devel] LinkBibHeadingsToAuthorities not working as expected
> 
> Thanks a lot for your tests.
> 
> I will try on our Bionic env with Zebra 2.2.1
> 
> Le 11/12/2020 à 06:56, dcook at prosentient.com.au a écrit :
>> This one is driving me a bit crazy, so I’ve logged an issue with
>> Indexdata and I’m hoping for the best:
>> https://github.com/indexdata/idzebra/issues/24
>> <https://github.com/indexdata/idzebra/issues/24>.
>>
>> David Cook
>>
>> Software Engineer
>>
>> Prosentient Systems
>>
>> Suite 7.03
>>
>> 6a Glen St
>>
>> Milsons Point NSW 2061
>>
>> Australia
>>
>> Office: 02 9212 0899
>>
>> Online: 02 8005 0595
>>
>> *From:*Koha-devel <koha-devel-bounces at lists.koha-community.org> *On
>> Behalf Of *dcook at prosentient.com.au
>> *Sent:* Friday, 11 December 2020 4:31 PM
>> *To:* 'Koha Devel' <koha-devel at lists.koha-community.org>
>> *Subject:* Re: [Koha-devel] LinkBibHeadingsToAuthorities not working
>> as expected
>>
>> Using koha-testing-docker set up for ICU and with my fix from
>> https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27198
>> <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27198>:
>>
>> querytype ccl2rpn
>>
>> set_cclfile /etc/koha/zebradb/ccl.properties
>>
>> format xml
>>
>> elements zebra::snippet
>>
>> Z> f Match-heading,phr,ext,do-not-truncate="the Q"
>>
>> Sent searchRequest.
>>
>> Received SearchResponse.
>>
>> Search was a success.
>>
>> Number of hits: 34, setno 24
>>
>> SearchResult-1: term=the cnt=34
>>
>> records returned: 0
>>
>> Elapsed: 0.000315
>>
>> Z> show
>>
>> Sent presentRequest (1+1).
>>
>> Records: 1
>>
>> Record type: XML
>>
>> <record xmlns="http://www.indexdata.com/zebra/
>> <http://www.indexdata.com/zebra/>">
>>
>>     <snippet name="Match-heading" type="p"
>> fields="Match">Xenophon<s>the</s>Historian</snippet>
>>
>> </record>nextResultSetPosition = 2
>>
>> Elapsed: 0.003864
>>
>> So that’s special… admittedly that’s Zebra 2.0.59…
>>
>> On Zebra 2.1.4 with ICU:
>>
>> Z> f Match-heading,phr,ext,do-not-truncate="the Q"
>>
>> Sent searchRequest.
>>
>> Received SearchResponse.
>>
>> Search was a success.
>>
>> Number of hits: 0, setno 2
>>
>> SearchResult-1: term=the  cnt=5383, term=Q cnt=10
>>
>> records returned: 0
>>
>> Elapsed: 0.009691
>>
>> Z> f Match-heading,phr,ext,do-not-truncate="the"
>>
>> Sent searchRequest.
>>
>> Received SearchResponse.
>>
>> Search was a success.
>>
>> Number of hits: 85, setno 3
>>
>> SearchResult-1: term=the cnt=85
>>
>> records returned: 0
>>
>> Elapsed: 0.002209
>>
>> However, 85 results is still too many. It should be 0 results.
>>
>> I can’t add the diagnostics from
>> https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27198
>> <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27198>
>> right now though… so will have to get back to this one another day probably.
>>
>> But maybe someone else using Zebra with ICU can look into this problem too.
>>
>> It’s leading to lots of duplicate authorities it seems…
>>
>> David Cook
>>
>> Software Engineer
>>
>> Prosentient Systems
>>
>> Suite 7.03
>>
>> 6a Glen St
>>
>> Milsons Point NSW 2061
>>
>> Australia
>>
>> Office: 02 9212 0899
>>
>> Online: 02 8005 0595
>>
>> *From:*Koha-devel <koha-devel-bounces at lists.koha-community.org
>> <mailto:koha-devel-bounces at lists.koha-community.org>> *On Behalf Of
>> *dcook at prosentient.com.au <mailto:dcook at prosentient.com.au>
>> *Sent:* Friday, 11 December 2020 4:22 PM
>> *To:* 'Koha Devel' <koha-devel at lists.koha-community.org
>> <mailto:koha-devel at lists.koha-community.org>>
>> *Subject:* Re: [Koha-devel] LinkBibHeadingsToAuthorities not working
>> as expected
>>
>> Ugh yeah no… I’m reproducing it with koha-testing-docker too.
>>
>> Looks like yet another ICU bug…
>>
>> David Cook
>>
>> Software Engineer
>>
>> Prosentient Systems
>>
>> Suite 7.03
>>
>> 6a Glen St
>>
>> Milsons Point NSW 2061
>>
>> Australia
>>
>> Office: 02 9212 0899
>>
>> Online: 02 8005 0595
>>
>> *From:*Koha-devel <koha-devel-bounces at lists.koha-community.org
>> <mailto:koha-devel-bounces at lists.koha-community.org>> *On Behalf Of
>> *dcook at prosentient.com.au <mailto:dcook at prosentient.com.au>
>> *Sent:* Friday, 11 December 2020 3:50 PM
>> *To:* 'Koha Devel' <koha-devel at lists.koha-community.org
>> <mailto:koha-devel at lists.koha-community.org>>
>> *Subject:* Re: [Koha-devel] LinkBibHeadingsToAuthorities not working
>> as expected
>>
>> Then again… I can’t reproduce this problem on koha-testing-docker, but
>> I can on a prod Koha running Zebra 2.1.4 with… a very strange
>> /etc/koha/zebradb/etc/default.idx file…
>>
>> David Cook
>>
>> Software Engineer
>>
>> Prosentient Systems
>>
>> Suite 7.03
>>
>> 6a Glen St
>>
>> Milsons Point NSW 2061
>>
>> Australia
>>
>> Office: 02 9212 0899
>>
>> Online: 02 8005 0595
>>
>> *From:*Koha-devel <koha-devel-bounces at lists.koha-community.org
>> <mailto:koha-devel-bounces at lists.koha-community.org>> *On Behalf Of
>> *dcook at prosentient.com.au <mailto:dcook at prosentient.com.au>
>> *Sent:* Friday, 11 December 2020 3:32 PM
>> *To:* 'Koha Devel' <koha-devel at lists.koha-community.org
>> <mailto:koha-devel at lists.koha-community.org>>
>> *Subject:* [Koha-devel] LinkBibHeadingsToAuthorities not working as
>> expected
>>
>> Hi all,
>>
>> I’m still investigating, but it seems to me that the
>> C4::Linker::Default in C4::Biblio::LinkBibHeadingsToAuthorities isn’t
>> searching accurately using C4::Heading::authorities.
>>
>> I’m looking at C4::AuthoritiesMarc::SearchAuthorities and at a glance
>> it looks OK, but in practice I think that my search queries are
>> getting way too many results.
>>
>> By hand, if I try the following query:
>>
>> Match-heading,phr,ext,do-not-truncate="e"
>>
>> I get a huge number of results, which is odd, since that should be an
>> “exact” match.
>>
>> I’ve opened
>> https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27198
>> <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27198>
>> because I need to improve the diagnostics available for a Zebra
>> authorities database, but yeah… not good. Hopefully I’ll know more soon.
>>
>> David Cook
>>
>> Software Engineer
>>
>> Prosentient Systems
>>
>> Suite 7.03
>>
>> 6a Glen St
>>
>> Milsons Point NSW 2061
>>
>> Australia
>>
>> Office: 02 9212 0899
>>
>> Online: 02 8005 0595
>>
>>
>> _______________________________________________
>> Koha-devel mailing list
>> Koha-devel at lists.koha-community.org
>> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>> website : http://www.koha-community.org/ git :
>> http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
>>
> 

-- 
Fridolin SOMERS <fridolin.somers at biblibre.com>
Software and system maintainer 🦄
BibLibre, France

From dcook at prosentient.com.au  Wed Dec 23 00:16:35 2020
From: dcook at prosentient.com.au (dcook at prosentient.com.au)
Date: Wed, 23 Dec 2020 10:16:35 +1100
Subject: [Koha-devel] Fixing exact search in Zebra ICU (formerly
 LinkBibHeadingsToAuthorities not working as expected)
Message-ID: <019201d6d8b8$7e22f2d0$7a68d870$@prosentient.com.au>

Thanks, Fridolin.

I've opened up https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27299 to track this topic in Koha. I've added a See Also to 18017.

I've added a patch to 27299 with the change I proposed in https://github.com/indexdata/idzebra/issues/24. 

I've tested it outside of Koha and it works as I expected/hoped. I just want to get Indexdata's blessing and then I'll push for it in Koha. 

David Cook
Software Engineer
Prosentient Systems
Suite 7.03
6a Glen St
Milsons Point NSW 2061
Australia

Office: 02 9212 0899
Online: 02 8005 0595

-----Original Message-----
From: Fridolin SOMERS <fridolin.somers at biblibre.com> 
Sent: Tuesday, 22 December 2020 10:11 PM
To: dcook at prosentient.com.au; koha-devel at lists.koha-community.org
Subject: Re: [Koha-devel] LinkBibHeadingsToAuthorities not working as expected

Hi,

I've pushed on
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18017

I copied from MARC21 the use of index_heading and index_match_heading that was crually missing.

I've seen and subscribed to :
https://github.com/indexdata/idzebra/issues/24

 > If you agree, I'll remove the token element from phrases-icu.xml and that would probably be case closed.
Whooo which change is this ?

Best regards

Le 17/12/2020 à 03:31, dcook at prosentient.com.au a écrit :
> Thanks, Fridolin!
> 
> I've reported it to Indexdata but they say they can't reproduce the problem...
> 
> David Cook
> Software Engineer
> Prosentient Systems
> Suite 7.03
> 6a Glen St
> Milsons Point NSW 2061
> Australia
> 
> Office: 02 9212 0899
> Online: 02 8005 0595
> 
> -----Original Message-----
> From: Koha-devel <koha-devel-bounces at lists.koha-community.org> On 
> Behalf Of Fridolin SOMERS
> Sent: Wednesday, 16 December 2020 7:54 PM
> To: koha-devel at lists.koha-community.org
> Subject: Re: [Koha-devel] LinkBibHeadingsToAuthorities not working as 
> expected
> 
> Thanks a lot for your tests.
> 
> I will try on our Bionic env with Zebra 2.2.1
> 
> Le 11/12/2020 à 06:56, dcook at prosentient.com.au a écrit :
>> This one is driving me a bit crazy, so I’ve logged an issue with 
>> Indexdata and I’m hoping for the best:
>> https://github.com/indexdata/idzebra/issues/24
>> <https://github.com/indexdata/idzebra/issues/24>.
>>
>> David Cook
>>
>> Software Engineer
>>
>> Prosentient Systems
>>
>> Suite 7.03
>>
>> 6a Glen St
>>
>> Milsons Point NSW 2061
>>
>> Australia
>>
>> Office: 02 9212 0899
>>
>> Online: 02 8005 0595
>>
>> *From:*Koha-devel <koha-devel-bounces at lists.koha-community.org> *On 
>> Behalf Of *dcook at prosentient.com.au
>> *Sent:* Friday, 11 December 2020 4:31 PM
>> *To:* 'Koha Devel' <koha-devel at lists.koha-community.org>
>> *Subject:* Re: [Koha-devel] LinkBibHeadingsToAuthorities not working 
>> as expected
>>
>> Using koha-testing-docker set up for ICU and with my fix from
>> https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27198
>> <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27198>:
>>
>> querytype ccl2rpn
>>
>> set_cclfile /etc/koha/zebradb/ccl.properties
>>
>> format xml
>>
>> elements zebra::snippet
>>
>> Z> f Match-heading,phr,ext,do-not-truncate="the Q"
>>
>> Sent searchRequest.
>>
>> Received SearchResponse.
>>
>> Search was a success.
>>
>> Number of hits: 34, setno 24
>>
>> SearchResult-1: term=the cnt=34
>>
>> records returned: 0
>>
>> Elapsed: 0.000315
>>
>> Z> show
>>
>> Sent presentRequest (1+1).
>>
>> Records: 1
>>
>> Record type: XML
>>
>> <record xmlns="http://www.indexdata.com/zebra/
>> <http://www.indexdata.com/zebra/>">
>>
>>     <snippet name="Match-heading" type="p"
>> fields="Match">Xenophon<s>the</s>Historian</snippet>
>>
>> </record>nextResultSetPosition = 2
>>
>> Elapsed: 0.003864
>>
>> So that’s special… admittedly that’s Zebra 2.0.59…
>>
>> On Zebra 2.1.4 with ICU:
>>
>> Z> f Match-heading,phr,ext,do-not-truncate="the Q"
>>
>> Sent searchRequest.
>>
>> Received SearchResponse.
>>
>> Search was a success.
>>
>> Number of hits: 0, setno 2
>>
>> SearchResult-1: term=the  cnt=5383, term=Q cnt=10
>>
>> records returned: 0
>>
>> Elapsed: 0.009691
>>
>> Z> f Match-heading,phr,ext,do-not-truncate="the"
>>
>> Sent searchRequest.
>>
>> Received SearchResponse.
>>
>> Search was a success.
>>
>> Number of hits: 85, setno 3
>>
>> SearchResult-1: term=the cnt=85
>>
>> records returned: 0
>>
>> Elapsed: 0.002209
>>
>> However, 85 results is still too many. It should be 0 results.
>>
>> I can’t add the diagnostics from
>> https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27198
>> <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27198>
>> right now though… so will have to get back to this one another day probably.
>>
>> But maybe someone else using Zebra with ICU can look into this problem too.
>>
>> It’s leading to lots of duplicate authorities it seems…
>>
>> David Cook
>>
>> Software Engineer
>>
>> Prosentient Systems
>>
>> Suite 7.03
>>
>> 6a Glen St
>>
>> Milsons Point NSW 2061
>>
>> Australia
>>
>> Office: 02 9212 0899
>>
>> Online: 02 8005 0595
>>
>> *From:*Koha-devel <koha-devel-bounces at lists.koha-community.org
>> <mailto:koha-devel-bounces at lists.koha-community.org>> *On Behalf Of 
>> *dcook at prosentient.com.au <mailto:dcook at prosentient.com.au>
>> *Sent:* Friday, 11 December 2020 4:22 PM
>> *To:* 'Koha Devel' <koha-devel at lists.koha-community.org
>> <mailto:koha-devel at lists.koha-community.org>>
>> *Subject:* Re: [Koha-devel] LinkBibHeadingsToAuthorities not working 
>> as expected
>>
>> Ugh yeah no… I’m reproducing it with koha-testing-docker too.
>>
>> Looks like yet another ICU bug…
>>
>> David Cook
>>
>> Software Engineer
>>
>> Prosentient Systems
>>
>> Suite 7.03
>>
>> 6a Glen St
>>
>> Milsons Point NSW 2061
>>
>> Australia
>>
>> Office: 02 9212 0899
>>
>> Online: 02 8005 0595
>>
>> *From:*Koha-devel <koha-devel-bounces at lists.koha-community.org
>> <mailto:koha-devel-bounces at lists.koha-community.org>> *On Behalf Of 
>> *dcook at prosentient.com.au <mailto:dcook at prosentient.com.au>
>> *Sent:* Friday, 11 December 2020 3:50 PM
>> *To:* 'Koha Devel' <koha-devel at lists.koha-community.org
>> <mailto:koha-devel at lists.koha-community.org>>
>> *Subject:* Re: [Koha-devel] LinkBibHeadingsToAuthorities not working 
>> as expected
>>
>> Then again… I can’t reproduce this problem on koha-testing-docker, 
>> but I can on a prod Koha running Zebra 2.1.4 with… a very strange 
>> /etc/koha/zebradb/etc/default.idx file…
>>
>> David Cook
>>
>> Software Engineer
>>
>> Prosentient Systems
>>
>> Suite 7.03
>>
>> 6a Glen St
>>
>> Milsons Point NSW 2061
>>
>> Australia
>>
>> Office: 02 9212 0899
>>
>> Online: 02 8005 0595
>>
>> *From:*Koha-devel <koha-devel-bounces at lists.koha-community.org
>> <mailto:koha-devel-bounces at lists.koha-community.org>> *On Behalf Of 
>> *dcook at prosentient.com.au <mailto:dcook at prosentient.com.au>
>> *Sent:* Friday, 11 December 2020 3:32 PM
>> *To:* 'Koha Devel' <koha-devel at lists.koha-community.org
>> <mailto:koha-devel at lists.koha-community.org>>
>> *Subject:* [Koha-devel] LinkBibHeadingsToAuthorities not working as 
>> expected
>>
>> Hi all,
>>
>> I’m still investigating, but it seems to me that the 
>> C4::Linker::Default in C4::Biblio::LinkBibHeadingsToAuthorities isn’t 
>> searching accurately using C4::Heading::authorities.
>>
>> I’m looking at C4::AuthoritiesMarc::SearchAuthorities and at a glance 
>> it looks OK, but in practice I think that my search queries are 
>> getting way too many results.
>>
>> By hand, if I try the following query:
>>
>> Match-heading,phr,ext,do-not-truncate="e"
>>
>> I get a huge number of results, which is odd, since that should be an 
>> “exact” match.
>>
>> I’ve opened
>> https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27198
>> <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27198>
>> because I need to improve the diagnostics available for a Zebra 
>> authorities database, but yeah… not good. Hopefully I’ll know more soon.
>>
>> David Cook
>>
>> Software Engineer
>>
>> Prosentient Systems
>>
>> Suite 7.03
>>
>> 6a Glen St
>>
>> Milsons Point NSW 2061
>>
>> Australia
>>
>> Office: 02 9212 0899
>>
>> Online: 02 8005 0595
>>
>>
>> _______________________________________________
>> Koha-devel mailing list
>> Koha-devel at lists.koha-community.org
>> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>> website : http://www.koha-community.org/ git :
>> http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
>>
> 

--
Fridolin SOMERS <fridolin.somers at biblibre.com> Software and system maintainer 🦄
BibLibre, France



From victor at tuxayo.net  Thu Dec 24 21:40:18 2020
From: victor at tuxayo.net (Victor Grousset/tuxayo)
Date: Thu, 24 Dec 2020 21:40:18 +0100
Subject: [Koha-devel] Time to translate: string freeze to prepare Koha
 19.11.13 has begun
Message-ID: <5718be72-f9a8-f718-35d6-c852f176c431@tuxayo.net>

Hi, saluton, hola, bonjour,

String freeze is into effect as of now for the 19.11.x maintenance 
branch. The release is scheduled for around the 5th or 6th of January.

This means it's the right time to head over to the translation platform:
https://translate.koha-community.org/projects/

Important reminder: if you add or change a translation in version 19.11,
then you must also copy it to 20.05 and 20.11. Otherwise your work will
be lost for future versions.


Happy translating,

-- 
Victor Grousset/tuxayo

From fridolin.somers at biblibre.com  Mon Dec 28 14:33:18 2020
From: fridolin.somers at biblibre.com (Fridolin SOMERS)
Date: Mon, 28 Dec 2020 14:33:18 +0100
Subject: [Koha-devel] Time to translate: string freeze to prepare Koha
 20.11.01 has begun
Message-ID: <d329cccb-2257-0c0e-42b8-c1dcc5c3b852@biblibre.com>

Hi,

String freeze is into effect as of now for the 20.11.x maintenance branch.
The release is scheduled for around the 5th or 6th of January.

This means it's the right time to head over to the translation platform:
https://translate.koha-community.org/projects/

Happy translating 🌎🌍🌏

-- 
Fridolin SOMERS <fridolin.somers at biblibre.com>
Software and system maintainer 🦄
BibLibre, France