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

Koha Community Newsletter: April 2018
by kohanews 02 May '18

02 May '18

Fellow Koha users: The Koha Community Newsletter for April 2018 is here: https://koha-community.org/koha-community-newsletter-april-2018/ 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. Thanks! -- Chad Roseburg Editor, Koha Community Newsletter

1 0

Koha on Ubuntu 18.04 LTS (Bionic Beaver)
by Giuseppe Angilella 01 May '18

01 May '18

Hi, I am trying to migrate my Koha installation from an Ubuntu 16.04 LTS "Xenial" [virtual] machine to a new machine, running Ubuntu 18.04 LTS "Bionic Beaver". Immediately after issuing the installation command: sudo apt-get install koha-common I get the error: Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: koha-common : Depends: libmarc-charset-perl but it is not installable Depends: libmarc-xml-perl but it is not installable Indeed, these two dependencies are not [yet] implemented for Ubuntu 18.04, as of https://packages.ubuntu.com . Any suggestion? Many thanks. Giuseppe.

2 1

For larger support companies
by Cab Vinton 26 Apr '18

26 Apr '18

Koha developers may be contrary enough that this wouldn't work, but still a fun idea: https://github.com/codedance/Retaliation Video here -- https://www.youtube.com/watch?v=1EGk2rvZe8A Many possible applications :-) Squirrel on your birdfeeder, child in the cookie jar, ... Cab Vinton Plaistow Public Library

5 4

Koha 17.05.11 release
by Fridolin SOMERS 26 Apr '18

26 Apr '18

The Koha community is proud to announce the release of Koha 17.05.11. This is a maintenance release. The full release notes are available at https://koha-community.org/koha-17-05-11-release/ Regards, -- Fridolin SOMERS <fridolin.somers(a)biblibre.com> BibLibre, France - software and system maintainer

1 0

Re: [Koha-devel] Official Docker image
by Benjamin Rokseth 24 Apr '18

24 Apr '18

>Hi everyone, on the CI front, I have recently introduced (successfully) the >broad use of Docker images to run the full test suite. This project, named >koha-testing-docker [1], evolved into a usable development environment too. >Right now I'm trying to spend some time on porting kohadevbox things into >it. Great news, Tomas! That will definitely ease development and sandboxing. Probably also migration to elasticsearch. > This Docker image is built and published automatically by our Jenkins > server, and then used in the three nodes we have to run the tests. > We also have a Docker image for building koha-* packages wherever we need > to (yes, we want to automate this, and properly test the generated packages > using the CI infrastructure). [2] Since you're already on gitlab, why not use it for CI instead? Then you could have all code in one place. Retire mr Jenkins, only thing we miss is the Chuck Norris plugin. >With this knowledge, and the infrastructure part of it solved, I would like >to start publishing an official Docker image of Koha. Once we have this, >the koha-testing-docker tools would be rebuilt on top of it. And it gets even better! Let us know if we can help Benjamin Rokseth Deichman Public Library

6 9

z39.50 server
by Johan Seyfferdt 23 Apr '18

23 Apr '18

Hello I am busy setting up a z39.50 server. After a lot of struggles the last couple of days, I was able to use it once successfully, and then I just rebooted the system, and then it didn't work anymore.... I am receiving this error message, help will be very appreciated! Johan Seyfferdt Connecting...OK. Sent initrequest. Connection rejected by v3 target. ID : 81 Name : GFS/YAZ Version: 4.2.30 98864b44c654645bc16b2c54f822dc2e45a93031 Init response contains 1 otherInfo unit: 1: otherInfo unit contains 1 diagnostic: 1: code=1 (Permanent system error), addinfo='' Options: search present triggerResourceCtrl namedResultSets Elapsed: 0.001400

1 0

Koha Core anyone?
by Benjamin Rokseth 20 Apr '18

20 Apr '18

Community hackers, on hackfest I got introvertly enthusiastic about the concept of a Koha Core, and about time I shared some thoughts. Background: Deichman (Oslo Public Library) is heavily leaning on bleeding edge Koha development (REST, Objects, Auth, NCIP and such) and, like at least some others, maintain a lot of local patches to tweak Koha into our users needs. Some are probably interesting to Community, others not. Now to keep everything in sync with Community would be amazing, but not likely to happen anytime soon. Great work has been done on refactoring Koha (new namespace, Koha Objects and REST api, etc.), but we'd like to suggest one more - a Koha core. The idea is simple: borrow from object oriented languages, java, or actually more ruby, since we're dealing with a dynamic language, use class/module inheritance and method overrides. Perl has the "use parent" concept which simplifies inheritance/subclassing and allows for nested overrides. As an example we refactored the current circulation in Koha, since this for us is the core functionality that we depend on and need to hook our local quirks on top of. An attempt to illustrate: +------------+ | Core::Main | +--^---------+ | +--+----------------+ | Core::Prefs | | Core::Exceptions | +-----------------------+ | Core::Circulation <-----+------+---| Deichman::Circulation | | ... | | | +---^-------------------+ +-------------------+ | | | | | | +------------------+------+ +--------------------------+ | Core::Circulation::SIP | |Deichman::Circulation::SIP| +------------------------------------------------------------+ | use parent qw( | Deichman::Circulation +----------------------+ Core::Circulation::SIP | Core::Circulation::UI| ) +----------------------+ | ~ * Core::Main is simply an empty class that act as a parent for any child, including Core::Circulation. * Core::Circulation has a constructor that takes koha objects item and library, optionally patron and sysprefs overrides. It can have accessors such as checkout, messages and other things needed for intra, SIP or whatever. It has methods Checkin, Checkout and Renew, amongst others. * then: Deichman::Circulation::SIP in this example is a local override that inherits from parents Deichman::Circulation and Core::Circulation::SIP now the beauty of this is that Deichman::Circulation::SIP can override anything (even the constructor) without touching any of the core code, and perl will traverse the inheritance tree until it finds the first matching constructor and method. Pros: - simpler, more readable and more reusable code. - local adaptations are easy to hande, and reusable for others - the slight overhead of using blessed objects and inheritance is easily gained by the fact that any operation will only need fetching Koha objects once (item,library,patron etc) instead of refetching them numerous times spread across methods calls and loops - way less db calls if done right, faster Koha - no more C4::Context, hopefully - systempreferences can be dramatically reduced, since most of them are about overrides anyways - can be done incrementally, replacing one functionality at a time cons: - refactoring doesnt make end users happy (but needs to be done in any case) - a bit of work to keep templates happy - requires a basic understanding of oop So to sum up: We already have a working example for circulation (though not in production) that we can demonstrate. It reimplements basically the entire C4::Circulation, just some small parts missing. So it can be done. But we'd love to hear second opinions from the community! We know the fear for breaking changes, but its neither scary or complicated to implement! Benjamin Rokseth Oslo Public Library

7 11

OAuth2 - client credentials fr 18.05
by Tomas Cohen Arazi 19 Apr '18

19 Apr '18

Hi, during the 18.05 release cycle a lot of progress has been made towards the goal of having a REST api. We voted the written and discussed RFC for the endpoints there was need to have [1] Some of them are already in master for 18.05, others are WIP. But the fact we have some roadmap of things we agreed on is a great milestone. Congrats! The missing piece for this (besides making the REST api grow faster) is having a standard way to authenticate external systems so they can interact with Koha in a healthy way. Take Coral as an example: it needs to be able to add biblios, add purchase orders, etc. Or custom user management systems to inject patrons or update their statuses, etc. We chose to implement the OAuth2 client credentials grant, which is a standard for this kind of use cases. Great work Julian! [2]. The patches have gone through the QA process, and we are almost done. We still have 2 days before the feature freeze to adjust things. So if you have an opinion (positive, negative but constructive, etc), please comment here or better in the related bugs. It is now, or after the release! Thanks! [1] https://wiki.koha-community.org/wiki/REST_api_RFCs [2] *https://bugs.koha-community.org/bugzilla3/showdependencygraph.cgi?id=20612 <https://bugs.koha-community.org/bugzilla3/showdependencygraph.cgi?id=20612>* -- Tomás Cohen Arazi Theke Solutions (https://theke.io <http://theke.io/>) ✆ +54 9351 3513384 GPG: B2F3C15F

3 2

Koha now requires Perl 5.20
by David Cook 19 Apr '18

19 Apr '18

Hi all, I just tried to work on Koha master on OpenSUSE 42.3, which was released on 2017-07-26, but I'm being prevented from installing Koha, because OpenSUSE 42.3 uses Perl 5.18.2 rather than Perl 5.20. I tracked the change back to https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20104. The claim was that C4::Log::cronlogaction uses caller and that caller doesn't exist before Perl 5.20, but that's not true. The caller function has been in Perl for an extremely long time. You can find it in RHEL 6.9 which uses Perl 5.10. I just used it in Perl 5.18.2. So that doesn't seem like a good justification for requiring a minimum version of Perl 5.20. I have a feeling that this change is going to bite other people developing and using Koha around the world. There are people running Koha on openSUSE, Suse Enterprise Linux, Fedora, Red Hat, CentOS. probably other distros as well. Are we really going to exclude everyone that doesn't use recent Debian-based distros from using newer versions of Koha? It seems to me that this decision was made without community discussion. Maybe I'm wrong, but I figured I'd bring it up with everyone. For my part, I'm just going to hack around this requirement for now, but I don't really like that as a long-term solution. What does everyone else think? David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595

5 12

Low hanging fruit: Removing un-needed use statements in C4 namespace
by Barton Chittenden 18 Apr '18

18 Apr '18

Just to see what happens, I enabled warnings in C4/Reserves.pm. All of the warnings were of the form Subroutine * redefined at C4/Reserves.pm line *. This is happening because of circular dependencies, e.g. C4/Reserves.pm uses C4::Members C4::Circulation Those modules in turn use C4::Reserves. None of the functions used in these modules is actually called in C4::Reserves, but removing the calls to use C4::Members and use C4::Circulation from C4/Reserves.pm isn't enough, apparently there's a deeper circular dependency there. I suspect that there are a number of unnecessary 'use' statements peppered throughout the C4 namespace; cleaning those up might fix the problem entirely, or at least allow us to resolve any remaining circular dependencies easily. --Barton

2 2