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

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

Does anyone use C4/SIP/t?
by dcook＠prosentient.com.au 15 Oct '20

15 Oct '20

Hi all, I just noticed C4/SIP/t/ in the Koha codebase. Does anyone actually use the test code there? Makefile.PL doesn't write it to the target, but still wondering if it's actually used. Looks like Makefile.PL has some old entries for "C4/SIP/koha_test" and "C4/tests" too, which we could just remove from Makefile.PL now. David Cook Software Engineer Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595

2 1

Can we remove the 'marc' column from auth_header?
by dcook＠prosentient.com.au 15 Oct '20

15 Oct '20

Hi all, Does anyone have any idea why we still have a 'marc' column in auth_header? David Cook Software Engineer Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595

2 2

Anyone know why C4/Barcodes/ValueBuilder.pm has a Perl shebang?
by dcook＠prosentient.com.au 14 Oct '20

14 Oct '20

Hi all, Anyone know why C4/Barcodes/ValueBuilder.pm has a Perl shebang? Is that due to some cataloguing plugin or something? Or is it just an error? Cheers, David Cook Software Engineer Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595

3 2

Scripts in C4/SIP directory
by dcook＠prosentient.com.au 14 Oct '20

14 Oct '20

Hi all, Is there any reason why we should have Perl (and Python) scripts in the C4/SIP of a deployed Koha? It seems to me like these are wrongly located? I'm also surprised to see C4/SIP/acstest.py. This looks like a legacy program anyway. David Cook Software Engineer Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595

1 0

Call for news: October 2020 Koha Newsletter
by Koha Newsletter 14 Oct '20

14 Oct '20

I'm collecting news for the October newsletter. Send anything noteworthy to: k o h a news AT gmail dot com News criteria: --------------------------- ** 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 T.B.A. are fine ...Eg., Kohacon - For past events , **** one month back is the cut-off ****. * News items can be of any length. * Images are fine * Anything and everything Koha. * Submit by the 26th of the month. 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! -- Chad Roseburg Editor, Koha Community Newsletter

1 0

Custom authority types cannot be used in automated authority linking
by dcook＠prosentient.com.au 13 Oct '20

13 Oct '20

Hi all, I just noticed that custom authority types cannot be used in automated authority linking. The details are at https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26662, but I reckon it's a fairly significant bug in Koha. You'll never encounter it if you don't create new authority types, but if you do use new authority types, link_bibs_to_authorities.pl will never work correctly and C4::Biblio::BiblioAutoLink will never work correctly. David Cook Software Engineer Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595

1 0

(no subject)
by Becky Bell 12 Oct '20

12 Oct '20

Unsubscribe

1 0