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

Koha Development Meeting Reminder
by Nick Clemens 11 Apr '17

11 Apr '17

Hi All, Just a friendly reminder that the next Koha Development IRC meeting is tomorrow, 12 April 2017, at 19UTC And a reminder that April is quickly followed by May so now is a good time to come and mention anything of import for 17.05. Here is a converter for local date and time: https://www.timeanddate.com/worldclock/fixedtime.html?msg=Koha+Developers+I… The agenda is on the wiki, please add any topics you wish to discuss https://wiki.koha-community.org/wiki/Development_IRC_meeting_12_April_2017#… I will try to send an ES update before or after the meeting, hope to see you all there :-) -Nick

1 0

Plack and CGI : where to put initialization code ?
by Julian Maurice 10 Apr '17

10 Apr '17

Hello developers, I need to execute code at the beginning of every request. For now it's in a BEGIN block. It works well in CGI mode, but not at all with plack (it's only executed once). I tried moving the BEGIN block into a sub init(), calling this sub in the BEGIN block and in the PSGI file (in CGI::new wrapper). It works but it doesn't feel "right". Is there a common place to put this kind of code ? Should I use the L1 cache (which is flushed at every request) to store some state (initialized or no) and call init() in every method of the module or something like that ? -- Julian Maurice <julian.maurice(a)biblibre.com> BibLibre

2 2

What's on in koha-devel #11
by Jonathan Druart 04 Apr '17

04 Apr '17

Hello librarians and developers, Not much has happened this month in terms of development. Things are going very slowly at the moment, despite the hackfest in Marseille. We see a lot of new people on the mailing list and the IRC channel asking for questions, but we need more people to be involved in the discussions and the signoff process. There are hundreds of people on this list, you need to know that the Koha community needs you to make the project moving forward. I know that nobody has enough time, but you know one hour per week of even per month can help a lot. It is very easy, fun and interesting :) = How to get involved? = The first action would be to join us on the #koha IRC channel and the koha-devel mailing list. Start by presenting yourself, where do you come from, what do you do? For how long have you been using Koha? How do you think you can help? Attend meetings! We have two kinds of monthly meeting. There is a general one to talk about koha-related stuffs, and the development meeting to talk about technical stuffs. It is important for the community to have a place to be all together and try to make things move. If you are a librarian, we need you to tell developers the directions they need to go. Open bug reports It is important to know that everybody can open new bug reports on our bug tracker (https://bugs.koha-community.org) It is useful for the development team to know the new bugs. And it is also important for you to search for known bugs. A lot of bugs are known from developers but we do not know how to fix them because we are waiting for feedbacks from users. The dashboard (http://dashboard.koha-community.org) is very helpful to know the "hot" bugs that need to be fixed/tested/QAed. The "Overall bug traker health status" section displays the number of new bugs that are important to follow, make moving. If a developer submits a patch for the bug you opened, try and test it! Test bugs Here is how you can really makes things move for the community. You become involved in the development process and make the Koha project better. Sandboxes (https://wiki.koha-community.org/wiki/Sandboxes) are available to test patch easily. You do not need to install anything on your computer and do not need any technical skills. If you are a Koha user, you can test patches! Write patches If you are a developer or have a minimum of technical skills you can write your own patches and fixes bugs or develop new feature. Our dedicated wiki page (wiki.koha-community.org/wiki/Submitting_A_Patch) will guide you over the different steps. It is very easy to get a development environment using KohaDevBox ( https://github.com/digibib/kohadevbox) Start with small patches :) = Refactoring = If you have read my previous "what's on in koha-devel" emails, you may have noticed I talked a lot of "refactoring" bugs. And maybe you do not know what it is and what it brings. The Koha codebase is aged/old, and has grown very quickly since 2006. Since the last few years the development team decided to make the code more robust and slow the integration of patches, getting a stronger integration process. That's why we need to have at least one tester validating the patches, then one QAer to review the patch technically and finally the Release Manager to push it. That's mean 4 independent persons for a single patch. That made our codebase stronger and less regression prone. Some part of the code now needs to be rewritten, and it is why I have focussed on the "refactoring" work over the last year. The goal is to rewrite modules of Koha, step by step. It cleans the code, makes it more readable, reduces the number of lines, centralise the responsibilities, homogenise the code, fixes bugs, adds test coverage, etc. On the mid-long term it means a modern application, easy to maintain, robust, flexible. The bugs will be easier to fix, the enhancements will be quicker to develop and so less expensive. Do you start to understand how it is useful? So yes, it's boring to test because it does not bring anything new to the interface, but the project needs it. If you have been using Koha for months or years, it made you save money, it makes you happy to use it and you love it. If you already got answer from people on the mailing lists or the IRC channel, it's time to say thank you, by getting involved! If you have any specific questions on how to get involved, you can join me on the IRC channel or by email. I can help and guide you if necessary. A developer that loves Koha but needs help, Jonathan

2 1

KohaDevBox refatoring
by Tomas Cohen Arazi 03 Apr '17

03 Apr '17

Hi everyone, this wekend I took the time to reorganize the tasks that are ran to get KohaDevBox up and running. The main task was splitting some steps (like koha-common install, instance creation and gitifying) This makes it easier to spot potential order issues. As usual, I hope you can have some time to test it and file bugs if needed. I'll try to fix them ASAP. Thanks! -- Tomás Cohen Arazi Theke Solutions (https://theke.io <http://theke.io/>) ✆ +54 9351 3513384 GPG: B2F3C15F

1 0

Documenting notices and scripts
by Barton Chittenden 31 Mar '17

31 Mar '17

I've been working on documenting all of the possible notices in the letter table, in terms of letter_code, available markup, and which tables we can pull data from. this is collected here: https://wiki.koha-community.org/wiki/Customising_Notices_and_Slips#Notice_S… I updated the wiki page this morning, everything is up-to-date with master... but there's one thing I don't understand: SendAlerts. It looks like the letter code is passed in via cgi param, and I don't know what letter_codes are available for the calls in C4/Serials.pm, acqui/ lateorders.pl and serials/claims.pl Searching for enlightenment, --Barton

1 0

Koha Community Newsletter: March 2017
by kohanews 31 Mar '17

31 Mar '17

Fellow Koha users: The Koha Community Newsletter for March 2017 is here: https://koha-community.org/koha-community-newsletter-march-2017/ Many thanks to the folks who submitted articles and news to this month's newsletter. Please feel free to email me with any corrections or suggestions. Thanks! -- Chad Roseburg Editor, Koha Community Newsletter

1 0

[Koha] Koha 3.22.19 security release
by Julian Maurice 31 Mar '17

31 Mar '17

The Koha community is proud to announce the release of Koha 3.22.19. This is a security release and contains several bugfixes. If you are running 3.22.x it is strongly recommended to upgrade. The full release notes are available at https://koha-community.org/koha-3-22-19-security-release/

1 0

Koha 16.11.06 released
by Katrin 31 Mar '17

31 Mar '17

The Koha community is proud to announce the release of Koha 16.11.06. This is a maintenance release of 16.11 and contains 9 bugfixes. The full release notes are available at https://koha-community.org/koha-16-11-06-release/ Packages will be available soon.

2 1

MySQL silently truncating strings due to 3 byte limit in 'utf8' charset
by David Cook 31 Mar '17

31 Mar '17

Hi all, I ran into a problem this afternoon where MySQL was silently truncating my UTF8 encoded string in biblio_metadata.metadata and biblio.notes. Admittedly, the string had some funny looking data*, but it was all valid UTF8. I had zero problems with XML::LibXML or MARC::Record. However, whenever I would use DBI or the mysql command line client, I’d get a truncated string**. This meant a completely invalid XML record which is irretrievable from the database using Koha’s XML handling methods. However, I eventually found https://bugs.mysql.com/bug.php?id=53005 where they state that the MySQL ‘utf8’ charset has a 3 byte limit (https://dev.mysql.com/doc/refman/5.7/en/charset-unicode-utf8.html) That tends to be fine in most cases, but 𝔤 is 4 bytes (f0 9d 94 a4 http://dev.networkerror.org/utf8/?start=120100 <http://dev.networkerror.org/utf8/?start=120100&end=120200&cols=4&show_uni_i…> &end=120200&cols=4&show_uni_int=on&show_uni_hex=on&show_html_ent=on&show_raw_hex=on&show_raw_bin=on). It was on this character that the truncation happened. Apparently, there is a 4 byte UTF-8 charset called utf8mb4: https://dev.mysql.com/doc/refman/5.7/en/charset-unicode-utf8mb4.html. If you “SET NAMES = ‘utf8mb4’” for your client and set the charset for your database column, that will allow you to correctly insert the data. So the truncation doesn’t generate an error but it does generate a warning, which is much more obvious in the mysql CLI client than when using DBI: MariaDB [devkohadcook]> update biblio set abstract = 'We introduce a new perspective and a generalization of spectral networks for 4d N=2" style="position: relative;" tabindex="0" id="MathJax-Element-1-Frame" class="MathJax">=2 theories of class S" style="position: relative;" tabindex="0" id="MathJax-Element-2-Frame" class="MathJax"> associated to Lie algebras g=An" style="position: relative;" tabindex="0" id="MathJax-Element-3-Frame" class="MathJax">𝔤=An, Dn" style="position: relative;" tabindex="0" id="MathJax-Element-4-Frame" class="MathJax">Dn, E6" style="position: relative;" tabindex="0" id="MathJax-Element-5-Frame" class="MathJax">E6, and E7" style="position: relative;" tabindex="0" id="MathJax-Element-6-Frame" class="MathJax">E7. Spectral networks directly compute the BPS spectra of 2d theories on surface defects coupled to the 4d theories. A Lie algebraic interpretation of these spectra emerges naturally from our construction, leading to a new description of 2d-4d wall-crossing phenomena. Our construction also provides an efficient framework for the study of BPS spectra of the 4d theories. In addition, we consider novel types of surface defects associated with minuscule representations of g" style="position: relative;" tabindex="0" id="MathJax-Element-7-Frame" class="MathJax">𝔤.' where biblionumber = 50314; Query OK, 0 rows affected, 1 warning (0.00 sec) Rows matched: 1 Changed: 0 Warnings: 1 Because it doesn’t raise an exception, I’d say it’s silent. You have to check for it. Using mysql, you can send “SHOW WARNINGS” after the insert query and you can see something like: +---------+------+--------------------------------------------------------------------------------+ | Level | Code | Message | +---------+------+--------------------------------------------------------------------------------+ | Warning | 1366 | Incorrect string value: '\xF0\x9D\x94\xA4=A...' for column 'abstract' at row 1 | +---------+------+--------------------------------------------------------------------------------+ 1 row in set (0.01 sec) With DBI, it’s harder: http://stackoverflow.com/questions/7946655/dbi-perl-logging-mysql-warnings. Apparently you can use $dbh->{mysql_warning_count} to check for warnings, and then send “SHOW WARNINGS” via the same database handle and that should give you your warning result. Or you can run MySQL in “traditional” mode which treats warnings as errors. So this seems like an edgecase… it’s some wonky data (albeit valid UTF8 data) in an otherwise English record. However, according to MySQL (I haven’t verified for myself), Chinese, Japanese, and Korean sometimes use 4 bytes for characters. So people using these languages with Koha could be getting truncated data without realising that’s what is happening or why. I’ve tried out utf8mb4 and it works great. I think the downside is that it uses more space for certain types of columns because it needs to allocate more space for that 4th byte. I don’t know whether we should consider switching from utf8 to utf8mb4, so that we’re inclusive of CJK and comply with RFC3629 which states that there’s a 4 byte maximum. I think it’s worth discussion though. This wouldn’t just affect libraries in Asia. It would affect any library which stores records with CJK characters in a MARC 880 “Alternate Graphic Representation” field. I’m at the end of my Friday work day, so I’m going to leave it there, but food for thought! *Aforementioned strange data: We introduce a new perspective and a generalization of spectral networks for 4d N=2" style="position: relative;" tabindex="0" id="MathJax-Element-1-Frame" class="MathJax">=2 theories of class S" style="position: relative;" tabindex="0" id="MathJax-Element-2-Frame" class="MathJax"> associated to Lie algebras g=An" style="position: relative;" tabindex="0" id="MathJax-Element-3-Frame" class="MathJax">𝔤=An, Dn" style="position: relative;" tabindex="0" id="MathJax-Element-4-Frame" class="MathJax">Dn, E6" style="position: relative;" tabindex="0" id="MathJax-Element-5-Frame" class="MathJax">E6, and E7" style="position: relative;" tabindex="0" id="MathJax-Element-6-Frame" class="MathJax">E7. Spectral networks directly compute the BPS spectra of 2d theories on surface defects coupled to the 4d theories. A Lie algebraic interpretation of these spectra emerges naturally from our construction, leading to a new description of 2d-4d wall-crossing phenomena. Our construction also provides an efficient framework for the study of BPS spectra of the 4d theories. In addition, we consider novel types of surface defects associated with minuscule representations of g" style="position: relative;" tabindex="0" id="MathJax-Element-7-Frame" class="MathJax">𝔤. ** Truncated string: We introduce a new perspective and a generalization of spectral networks for 4d N=2" style="position: relative;" tabindex="0" id="MathJax-Element-1-Frame" class="MathJax">=2 theories of class S" style="position: relative;" tabindex="0" id="MathJax-Element-2-Frame" class="MathJax"> associated to Lie algebras g=An" style="position: relative;" tabindex="0" id="MathJax-Element-3-Frame" class="MathJax">𝔤 David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595

3 4

Development/ QA protocol question
by Cab Vinton 30 Mar '17

30 Mar '17

Hi, All -- A small group of small NH libraries has co-sponsored a small enhancement to get its feet wet in the Koha development world: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14365 As I understand it, once a patch has been signed off & passed on to QA, it can hit a bottleneck as there are limited number of QA Team Members. To make this as positive experience as possible for our informal consortium & to increase the chances of similar collaborations in the future, it would help if we can move through the development process as quickly as possible. So here's my question -- For sponsored (i.e., funded) projects, would it make sense to include funds to pay for the cost of a QA Team Member's time to review a patch? I'm thinking the financial commitment would be one way of boosting a patch's status in the queue. Hounding the developer is another option, of course, but that's unpleasant for both sides :-) I realize the QA person often, & perhaps preferably, will work for a different firm. And there may be other complicating factors I'm not aware of. Grateful for any thoughts from folks on the programming side of things. Cheers, Cab Vinton, Director Plaistow Public Library Plaistow, NH

5 16