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

Koha versions 22.11.01, 22.05.08, 21.11.15 and 21.05.22 released
by Renvoize, Martin 11 Jan '23

11 Jan '23

The Koha community is proud to announce the latest releases of the current stable, oldstable, oldoldstable and lts versions of the software. This is a security and maintenance release on all branches, so please update at the earliest opportunity. As always, you can download the release from https://download.koha-community.org and the packages are already available now. This is the new development team at ptfs-europe's first release as the stable branch maintainers and we'd like to thank the community for this opportunity and the support we've received from the other branch maintainers already in getting up to speed. Thank you very much to everyone involved in this release. Release notes for respective branches are available online now at: * https://koha-community.org/koha-22-11-01-released/ * https://koha-community.org/koha-22-05-08-released/ * https://koha-community.org/koha-21-11-15-released/ * https://koha-community.org/koha-21-05-22-released/ Martin Renvoize, MPhys (Hons) Head of Development and Community Engagement E: martin.renvoize(a)ptfs-europe.com P: +44 (0) 1483 378728 M: +44 (0) 7725 985636 www.ptfs-europe.com

1 0

Re: [Koha-devel] libtest-dbix-class-perl not installable on Docker Debian Bullseye image...
by David Cook 11 Jan '23

11 Jan '23

Hi again, The problem was with the interaction of devscripts and libtest-dbix-class-perl. They have mutually incompatible dependencies. (Well, a devscript recommendation and a libtest-dbix-class-perl dependency.) I removed libtest-dbix-class-perl from my control file and now I'm fine. Should be OK without a test library. Doubt this will affect other people using the traditional "debian/build-git-snapshot" method or using pbuilder some other way. I use regular ol' debuild within a Docker container, so that's why devscripts is conflicting. David Cook Senior Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595 From: David Cook <dcook(a)prosentient.com.au> Sent: Wednesday, 11 January 2023 2:25 PM To: 'Koha-devel' <koha-devel(a)lists.koha-community.org> Cc: 'Mason James' <mtj(a)kohaaloha.com> Subject: libtest-dbix-class-perl not installable on Docker Debian Bullseye image... Hi all, I'm trying to build Debian packages for Koha 22.11 but keep having little hiccups. The last one is that libtest-dbix-class-perl is not installable on Docker's Debian Bullseye image. It looks like libtest-dbix-class-perl's dep libdbix-class-uuidcolumns-perl uses either libuuid-perl or libossp-uuid-perl, but libtest-dbix-class-perl requires libdata-uuid-perl which conflicts with libossp-uuid-perl. The Docker Debian Bullseye image seems to come with libossp-uuid-perl installed out of the box. The Koha Dashboard says 22.11 is building on D11 Bullseye, but I'm guessing that's using pbuilder with a very basic environment. I notice I have some Debian Bullseye systems with libossp-uuid-perl installed. They're not Koha systems, but I wonder if Koha 22.11 will be installable on Debian Bullseye without removing the incompatible package manually. -- sudo apt-get install -s libtest-dbix-class-perl Reading package lists... Done Building dependency tree... Done Reading state information... Done 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: libossp-uuid-perl : Conflicts: libdata-uuid-perl E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages. It looks like libtest-dbix-class-perl's libdata-uuid-perl dependency conflicts with libossp-uuid-perl The libdbix-class-uuidcolumns-perl package depends on either libuuid-perl or libossp-uuid-perl. David Cook Senior Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595

1 0

libtest-dbix-class-perl not installable on Docker Debian Bullseye image...
by David Cook 11 Jan '23

11 Jan '23

Hi all, I'm trying to build Debian packages for Koha 22.11 but keep having little hiccups. The last one is that libtest-dbix-class-perl is not installable on Docker's Debian Bullseye image. It looks like libtest-dbix-class-perl's dep libdbix-class-uuidcolumns-perl uses either libuuid-perl or libossp-uuid-perl, but libtest-dbix-class-perl requires libdata-uuid-perl which conflicts with libossp-uuid-perl. The Docker Debian Bullseye image seems to come with libossp-uuid-perl installed out of the box. The Koha Dashboard says 22.11 is building on D11 Bullseye, but I'm guessing that's using pbuilder with a very basic environment. I notice I have some Debian Bullseye systems with libossp-uuid-perl installed. They're not Koha systems, but I wonder if Koha 22.11 will be installable on Debian Bullseye without removing the incompatible package manually. -- sudo apt-get install -s libtest-dbix-class-perl Reading package lists... Done Building dependency tree... Done Reading state information... Done 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: libossp-uuid-perl : Conflicts: libdata-uuid-perl E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages. It looks like libtest-dbix-class-perl's libdata-uuid-perl dependency conflicts with libossp-uuid-perl The libdbix-class-uuidcolumns-perl package depends on either libuuid-perl or libossp-uuid-perl. David Cook Senior Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595

1 0

debian/control out of date in master
by David Cook 11 Jan '23

11 Jan '23

Hi all, It looks like debian/control is out of date in master. I know that we update it from debian/control.in using debian/update-control when the official packages are made, but why don't we run that as part of tagged releases? It seems to me like it would make sense to have a stable debian/control for each tagged released. In the process of trying to update debian/control in koha-testing-docker and it's a long process (due to the use of apt-file). What do folk think? David Cook Senior Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595

1 0

Volunteer needed to open the bidding for KohaCon24 & need confirmation of task list
by tuxayo 08 Jan '23

08 Jan '23

Hi :) The things to do are: - making the wikipage using the template - make an announcement email using past ones - send reminders - @all: anything else? The aim is to start the bid this month so proposals that start early 2024 have time to plan. And let the bid run until the next general meeting in april I can help with proofreading and finding past resources. Cheers, -- tuxayo

1 0

borrower_message_preference_id reaches limit - quickfix?
by Magnus Enger 05 Jan '23

05 Jan '23

Kia ora and happy new year, Koha! Yesterday I reported this bug: Bug 32556 - borrower_message_preference_id reaches limit https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32556 Has anyone else run into this, and found a quickfix that works? I tried dumping the database, changing the id columns from INT to BIGINT, but got a foreign key error when loading the database back in. I have tried to Google this problem, and several solutions suggest turning off foreign key checks temporarily. How risky would that be? Best regaqrds, Magnus Enger Libriotech AS

2 2

REST API should not advertise required permissions
by David Cook 04 Jan '23

04 Jan '23

Hi all, I just noticed the following error while testing the REST API: {"error":"Authorization failure. Missing required permission(s).","required_permissions":{"borrowers":"1"}} It seems to me that we should just stop at "Authorization failure". While it might be helpful for a dev to know what the required permissions are, I think it would also be overly helpful for an attacker to know what permissions are required too, no? I suppose Koha is open source, so it wouldn't be hard for them to look them up anyway, but it just seems odd? David Cook Senior Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595

3 2

Roadmap for v23.05
by Tomas Cohen Arazi 03 Jan '23

03 Jan '23

Hi all, last cycle we worked through a roadmap which was not 100% finished, but we made good progress in many of the main milestones: - Task queue streamlining (several improvements, progress bars, etc) - ERM (done) - Introduction of Vue (done) - Dates handling (partially done) - Circ, holds, biblios and items refactoring (partially done) - New staff interface (done) - API refinements (partially done) - Wiki migration (done) Now, it is time for us to build a new one ofr this cycle. Please fill with the things you plan to work on this cycle, and put your name so we all know and can help each other. https://annuel.framapad.org/p/Roadmap_for_Koha_v23.05 Thanks in advance! -- Tomás Cohen Arazi Theke Solutions (http://theke.io) ✆ +54 9351 3513384 GPG: B2F3C15F

2 1

Hackfest in Marseille
by Paul Poulain 02 Jan '23

02 Jan '23

<TL:DR>The hackfest will take place in March, 27th - 31th, drop me an email if you want to join Hello ladies and gentlemen, After 3 years of pandemic where everything was messy, the hackfest in Marseille is back ! Join us for coding/testing/translating/documenting/dreaming about the future of your preferred ILS, in Marseille, 108 rue Breteuil, 13006 Marseille. We'll start on monday, March, 27th, and end on Friday, March, 31th. * *How to register ?* Just drop me an email ! * *How much does it cost ?* Nothing. We just ask some fees for the lunch [special information: cheese lunch on Tuesday] * *What is the agenda ?* there's none, come with your ideas, your wish, your goodwill, and we'll do a lot of things in smaller or larger groups. * *5 days, wow, that's a lot !* yes, but as it's an "un-conference", you can come just for a part of the week. I suggest not less than 3 days, but no obligation here. * *I'm not a developer !* That's not a problem. MANY librarians come to the hackfest, they meet other librarians, they talk about Koha, they help testing, documenting, translating... There's always a lot of things to do Also note: it will be the very last hackfest in our current office, we'll move to another office in May (but don't worry, I plan to continue hackfesting in your new office) -- Paul Poulain, Associé-gérant / co-owner BibLibre, Services en logiciels libres pour les bibliothèques BibLibre, Open Source software and services for libraries

1 0

How best to support MARC21 880?
by David Cook 01 Jan '23

01 Jan '23

Hi all, The MARC21 880 field allows you to provide alternative graphical representations for pretty much any other MARC field. Typically, in Koha (and perhaps other library systems), we display these alternative graphical representations on the "detail page". You can see the roman script, the Arabic script, the Chinese script, etc. In Koha, we also show some data in the search results, and that's more problematic. because the search results should take up a limited amount of space on the screen, but hypothetically you can include many different scripts via the 880. I used to work in a government library in Canada where many of our bibliographic records contained quite a few different 880s. So it does happen. I have a library that has catalogued records using the roman alphabet (ie using Pinyin) and provided Chinese versions via the 880. They'd like to show both the romanized and Chinese versions throughout Koha (e.g. in the cart, checkout screens, course reserves, etc.) I've coded some of those customizations, since they only have 880s in Chinese, but I'm increasingly reluctant to make these changes. I don't want to carry these customizations locally, but I don't know that the Koha community would accept these changes. What do you all think about this? Should we include every 880 title and author in every screen? Should we maybe include them but hide them by default using CSS and then allow certain libraries to just show particular languages used by their patrons or by checking the current language? I know I can go faster on my own, but I rather go farther with all of you, so please let me know your thoughts : ) David Cook Senior Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595

2 1