- Koha-devel - lists.koha-community.org

Koha Community Newsletter: October 2020
by Koha Newsletter 03 Nov '20

03 Nov '20

The Koha Community Newsletter for October 2020 is here: https://koha-community.org/koha-community-newsletter-october-2020/ Many thanks to the folks who submitted articles and news to this month's newsletter. Please feel free to email me with any corrections or suggestions. NOTE: It’s time to pass the baton as editor of the Koha Newsletter. Job priorities have changed and I will no longer have time to give this the attention it deserves. If you’re interested in compiling the newsletter, email the main Koha list and let me know. Once you’ve been confirmed as the next editor, I’ll be more than happy to help you get started. Thank you! -- Chad Roseburg Editor, Koha Community Newsletter

4 5

This week's Development IRC Meeting - change of time to 4 November 2020, 15:00 UTC
by David Nind 03 Nov '20

03 Nov '20

Last week's meeting was deferred, and the time set now clashes with the General Monthly IRC meeting. "We" have changed the time to 4 November 2020, 15:00 UTC The agenda and calendar now reflect this: - https://wiki.koha-community.org/wiki/Development_IRC_meeting_4_November_2020 - https://www.timeanddate.com/worldclock/fixedtime.html?msg=Koha+Developers+I… - https://koha-community.org/calendar/ David Nind | david.nind(a)gmail.com PO Box 12367, Thorndon, Wellington, New Zealand 6144 m. +64 21 0537 847

1 0

stage-marc-import.pl behaves erratically...
by dcook＠prosentient.com.au 28 Oct '20

28 Oct '20

Hi all, On a pure CGI Koha, it's taking about 30 seconds to get stage-marc-import.pl to complete its AJAX call to stage-marc-import.pl for 34,000 records. After that, sometimes it polls background-job-process.pl and sometimes it doesn't. Sometimes it starts up after 60% of the job progress is done. Actually, the one time where it has started at the beginning, it seems to have a wildly incorrect progress meter. Almost like it's fetching the wrong job. On a Plack Koha that does not proxy stage-marc-import.pl, I get a 502 error after the stage-marc-import.pl doesn't return for 5 minutes. Looking at Bugzilla, it seems like people have had mixed experiences with this script. (https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20342) However, my experiences might be a bit different, and just add to the mixed bag. While I like the idea of using RabbitMQ for this one, I really want to get a fix out for stable branches. I'll keep investigating (another day). David Cook Software Engineer Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595

1 0

Re: [Koha-devel] [Koha] Koha 20.05.05 released
by Tomas Cohen Arazi 28 Oct '20

28 Oct '20

That's awesome, Lucas! On Tue, Oct 27, 2020, 19:52 Lucas Gass <lucas(a)bywatersolutions.com> wrote: > Hello everyone! > > The Koha community is proud to announce the release of Koha 20.05.05. > > Koha 20.05.05 is a security release including 2 security fixes, 30 > enhancements, and 31 bugfixes. > > The full release notes are available here: > https://koha-community.org/koha-20-05-05-release/ > <https://koha-community.org/koha-20-05-04-released/> > > Debian packages are ready and can be downloaded here: > https://download.koha-community.org/ > > > -- > Lucas Gass > Web Developer > _______________________________________________ > > Koha mailing list http://koha-community.org > Koha(a)lists.katipo.co.nz > Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha >

1 0

Ubuntu 18.04 + Shibboleth SP
by dcook＠prosentient.com.au 26 Oct '20

26 Oct '20

Hi all, Is anyone using Shibboleth SP and Ubuntu 18.04? It's looking to me like it's impossible to install Shibboleth SP due to the issues documented at https://launchpad.net/ubuntu/+source/shibboleth-sp2/+bugs. I take it most people are using (older versions of) Debian? David Cook Software Engineer Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595

1 0

New version of Zebra released
by dcook＠prosentient.com.au 23 Oct '20

23 Oct '20

Hi all, As the English idiom goes, the squeaky wheel gets the oil. After I raised an issue on GitHub, IndexData have released a new version of Zebra, and added packages for Debian Buster and Ubuntu Focal, so folk using Koha on Debian Buster no longer have to use the 2.0.59 version (with the ICU bugs) from the Debian repositories. David Cook Software Engineer Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595

2 1

Time to translate: string freeze to prepare Koha 19.05.16 has begun
by Victor Grousset/tuxayo 21 Oct '20

21 Oct '20

Hi, saluton, hola, bonjour, String freeze will be into effect today the 21th of October for the 19.05.x maintenance branch. The 19.05.16 release is scheduled for the 27th of October. 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.05, then you must also copy it to 19.11 and 20.05. Otherwise your work will be lost for future versions. Happy translating, -- Victor Grousset/tuxayo

1 0

String freeze for 19.11.x
by Aleisha Amohia 19 Oct '20

19 Oct '20

Hi all, String freeze will go into effect end of on Tuesday 20 October 2020 for the 19.11.x maintenance branch. 19.11.11 release scheduled for Tuesday 27 October 2020. Thanks -- Aleisha Amohia (she/her) Koha Developer Catalyst IT - Expert Open Source Solutions www.catalyst.net.nz

1 0

Inconsistent Perl shebangs (new coding guideline?)
by dcook＠prosentient.com.au 16 Oct '20

16 Oct '20

Hi all, I was looking at "Bug 20582 - Turn Koha into a Mojolicious application" when I noticed that some of the scripts were using "#!/usr/bin/env perl" instead of "#!/usr/bin/perl". While there is no requirement in the Coding Guidelines to use "#!/usr/bin/perl", I thought it would be best for all our Perl scripts to be consistent. However, now I'm weighing up the options. Conceptually, using "#!/usr/bin/env perl" means that we can use perlbrew/plenv (or manually provide a different Perl in our $PATH) when running these scripts, so that we don't have to use the system Perl located at /usr/bin/perl. That said, I was concerned about how most CGI scripts have "#!/usr/bin/perl" in them and the implications that might have if we invoked Starman/Morbo/Hypnotoad with a different Perl, but looking at Plack::App::CGIBin, CGI::Emulate::PSGI, Plack::App::WrapCGI, CGI::Compile, and Koha::App::Plugin::CGIBinKoha makes me think that the shebang in CGI scripts is ignored when using these Perl application servers, since they're just read as Perl code and not handed to the exec() family of kernel syscalls. Starman/Morbo/Hypnotoad have been installed with /usr/bin/perl shebangs, so they'll use the system Perl by default, but I think if they were installed using plenv and Carton for instance that they'd have their shebangs rewritten appropriately. We could also invoke Starman/Morbo/Hypnotoad with the version of Perl that we desire. So ultimately. I suppose the most reasonable thing to do is probably to mandate "#!/usr/bin/perl" for all Koha Perl scripts? If someone does want to use a different Perl, I suppose the onus is on them to make sure they execute Koha Perl scripts with a different Perl binary? Also, do people think there is a point in repairing existing Koha Perl scripts that have '#!/usr/bin/env perl' instead of '#!/usr/bin/perl'? Cheers, David Cook Software Engineer Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595

7 9

Koha metapackage for easier installs
by dcook＠prosentient.com.au 16 Oct '20

16 Oct '20

Hi all, As we add external dependencies to Koha (e.g. MariaDB, Elasticsearch, RabbitMQ, etc), there are fears that we are making Koha harder to install for less technical users. As a result, Jonathan, Tomas, Martin, Mason, and I have been discussing* creating a Koha metapackage that incudes all of Koha's external dependencies, so that people can keep installing Koha with a minimum number of steps. I think we're at a point where we now need to decide on some names for metapackages. Mason has already commented that it would be best to leave the current "koha" and "koha-common" packages as they are and I think that makes sense. While no one uses the "koha" package, I think there is still a dream of one day getting Koha into the upstream Debian repositories with that package name. Likewise, "koha-common" is so common that we had best not change it any time soon. Here are some naming options that have been discussed: 1. Option 1 a. koha-lite (this metapackage installs koha-common) b. koha-full (this metapackage installs koha-common, MariaDB, Elasticsearch, RabbitMQ, etc) 2. Option 2 a. koha-full (this metapackage installs koha-common, MariaDB, Elasticsearch, RabbitMQ, etc) 3. Option 3 a. koha-standalone (this metapackage installs koha-common, MariaDB, Elasticsearch, RabbitMQ, etc) 4. Option 4 (David's Preferred Option) a. koha-core (this metapackage installs koha-common) i. I would avoid "koha-lite" as it implies a little application whereas Koha is a large application ii. I think that koha-common is currently misnamed as it really is more of a "core" package than a "common" package that is shared among different packages or standalone applications (like postgresql-common being shared between client and server). However, koha-common has legacy value as a name. iii. In time, I'd like to see services like the SIP server, Z3950 responder, etc broken out of "koha-core" and put into their own packages. Eventually "koha-common" would just contain a set of core libraries that are shared amongst different Koha services. This would help with scalability, especially when using containers and other forms of modern computing. b. koha-full (this metapackage installs koha-common, MariaDB, Elasticsearch, RabbitMQ, etc) i. I would avoid "koha-standalone" as I think that it implies a package without dependencies, whereas ours would have several dependencies and be more in line with "koha-full". This is based on some searches through Debian repos: 1. https://packages.debian.org/search?suite=default <https://packages.debian.org/search?suite=default&section=all&arch=any&searc hon=names&keywords=-standalone> &section=all&arch=any&searchon=names&keywords=-standalone 2. https://packages.debian.org/search?searchon=names <https://packages.debian.org/search?searchon=names&keywords=-full> &keywords=-full ii. In Debian, there is a nginx-full package which installs many components (e.g. nginx-common, libnginx-mod-http-auth-pam, etc) and there is a nginx-core package which installs nginx-common and a small subset of libnginx-* packages I ask that people comment here on the listserv, and ultimately we can conclude that discussion in Bugzilla at https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26672. Cheers! *based on my comment at https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22417#c266 David Cook Software Engineer Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595

6 10