From ivan.dziuba at inlibro.com Tue Jun 1 17:30:13 2021 From: ivan.dziuba at inlibro.com (Ivan Dziuba) Date: Tue, 01 Jun 2021 11:30:13 -0400 Subject: [Koha-devel] Question about Koha Session Message-ID: <1499921622561342@mail.yandex.ru> An HTML attachment was scrubbed... URL: From philippe.blouin at inlibro.com Tue Jun 1 17:53:23 2021 From: philippe.blouin at inlibro.com (Philippe Blouin) Date: Tue, 1 Jun 2021 11:53:23 -0400 Subject: [Koha-devel] Question about Koha Session In-Reply-To: <1499921622561342@mail.yandex.ru> References: <1499921622561342@mail.yandex.ru> Message-ID: <5709e0ad-b2c5-dc87-96c9-23781c98f126@inlibro.com> Hello Koha, Actually, I'll extend Ivan's question a bit: is CGI::Session->load() the way to go, or C4::Auth::get_session() would do the same thing ? Thnaks Philippe Blouin, Directeur de la technologie Tél.  : (833) 465-4276, poste 230 philippe.blouin at inLibro.com inLibro | pour esprit libre | www.inLibro.com On 2021-06-01 11:30 a.m., Ivan Dziuba wrote: > Hello! > I develop one patch of Koha for Autocomplete - > https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27113 > In this patch I use a session. I don't want to create every time new > session and I have changed *CGI::Session->new()* > from*CGI::Session->load().* > But I don't sure in this condition *'CGI::Session->load() or die > CGI::Session->errstr();'* > Can I use (*DIE*) in this condition or not? > Thanks! > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : https://www.koha-community.org/ > git : https://git.koha-community.org/ > bugs : https://bugs.koha-community.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Wed Jun 2 05:56:55 2021 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Wed, 2 Jun 2021 13:56:55 +1000 Subject: [Koha-devel] Question about Koha Session In-Reply-To: <5709e0ad-b2c5-dc87-96c9-23781c98f126@inlibro.com> References: <1499921622561342@mail.yandex.ru> <5709e0ad-b2c5-dc87-96c9-23781c98f126@inlibro.com> Message-ID: <019501d75763$5467b320$fd371960$@prosentient.com.au> Glancing at https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27113, I don’t know why a person would need to use a session object. Happy for that to be explained. (Technically, it doesn’t look like it’s actually doing anything useful with CGI::Session, since it looks like it’s just throwing data into a file-backed session, and not even using it.) As for sessions more generally, Koha does not handle sessions very well. It’s a goal of mine to create a Koha::Session class at some point, but there are only so many hours in the day. When I work with sessions, I use C4::Auth::get_session($sessionID) where $sessionID is the value of the CGISESSID cookie. You will always have a CGISESSID *except* when you land on Koha for the very first time. But then when you’re on the landing page, you have access to the new session object directly anyway. I think Ivan might be on the wrong path here. Happy to discuss it further though. 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 On Behalf Of Philippe Blouin Sent: Wednesday, 2 June 2021 1:53 AM To: Ivan Dziuba ; koha-devel at lists.koha-community.org Subject: Re: [Koha-devel] Question about Koha Session Hello Koha, Actually, I'll extend Ivan's question a bit: is CGI::Session->load() the way to go, or C4::Auth::get_session() would do the same thing ? Thnaks Philippe Blouin, Directeur de la technologie Tél. : (833) 465-4276, poste 230 philippe.blouin at inLibro.com inLibro | pour esprit libre | www.inLibro.com On 2021-06-01 11:30 a.m., Ivan Dziuba wrote: Hello! I develop one patch of Koha for Autocomplete - https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27113 In this patch I use a session. I don't want to create every time new session and I have changed CGI::Session->new() from CGI::Session->load(). But I don't sure in this condition 'CGI::Session->load() or die CGI::Session->errstr();' Can I use (DIE) in this condition or not? Thanks! _______________________________________________ Koha-devel mailing list Koha-devel at lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : https://www.koha-community.org/ git : https://git.koha-community.org/ bugs : https://bugs.koha-community.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.druart at bugs.koha-community.org Thu Jun 3 15:07:00 2021 From: jonathan.druart at bugs.koha-community.org (Jonathan Druart) Date: Thu, 3 Jun 2021 15:07:00 +0200 Subject: [Koha-devel] Replacement of mailman (mailing lists) Message-ID: Hi devs, Should we keep the historical mailing list or move to something modern, like discourse or flarum? Is it something: - we really want/need - we don't want/need - neat we could have Currently the lists are not maintained (messages are not reviewed/no moderation), the mailman version is old, looks like there are a lot of email bounding, etc. Asking for koha-devel first. Cheers, Jonathan From katrin.fischer.83 at web.de Thu Jun 3 18:37:02 2021 From: katrin.fischer.83 at web.de (Katrin Fischer) Date: Thu, 3 Jun 2021 18:37:02 +0200 Subject: [Koha-devel] Replacement of mailman (mailing lists) In-Reply-To: References: Message-ID: <65f9dba6-2eee-2820-5ec6-33362a5926a7@web.de> Hi Jonathan, I haven't used any of the alternatives, so cannot tell what advantages they might bring. Maybe you or others can share their experiences? If we decide not to switch to another software, updating and naming moderators would certainly be a good thing. Katrin On 03.06.21 15:07, Jonathan Druart wrote: > Hi devs, > > Should we keep the historical mailing list or move to something > modern, like discourse or flarum? > Is it something: > - we really want/need > - we don't want/need > - neat we could have > > Currently the lists are not maintained (messages are not reviewed/no > moderation), the mailman version is old, looks like there are a lot of > email bounding, etc. > > Asking for koha-devel first. > > Cheers, > Jonathan > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : https://www.koha-community.org/ > git : https://git.koha-community.org/ > bugs : https://bugs.koha-community.org/ From joonas.kylmala at helsinki.fi Thu Jun 3 20:59:48 2021 From: joonas.kylmala at helsinki.fi (=?UTF-8?Q?Joonas_Kylm=c3=a4l=c3=a4?=) Date: Thu, 3 Jun 2021 21:59:48 +0300 Subject: [Koha-devel] Replacement of mailman (mailing lists) In-Reply-To: References: Message-ID: <0bdff4d2-92c3-c487-f2c3-a7d0b4d8230c@helsinki.fi> Hi, On 03/06/2021 16:07, Jonathan Druart wrote: > Should we keep the historical mailing list or move to something > modern, like discourse or flarum? > Is it something: > - we really want/need > - we don't want/need > - neat we could have I personally don't have a need for forum type of solution, and I actually prefer mailing lists so I can have all updates from all different projects at one inbox. > Currently the lists are not maintained (messages are not reviewed/no > moderation), the mailman version is old, looks like there are a lot of > email bounding, etc. Besides the emails bounding issue, the maintenance burden would be the same with forum software, right? Also, regarding this specific case of mailman being outdated, would it be possible to just enable unattended-upgrades (if debian based server) with automatic reboot to solve this? About email moderation, I have not noticed getting any spam through this mailing list. If the email is not accepted won't it bounce so if someone wants to send something (like a big file) they can contact via irc or other channels to say there is a problem. Joonas From mtj at kohaaloha.com Fri Jun 4 07:47:04 2021 From: mtj at kohaaloha.com (Mason James) Date: Fri, 4 Jun 2021 17:47:04 +1200 Subject: [Koha-devel] [Koha] Koha 21.05.00 released In-Reply-To: References: Message-ID: <16412f32-3451-b715-b7cf-712ea6dba98f@kohaaloha.com> kia ora community the packages are up 🎁 cheers, Mason On 29/05/21 1:02 am, Jonathan Druart wrote: > Hello everybody, > > It is with great pleasure that the Koha community announces the > release of Koha 21.05, a major release of the Koha open source > integrated library system. > > Read the full release notes here: > https://koha-community.org/koha-21-05-released/ > > The Debian packages for this new version will be available soon. Stay tuned! > > Cheers, > Jonathan > _______________________________________________ > > Koha mailing list http://koha-community.org > Koha at lists.katipo.co.nz > Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha From joonas.kylmala at helsinki.fi Fri Jun 4 12:36:11 2021 From: joonas.kylmala at helsinki.fi (=?UTF-8?Q?Joonas_Kylm=c3=a4l=c3=a4?=) Date: Fri, 4 Jun 2021 13:36:11 +0300 Subject: [Koha-devel] Follow-up patches and why not to use them Message-ID: Hi, I just bumped in another case of follow-up patch style causing us trouble. In bug https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28490 I had to spend considerable amount of time just reverting all the problematic patches and making sure I didn't miss any related patches, instead of just reverting one patch and knowing I would be good to go with that. Reverting this many patches also means a lot more review work yet again because you have no commit messages to reference to easily or if you want to use those you have to jump from patch to patch to find out what the change does. And this extra review work needs to be done by two people when reverting such follow-up patch series! If we instead asked the original author to fix the patches then this work would need to be done only ~once. The argument against this I have heard is that it makes the review work harder because you don't know what has changed since the previous version. I think however that is not very useful because the second reviewer doesn't benefit from this at all and makes their work harder and also the first reviewer even sometimes might review the revision after many days by which time they have forgotten already the context so basically they end up in the same situation as the second reviewer and have to jump between patches. Just my two cents, I hope we can stop doing follow-ups and instead have commits which contain one single change to decrease our time spent on review and make sure we don't miss any problems due to having to jump between so many contexts. Joonas From julian.maurice at biblibre.com Fri Jun 4 14:42:32 2021 From: julian.maurice at biblibre.com (Julian Maurice) Date: Fri, 4 Jun 2021 14:42:32 +0200 Subject: [Koha-devel] Follow-up patches and why not to use them In-Reply-To: References: Message-ID: Hi Joonas, Do you know you can revert multiple commits at once (ie. only one "revert commit" that revert a series of commits) ? Would that make it easier for cases like that ? And when trying to find all commits of a particular bug, git log --grep is your friend. Also, you can show a list of commits as a single diff. I have a git alias defined to "diff origin/HEAD..." which shows all differences on my local branch from the remote default branch (master). When you have a lot of patches, I agree that it is sometimes useful to see it as a single patch (that's why I have this git alias). But often it makes sense to have separate patches. By enforcing a "1 commit" rule we would lose the (often) logical separation of patches that makes review easier. That being said, there are other times where it would have made sense to just squash all commits together before pushing them to master. So I guess my opinion can be summarized at "it depends" :-) Le 04/06/2021 à 12:36, Joonas Kylmälä a écrit : > Hi, > > I just bumped in another case of follow-up patch style causing us > trouble. In bug > https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28490 I had to > spend considerable amount of time just reverting all the problematic > patches and making sure I didn't miss any related patches, instead of > just reverting one patch and knowing I would be good to go with that. > Reverting this many patches also means a lot more review work yet again > because you have no commit messages to reference to easily or if you > want to use those you have to jump from patch to patch to find out what > the change does. And this extra review work needs to be done by two > people when reverting such follow-up patch series! > > If we instead asked the original author to fix the patches then this > work would need to be done only ~once. The argument against this I have > heard is that it makes the review work harder because you don't know > what has changed since the previous version. I think however that is not > very useful because the second reviewer doesn't benefit from this at all > and makes their work harder and also the first reviewer even sometimes > might review the revision after many days by which time they have > forgotten already the context so basically they end up in the same > situation as the second reviewer and have to jump between patches. > > Just my two cents, I hope we can stop doing follow-ups and instead have > commits which contain one single change to decrease our time spent on > review and make sure we don't miss any problems due to having to jump > between so many contexts. > > Joonas > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : https://www.koha-community.org/ > git : https://git.koha-community.org/ > bugs : https://bugs.koha-community.org/ > -- Julian Maurice BibLibre From jonathan.druart at bugs.koha-community.org Fri Jun 4 16:03:03 2021 From: jonathan.druart at bugs.koha-community.org (Jonathan Druart) Date: Fri, 4 Jun 2021 16:03:03 +0200 Subject: [Koha-devel] Replacement of mailman (mailing lists) In-Reply-To: <0bdff4d2-92c3-c487-f2c3-a7d0b4d8230c@helsinki.fi> References: <0bdff4d2-92c3-c487-f2c3-a7d0b4d8230c@helsinki.fi> Message-ID: Le jeu. 3 juin 2021 à 20:59, Joonas Kylmälä a écrit : > > Hi, > > On 03/06/2021 16:07, Jonathan Druart wrote: > > Should we keep the historical mailing list or move to something > > modern, like discourse or flarum? > > Is it something: > > - we really want/need > > - we don't want/need > > - neat we could have > > I personally don't have a need for forum type of solution, and I > actually prefer mailing lists so I can have all updates from all > different projects at one inbox. I think that the two solutions I suggested can be used as a mailing list. > > Currently the lists are not maintained (messages are not reviewed/no > > moderation), the mailman version is old, looks like there are a lot of > > email bounding, etc. > > Besides the emails bounding issue, the maintenance burden would be the > same with forum software, right? Also, regarding this specific case of > mailman being outdated, would it be possible to just enable > unattended-upgrades (if debian based server) with automatic reboot to > solve this? The problem is that the upgrade from v2 to v3 is not trivial apparently. > About email moderation, I have not noticed getting any spam through this > mailing list. If the email is not accepted won't it bounce so if someone > wants to send something (like a big file) they can contact via irc or > other channels to say there is a problem. There is work that needs to be done on the server, upgrade + maintenance, and maybe reinstall/move of the server. For instance, on the server: "400 undelivered mail return to the sender", "The user you are trying to contact is receiving mail at a rate that 550-5.2.1 prevents additional messages from being delivered", etc. There are tons like that and it's not good for server's ip reputation. The question is: do we make the work to keep mailman, or do we consider it obsolete and we need something more modern? And I have no idea I will have time to dedicate to this task anyway, volunteers are welcome to help! From joonas.kylmala at helsinki.fi Mon Jun 7 06:26:19 2021 From: joonas.kylmala at helsinki.fi (=?UTF-8?Q?Joonas_Kylm=c3=a4l=c3=a4?=) Date: Mon, 7 Jun 2021 07:26:19 +0300 Subject: [Koha-devel] Follow-up patches and why not to use them In-Reply-To: References: Message-ID: <7965dba3-c0b1-1cba-457e-9508d0f39ac9@helsinki.fi> Hi, On 04/06/2021 15:42, Julian Maurice wrote: > Do you know you can revert multiple commits at once (ie. only one > "revert commit" that revert a series of commits) ? Would that make it > easier for cases like that ? > And when trying to find all commits of a particular bug, git log --grep > is your friend. Yup, however you still need to verify all the changes make sense on top of the new code base so that doesn't help. > By enforcing a "1 commit" rule we would lose the (often) logical > separation of patches that makes review easier. I didn't suggest 1 commit hard rule per bug. I'm after commits containing one logical change also. Joonas From dcook at prosentient.com.au Mon Jun 7 08:22:46 2021 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Mon, 7 Jun 2021 16:22:46 +1000 Subject: [Koha-devel] Increasing Debian Package Compatibility Levels Message-ID: <048b01d75b65$882c2d20$98848760$@prosentient.com.au> Hi all, I've been noticing lately some of the following warnings when I'm building Koha Debian packages: dh_install: Compatibility levels before 9 are deprecated (level 7 in use) dh_installdocs dh_installdocs: Compatibility levels before 9 are deprecated (level 7 in use) dh_installchangelogs dh_installchangelogs: Compatibility levels before 9 are deprecated (level 7 in use) dh_compress dh_fixperms dh_installdeb dh_installdeb: Compatibility levels before 9 are deprecated (level 7 in use) dh_gencontrol It seems to me that we should look at upping our compatibility level. We can see the changes between v7, 8, and 9 at https://manpages.debian.org/testing/debhelper/debhelper.7.en.html. At a glance, I think that we'd probably be OK moving up to 9 from 7. But we'd want to do some testing. 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: From dcook at prosentient.com.au Mon Jun 7 08:26:33 2021 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Mon, 7 Jun 2021 16:26:33 +1000 Subject: [Koha-devel] Increasing Debian Package Compatibility Levels Message-ID: <049001d75b66$0fa8c6f0$2efa54d0$@prosentient.com.au> Note that those warnings are from Debian Stretch. Since it's oldstable, it's probably still OK to be building on it. What OS do the Koha CI servers use? 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: dcook at prosentient.com.au Sent: Monday, 7 June 2021 4:23 PM To: 'koha-devel at lists.koha-community.org' Cc: 'Mason James' Subject: Increasing Debian Package Compatibility Levels Hi all, I've been noticing lately some of the following warnings when I'm building Koha Debian packages: dh_install: Compatibility levels before 9 are deprecated (level 7 in use) dh_installdocs dh_installdocs: Compatibility levels before 9 are deprecated (level 7 in use) dh_installchangelogs dh_installchangelogs: Compatibility levels before 9 are deprecated (level 7 in use) dh_compress dh_fixperms dh_installdeb dh_installdeb: Compatibility levels before 9 are deprecated (level 7 in use) dh_gencontrol It seems to me that we should look at upping our compatibility level. We can see the changes between v7, 8, and 9 at https://manpages.debian.org/testing/debhelper/debhelper.7.en.html. At a glance, I think that we'd probably be OK moving up to 9 from 7. But we'd want to do some testing. 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: From domm at plix.at Tue Jun 8 12:35:22 2021 From: domm at plix.at (Thomas Klausner) Date: Tue, 8 Jun 2021 12:35:22 +0200 Subject: [Koha-devel] The Perl and Raku Conference (In the Cloud) Message-ID: Hi! Today starts this years Perl and Raku Conference (still in the cloud, thanks to Corona): https://perlconference.us/tprc-2021-cloud/ As Koha is written in Perl, this event might interest a few of you. You can watch the live stream for free via YouTube, if you want to participate via Zoom and Slack you need to pay a 10$ fee. Here you can find the schedule (where you can also select your timezone): https://tprc2021cic.sched.com/ I'm doing a short talk on Koha on Thursday, but it's not going to be very technical. As a long time Perl dev I have only recently learned about Koha and it's big community, and want to introduce this project to the Perl community. Greetings, domm -- #!/usr/bin/perl https://domm.plix.at for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/} From bargioni at pusc.it Tue Jun 8 14:21:51 2021 From: bargioni at pusc.it (Stefano Bargioni) Date: Tue, 8 Jun 2021 14:21:51 +0200 Subject: [Koha-devel] Columns settings fails Message-ID: Hi, imho, Columns settings in circ/circulation.pl (while checking out) doesn't save columns chosen by the librarian. This behaviour is expected by my staff. Any opinion? Thx. Stefano From fridolin.somers at biblibre.com Thu Jun 10 13:46:02 2021 From: fridolin.somers at biblibre.com (Fridolin SOMERS) Date: Thu, 10 Jun 2021 13:46:02 +0200 Subject: [Koha-devel] The Perl and Raku Conference (In the Cloud) In-Reply-To: References: Message-ID: <454a84d8-7b1c-c746-2d90-06d2d7242683@biblibre.com> Whaou super. We at Koha are proud to be perl-geeks ;) Looking forward to have a feedback of that. Best regards, Le 08/06/2021 à 12:35, Thomas Klausner a écrit : > Hi! > > Today starts this years Perl and Raku Conference (still in the cloud, > thanks to Corona): > > https://perlconference.us/tprc-2021-cloud/ > > As Koha is written in Perl, this event might interest a few of you. You > can watch the live stream for free via YouTube, if you want to > participate via Zoom and Slack you need to pay a 10$ fee. > > Here you can find the schedule (where you can also select your > timezone): https://tprc2021cic.sched.com/ > > I'm doing a short talk on Koha on Thursday, but it's not going to be > very technical. As a long time Perl dev I have only recently learned > about Koha and it's big community, and want to introduce this project to > the Perl community. > > Greetings, > domm > -- Fridolin SOMERS Software and system maintainer 🦄 BibLibre, France From jonathan.druart at bugs.koha-community.org Fri Jun 11 13:47:18 2021 From: jonathan.druart at bugs.koha-community.org (Jonathan Druart) Date: Fri, 11 Jun 2021 13:47:18 +0200 Subject: [Koha-devel] Columns settings fails In-Reply-To: References: Message-ID: Hello Stefano, This idea has been discussed on bug 16881. It's also indirectly related to bug 27467. Cheers, Jonathan Le mar. 8 juin 2021 à 14:21, Stefano Bargioni a écrit : > > Hi, > imho, Columns settings in circ/circulation.pl (while checking out) doesn't save columns chosen by the librarian. > This behaviour is expected by my staff. > Any opinion? > Thx. Stefano > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : https://www.koha-community.org/ > git : https://git.koha-community.org/ > bugs : https://bugs.koha-community.org/ From jonathan.druart at bugs.koha-community.org Fri Jun 11 16:59:00 2021 From: jonathan.druart at bugs.koha-community.org (Jonathan Druart) Date: Fri, 11 Jun 2021 16:59:00 +0200 Subject: [Koha-devel] First big moves for 21.06 - early pushes Message-ID: Hi devs, I'd like to see us focus on those bugs, good candidates for early push: Bug 17600 - Standardize the EXPORT Bug 27526 - Remove Mod/AddItemFromMarc from additem.pl (first step, more work needed in this area) Bug 17427 - Replace CGI::Session with Data::Session Bug 25078 - Update DB process - wrap each DBRev inside a transaction and better error handling (need it soon to prevent unnecessary work later when lot of DBrevs will exist in 21.06) I am going to provide an updated version for the last one, the others are ready for testing. Hoping to see some help there :) Cheers, Jonathan From tomascohen at gmail.com Fri Jun 11 17:04:54 2021 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Fri, 11 Jun 2021 12:04:54 -0300 Subject: [Koha-devel] Notes about Docker Swarm / Portainer and Koha Message-ID: Hi all, for the 21.05 release, I proposed to launch the API docs site [1]. I did it on Theke's infrastructure for simplicity, but then started thinking how management could be handed to the community. This site is provided by a docker image [2] that is built on each change on the Koha community repository. This is triggered by webhooks. With the idea that this image should be deployed in production automatically, I deployed a Portainer service. Portainer would let us configure and deploy (dockerized) services in a fairly easy way, has an API, and also provides webhooks for triggering things like redeploying/updating (what I needed for api.koha-community.org). Right now this is running under Theke's umbrella, but my idea is to hand this to the community, especially those running the services we use. The short term plan would be to: 1. Have the following domains point to the server we are providing: - traefik.koha-community.org - portainer.koha-community.org - api.koha-community.org 2. Migrate Jenkins into this server/setup 3. Anyone running server for community purposes, can make them join this 'swarm' so we can use them. 4. There will be some community members with admin access to this, so we can all do maintenance tasks like restarting a service, etc. 5. Help is needed regarding backups and how we want to deal with that. We volunteer to help anyone running community sites migrate to this schema. [1] https://api.koha-community.org [2] https://gitlab.com/koha-community/koha-api-docs/-/pipelines/316321820 -- Tomás Cohen Arazi Theke Solutions (http://theke.io) ✆ +54 9351 3513384 GPG: B2F3C15F -------------- next part -------------- An HTML attachment was scrubbed... URL: From kohanews at gmail.com Sun Jun 13 07:41:31 2021 From: kohanews at gmail.com (Koha Newsletter) Date: Sun, 13 Jun 2021 07:41:31 +0200 Subject: [Koha-devel] Call for news - Newsletter June 2021 Message-ID: Hi I'm collecting news for the June 2021 Koha Community Newsletter. Please send anything noteworthy to: kohanews (at) gmail (dot) com News criteria: * News items can be of any length, they should be in plain text. * 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: From katrin.fischer.83 at web.de Sun Jun 13 22:19:06 2021 From: katrin.fischer.83 at web.de (Katrin Fischer) Date: Sun, 13 Jun 2021 22:19:06 +0200 Subject: [Koha-devel] Columns settings fails In-Reply-To: References: Message-ID: <99bc9ec6-6327-dfc4-a8b1-801d5c49925a@web.de> Hi Stefano, Jonathan had already replied, but maybe it got missed: Hello Stefano, This idea has been discussed on bug 16881. It's also indirectly related to bug 27467. Cheers, Jonathan To explain a bit more, at the moment the columns configuration can be set to a default via administration or for "the moment" on the pages, but the information is not kept. When you reload a page, the default column configuration will be shown. It's not stored per user or per session. Katrin On 08.06.21 14:21, Stefano Bargioni wrote: > Hi, > imho, Columns settings in circ/circulation.pl (while checking out) doesn't save columns chosen by the librarian. > This behaviour is expected by my staff. > Any opinion? > Thx. Stefano > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : https://www.koha-community.org/ > git : https://git.koha-community.org/ > bugs : https://bugs.koha-community.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Tue Jun 15 01:42:52 2021 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Tue, 15 Jun 2021 09:42:52 +1000 Subject: [Koha-devel] Notes about Docker Swarm / Portainer and Koha In-Reply-To: References: Message-ID: <00fd01d76176$fdd774f0$f9865ed0$@prosentient.com.au> Sounds like a plan to 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 From: Koha-devel On Behalf Of Tomas Cohen Arazi Sent: Saturday, 12 June 2021 1:05 AM To: koha-devel Subject: [Koha-devel] Notes about Docker Swarm / Portainer and Koha Hi all, for the 21.05 release, I proposed to launch the API docs site [1]. I did it on Theke's infrastructure for simplicity, but then started thinking how management could be handed to the community. This site is provided by a docker image [2] that is built on each change on the Koha community repository. This is triggered by webhooks. With the idea that this image should be deployed in production automatically, I deployed a Portainer service. Portainer would let us configure and deploy (dockerized) services in a fairly easy way, has an API, and also provides webhooks for triggering things like redeploying/updating (what I needed for api.koha-community.org ). Right now this is running under Theke's umbrella, but my idea is to hand this to the community, especially those running the services we use. The short term plan would be to: 1. Have the following domains point to the server we are providing: - traefik.koha-community.org - portainer.koha-community.org - api.koha-community.org 2. Migrate Jenkins into this server/setup 3. Anyone running server for community purposes, can make them join this 'swarm' so we can use them. 4. There will be some community members with admin access to this, so we can all do maintenance tasks like restarting a service, etc. 5. Help is needed regarding backups and how we want to deal with that. We volunteer to help anyone running community sites migrate to this schema. [1] https://api.koha-community.org [2] https://gitlab.com/koha-community/koha-api-docs/-/pipelines/316321820 -- Tomás Cohen Arazi Theke Solutions (http://theke.io ) ✆ +54 9351 3513384 GPG: B2F3C15F -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Tue Jun 15 01:47:22 2021 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Tue, 15 Jun 2021 09:47:22 +1000 Subject: [Koha-devel] Sharing installation method with Hea Message-ID: <010701d76177$9eeaa7e0$dcbff7a0$@prosentient.com.au> Hi all, I was looking at https://hea.koha-community.org/systempreferences to view the different versions of Koha out there, and it got me thinking how it would be nice to know how people install Koha. I imagine that we all think that the majority of people use the Debian packages, but it would be good to know. What do people think? 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: From victor at tuxayo.net Tue Jun 15 07:09:21 2021 From: victor at tuxayo.net (Victor Grousset/tuxayo) Date: Tue, 15 Jun 2021 07:09:21 +0200 Subject: [Koha-devel] Sharing installation method with Hea In-Reply-To: <010701d76177$9eeaa7e0$dcbff7a0$@prosentient.com.au> References: <010701d76177$9eeaa7e0$dcbff7a0$@prosentient.com.au> Message-ID: Hi :) On 21-06-15 01:47, dcook at prosentient.com.au wrote: > I was looking at https://hea.koha-community.org/systempreferences > to view the different > versions of Koha out there, and it got me thinking how it would be nice > to know how people install Koha. > > I imagine that we all think that the majority of people use the Debian > packages, but it would be good to know. > > What do people think? Does Koha already have data that would allow to deduce the install method? If not, how to infer that for Debian packages? For a git install, checking for a .git is enough. Cheers, -- Victor Grousset/tuxayo From dcook at prosentient.com.au Tue Jun 15 08:04:42 2021 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Tue, 15 Jun 2021 16:04:42 +1000 Subject: [Koha-devel] Sharing installation method with Hea In-Reply-To: References: <010701d76177$9eeaa7e0$dcbff7a0$@prosentient.com.au> Message-ID: <015001d761ac$55a6c160$00f44420$@prosentient.com.au> I was wondering if Koha already had that data, but I'm not so sure. I am thinking that "make install" would perhaps create a file containing the index method, and the Debian package build could overwrite that. 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 On Behalf Of Victor Grousset/tuxayo Sent: Tuesday, 15 June 2021 3:09 PM To: koha-devel at lists.koha-community.org Subject: Re: [Koha-devel] Sharing installation method with Hea Hi :) On 21-06-15 01:47, dcook at prosentient.com.au wrote: > I was looking at https://hea.koha-community.org/systempreferences > to view the > different versions of Koha out there, and it got me thinking how it > would be nice to know how people install Koha. > > I imagine that we all think that the majority of people use the Debian > packages, but it would be good to know. > > What do people think? Does Koha already have data that would allow to deduce the install method? If not, how to infer that for Debian packages? For a git install, checking for a .git is enough. Cheers, -- Victor Grousset/tuxayo _______________________________________________ Koha-devel mailing list Koha-devel at lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : https://www.koha-community.org/ git : https://git.koha-community.org/ bugs : https://bugs.koha-community.org/ From fridolin.somers at biblibre.com Tue Jun 15 10:19:12 2021 From: fridolin.somers at biblibre.com (Fridolin SOMERS) Date: Tue, 15 Jun 2021 10:19:12 +0200 Subject: [Koha-devel] Perl syntax for strings Message-ID: Hi, I see in Perl code some cases where a string in written with a space between q or qq or qw and string. Like : qq /foo bar/ instead of qq/foo bar/ It works, but I dont find it in docs like https://perldoc.perl.org/perlop#Quote-Like-Operators Most of cases are in : use CGI qw ( -utf8 ); There are only 29 other cases : git grep -E ' q[qw]? [/({]' | grep -v 'use CGI qw ' Should we add a coding guideline ? https://wiki.koha-community.org/wiki/Coding_Guidelines I must admint for me it would be better to avoid it because it breaks syntax coloring in my editor (Eclipse with EPIC). But maybe other have the same issue. Best regards, -- Fridolin SOMERS Software and system maintainer 🦄 BibLibre, France From domm at plix.at Tue Jun 15 10:48:19 2021 From: domm at plix.at (Thomas Klausner) Date: Tue, 15 Jun 2021 10:48:19 +0200 Subject: [Koha-devel] some thoughts on #28519 regarding lib Message-ID: Hi! without knowing a lot of Koha-internals (still..), I'd strongly prefer to have all the code in a lib dir (as is standard in Perl apps / modules for ages). There are also a lot of tools available to make using code stored `lib` (but not "installed" in the system, i.e. only available in the checkout) easy. The simplest is of course 'lib': https://perldoc.perl.org/lib Or more complex like https://metacpan.org/pod/lib::projectroot (which I wrote some time ago to handle a Monorepo setup; it also includes a comparison of different modules in the SEE ALSO section) OTOH, CGI::Session::Serialize is a cpan module, so technically it should not be checked out into the app code `lib`, but installed as a dependency. There are even more ways to handle installing of dependencies and the finding them, but the currently most comfortable one is https://metacpan.org/pod/Carton. Or (if running everything via Carton is too much of a change), a combination of https://metacpan.org/pod/local::lib and a modern CPAN client (https://metacpan.org/pod/App::cpanminus or https://metacpan.org/pod/App::cpm. I did not want to spam the actuall ticket with this, as I'm not sure if any of this is in fact relevant to the bug, and/or matches the current plans for Koha. Greetings, domm -- #!/usr/bin/perl https://domm.plix.at for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/} From domm at plix.at Tue Jun 15 11:00:38 2021 From: domm at plix.at (Thomas Klausner) Date: Tue, 15 Jun 2021 11:00:38 +0200 Subject: [Koha-devel] Perl syntax for strings In-Reply-To: References: Message-ID: Hi! On Tue, Jun 15, 2021 at 10:19:12AM +0200, Fridolin SOMERS wrote: > I see in Perl code some cases where a string in written with a space between > q or qq or qw and string. > Like : qq /foo bar/ instead of qq/foo bar/ While this works, it is strongly recommended to not use this "feature". It's main "use" is to use ANY string as quote-like operator: perl -E 'say qq A({/";A' ({/"; But of course this is horrible and should not be used (outside of obfuscations..) > Most of cases are in : > use CGI qw ( -utf8 ); This isn't even using the "feature" to allow any string.. > There are only 29 other cases : > git grep -E ' q[qw]? [/({]' | grep -v 'use CGI qw ' Of course this regex would fail to find why the space after q/qq/qw is allowed, because using the space you can use ANY char for the quote-like op. But I'm quite sure that nobody is crazy enough to put that into production code. And coming up with a regex that matches this would be quite hard... Though maybe there is a Perl::Critic rule for it? > Should we add a coding guideline ? > https://wiki.koha-community.org/wiki/Coding_Guidelines ++ Greetings, domm -- #!/usr/bin/perl https://domm.plix.at for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/} From jonathan.druart at bugs.koha-community.org Tue Jun 15 11:26:18 2021 From: jonathan.druart at bugs.koha-community.org (Jonathan Druart) Date: Tue, 15 Jun 2021 11:26:18 +0200 Subject: [Koha-devel] some thoughts on #28519 regarding lib In-Reply-To: References: Message-ID: Hi Thomas, I've sent the following notes to the QA team, but maybe it needed to be public. The history behind 28519 is not trivial :) """ To clarify and explain a bit more what we are doing here (to those outside of the loop): - We switched from YAML[::Syck] to YAML::XS (22824, 27673) - We had to replace the YAML serializer provided by CGI::Session (no YAML::XS serializer exists in cpan). - We decided to switch back to the default serializer (using Data::Dumper), which we used a looong time ago in Koha already, but faced... encoding problems. However we couldn't replicate them and thought we were safe (28317). - 21.05.00 is released and we discover a bug (28489), there is an encoding issue caused by Data::Dumper (and more precisely its C implementation, see bug 28489 comment 13 for more info). To add to the confusion: the bug appears only if strict_sql_modes is on. - We need a fix for 21.05.01! - There are several options we investigate on Friday, lot seems to be working but few really work: * $Data::Dumper::Useperl=1 (maybe) * Reintroduce YAML::Syck and get back to CGI::Session::Serializer::YAML * Use our own YAML::XS serializer (which has been suggested when we moved to Data::Dumper already) We decided to go with the latter and Andrew wrote a patch. A bit hacky as the Serializer::yamlxs code was inside C4::Auth. David wrote a follow-up (28519) to clean it and move the code to a separate file. What's next? - We need 28489 for 21.05.01 - Ideally we need 28519 as well! - We should move to Data::Session and decide on the JSON serializer or write our YAML::XS serializer for Data::Session (17427) """ We actually need CGI::Session::Serializer::yamlxs, not CGI::Session (we are still installing it from the debian package). Hope that clarifies Cheers, Jonathan Le mar. 15 juin 2021 à 10:48, Thomas Klausner a écrit : > > Hi! > > without knowing a lot of Koha-internals (still..), I'd strongly prefer > to have all the code in a lib dir (as is standard in Perl apps / modules > for ages). > > There are also a lot of tools available to make using code stored `lib` > (but not "installed" in the system, i.e. only available in the checkout) > easy. The simplest is of course 'lib': https://perldoc.perl.org/lib > > Or more complex like https://metacpan.org/pod/lib::projectroot (which I > wrote some time ago to handle a Monorepo setup; it also includes a > comparison of different modules in the SEE ALSO section) > > OTOH, CGI::Session::Serialize is a cpan module, so technically it should > not be checked out into the app code `lib`, but installed as a > dependency. There are even more ways to handle installing of > dependencies and the finding them, but the currently most comfortable > one is https://metacpan.org/pod/Carton. Or (if running everything via > Carton is too much of a change), a combination of > https://metacpan.org/pod/local::lib and a modern CPAN client > (https://metacpan.org/pod/App::cpanminus or > https://metacpan.org/pod/App::cpm. > > I did not want to spam the actuall ticket with this, as I'm not sure if > any of this is in fact relevant to the bug, and/or matches the current > plans for Koha. > > Greetings, > domm > > > -- > #!/usr/bin/perl https://domm.plix.at > for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/} > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : https://www.koha-community.org/ > git : https://git.koha-community.org/ > bugs : https://bugs.koha-community.org/ From dcook at prosentient.com.au Wed Jun 16 05:42:08 2021 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Wed, 16 Jun 2021 13:42:08 +1000 Subject: [Koha-devel] some thoughts on #28519 regarding lib In-Reply-To: References: Message-ID: <01df01d76261$955eb280$c01c1780$@prosentient.com.au> Ditto what Jonathan said. CGI::Session::Serializer::yamlxs is 100% a Koha module at this point. Doesn't exist on CPAN. In this case, I created #28519 to make it easier to use additional namespaces beyond C4 and Koha (and historically OpenILS) without having to update Makefile.PL. Of course, I had to update Makefile.PL for #28519, but I was trying to future-proof us a bit, and trying to provide a way for us to hopefully one day transition all the Perl modules into "./lib", so that we could get the benefits you described, Thomas. 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 On Behalf Of Jonathan Druart Sent: Tuesday, 15 June 2021 7:26 PM To: koha-devel Subject: Re: [Koha-devel] some thoughts on #28519 regarding lib Hi Thomas, I've sent the following notes to the QA team, but maybe it needed to be public. The history behind 28519 is not trivial :) """ To clarify and explain a bit more what we are doing here (to those outside of the loop): - We switched from YAML[::Syck] to YAML::XS (22824, 27673) - We had to replace the YAML serializer provided by CGI::Session (no YAML::XS serializer exists in cpan). - We decided to switch back to the default serializer (using Data::Dumper), which we used a looong time ago in Koha already, but faced... encoding problems. However we couldn't replicate them and thought we were safe (28317). - 21.05.00 is released and we discover a bug (28489), there is an encoding issue caused by Data::Dumper (and more precisely its C implementation, see bug 28489 comment 13 for more info). To add to the confusion: the bug appears only if strict_sql_modes is on. - We need a fix for 21.05.01! - There are several options we investigate on Friday, lot seems to be working but few really work: * $Data::Dumper::Useperl=1 (maybe) * Reintroduce YAML::Syck and get back to CGI::Session::Serializer::YAML * Use our own YAML::XS serializer (which has been suggested when we moved to Data::Dumper already) We decided to go with the latter and Andrew wrote a patch. A bit hacky as the Serializer::yamlxs code was inside C4::Auth. David wrote a follow-up (28519) to clean it and move the code to a separate file. What's next? - We need 28489 for 21.05.01 - Ideally we need 28519 as well! - We should move to Data::Session and decide on the JSON serializer or write our YAML::XS serializer for Data::Session (17427) """ We actually need CGI::Session::Serializer::yamlxs, not CGI::Session (we are still installing it from the debian package). Hope that clarifies Cheers, Jonathan Le mar. 15 juin 2021 à 10:48, Thomas Klausner a écrit : > > Hi! > > without knowing a lot of Koha-internals (still..), I'd strongly prefer > to have all the code in a lib dir (as is standard in Perl apps / > modules for ages). > > There are also a lot of tools available to make using code stored > `lib` (but not "installed" in the system, i.e. only available in the > checkout) easy. The simplest is of course 'lib': > https://perldoc.perl.org/lib > > Or more complex like https://metacpan.org/pod/lib::projectroot (which > I wrote some time ago to handle a Monorepo setup; it also includes a > comparison of different modules in the SEE ALSO section) > > OTOH, CGI::Session::Serialize is a cpan module, so technically it > should not be checked out into the app code `lib`, but installed as a > dependency. There are even more ways to handle installing of > dependencies and the finding them, but the currently most comfortable > one is https://metacpan.org/pod/Carton. Or (if running everything via > Carton is too much of a change), a combination of > https://metacpan.org/pod/local::lib and a modern CPAN client > (https://metacpan.org/pod/App::cpanminus or > https://metacpan.org/pod/App::cpm. > > I did not want to spam the actuall ticket with this, as I'm not sure > if any of this is in fact relevant to the bug, and/or matches the > current plans for Koha. > > Greetings, > domm > > > -- > #!/usr/bin/perl https://domm.plix.at > for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/} > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : https://www.koha-community.org/ git : > https://git.koha-community.org/ bugs : > https://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 : https://www.koha-community.org/ git : https://git.koha-community.org/ bugs : https://bugs.koha-community.org/ From dcook at prosentient.com.au Wed Jun 16 06:58:36 2021 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Wed, 16 Jun 2021 14:58:36 +1000 Subject: [Koha-devel] some thoughts on #28519 regarding lib In-Reply-To: <01df01d76261$955eb280$c01c1780$@prosentient.com.au> References: <01df01d76261$955eb280$c01c1780$@prosentient.com.au> Message-ID: <01ea01d7626c$43b9f790$cb2de6b0$@prosentient.com.au> Speaking of benefits, I have a different Perl project I support and develop, and it stores all its Perl modules in a "./lib" directory, and I'm able to easily run my app from a git checkout or a package deployment. The only difference is path configuration. Also, while I have provided dependencies via RPM packaging historically, in the not too distant future, I'll be moving to using carton for providing the dependencies from CPAN. In that case, I only store cpanfile and cpanfile.snapshot in my git. Then, in my dev environment, I use cpanfile.snapshot to install the dependencies into carton's default "./local/lib/perl5". When I do my RPM packaging, I do a "git archive" to create my source code bundle, I use tar to bundle "./local" into ".tar.gz", and then I create 1 package from both those tarballs (although I could easily build separate app.rpm and app-deps.rpm packages). Developing, testing, and deploying is so fast and easy. Anyway, baby steps for Koha. Even if we never move away from Debian package dependencies, I think the "./lib" directory is invaluable for allowing us to easily work with multiple Perl module namespaces. 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 On Behalf Of dcook at prosentient.com.au Sent: Wednesday, 16 June 2021 1:42 PM To: 'Jonathan Druart' ; 'koha-devel' Subject: Re: [Koha-devel] some thoughts on #28519 regarding lib Ditto what Jonathan said. CGI::Session::Serializer::yamlxs is 100% a Koha module at this point. Doesn't exist on CPAN. In this case, I created #28519 to make it easier to use additional namespaces beyond C4 and Koha (and historically OpenILS) without having to update Makefile.PL. Of course, I had to update Makefile.PL for #28519, but I was trying to future-proof us a bit, and trying to provide a way for us to hopefully one day transition all the Perl modules into "./lib", so that we could get the benefits you described, Thomas. 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 On Behalf Of Jonathan Druart Sent: Tuesday, 15 June 2021 7:26 PM To: koha-devel Subject: Re: [Koha-devel] some thoughts on #28519 regarding lib Hi Thomas, I've sent the following notes to the QA team, but maybe it needed to be public. The history behind 28519 is not trivial :) """ To clarify and explain a bit more what we are doing here (to those outside of the loop): - We switched from YAML[::Syck] to YAML::XS (22824, 27673) - We had to replace the YAML serializer provided by CGI::Session (no YAML::XS serializer exists in cpan). - We decided to switch back to the default serializer (using Data::Dumper), which we used a looong time ago in Koha already, but faced... encoding problems. However we couldn't replicate them and thought we were safe (28317). - 21.05.00 is released and we discover a bug (28489), there is an encoding issue caused by Data::Dumper (and more precisely its C implementation, see bug 28489 comment 13 for more info). To add to the confusion: the bug appears only if strict_sql_modes is on. - We need a fix for 21.05.01! - There are several options we investigate on Friday, lot seems to be working but few really work: * $Data::Dumper::Useperl=1 (maybe) * Reintroduce YAML::Syck and get back to CGI::Session::Serializer::YAML * Use our own YAML::XS serializer (which has been suggested when we moved to Data::Dumper already) We decided to go with the latter and Andrew wrote a patch. A bit hacky as the Serializer::yamlxs code was inside C4::Auth. David wrote a follow-up (28519) to clean it and move the code to a separate file. What's next? - We need 28489 for 21.05.01 - Ideally we need 28519 as well! - We should move to Data::Session and decide on the JSON serializer or write our YAML::XS serializer for Data::Session (17427) """ We actually need CGI::Session::Serializer::yamlxs, not CGI::Session (we are still installing it from the debian package). Hope that clarifies Cheers, Jonathan Le mar. 15 juin 2021 à 10:48, Thomas Klausner a écrit : > > Hi! > > without knowing a lot of Koha-internals (still..), I'd strongly prefer > to have all the code in a lib dir (as is standard in Perl apps / > modules for ages). > > There are also a lot of tools available to make using code stored > `lib` (but not "installed" in the system, i.e. only available in the > checkout) easy. The simplest is of course 'lib': > https://perldoc.perl.org/lib > > Or more complex like https://metacpan.org/pod/lib::projectroot (which > I wrote some time ago to handle a Monorepo setup; it also includes a > comparison of different modules in the SEE ALSO section) > > OTOH, CGI::Session::Serialize is a cpan module, so technically it > should not be checked out into the app code `lib`, but installed as a > dependency. There are even more ways to handle installing of > dependencies and the finding them, but the currently most comfortable > one is https://metacpan.org/pod/Carton. Or (if running everything via > Carton is too much of a change), a combination of > https://metacpan.org/pod/local::lib and a modern CPAN client > (https://metacpan.org/pod/App::cpanminus or > https://metacpan.org/pod/App::cpm. > > I did not want to spam the actuall ticket with this, as I'm not sure > if any of this is in fact relevant to the bug, and/or matches the > current plans for Koha. > > Greetings, > domm > > > -- > #!/usr/bin/perl https://domm.plix.at > for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/} > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : https://www.koha-community.org/ git : > https://git.koha-community.org/ bugs : > https://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 : https://www.koha-community.org/ git : https://git.koha-community.org/ bugs : https://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 : https://www.koha-community.org/ git : https://git.koha-community.org/ bugs : https://bugs.koha-community.org/ From fridolin.somers at biblibre.com Wed Jun 16 17:17:52 2021 From: fridolin.somers at biblibre.com (Fridolin SOMERS) Date: Wed, 16 Jun 2021 17:17:52 +0200 Subject: [Koha-devel] Perl syntax for strings In-Reply-To: References: Message-ID: OK so proposing to remove this space makes sens, great ;) Also looks like Perl::Tidy does not remove the space. Le 15/06/2021 à 11:00, Thomas Klausner a écrit : > Hi! > > On Tue, Jun 15, 2021 at 10:19:12AM +0200, Fridolin SOMERS wrote: > >> I see in Perl code some cases where a string in written with a space between >> q or qq or qw and string. >> Like : qq /foo bar/ instead of qq/foo bar/ > > While this works, it is strongly recommended to not use this "feature". > It's main "use" is to use ANY string as quote-like operator: > > perl -E 'say qq A({/";A' > ({/"; > > But of course this is horrible and should not be used (outside of > obfuscations..) > >> Most of cases are in : >> use CGI qw ( -utf8 ); > > This isn't even using the "feature" to allow any string.. > >> There are only 29 other cases : >> git grep -E ' q[qw]? [/({]' | grep -v 'use CGI qw ' > > Of course this regex would fail to find why the space after q/qq/qw is > allowed, because using the space you can use ANY char for the quote-like > op. But I'm quite sure that nobody is crazy enough to put that into > production code. And coming up with a regex that matches this would be > quite hard... Though maybe there is a Perl::Critic rule for it? > >> Should we add a coding guideline ? >> https://wiki.koha-community.org/wiki/Coding_Guidelines > > ++ > > Greetings, > domm > -- Fridolin SOMERS Software and system maintainer 🦄 BibLibre, France From victor at tuxayo.net Thu Jun 17 00:14:11 2021 From: victor at tuxayo.net (Victor Grousset/tuxayo) Date: Thu, 17 Jun 2021 00:14:11 +0200 Subject: [Koha-devel] Time to translate: string freeze to prepare Koha 20.05.13 has begun Message-ID: Hi, saluton, hola, bonjour, String freeze is into effect as of now for the 20.05.x maintenance branch. The minor release is scheduled for around the 22th. This means it's the right time to head over to the translation platform: https://translate.koha-community.org/projects/ Reminder: if you add or change a translation in version 20.05, then you must also copy it to 20.11 and 21.05. Otherwise your work will be lost for future versions. (We've had a recent significant case of that!) Happy translating, -- Victor Grousset/tuxayo From rooy.de.m at gmail.com Fri Jun 18 08:36:11 2021 From: rooy.de.m at gmail.com (Marcel de Rooy) Date: Fri, 18 Jun 2021 08:36:11 +0200 Subject: [Koha-devel] pqf.properties / Zebra / Z3950 Message-ID: Hi all, Looking at bug 8280. I am wondering why we should have two pqf.properties files. They are already not exactly the same. Could we let the new daemon use the pqf file from the Zebra folder ? Marcel -------------- next part -------------- An HTML attachment was scrubbed... URL: From M.de.Rooy at rijksmuseum.nl Fri Jun 18 08:45:33 2021 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Fri, 18 Jun 2021 06:45:33 +0000 Subject: [Koha-devel] Follow-up patches and why not to use them In-Reply-To: References: Message-ID: Agree with Julian here. It depends. You could squash follow-up patches yourself too before reverting them? In some cases patches tell us a nice story, in a lot of cases it might be confusing or messy.. ________________________________ RIJKS MUSEUM ​T/m 18 jaar gratis ​ ​Kijk hier de nieuwste aflevering van Rijksmuseum Unlocked RM xxx ​Please think before you print Van: Koha-devel namens Joonas Kylmälä Verzonden: vrijdag 4 juni 2021 12:36 Aan: koha-devel Onderwerp: [Koha-devel] Follow-up patches and why not to use them Hi, I just bumped in another case of follow-up patch style causing us trouble. In bug https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.koha-community.org%2Fbugzilla3%2Fshow_bug.cgi%3Fid%3D28490&data=04%7C01%7Cm.de.rooy%40rijksmuseum.nl%7C034cbe091d724aacf4bb08d927449659%7C635b05eb66c748e1a94fb4b05a1b058b%7C0%7C0%7C637583998828372650%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=MO%2B9n0LRxKvAcR56xjhqEKk9Rj%2F1LXAT2h%2F8Gs0KFuo%3D&reserved=0 I had to spend considerable amount of time just reverting all the problematic patches and making sure I didn't miss any related patches, instead of just reverting one patch and knowing I would be good to go with that. Reverting this many patches also means a lot more review work yet again because you have no commit messages to reference to easily or if you want to use those you have to jump from patch to patch to find out what the change does. And this extra review work needs to be done by two people when reverting such follow-up patch series! If we instead asked the original author to fix the patches then this work would need to be done only ~once. The argument against this I have heard is that it makes the review work harder because you don't know what has changed since the previous version. I think however that is not very useful because the second reviewer doesn't benefit from this at all and makes their work harder and also the first reviewer even sometimes might review the revision after many days by which time they have forgotten already the context so basically they end up in the same situation as the second reviewer and have to jump between patches. Just my two cents, I hope we can stop doing follow-ups and instead have commits which contain one single change to decrease our time spent on review and make sure we don't miss any problems due to having to jump between so many contexts. Joonas _______________________________________________ Koha-devel mailing list Koha-devel at lists.koha-community.org https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.koha-community.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fkoha-devel&data=04%7C01%7Cm.de.rooy%40rijksmuseum.nl%7C034cbe091d724aacf4bb08d927449659%7C635b05eb66c748e1a94fb4b05a1b058b%7C0%7C0%7C637583998828372650%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=YOfCRiFHuDipvbacs%2F7rSGBjfNdBLiMalVrX%2Fw6DPJU%3D&reserved=0 website : https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.koha-community.org%2F&data=04%7C01%7Cm.de.rooy%40rijksmuseum.nl%7C034cbe091d724aacf4bb08d927449659%7C635b05eb66c748e1a94fb4b05a1b058b%7C0%7C0%7C637583998828372650%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=BfRZNeIWzogwtfG6rXjeDhxj74KeD3fHMmpdkOD%2B5b4%3D&reserved=0 git : https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.koha-community.org%2F&data=04%7C01%7Cm.de.rooy%40rijksmuseum.nl%7C034cbe091d724aacf4bb08d927449659%7C635b05eb66c748e1a94fb4b05a1b058b%7C0%7C0%7C637583998828382643%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=pofwHQiWC6PyO%2BOdya3i4bs4SMRX%2Bj61%2Fg3EZo6Y5iA%3D&reserved=0 bugs : https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.koha-community.org%2F&data=04%7C01%7Cm.de.rooy%40rijksmuseum.nl%7C034cbe091d724aacf4bb08d927449659%7C635b05eb66c748e1a94fb4b05a1b058b%7C0%7C0%7C637583998828382643%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=tg71m%2Fsy1lxJpDd7rIX9CIbqVgcvMiOOi4%2BsGFM1534%3D&reserved=0 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image015731.jpg Type: image/jpeg Size: 10243 bytes Desc: image015731.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image692184.png Type: image/png Size: 910 bytes Desc: image692184.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image098181.png Type: image/png Size: 737 bytes Desc: image098181.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image399729.png Type: image/png Size: 799 bytes Desc: image399729.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image713238.png Type: image/png Size: 804 bytes Desc: image713238.png URL: From joonas.kylmala at helsinki.fi Fri Jun 18 09:35:39 2021 From: joonas.kylmala at helsinki.fi (=?UTF-8?Q?Joonas_Kylm=c3=a4l=c3=a4?=) Date: Fri, 18 Jun 2021 10:35:39 +0300 Subject: [Koha-devel] Follow-up patches and why not to use them In-Reply-To: References: Message-ID: <56d5f1a4-3d99-a851-c044-6184e949ba19@helsinki.fi> Hi Marcel, On 18/06/2021 09:45, Marcel de Rooy wrote: > Agree with Julian here. It depends. > You could squash follow-up patches yourself too before reverting them? > In some cases patches tell us a nice story, in a lot of cases it might > be confusing or messy.. I think you might not have seen yet my follow-up email yet to Julian sent on the 7th of June. Basically squashing or reverting blindly is not an option when you want to review that the changes make sense on top of the new code base. Then the "nice story" or "confusing/messy story" part: as I said in the follow-up email to Julian my wish was to have as well commits with one logical change in each so then we should have *always* a nice story to read. Would love to hear your opinion now with these points clarified. Joonas From rooy.de.m at gmail.com Fri Jun 18 09:40:47 2021 From: rooy.de.m at gmail.com (Marcel de Rooy) Date: Fri, 18 Jun 2021 09:40:47 +0200 Subject: [Koha-devel] Follow-up patches and why not to use them In-Reply-To: <56d5f1a4-3d99-a851-c044-6184e949ba19@helsinki.fi> References: <56d5f1a4-3d99-a851-c044-6184e949ba19@helsinki.fi> Message-ID: Yeah I probably missed it while catching up ;) What you say makes sense, but the problem probably boils down to the gap between theory and practice. Op vr 18 jun. 2021 om 09:36 schreef Joonas Kylmälä < joonas.kylmala at helsinki.fi>: > Hi Marcel, > > On 18/06/2021 09:45, Marcel de Rooy wrote: > > Agree with Julian here. It depends. > > You could squash follow-up patches yourself too before reverting them? > > In some cases patches tell us a nice story, in a lot of cases it might > > be confusing or messy.. > > I think you might not have seen yet my follow-up email yet to Julian > sent on the 7th of June. Basically squashing or reverting blindly is not > an option when you want to review that the changes make sense on top of > the new code base. Then the "nice story" or "confusing/messy story" > part: as I said in the follow-up email to Julian my wish was to have as > well commits with one logical change in each so then we should have > *always* a nice story to read. > > Would love to hear your opinion now with these points clarified. > > Joonas > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : https://www.koha-community.org/ > git : https://git.koha-community.org/ > bugs : https://bugs.koha-community.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From julien.sicot at univ-rennes2.fr Fri Jun 18 12:22:39 2021 From: julien.sicot at univ-rennes2.fr (Julien Sicot) Date: Fri, 18 Jun 2021 12:22:39 +0200 Subject: [Koha-devel] plugin won't enabled in 20.11.x and no error in logs Message-ID: <6C802239-F2BB-458E-86FF-91C1E5E60377@univ-rennes2.fr> Hi all, I'm facing an installation problem on a plugin we developed to manage requests for documents from stacks (which is inspired by the article request module). https://github.com/DSI-Universite-Rennes2/koha-plugin-warehouse-request Until now it worked fine, but after a koha upgrade in 20.11.x, it is stuck with the status disabled and it won't activate. The plugin seems to compile well and I get no errors in the logs which is a bit tricky for debugging :-( In the database it is considered as enabled and installed which is odd... Only the plugin_methods is not supplied. The « tool » and « configure » parts seems to work but not the contrib API routes… I must be missing something but I can't see what… Thanks for the help Best, Julien Sicot Systems Librarian Université Rennes 2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.druart at bugs.koha-community.org Fri Jun 18 12:49:51 2021 From: jonathan.druart at bugs.koha-community.org (Jonathan Druart) Date: Fri, 18 Jun 2021 12:49:51 +0200 Subject: [Koha-devel] plugin won't enabled in 20.11.x and no error in logs In-Reply-To: <6C802239-F2BB-458E-86FF-91C1E5E60377@univ-rennes2.fr> References: <6C802239-F2BB-458E-86FF-91C1E5E60377@univ-rennes2.fr> Message-ID: > Until now it worked fine, but after a koha upgrade in 20.11.x, it is stuck with the status disabled and it won't activate. Just a guess: is the is_enable code correct? https://github.com/DSI-Universite-Rennes2/koha-plugin-warehouse-request/blob/master/Koha/Plugin/Fr/UnivRennes2/WRM.pm#L310 Le ven. 18 juin 2021 à 12:22, Julien Sicot a écrit : > > Hi all, > > I'm facing an installation problem on a plugin we developed to manage requests for documents from stacks (which is inspired by the article request module). > https://github.com/DSI-Universite-Rennes2/koha-plugin-warehouse-request > > Until now it worked fine, but after a koha upgrade in 20.11.x, it is stuck with the status disabled and it won't activate. > The plugin seems to compile well and I get no errors in the logs which is a bit tricky for debugging :-( > In the database it is considered as enabled and installed which is odd... Only the plugin_methods is not supplied. > The « tool » and « configure » parts seems to work but not the contrib API routes… > > I must be missing something but I can't see what… > > Thanks for the help > Best, > > Julien Sicot > Systems Librarian > Université Rennes 2 > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : https://www.koha-community.org/ > git : https://git.koha-community.org/ > bugs : https://bugs.koha-community.org/ From tomascohen at gmail.com Fri Jun 18 13:08:17 2021 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Fri, 18 Jun 2021 08:08:17 -0300 Subject: [Koha-devel] plugin won't enabled in 20.11.x and no error in logs In-Reply-To: <6C802239-F2BB-458E-86FF-91C1E5E60377@univ-rennes2.fr> References: <6C802239-F2BB-458E-86FF-91C1E5E60377@univ-rennes2.fr> Message-ID: Make sure you run the install_plugins.pl script if this was an upgrade. I'm not sure what version you come from, but you need to see the API related methods listed in plugin_methods. Also, check the logs, because there might be problems with the API spec that make Koha skip the routes. Also restart all the things just in case he. El vie., 18 jun. 2021 7:23, Julien Sicot escribió: > Hi all, > > I'm facing an installation problem on a plugin we developed to manage > requests for documents from stacks (which is inspired by the article > request module). > https://github.com/DSI-Universite-Rennes2/koha-plugin-warehouse-request > > Until now it worked fine, but after a koha upgrade in 20.11.x, it is stuck > with the status disabled and it won't activate. > The plugin seems to compile well and I get no errors in the logs which is > a bit tricky for debugging :-( > In the database it is considered as enabled and installed which is odd... > Only the plugin_methods is not supplied. > The « tool » and « configure » parts seems to work but not the contrib API > routes… > > I must be missing something but I can't see what… > > Thanks for the help > Best, > > Julien Sicot > Systems Librarian > Université Rennes 2 > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : https://www.koha-community.org/ > git : https://git.koha-community.org/ > bugs : https://bugs.koha-community.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolas.legrand at bulac.fr Fri Jun 18 13:49:01 2021 From: nicolas.legrand at bulac.fr (Nicolas Legrand) Date: Fri, 18 Jun 2021 13:49:01 +0200 Subject: [Koha-devel] plugin won't enabled in 20.11.x and no error in logs In-Reply-To: References: <6C802239-F2BB-458E-86FF-91C1E5E60377@univ-rennes2.fr> Message-ID: Le ven. 18 juin 2021 à 12:50, Jonathan Druart < jonathan.druart at bugs.koha-community.org> a écrit : > > Until now it worked fine, but after a koha upgrade in 20.11.x, it is > stuck with the status disabled and it won't activate. > > Just a guess: is the is_enable code correct? > > > https://github.com/DSI-Universite-Rennes2/koha-plugin-warehouse-request/blob/master/Koha/Plugin/Fr/UnivRennes2/WRM.pm#L310 Julien, we got this one on, though we don't use it right now. This could explain it's working with our 20.11 ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mtj at kohaaloha.com Fri Jun 18 14:02:33 2021 From: mtj at kohaaloha.com (Mason James) Date: Sat, 19 Jun 2021 00:02:33 +1200 Subject: [Koha-devel] docker1 needs debian upgrading Message-ID: hi folks can someone (possibly bywater) upgrade debian on docker1, pleeese some tests are failing because it's debian is too old thanks, Mason From tomascohen at gmail.com Fri Jun 18 14:13:13 2021 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Fri, 18 Jun 2021 09:13:13 -0300 Subject: [Koha-devel] docker1 needs debian upgrading In-Reply-To: References: Message-ID: Isn't all being run inside containers? I can try upgrading it anyway. El vie, 18 jun 2021 a las 9:03, Mason James () escribió: > hi folks > can someone (possibly bywater) upgrade debian on docker1, pleeese > > some tests are failing because it's debian is too old > > thanks, Mason > > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : https://www.koha-community.org/ > git : https://git.koha-community.org/ > bugs : https://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: From julien.sicot at univ-rennes2.fr Fri Jun 18 17:38:59 2021 From: julien.sicot at univ-rennes2.fr (Julien Sicot) Date: Fri, 18 Jun 2021 17:38:59 +0200 Subject: [Koha-devel] plugin won't enabled in 20.11.x and no error in logs In-Reply-To: References: <6C802239-F2BB-458E-86FF-91C1E5E60377@univ-rennes2.fr> Message-ID: On Fri, Jun 18, 2021 at 1:49 PM Nicolas Legrand wrote: > > > Le ven. 18 juin 2021 à 12:50, Jonathan Druart < > jonathan.druart at bugs.koha-community.org> a écrit : > >> > Until now it worked fine, but after a koha upgrade in 20.11.x, it is >> stuck with the status disabled and it won't activate. >> >> Just a guess: is the is_enable code correct? >> >> >> https://github.com/DSI-Universite-Rennes2/koha-plugin-warehouse-request/blob/master/Koha/Plugin/Fr/UnivRennes2/WRM.pm#L310 > > > > Julien, we got this one on, though we don't use it right now. This could > explain it's working with our 20.11 ? > Jonathan, I don't know how to thank you! How did I not see this ^^, I thought I would lose my mind... I had introduced this feature before the community enable/disable system, I didn't think about it anymore... a big thank you also to Nicolas and Thomas I was already checked the logs and used the script install_plugins.pl without success Best, Julien -- *Julien Sicot* Responsable Système d'Information Documentaire SCD/DSI Université Rennes 2 02 99 14 12 64 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: noname Type: image/png Size: 3379 bytes Desc: not available URL: From tomascohen at gmail.com Fri Jun 18 17:43:51 2021 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Fri, 18 Jun 2021 12:43:51 -0300 Subject: [Koha-devel] plugin won't enabled in 20.11.x and no error in logs In-Reply-To: References: <6C802239-F2BB-458E-86FF-91C1E5E60377@univ-rennes2.fr> Message-ID: Problem solved! That's great for a Friday! Cheers! El vie., 18 jun. 2021 12:39, Julien Sicot escribió: > > > > On Fri, Jun 18, 2021 at 1:49 PM Nicolas Legrand > wrote: > >> >> >> Le ven. 18 juin 2021 à 12:50, Jonathan Druart < >> jonathan.druart at bugs.koha-community.org> a écrit : >> >>> > Until now it worked fine, but after a koha upgrade in 20.11.x, it is >>> stuck with the status disabled and it won't activate. >>> >>> Just a guess: is the is_enable code correct? >>> >>> >>> https://github.com/DSI-Universite-Rennes2/koha-plugin-warehouse-request/blob/master/Koha/Plugin/Fr/UnivRennes2/WRM.pm#L310 >> >> >> >> Julien, we got this one on, though we don't use it right now. This could >> explain it's working with our 20.11 ? >> > > Jonathan, I don't know how to thank you! > How did I not see this ^^, I thought I would lose my mind... > I had introduced this feature before the community enable/disable system, > I didn't think about it anymore... > > a big thank you also to Nicolas and Thomas > > I was already checked the logs and used the script install_plugins.pl > without success > > Best, > Julien > > -- > > > > *Julien Sicot* > Responsable Système d'Information Documentaire > SCD/DSI > Université Rennes 2 > 02 99 14 12 64 > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : https://www.koha-community.org/ > git : https://git.koha-community.org/ > bugs : https://bugs.koha-community.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mtj at kohaaloha.com Fri Jun 18 21:30:19 2021 From: mtj at kohaaloha.com (Mason James) Date: Sat, 19 Jun 2021 07:30:19 +1200 Subject: [Koha-devel] docker1 needs debian upgrading In-Reply-To: References: Message-ID: hiya, docker1 is having this error 38)Function not implemented: AH00141: Could not initialize random number generator more info... https://www.reddit.com/r/synology/comments/j5770x/apache_rng_error_any_help/ On 19/06/21 12:13 am, Tomas Cohen Arazi wrote: > Isn't all being run inside containers? I can try upgrading it anyway. > > El vie, 18 jun 2021 a las 9:03, Mason James (>) escribió: > > hi folks > can someone (possibly bywater) upgrade debian on docker1, pleeese > > some tests are failing because it's debian is too old > > thanks, Mason > > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : https://www.koha-community.org/ > git : https://git.koha-community.org/ > bugs : https://bugs.koha-community.org/ > > > > -- > Tomás Cohen Arazi > Theke Solutions (http://theke.io ) > ✆ +54 9351 3513384 > GPG: B2F3C15F From mtj at kohaaloha.com Sat Jun 19 08:35:30 2021 From: mtj at kohaaloha.com (Mason James) Date: Sat, 19 Jun 2021 18:35:30 +1200 Subject: [Koha-devel] docker1 needs debian upgrading In-Reply-To: References: Message-ID: <22801ab9-a46e-36d1-84ea-450beed25b26@kohaaloha.com> it's a weird bug... my understanding is that all deb11 builds (and others?) are failing on docker1, because docker1 is running jessie with kernel 3.16 the version of apache2 on deb11 uses the getrandom() syscall, which does not exist on kernel 3.16, (it's introduced in 3.17)  more info... https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978045 you can see a failed build here -> https://jenkins.koha-community.org/job/Koha_20.05_D11/161/console  00:03:25.748 db_1         | Version: '10.3.27-MariaDB-1:10.3.27+maria~focal'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  mariadb.org binary distribution  00:03:25.964 koha_1       | [Wed Jan 13 00:40:24.341834 2021] [:crit] [pid 148] (38)Function not implemented: AH00141: Could not initialize random number generator  00:03:25.969 koha_1       | Koha requires mpm_itk to be enabled within Apache in order to run.  00:03:26.508 koha_koha_1 exited with code 1  00:03:42.344 Finished: FAILURE upgrading docker1 to a newer kernel should fix the problem, and jessie is EOL (i think?) On 19/06/21 7:30 am, Mason James wrote: > hiya, docker1 is having this error > > 38)Function not implemented: AH00141: Could not initialize random number generator > > more info... > https://www.reddit.com/r/synology/comments/j5770x/apache_rng_error_any_help/ > > > On 19/06/21 12:13 am, Tomas Cohen Arazi wrote: >> Isn't all being run inside containers? I can try upgrading it anyway. >> >> El vie, 18 jun 2021 a las 9:03, Mason James (>) escribió: >> >>     hi folks >>     can someone (possibly bywater) upgrade debian on docker1, pleeese >> >>     some tests are failing because it's debian is too old >> >>     thanks, Mason >> >> >> >>     _______________________________________________ >>     Koha-devel mailing list >>     Koha-devel at lists.koha-community.org >> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >>     website : https://www.koha-community.org/ >>     git : https://git.koha-community.org/ >>     bugs : https://bugs.koha-community.org/ >> >> >> >> -- >> Tomás Cohen Arazi >> Theke Solutions (http://theke.io ) >> ✆ +54 9351 3513384 >> GPG: B2F3C15F > From tomascohen at gmail.com Sat Jun 19 14:39:41 2021 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Sat, 19 Jun 2021 09:39:41 -0300 Subject: [Koha-devel] docker1 needs debian upgrading In-Reply-To: <22801ab9-a46e-36d1-84ea-450beed25b26@kohaaloha.com> References: <22801ab9-a46e-36d1-84ea-450beed25b26@kohaaloha.com> Message-ID: The problem is I upgraded the OS several months ago. So it is buster. Are you sure it is that node? I would just destroy it and recreate it that's the problem. Maybe there's another old one. El sáb., 19 jun. 2021 3:35, Mason James escribió: > it's a weird bug... > my understanding is that all deb11 builds (and others?) are failing on > docker1, because docker1 is running jessie with kernel 3.16 > > the version of apache2 on deb11 uses the getrandom() syscall, which does > not exist on kernel 3.16, (it's introduced in 3.17) > > more info... https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978045 > > > you can see a failed build here -> > https://jenkins.koha-community.org/job/Koha_20.05_D11/161/console > > 00:03:25.748 db_1 | Version: > '10.3.27-MariaDB-1:10.3.27+maria~focal' socket: > '/var/run/mysqld/mysqld.sock' port: 3306 mariadb.org binary distribution > 00:03:25.964 koha_1 | [Wed Jan 13 00:40:24.341834 2021] [:crit] > [pid 148] (38)Function not implemented: AH00141: Could not initialize > random number generator > 00:03:25.969 koha_1 | Koha requires mpm_itk to be enabled within > Apache in order to run. > 00:03:26.508 koha_koha_1 exited with code 1 > 00:03:42.344 Finished: FAILURE > > upgrading docker1 to a newer kernel should fix the problem, and jessie is > EOL (i think?) > > > > On 19/06/21 7:30 am, Mason James wrote: > > hiya, docker1 is having this error > > > > 38)Function not implemented: AH00141: Could not initialize random number > generator > > > > more info... > > > https://www.reddit.com/r/synology/comments/j5770x/apache_rng_error_any_help/ > > > > > > On 19/06/21 12:13 am, Tomas Cohen Arazi wrote: > >> Isn't all being run inside containers? I can try upgrading it anyway. > >> > >> El vie, 18 jun 2021 a las 9:03, Mason James ( >) escribió: > >> > >> hi folks > >> can someone (possibly bywater) upgrade debian on docker1, pleeese > >> > >> some tests are failing because it's debian is too old > >> > >> thanks, Mason > >> > >> > >> > >> _______________________________________________ > >> Koha-devel mailing list > >> Koha-devel at lists.koha-community.org Koha-devel at lists.koha-community.org> > >> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel < > https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel> > >> website : https://www.koha-community.org/ < > https://www.koha-community.org/> > >> git : https://git.koha-community.org/ < > https://git.koha-community.org/> > >> bugs : https://bugs.koha-community.org/ < > https://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: From julien.sicot at univ-rennes2.fr Sat Jun 19 20:08:38 2021 From: julien.sicot at univ-rennes2.fr (Julien Sicot) Date: Sat, 19 Jun 2021 20:08:38 +0200 Subject: [Koha-devel] Embed see-from headings (authorities) into bibliographic records at OAI repository level Message-ID: Hi all, An enhancement idea : It could be interesting to enrich the bibliographic records exposed in OAI with see-from headings, this would allow users who use koha with a discovery tool to be able to manage, normalize and index some authorities data ? This is something that could be done directly in C4::Biblio::GetMarcBiblio following the same method used for embedding items. We could use an optional parameter like embed_items (embed_seefromheading) and a function similar to C4::Biblio::EmbedItemsInMarcBiblio by reusing what was made for zebra with EmbedSeeFromHeadings (bug #7417 ). What do you think about this? Thanks for feedback, Best -- Julien Sicot Systems Librarian Université Rennes 2 02 22 51 44 41 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 096af0a1-34a2-4a88-ac19-85cad80f4cb1.png Type: image/png Size: 59715 bytes Desc: not available URL: From mtj at kohaaloha.com Sun Jun 20 03:16:50 2021 From: mtj at kohaaloha.com (Mason James) Date: Sun, 20 Jun 2021 13:16:50 +1200 Subject: [Koha-devel] docker1 needs debian upgrading In-Reply-To: References: <22801ab9-a46e-36d1-84ea-450beed25b26@kohaaloha.com> Message-ID: aah, problem solved if docker1 is now buster thanks! ❤️ On 20/06/21 12:39 am, Tomas Cohen Arazi wrote: > The problem is I upgraded the OS several months ago. So it is buster. > Are you sure it is that node? > I would just destroy it and recreate it that's the problem. From rooy.de.m at gmail.com Mon Jun 21 15:37:46 2021 From: rooy.de.m at gmail.com (Marcel de Rooy) Date: Mon, 21 Jun 2021 15:37:46 +0200 Subject: [Koha-devel] False qa tools warning? Message-ID: Hi all, I am looking at bug 27944 and see the following qa warn: FAIL koha-tmpl/intranet-tmpl/prog/en/modules/circ/request-article.tt OK filters OK forbidden patterns OK git manipulation OK js_in_body SKIP spelling OK tt_valid FAIL valid_template Attempt to reload Koha/Template/Plugin/Biblio.pm aborted. Compilation failed in require at /usr/lib/x86_64-linux-gnu/perl5/5.28/Template/Plugins.pm line 206. This seems to be a false warning. But since it apparently refers to a compile error, I still would like to know where does it come from? The module for the Biblio plugin compiles just fine. The [% USE Biblio %] comes from an include in the template: biblio-view-menu.inc. Any ideas? Thnx, Marcel -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Tue Jun 22 09:02:05 2021 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Tue, 22 Jun 2021 17:02:05 +1000 Subject: [Koha-devel] Add multi-branch support to AutoSelfCheckAllowed Message-ID: <030001d76734$825185a0$86f490e0$@prosentient.com.au> AutoSelfCheckAllowed is a useful system preference, but it really only works if you have 1 branch. Lots of libraries have multiple branches. We have a local customization to get around this but I don't love it. How do people think Koha could have multi-branch support for AutoSelfCheckAllowed? Of course, AutoSelfCheckID and AutoSelfCheckPass are a hack. But that's a topic for another day. 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: From victor at tuxayo.net Wed Jun 23 02:49:25 2021 From: victor at tuxayo.net (Victor Grousset/tuxayo) Date: Wed, 23 Jun 2021 02:49:25 +0200 Subject: [Koha-devel] Replacement of mailman (mailing lists) In-Reply-To: References: <0bdff4d2-92c3-c487-f2c3-a7d0b4d8230c@helsinki.fi> Message-ID: <68ebadd9-9fd7-ad3e-a95f-051c685688c5@tuxayo.net> Hi :) On 21-06-04 16:03, Jonathan Druart wrote: > The question is: do we make the work to keep mailman, or do we > consider it obsolete and we need something more modern? I think that a forum software would help users ask and answer more questions. As well as having them indexed by search engines. "Just" upgrading mailman to v3 and more administrating would be nice for the reasons you exposed. And v2 still stores the passwords as plaintext. And as a provocation (or honesty?) it sends them back to oneself every month ^^ Anyway, that would still be a good outcome. The final outcome might depend more on who are in a good position to do one of the paths. Anyone(s)[1] feeling like being such a position? Cheers, -- Victor Grousset/tuxayo [1] I know it's not valid english :P From julien.sicot at univ-rennes2.fr Wed Jun 23 12:27:56 2021 From: julien.sicot at univ-rennes2.fr (Julien Sicot) Date: Wed, 23 Jun 2021 12:27:56 +0200 Subject: [Koha-devel] Replacement of mailman (mailing lists) In-Reply-To: <68ebadd9-9fd7-ad3e-a95f-051c685688c5@tuxayo.net> References: <0bdff4d2-92c3-c487-f2c3-a7d0b4d8230c@helsinki.fi> <68ebadd9-9fd7-ad3e-a95f-051c685688c5@tuxayo.net> Message-ID: Hi all, Like Victor, I think this is a good idea to provide a dedicate space like discourse. For example, see what the omeka community offers : https://forum.omeka.org/ It would allow more involvement of the community and also encourage the sharing of practices. The benefit is also that answers to questions are more easily discoverable (organization by category, indexing) so it works as a knowledge base useful to the whole community. I also see the opportunity to merge in one point all the koha communities by using groups (geographical or languages communities like kohala in France that use separate mail discussion list). Best, Julien > Le 23 juin 2021 à 02:49, Victor Grousset/tuxayo a écrit : > > Hi :) > > On 21-06-04 16:03, Jonathan Druart wrote: >> The question is: do we make the work to keep mailman, or do we >> consider it obsolete and we need something more modern? > > I think that a forum software would help users ask and answer more questions. As well as having them indexed by search engines. > > "Just" upgrading mailman to v3 and more administrating would be nice for the reasons you exposed. And v2 still stores the passwords as plaintext. And as a provocation (or honesty?) it sends them back to oneself every month ^^ > Anyway, that would still be a good outcome. > > The final outcome might depend more on who are in a good position to do one of the paths. > Anyone(s)[1] feeling like being such a position? > > Cheers, > > -- > Victor Grousset/tuxayo > > [1] I know it's not valid english :P > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : https://www.koha-community.org/ > git : https://git.koha-community.org/ > bugs : https://bugs.koha-community.org/ From victor at tuxayo.net Wed Jun 23 23:05:07 2021 From: victor at tuxayo.net (Victor Grousset/tuxayo) Date: Wed, 23 Jun 2021 23:05:07 +0200 Subject: [Koha-devel] Replacement of mailman (mailing lists) In-Reply-To: References: <0bdff4d2-92c3-c487-f2c3-a7d0b4d8230c@helsinki.fi> <68ebadd9-9fd7-ad3e-a95f-051c685688c5@tuxayo.net> Message-ID: <1244d715-3550-ca43-4b2d-8c42832ed4b5@tuxayo.net> On 21-06-23 12:27, Julien Sicot wrote> I also see the opportunity to merge in one point all the koha communities by using groups (geographical or languages communities like kohala in France that use separate mail discussion list). Yes, this is great! It would be a very easy way to create a discussion space for sub-communities. Without a website or mailing list. And it would be very discoverable. As someone must be lucky to stumble on this page: https://wiki.koha-community.org/wiki/Koha_Users_Groups While we are at it, anything missing on it? ^^ Cheers, -- Victor Grousset/tuxayo From jonathan.druart at bugs.koha-community.org Thu Jun 24 15:57:17 2021 From: jonathan.druart at bugs.koha-community.org (Jonathan Druart) Date: Thu, 24 Jun 2021 15:57:17 +0200 Subject: [Koha-devel] pull latest koha-testing-docker-images (Add new lib directory) Message-ID: (This is a message from last week that didn't reach the list) Hi, I've just pushed bug 28489 that is adding a new "lib" directory. It needs to be added to the apache config, and new koha-testing-docker images have been published. The error: couldn't load CGI::Session::Serialize::yamlxs: Can't locate CGI/Session/Serialize/yamlxs.pm in @INC (you may need to install the CGI::Session::Serialize::yamlxs module) The KTD solution: `docker-compose pull` A workaround (if you are not using ktd): In your apache config, add the lib directory: SetEnv PERL5LIB "/kohadevbox/koha:/kohadevbox/koha/lib" That's not enough, for the CLI scripts (and tests), you will need to adjust PERL5LIB as well In koha-testing-docker, edit .env and replace the PERL5LIB line with: PERL5LIB=/kohadevbox/koha:/kohadevbox/koha/lib:/kohadevbox/qa-test-tools Cheers, Jonathan From nick at bywatersolutions.com Thu Jun 24 19:27:40 2021 From: nick at bywatersolutions.com (Nick Clemens) Date: Thu, 24 Jun 2021 13:27:40 -0400 Subject: [Koha-devel] Release of Koha 21.05.01 Message-ID: Hi all! The Koha community is pleased to announce the release of Koha 21.05.01! The full release notes can be found here: https://koha-community.org/koha-21-05-01-released/ Thanks! Kyle + Nick -- Nick Clemens ByWater Solutions bywatersolutions.com Phone: (888) 900-8944 Pronouns: (he/him/his) Timezone: Eastern Follow us: -------------- next part -------------- An HTML attachment was scrubbed... URL: From JBoyer at equinoxOLI.org Thu Jun 24 20:30:48 2021 From: JBoyer at equinoxOLI.org (Jason Boyer) Date: Thu, 24 Jun 2021 14:30:48 -0400 Subject: [Koha-devel] Z39.50 daemon with ElasticSearch In-Reply-To: <8527eba7-d6c0-3d7d-366d-e85257e827e7@gmail.com> References: <8527eba7-d6c0-3d7d-366d-e85257e827e7@gmail.com> Message-ID: <35868655-B963-4CCB-8967-BC29642D7B82@equinoxOLI.org> I was glad that I remembered this exchange, I was setting up ES and the z3950 responder today and having some trouble. I poked at the script a bit to see what might be the problem but didn’t have time to figure out the issue. I am fairly comfortable with systemd units though, so I put together the attached instanced service so you can create as many z3950 instances as needed on a Debian-packages based system like so: systmectl start koha-z3950-responder at instance-name.service systmectl enable koha-z3950-responder at instance-name.service And it should work as intended with koha-z3950-responder --start ... Since systemd keeps track of things there’s no need to worry about the -u or -p options Jason -- Jason Boyer Senior System Administrator Equinox Open Library Initiative JBoyer at equinoxOLI.org +1 (877) Open-ILS (673-6457) https://equinoxOLI.org/ > On Dec 15, 2020, at 6:02 PM, Zeno Tajoli wrote: > > 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= > > 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 > _______________________________________________ > 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: From JBoyer at equinoxOLI.org Thu Jun 24 20:34:02 2021 From: JBoyer at equinoxOLI.org (Jason Boyer) Date: Thu, 24 Jun 2021 14:34:02 -0400 Subject: [Koha-devel] Z39.50 daemon with ElasticSearch In-Reply-To: <35868655-B963-4CCB-8967-BC29642D7B82@equinoxOLI.org> References: <8527eba7-d6c0-3d7d-366d-e85257e827e7@gmail.com> <35868655-B963-4CCB-8967-BC29642D7B82@equinoxOLI.org> Message-ID: Oops, accidentally hit send too soon. Also, to keep the regular koha-z3950-responder script from interfering you have to rename the config dir as Zeno did. I picked z3950-srv, but anything will work so long as you rename all of them the same way. Jason -- Jason Boyer Senior System Administrator Equinox Open Library Initiative JBoyer at equinoxOLI.org +1 (877) Open-ILS (673-6457) https://equinoxOLI.org/ > On Jun 24, 2021, at 2:30 PM, Jason Boyer wrote: > > I was glad that I remembered this exchange, I was setting up ES and the z3950 responder today and having some trouble. I poked at the script a bit to see what might be the problem but didn’t have time to figure out the issue. I am fairly comfortable with systemd units though, so I put together the attached instanced service so you can create as many z3950 instances as needed on a Debian-packages based system like so: > > systmectl start koha-z3950-responder at instance-name.service > systmectl enable koha-z3950-responder at instance-name.service > > And it should work as intended with koha-z3950-responder --start ... > > Since systemd keeps track of things there’s no need to worry about the -u or -p options > > Jason > > -- > Jason Boyer > Senior System Administrator > Equinox Open Library Initiative > JBoyer at equinoxOLI.org > +1 (877) Open-ILS (673-6457) > https://equinoxOLI.org/ > >> On Dec 15, 2020, at 6:02 PM, Zeno Tajoli > wrote: >> >> 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= >> >> 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 >> _______________________________________________ >> 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: koha-z3950-responder at .service Type: application/octet-stream Size: 343 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From victor at tuxayo.net Fri Jun 25 02:49:50 2021 From: victor at tuxayo.net (Victor Grousset/tuxayo) Date: Fri, 25 Jun 2021 02:49:50 +0200 Subject: [Koha-devel] =?utf-8?b?S29oYSAyMC4wNS4xMyByZWxlYXNlZCwg4pqgIHNl?= =?utf-8?q?curity_release?= Message-ID: Hello! :) The Koha Community is happy to announce the release of Koha 20.05.13 The full release notes can be found at: https://koha-community.org/koha-20.05.13-released/ Debian packages should be available shortly. Thanks to everyone involved :) Cheers, -- Victor Grousset/tuxayo From rooy.de.m at gmail.com Fri Jun 25 11:35:07 2021 From: rooy.de.m at gmail.com (Marcel de Rooy) Date: Fri, 25 Jun 2021 11:35:07 +0200 Subject: [Koha-devel] Request for two signoffs Message-ID: Hi all, The following two bugs have been waiting for attention for some time already: Bug 20310 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20310 Article requests: Can we redirect article records without items to host record? Has been adjusted after earlier feedback. Bug 26302 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26302 OPAC XSLT Results: List variable number of itemcallnumbers Submitted 2020, rebased, extended yesterday. Thanks for your help in getting this further. Marcel -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.druart at bugs.koha-community.org Fri Jun 25 16:11:19 2021 From: jonathan.druart at bugs.koha-community.org (Jonathan Druart) Date: Fri, 25 Jun 2021 16:11:19 +0200 Subject: [Koha-devel] False qa tools warning? In-Reply-To: References: Message-ID: I've answered on the bug report. It's a valid error. Le lun. 21 juin 2021 à 15:37, Marcel de Rooy a écrit : > > Hi all, > > I am looking at bug 27944 and see the following qa warn: > > FAIL koha-tmpl/intranet-tmpl/prog/en/modules/circ/request-article.tt > OK filters > OK forbidden patterns > OK git manipulation > OK js_in_body > SKIP spelling > OK tt_valid > FAIL valid_template > Attempt to reload Koha/Template/Plugin/Biblio.pm aborted. > Compilation failed in require at /usr/lib/x86_64-linux-gnu/perl5/5.28/Template/Plugins.pm line 206. > > This seems to be a false warning. > But since it apparently refers to a compile error, I still would like to know where does it come from? > The module for the Biblio plugin compiles just fine. > The [% USE Biblio %] comes from an include in the template: biblio-view-menu.inc. > > Any ideas? > > Thnx, > Marcel > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : https://www.koha-community.org/ > git : https://git.koha-community.org/ > bugs : https://bugs.koha-community.org/ From victor at tuxayo.net Fri Jun 25 17:26:34 2021 From: victor at tuxayo.net (Victor Grousset/tuxayo) Date: Fri, 25 Jun 2021 17:26:34 +0200 Subject: [Koha-devel] pull latest koha-testing-docker-images (Add new lib directory) In-Reply-To: References: Message-ID: <4c684120-8c6d-9531-7d78-df68b64c4a55@tuxayo.net> Thanks for the heads up :) -- Victor Grousset/tuxayo From victor at tuxayo.net Fri Jun 25 17:34:24 2021 From: victor at tuxayo.net (Victor Grousset/tuxayo) Date: Fri, 25 Jun 2021 17:34:24 +0200 Subject: [Koha-devel] pull latest koha-testing-docker-images (Add new lib directory) In-Reply-To: References: Message-ID: <92d64688-8de6-3990-a877-ce0c3c2ce4d5@tuxayo.net> On 21-06-24 15:57, Jonathan Druart wrote: > I've just pushed bug 28489 that is adding a new "lib" directory. Isn't it this one instead ? Bug 28519 - Add a 2nd directory for Perl modules https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28519 Cheers, -- Victor Grousset/tuxayo From jonathan.druart at bugs.koha-community.org Fri Jun 25 18:36:59 2021 From: jonathan.druart at bugs.koha-community.org (Jonathan Druart) Date: Fri, 25 Jun 2021 18:36:59 +0200 Subject: [Koha-devel] pull latest koha-testing-docker-images (Add new lib directory) In-Reply-To: <92d64688-8de6-3990-a877-ce0c3c2ce4d5@tuxayo.net> References: <92d64688-8de6-3990-a877-ce0c3c2ce4d5@tuxayo.net> Message-ID: Yes Le ven. 25 juin 2021 à 17:34, Victor Grousset/tuxayo a écrit : > On 21-06-24 15:57, Jonathan Druart wrote: > > I've just pushed bug 28489 that is adding a new "lib" directory. > > Isn't it this one instead ? Bug 28519 - Add a 2nd directory for Perl > modules > https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28519 > > Cheers, > > -- > Victor Grousset/tuxayo > -------------- next part -------------- An HTML attachment was scrubbed... URL: From katrin.fischer.83 at web.de Sat Jun 26 17:39:46 2021 From: katrin.fischer.83 at web.de (Katrin Fischer) Date: Sat, 26 Jun 2021 17:39:46 +0200 Subject: [Koha-devel] Add multi-branch support to AutoSelfCheckAllowed In-Reply-To: <030001d76734$825185a0$86f490e0$@prosentient.com.au> References: <030001d76734$825185a0$86f490e0$@prosentient.com.au> Message-ID: Hi David, did you see: *Bug 21250* - Auto-self-checkout not fully compatible with multi-branch library setup ? We found a workaround there using overwrites in koha-conf.xml, but there was definitely interest in having an easier solution. Hope this helps, Katrin On 22.06.21 09:02, dcook at prosentient.com.au wrote: > > AutoSelfCheckAllowed is a useful system preference, but it really only > works if you have 1 branch. Lots of libraries have multiple branches. > We have a local customization to get around this but I don’t love it. > > How do people think Koha could have multi-branch support for > AutoSelfCheckAllowed? > > Of course, AutoSelfCheckID and AutoSelfCheckPass are a hack. But > that’s a topic for another day… > > 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 : https://www.koha-community.org/ > git : https://git.koha-community.org/ > bugs : https://bugs.koha-community.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomascohen at gmail.com Sat Jun 26 19:47:57 2021 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Sat, 26 Jun 2021 14:47:57 -0300 Subject: [Koha-devel] Add multi-branch support to AutoSelfCheckAllowed In-Reply-To: <030001d76734$825185a0$86f490e0$@prosentient.com.au> References: <030001d76734$825185a0$86f490e0$@prosentient.com.au> Message-ID: We should make use of... The configurations table hahaha. El mar., 22 jun. 2021 4:22, escribió: > AutoSelfCheckAllowed is a useful system preference, but it really only > works if you have 1 branch. Lots of libraries have multiple branches. We > have a local customization to get around this but I don’t love it. > > > > How do people think Koha could have multi-branch support for > AutoSelfCheckAllowed? > > > > Of course, AutoSelfCheckID and AutoSelfCheckPass are a hack. But that’s a > topic for another day… > > > > 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 : https://www.koha-community.org/ > git : https://git.koha-community.org/ > bugs : https://bugs.koha-community.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From katrin.fischer.83 at web.de Sun Jun 27 10:27:36 2021 From: katrin.fischer.83 at web.de (Katrin Fischer) Date: Sun, 27 Jun 2021 10:27:36 +0200 Subject: [Koha-devel] Embed see-from headings (authorities) into bibliographic records at OAI repository level In-Reply-To: References: Message-ID: <7857ec78-cf08-5525-7421-db7341c2d8c2@web.de> Hi Julien, not sure if GetMarcBiblio would be the best spot, but I like the idea in general, especially as an optional switch. Maybe file a bug report for further discussion? Katrin On 19.06.21 20:08, Julien Sicot wrote: > Hi all, > > An enhancement idea : > > It could be interesting to enrich the bibliographic records exposed in > OAI with see-from headings, this would allow users who use koha with a > discovery tool to be able to manage, normalize and index some > authorities data ? > > This is something that could be done directly in > C4::Biblio::GetMarcBiblio following the same method used for embedding > items. > We could use an optional parameter like embed_items > (embed_seefromheading) and a function similar to > C4::Biblio::EmbedItemsInMarcBiblio by reusing what was made for zebra > with EmbedSeeFromHeadings (bug #7417 > ). > > What do you think about this? > > > > Thanks for feedback, > Best > > -- > *Julien Sicot* > Systems Librarian > Université Rennes 2 > 02 22 51 44 41 > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : https://www.koha-community.org/ > git : https://git.koha-community.org/ > bugs : https://bugs.koha-community.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 096af0a1-34a2-4a88-ac19-85cad80f4cb1.png Type: image/png Size: 59715 bytes Desc: not available URL: From victor at tuxayo.net Mon Jun 28 02:40:20 2021 From: victor at tuxayo.net (Victor Grousset/tuxayo) Date: Mon, 28 Jun 2021 02:40:20 +0200 Subject: [Koha-devel] =?utf-8?b?S29oYSAyMC4xMS4wNyByZWxlYXNlZCwg4pqgIHNl?= =?utf-8?q?curity_release?= Message-ID: <078ed22f-9f9e-7331-429f-3f542b06b14f@tuxayo.net> Hello! :) The Koha Community is happy to announce the release of Koha 20.11.07 The full release notes can be found at: https://koha-community.org/koha-20.11.07-released Debian packages should be available shortly. Thanks to everyone involved :) Fridolin will be back for the next release, I’m just replacing them for this one. Cheers, -- Victor Grousset/tuxayo From dcook at prosentient.com.au Mon Jun 28 03:17:10 2021 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Mon, 28 Jun 2021 11:17:10 +1000 Subject: [Koha-devel] Add multi-branch support to AutoSelfCheckAllowed In-Reply-To: References: <030001d76734$825185a0$86f490e0$@prosentient.com.au> Message-ID: <038301d76bbb$51caa390$f55feab0$@prosentient.com.au> Tomas: I knew you were going to say that heh. Does the configurations table have a password field type available? Katrin: I hadn’t seen that one, but I’ll comment there. 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: Tomas Cohen Arazi Sent: Sunday, 27 June 2021 3:48 AM To: David Cook Cc: koha-devel Subject: Re: [Koha-devel] Add multi-branch support to AutoSelfCheckAllowed We should make use of... The configurations table hahaha. El mar., 22 jun. 2021 4:22, > escribió: AutoSelfCheckAllowed is a useful system preference, but it really only works if you have 1 branch. Lots of libraries have multiple branches. We have a local customization to get around this but I don’t love it. How do people think Koha could have multi-branch support for AutoSelfCheckAllowed? Of course, AutoSelfCheckID and AutoSelfCheckPass are a hack. But that’s a topic for another day… 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 : https://www.koha-community.org/ git : https://git.koha-community.org/ bugs : https://bugs.koha-community.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Mon Jun 28 03:21:25 2021 From: dcook at prosentient.com.au (dcook at prosentient.com.au) Date: Mon, 28 Jun 2021 11:21:25 +1000 Subject: [Koha-devel] Add multi-branch support to AutoSelfCheckAllowed References: <030001d76734$825185a0$86f490e0$@prosentient.com.au> Message-ID: <038801d76bbb$e992b000$bcb81000$@prosentient.com.au> Actually, what I was thinking was possibly adding a field to the “branches” table to specify a user to use, and not requiring a password. Of course, if you don’t require a password, someone could specify any user they want, so that won’t work either. 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: dcook at prosentient.com.au Sent: Monday, 28 June 2021 11:17 AM To: 'Tomas Cohen Arazi' Cc: 'koha-devel' Subject: RE: [Koha-devel] Add multi-branch support to AutoSelfCheckAllowed Tomas: I knew you were going to say that heh. Does the configurations table have a password field type available? Katrin: I hadn’t seen that one, but I’ll comment there. 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: Tomas Cohen Arazi > Sent: Sunday, 27 June 2021 3:48 AM To: David Cook > Cc: koha-devel > Subject: Re: [Koha-devel] Add multi-branch support to AutoSelfCheckAllowed We should make use of... The configurations table hahaha. El mar., 22 jun. 2021 4:22, > escribió: AutoSelfCheckAllowed is a useful system preference, but it really only works if you have 1 branch. Lots of libraries have multiple branches. We have a local customization to get around this but I don’t love it. How do people think Koha could have multi-branch support for AutoSelfCheckAllowed? Of course, AutoSelfCheckID and AutoSelfCheckPass are a hack. But that’s a topic for another day… 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 : https://www.koha-community.org/ git : https://git.koha-community.org/ bugs : https://bugs.koha-community.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mtj at kohaaloha.com Mon Jun 28 04:26:59 2021 From: mtj at kohaaloha.com (Mason James) Date: Mon, 28 Jun 2021 14:26:59 +1200 Subject: [Koha-devel] =?utf-8?q?Koha_packages_are_available_=F0=9F=8E=81?= In-Reply-To: <078ed22f-9f9e-7331-429f-3f542b06b14f@tuxayo.net> References: <078ed22f-9f9e-7331-429f-3f542b06b14f@tuxayo.net> Message-ID: <7cecf22e-1d39-75bb-2e75-046913768322@kohaaloha.com> kia ora community, the latest Koha packages are available cheers, Mason From ism at kis.in Mon Jun 28 14:10:27 2021 From: ism at kis.in (ism at kis.in) Date: Mon, 28 Jun 2021 17:40:27 +0530 Subject: [Koha-devel] Koha OPAC page messed up after upgrade from 18.04 to 21.05 Message-ID: <051301d76c16$95e370b0$c1aa5210$@kis.in> I have upgraded our Koha to a new server with Ubuntu 21.04 and Koha 21.05.01.003. While data migration and staff page are ok the OPAC page is messed up. It seems like some .css or .js are missing. When I open the opac page I can see 404.pl popping up: But I am not able to find what is missing. I have checked the 'view-source' of the page but don't see any links to non-existing files. Any ideas on how to find what is missing? Thank you very much for any help or ideas. Rudy Wuthrich Kodaikanal International School -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 32578 bytes Desc: not available URL: From mtj at kohaaloha.com Mon Jun 28 15:33:58 2021 From: mtj at kohaaloha.com (Mason James) Date: Tue, 29 Jun 2021 01:33:58 +1200 Subject: [Koha-devel] Koha OPAC page messed up after upgrade from 18.04 to 21.05 In-Reply-To: <051301d76c16$95e370b0$c1aa5210$@kis.in> References: <051301d76c16$95e370b0$c1aa5210$@kis.in> Message-ID: <1a9ce33a-9e03-1d7f-cc53-92202a9f508e@kohaaloha.com> hi Rudy ubuntu 21.04 is very new make sure you have the following line in your |/etc/apt/sources.list.d/koha.list| file, (note the 'hirsute') | deb http://debian.koha-community.org/koha-staging 21.05 main hirsute then...  sudo apt update  sudo apt upgrade  sudo systemctl restart koha-common cheers, Mason | On 29/06/21 12:10 am, ism at kis.in wrote: > > I have upgraded our Koha to a new server with Ubuntu 21.04 and Koha 21.05.01.003. > > While data migration and staff page are ok the OPAC page is messed up. > > It seems like some .css or .js  are missing. > > When I open the opac page I can see 404.pl popping up: > > But I am not able to find what is missing. > > I have checked the ‘view-source’ of the page but don’t see any links to non-existing files. > > Any ideas on how to find what is missing? > > Thank you very much for any help or ideas. > > Rudy Wuthrich > Kodaikanal International School > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : https://www.koha-community.org/ > git : https://git.koha-community.org/ > bugs : https://bugs.koha-community.org/ From mtj at kohaaloha.com Mon Jun 28 15:38:32 2021 From: mtj at kohaaloha.com (Mason James) Date: Tue, 29 Jun 2021 01:38:32 +1200 Subject: [Koha-devel] Koha OPAC page messed up after upgrade from 18.04 to 21.05 In-Reply-To: <1a9ce33a-9e03-1d7f-cc53-92202a9f508e@kohaaloha.com> References: <051301d76c16$95e370b0$c1aa5210$@kis.in> <1a9ce33a-9e03-1d7f-cc53-92202a9f508e@kohaaloha.com> Message-ID: <5f244f6e-1259-8df0-02bf-94179f0684c0@kohaaloha.com> On 29/06/21 1:33 am, Mason James wrote: > hi Rudy > ubuntu 21.04 is very new > > make sure you have the following line in your |/etc/apt/sources.list.d/koha.list| file, (note the 'hirsute') > > | deb http://debian.koha-community.org/koha-staging 21.05 main hirsute oops!!!  the correct line is... deb http://debian.koha-community.org/koha 21.05 main hirsute From kohanews at gmail.com Mon Jun 28 18:13:15 2021 From: kohanews at gmail.com (Koha Newsletter) Date: Mon, 28 Jun 2021 18:13:15 +0200 Subject: [Koha-devel] Koha Community Newsletter: June 2021 Message-ID: The Koha Community Newsletter for June 2021 is here: * https://koha-community.org/koha-community-newsletter-june-2021/ Many thanks to everyone who submitted articles and news to last month's newsletter! Please feel free to email me with any corrections or suggestions. -- Michael Kuhn Editor, Koha Community Newsletter -------------- next part -------------- An HTML attachment was scrubbed... URL: From ism at kis.in Mon Jun 28 18:43:13 2021 From: ism at kis.in (ISM KIS) Date: Mon, 28 Jun 2021 22:13:13 +0530 Subject: [Koha-devel] Koha OPAC page messed up after upgrade from 18.04 to 21.05 In-Reply-To: <051301d76c16$95e370b0$c1aa5210$@kis.in> References: <051301d76c16$95e370b0$c1aa5210$@kis.in> Message-ID: On my new Koha 21.05 the OPAC (opacheader_en) in preview looks correct. But then on the OPAC site it looks like jQuery or css are missing. Why would that be? Why does the page not show the same thing as the preview? On Mon, Jun 28, 2021 at 5:40 PM wrote: > I have upgraded our Koha to a new server with Ubuntu 21.04 and Koha > 21.05.01.003. > > > > While data migration and staff page are ok the OPAC page is messed up. > > It seems like some .css or .js are missing. > > > > When I open the opac page I can see 404.pl popping up: > > > > But I am not able to find what is missing. > > > > I have checked the ‘view-source’ of the page but don’t see any links to > non-existing files. > > > > Any ideas on how to find what is missing? > > > > Thank you very much for any help or ideas. > > > > Rudy Wuthrich > Kodaikanal International School > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 32578 bytes Desc: not available URL: From indradg at gmail.com Mon Jun 28 18:56:55 2021 From: indradg at gmail.com (Indranil Das Gupta) Date: Mon, 28 Jun 2021 22:26:55 +0530 Subject: [Koha-devel] Koha OPAC page messed up after upgrade from 18.04 to 21.05 In-Reply-To: References: <051301d76c16$95e370b0$c1aa5210$@kis.in> Message-ID: Hi Ruth, Koha 20.11 (which you skipped) removed support for the ancient Bootstrap 2.3.x (2013 vintage) and replaced it with Bootstrap 4.5 (released May 2020). The classes, grid system, scaffolding and pseudo classes etc have undergone several changes. And based on that Koha OPAC's own markup too had changed e.g. instead of #wrap it's now #wrapper IIRC. You will need to touch up the custom HTML, css and JavaScript that you had added earlier and make it compliant to the new structure. HTH, Indranil Das Gupta L2C2 Technologies On Mon, 28 Jun, 2021, 10:13 pm ISM KIS, wrote: > On my new Koha 21.05 the OPAC (opacheader_en) in preview looks correct. > But then on the OPAC site it looks like jQuery or css are missing. > > Why would that be? Why does the page not show the same thing as the > preview? > > On Mon, Jun 28, 2021 at 5:40 PM wrote: > >> I have upgraded our Koha to a new server with Ubuntu 21.04 and Koha >> 21.05.01.003. >> >> >> >> While data migration and staff page are ok the OPAC page is messed up. >> >> It seems like some .css or .js are missing. >> >> >> >> When I open the opac page I can see 404.pl popping up: >> >> >> >> But I am not able to find what is missing. >> >> >> >> I have checked the ‘view-source’ of the page but don’t see any links to >> non-existing files. >> >> >> >> Any ideas on how to find what is missing? >> >> >> >> Thank you very much for any help or ideas. >> >> >> >> Rudy Wuthrich >> Kodaikanal International School >> >> >> > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : https://www.koha-community.org/ > git : https://git.koha-community.org/ > bugs : https://bugs.koha-community.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 32578 bytes Desc: not available URL: From M.de.Rooy at rijksmuseum.nl Tue Jun 29 13:36:26 2021 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Tue, 29 Jun 2021 11:36:26 +0000 Subject: [Koha-devel] False qa tools warning? In-Reply-To: References: , Message-ID: Thx for trying. But it does not seem to be the final resolution.. ________________________________ RIJKS MUSEUM ​T/m 18 jaar gratis ​ ​Kijk hier de nieuwste aflevering van Rijksmuseum Unlocked RM xxx ​Please think before you print Van: Koha-devel namens Jonathan Druart Verzonden: vrijdag 25 juni 2021 16:11 Aan: Marcel de Rooy CC: koha-devel Onderwerp: Re: [Koha-devel] False qa tools warning? I've answered on the bug report. It's a valid error. Le lun. 21 juin 2021 à 15:37, Marcel de Rooy a écrit : > > Hi all, > > I am looking at bug 27944 and see the following qa warn: > > FAIL koha-tmpl/intranet-tmpl/prog/en/modules/circ/request-article.tt > OK filters > OK forbidden patterns > OK git manipulation > OK js_in_body > SKIP spelling > OK tt_valid > FAIL valid_template > Attempt to reload Koha/Template/Plugin/Biblio.pm aborted. > Compilation failed in require at /usr/lib/x86_64-linux-gnu/perl5/5.28/Template/Plugins.pm line 206. > > This seems to be a false warning. > But since it apparently refers to a compile error, I still would like to know where does it come from? > The module for the Biblio plugin compiles just fine. > The [% USE Biblio %] comes from an include in the template: biblio-view-menu.inc. > > Any ideas? > > Thnx, > Marcel > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.koha-community.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fkoha-devel&data=04%7C01%7Cm.de.rooy%40rijksmuseum.nl%7Cd95737498b6b4a2bbee708d937e32527%7C635b05eb66c748e1a94fb4b05a1b058b%7C0%7C0%7C637602271584807514%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=lhERNy8jDeAg1jNQxHIWkwE9RjQB0L9c%2FIM17kqA1QU%3D&reserved=0 > website : https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.koha-community.org%2F&data=04%7C01%7Cm.de.rooy%40rijksmuseum.nl%7Cd95737498b6b4a2bbee708d937e32527%7C635b05eb66c748e1a94fb4b05a1b058b%7C0%7C0%7C637602271584817509%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3OAK%2BCU2QGjqwWBaKHrfFcWhhuJZWSYjuk1Fisei36g%3D&reserved=0 > git : https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.koha-community.org%2F&data=04%7C01%7Cm.de.rooy%40rijksmuseum.nl%7Cd95737498b6b4a2bbee708d937e32527%7C635b05eb66c748e1a94fb4b05a1b058b%7C0%7C0%7C637602271584817509%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=MayItuZ5xpXc952xHG99HKw4GgcrBKYxyqwwczZpnFA%3D&reserved=0 > bugs : https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.koha-community.org%2F&data=04%7C01%7Cm.de.rooy%40rijksmuseum.nl%7Cd95737498b6b4a2bbee708d937e32527%7C635b05eb66c748e1a94fb4b05a1b058b%7C0%7C0%7C637602271584817509%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=gPJJtYfFKcKYdKfyI8upv0tfkw5xE%2BJouGVEAad5trI%3D&reserved=0 _______________________________________________ Koha-devel mailing list Koha-devel at lists.koha-community.org https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.koha-community.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fkoha-devel&data=04%7C01%7Cm.de.rooy%40rijksmuseum.nl%7Cd95737498b6b4a2bbee708d937e32527%7C635b05eb66c748e1a94fb4b05a1b058b%7C0%7C0%7C637602271584817509%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=NY%2FCV4oITvhXdU8vj4xqGqF2mw%2Fhr0PL5Cvf11iIkkU%3D&reserved=0 website : https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.koha-community.org%2F&data=04%7C01%7Cm.de.rooy%40rijksmuseum.nl%7Cd95737498b6b4a2bbee708d937e32527%7C635b05eb66c748e1a94fb4b05a1b058b%7C0%7C0%7C637602271584817509%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3OAK%2BCU2QGjqwWBaKHrfFcWhhuJZWSYjuk1Fisei36g%3D&reserved=0 git : https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.koha-community.org%2F&data=04%7C01%7Cm.de.rooy%40rijksmuseum.nl%7Cd95737498b6b4a2bbee708d937e32527%7C635b05eb66c748e1a94fb4b05a1b058b%7C0%7C0%7C637602271584817509%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=MayItuZ5xpXc952xHG99HKw4GgcrBKYxyqwwczZpnFA%3D&reserved=0 bugs : https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.koha-community.org%2F&data=04%7C01%7Cm.de.rooy%40rijksmuseum.nl%7Cd95737498b6b4a2bbee708d937e32527%7C635b05eb66c748e1a94fb4b05a1b058b%7C0%7C0%7C637602271584817509%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=gPJJtYfFKcKYdKfyI8upv0tfkw5xE%2BJouGVEAad5trI%3D&reserved=0 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image632466.jpg Type: image/jpeg Size: 10243 bytes Desc: image632466.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image457223.png Type: image/png Size: 910 bytes Desc: image457223.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image096087.png Type: image/png Size: 737 bytes Desc: image096087.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image194367.png Type: image/png Size: 799 bytes Desc: image194367.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image292038.png Type: image/png Size: 804 bytes Desc: image292038.png URL: From wainuiwitikapark at catalyst.net.nz Wed Jun 30 04:01:48 2021 From: wainuiwitikapark at catalyst.net.nz (Wainui Witika-Park) Date: Wed, 30 Jun 2021 14:01:48 +1200 Subject: [Koha-devel] Koha 19.11.19 released Message-ID: <7a70f74e-9493-e37d-ca53-82d6f747189f@catalyst.net.nz> Hello everyone! The Koha community is proud to announce the release of version 19.11.19. The full release notes can be found at: https://koha-community.org/koha-19-11-19-release/ Thank you to everyone involved! Cheers, Wainui Witika-Park (she/her) From julien.sicot at univ-rennes2.fr Wed Jun 30 12:08:32 2021 From: julien.sicot at univ-rennes2.fr (Julien Sicot) Date: Wed, 30 Jun 2021 12:08:32 +0200 Subject: [Koha-devel] Embed see-from headings (authorities) into bibliographic records at OAI repository level In-Reply-To: <7857ec78-cf08-5525-7421-db7341c2d8c2@web.de> References: <7857ec78-cf08-5525-7421-db7341c2d8c2@web.de> Message-ID: <9659CD54-B5F5-4708-954F-48B719B5B716@univ-rennes2.fr> Hi Katrin, I create bug 28639 I have also submitted a patch proposal There is probably a better way to do this. if someone can take a look at it, he is welcome :-) Thanks again Best Julien Sicot Applications documentaires DSI - Pôle Applications Université Rennes 2 02 22 51 44 41 > Le 27 juin 2021 à 10:27, Katrin Fischer a écrit : > > Hi Julien, > > not sure if GetMarcBiblio would be the best spot, but I like the idea in general, especially as an optional switch. Maybe file a bug report for further discussion? > > Katrin > > On 19.06.21 20:08, Julien Sicot wrote: >> Hi all, >> >> An enhancement idea : >> >> It could be interesting to enrich the bibliographic records exposed in OAI with see-from headings, this would allow users who use koha with a discovery tool to be able to manage, normalize and index some authorities data ? >> >> This is something that could be done directly in C4::Biblio::GetMarcBiblio following the same method used for embedding items. >> We could use an optional parameter like embed_items (embed_seefromheading) and a function similar to C4::Biblio::EmbedItemsInMarcBiblio by reusing what was made for zebra with EmbedSeeFromHeadings (bug #7417 ). >> >> What do you think about this? >> >> <096af0a1-34a2-4a88-ac19-85cad80f4cb1.png> >> >> Thanks for feedback, >> Best >> >> -- >> Julien Sicot >> Systems Librarian >> Université Rennes 2 >> 02 22 51 44 41 >> >> >> >> _______________________________________________ >> Koha-devel mailing list >> Koha-devel at lists.koha-community.org >> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >> website : https://www.koha-community.org/ >> git : https://git.koha-community.org/ >> bugs : https://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 : https://www.koha-community.org/ > git : https://git.koha-community.org/ > bugs : https://bugs.koha-community.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: