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

Re: [Koha-devel] Packing needs - status to add to bugzilla and the dashboard?
by Paul A 09 Mar '16

09 Mar '16

At 07:42 AM 3/9/2016 -0500, Kyle Hall wrote: >Also, are you saying any newly packaged libraries *must* make it in to >Debian? Can we not host our own packaged libraries on our apt server? Why >must packages meet the Debian requirements? >This seems like it's adding yet another barrier to entry for new Koha >developers. Now we all need to be Debian package maintainers as well? >It seems like we're taking away one of the most powerful features of Perl, >it's extensive library of available modules. One of Koha's strengths certainly was, and most probably still is, the ability for an admin to be able to aptitude/apt-get (even yum) dependencies that conform to her o/s. We used to publish "warnings" about using CPAN. Debian trickles down to Ubuntu -- with a possible time-lag -- and these two o/s are perhaps the most used by Koha-based libraries. If Koha needs to use a custom *library* and there is reticence to put it through the Debian/Ubuntu loop, surely the proper solution is to put it into the Koha environment (package and tarball) where it remains Koha-specific and the remainder of the o/s, including Perl, stays unchanged without potential repercussions on other installed applications/progammes. This might well also facilitate version control -- each Koha update has the correct libraries in /usr/share/koha/bin, /usr/share/koha/lib/C4, wherever, but not in /usr/lib/perl* (or /usr/bin/perl) (with or without /local/) available to the entire o/s. This removes any "barrier to entry for new Koha developers", might ease proper installation/upgrade operations and has the potential to obviate obscure security concerns. Best -- Paul >Just a thought. > ><http://www.kylehall.info>http://www.kylehall.info >ByWater Solutions ( <http://bywatersolutions.com>http://bywatersolutions.com ) >Meadville Public Library ( ><http://www.meadvillelibrary.org>http://www.meadvillelibrary.org ) >Crawford County Federated Library System ( ><http://www.ccfls.org>http://www.ccfls.org ) >Mill Run Technology Solutions ( ><http://millruntech.com>http://millruntech.com ) > >On Tue, Mar 8, 2016 at 6:03 PM, Galen Charlton ><<mailto:gmc@esilibrary.com>gmc(a)esilibrary.com> wrote: >Hi, > >On Tue, Mar 8, 2016 at 12:50 PM, Brendan Gallagher ><<mailto:info@bywatersolutions.com>info(a)bywatersolutions.com> wrote: >Do we have a defined role description of responsibility of the Packaging >Manager?Â (I've only read Robin's posts to the mailing list before - is >that it?) > > >We do now, seeded with my view of the position: > ><https://wiki.koha-community.org/wiki/Project_roles#Packaging_manager>https://wiki.koha-community.org/wiki/Project_roles#Packaging_managerÂ > > >On a side note, the overall page is new; I'm figuring that it might be a >useful exercise to outline minimum role responsibilities for all of the >named project positions. > >Regards, > >Galen >-- >Galen Charlton >Infrastructure and Added Services Manager >Equinox Software, Inc. / Open Your Library >email: Â <mailto:gmc@esilibrary.com>gmc(a)esilibrary.com >direct: <tel:%2B1%20770-709-5581>+1 770-709-5581 >cell: Â <tel:%2B1%20404-984-4366>+1 404-984-4366 >skype: Â gmcharlt >web: Â Â <http://www.esilibrary.com/>http://www.esilibrary.com/ >Supporting Koha and Evergreen: ><http://koha-community.org>http://koha-community.org & http://evergreen-ils.org > >_______________________________________________ >Koha-devel mailing list ><mailto:Koha-devel@lists.koha-community.org>Koha-devel(a)lists.koha-community.org >http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >website : <http://www.koha-community.org/>http://www.koha-community.org/ >git : <http://git.koha-community.org/>http://git.koha-community.org/ >bugs : <http://bugs.koha-community.org/>http://bugs.koha-community.org/ > > >_______________________________________________ >Koha-devel mailing list >Koha-devel(a)lists.koha-community.org >http://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/ --- Maritime heritage and history, preservation and conservation, research and education through the written word and the arts. <http://NavalMarineArchive.com> and <http://UltraMarine.ca>

4 4

Packing needs - status to add to bugzilla and the dashboard?
by Brendan Gallagher 09 Mar '16

09 Mar '16

Hello All - I'd like to have a chance to talk about the packing work flow at the next developers meeting or even the general meeting. My thoughts are that we need a status in Bugzilla that says something like "Needs package created" or something. Also add a little spot on the dashboard under the Bugs Statuses which has a canned search for that queue. I imagine the workflow being something like... 1. RM pushes code to master 2. RM changes status to "needs package created" 3. PackingManager creates package 4. PM changes the status to "Pushed to Master" The work flow is important and I'd like to make it as transparent as possible and make sure that we don't miss something. Robin, Galen, or others do you have any thoughts on this? Thanks, Brendan -- --------------------------------------------------------------------------------------------------------------- Brendan A. Gallagher ByWater Solutions CEO Support and Consulting for Open Source Software Installation, Data Migration, Training, Customization, Hosting and Complete Support Packages Headquarters: Santa Barbara, CA - Office: Redding, CT Phone # (888) 900-8944 http://bywatersolutions.com info(a)bywatersolutions.com

5 9

Attaching files in Koha 3.22
by Keith Kahn-Harris 09 Mar '16

09 Mar '16

Hello I am working on an archiving project for a library that has just adopted Koha 3.18. We are planning on undertaking a sizeable digitisation project for various special collections we hold - including sound files, pdfs and jpegs. The question we are looking at now is where to host these files. I understand that Koha 3.22 allows for attaching files to bibliographic records. What I’d like to know is how well this system works as a means of hosting archival material - and whether it obviates the need for a separate archiving and hosting system. So has anyone on this list used Koha 3.22 for this purpose? Are there any library systems I can look at that display attached files through Koha 3.22? Or does anyone have some screenshots they could send me? Do excuse the lack of technical literacy - we are only just getting going on this process and grappling with Koha. Many thanks Dr Keith Kahn-Harris

2 1

merge_authority.pl and merges in general not working correctly on 3.22 and master
by Remi MP 09 Mar '16

09 Mar '16

Hi, one of our clients has just migrated to 3.22.04 and noticed that even since bug15358, authority merge will not change the corresponding notices properly. It changes the authority number in the biblios but not the corresponding fields. Also, the merge_authority.pl script doesn't work on master : Can't locate object method "authtypecode" via package "2" (perhaps you forgot to load "2"?) at ./merge_authority.pl line 58. Is this an important issue for anyone else?

3 3

Proposal - Deal with modules versioning ($VERSION)
by Jonathan Druart 09 Mar '16

09 Mar '16

Hi devs, During the last dev meeting [1] we talked about how we should manage the $VERSION var of our Koha modules. (a)The first idea was to remove it: it is stuck to an old version and it does not make sense to keep it as it. Another idea would be to keep it and use it (i.e. update it). This idea has already been discussed on bug 7941 [2], but never been set up. In this second approach, there are different ways to do, either we update all of our modules to the Koha::version or update them individually, when they change. Based on 2 blog entries [3, 4] and the Perl Best Practices (Chap 17: Modules, Version Numbers), the way to do would be to use a three-part version numbers ('1.0.3') using the version module (`use version; our $VERSION = qv('1.0.3');`). But there are no specific guidelines to manage the different modules inside a project. I have checked several perl projects and they don't assign a version to each modules (Dancer, DBIx::Class, Mail-SpamAssassin). (b)Set the same $VERSION variable to all our modules does not seem very useful (unless making `perlcritic -2` happy). (c)On the contrary it would make sense to version them individually, following the Koha::version: when a module is modified, the minor version is increased. That would be easy to do for stable releases: the version is updated when releasing. But for master we could have a module version > Koha::version (indeed the Koha::version is only updated when a DB entry is added). To avoid that we could decide not to update the version during the development process (master). (d)Another way to do would be to initially set the version to 1.0.0 (or 3.0.0 or whatever) to all the modules and increase the version when they are modified, but the version numbers would not make sense and won't be helpful: some unchanged modules will have 1.0.1 and others 1.2.34. I think (c) makes sense: for instance if C4::Budgets is not modified between 3.22.x and 3.24.x, its version will stick to 3.22.x. Looking at this version we would know if this module has been updated recently or not. Concretely, we would set all of our modules to 3.24.00.000 (not that does not respect the 3-digit and 3-part version numbers "conventions") when releasing 3.24 (scripts will provided to automate everything), 3.25 will come and won't update the module versions until 3.26. 3.24 RMaint will update the versions of the modified modules when releasing 3.24.01.000 3.26 RM will update the versions of the modified modules when releasing 3.26.00.000 Note that we could "back-versioning" the modules of all our stable branches (3.18, 3.20 and 3.22). What are your thoughts? Are you more a, b, c, d or ... e? Cheers, Jonathan [1] http://meetings.koha-community.org/2016/development_irc_meeting_1_march_201… at 15:40:52 [2] https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7941#c2 [3] http://www.modernperlbooks.com/mt/2009/07/version-confusion.html [4] http://www.dagolden.com/index.php/369/version-numbers-should-be-boring/

5 8

General IRC meeting 9 March 2016 at 20:00 UTC
by Brendan Gallagher 08 Mar '16

08 Mar '16

Hello - Just a reminder that there is a General IRC Meeting tomorrow. Here is the link to the agenda. https://wiki.koha-community.org/wiki/General_IRC_meeting_9_March_2016 You'll also find a time converter in the wiki link so you can adjust to your local time. Thanks, Brendan -- --------------------------------------------------------------------------------------------------------------- Brendan A. Gallagher ByWater Solutions CEO

1 0

More qa test tool patches
by Mark Tompsett 08 Mar '16

08 Mar '16

Greetings, Seems like bug 15870 has motivated me to work on patches for Koha’s QA test tool. I just wrote a nicer counter/complimentary patch for 16003 (either or both, I don’t care), and now that “fatal” warning will clear up nicely with bug 16008. GPML, Mark Tompsett

1 0

Fwd: Packing needs - status to add to bugzilla and the dashboard?
by Brendan Gallagher 08 Mar '16

08 Mar '16

Thanks Liz. ---------- Forwarded message ---------- From: Liz Rea <liz(a)catalyst.net.nz> Date: Tue, Mar 8, 2016 at 12:37 PM Subject: Re: [Koha-devel] Packing needs - status to add to bugzilla and the dashboard? To: Brendan Gallagher <info(a)bywatersolutions.com> Robin wrote a couple of quite good wiki pages on this subject: https://wiki.koha-community.org/wiki/Building_Debian_Dependencies https://wiki.koha-community.org/wiki/Building_Debian_Dependencies/Dependenc… On 09/03/16 06:50, Brendan Gallagher wrote: Yup all good points. Not to put it all on the PM - but I think a way to track this in BZ is needed. A better workflow - perhaps based on Chris's point - a "failed QA - needs package" status (or some worded status)? Do we have a defined role description of responsibility of the Packaging Manager? (I've only read Robin's posts to the mailing list before - is that it?) On Tue, Mar 8, 2016 at 9:37 AM, Galen Charlton <gmc(a)esilibrary.com> <gmc(a)esilibrary.com> wrote: Hi, On Tue, Mar 8, 2016 at 12:30 PM, Chris Cormack <chrisc(a)catalyst.net.nz> <chrisc(a)catalyst.net.nz> wrote: I don't think it's fair to push this all on the package manager. If a dev introduces new dependencies that need packaging, it should be their responsibility to make sure this is done. Indeed. I am willing to build *some* packages (and submit them to Debian), but that willingness is decidedly not infinite. The first question that somebody who proposes to add a new dependency should ask themselves is this: is there a way to accomplish the task at hand without adding a new dependency? If not, can the task at hand be accomplished using packages that are already in Debian stable? If not, does the dependency at least have an active third-party ITP (intent to package) in the Debian bug tracker? Regards, Galen -- Galen Charlton Infrastructure and Added Services Manager Equinox Software, Inc. / Open Your Library email: gmc(a)esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org &http://evergreen-ils.org _______________________________________________ Koha-devel mailing listKoha-devel@lists.koha-community.orghttp://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/ -- -- Liz Rea Catalyst.Net Limited Level 6, Catalyst House, 150 Willis Street, Wellington. P.O Box 11053, Manners Street, Wellington 6142 GPG: B149 A443 6B01 7386 C2C7 F481 B6c2 A49D 3726 38B7 -- --------------------------------------------------------------------------------------------------------------- Brendan A. Gallagher ByWater Solutions CEO Support and Consulting for Open Source Software Installation, Data Migration, Training, Customization, Hosting and Complete Support Packages Headquarters: Santa Barbara, CA - Office: Redding, CT Phone # (888) 900-8944 http://bywatersolutions.com info(a)bywatersolutions.com

2 1

ARG! It really is isnt. It is not a typo.
by Mark Tompsett 08 Mar '16

08 Mar '16

Greetings, $ koha-qa.pl –v 2 –c 4 ... FAIL t/db_dependent/Filter_MARC_ViewPolicy.t OK critic OK forbidden patterns OK pod FAIL spelling isnt ==> isn't OK valid ... $ grep isnt t/db_dependent/Filter_MARC_ViewPolicy.t isnt( $unfiltered_record->field('020'), undef, isnt( $unfiltered_record->field('008'), undef, isnt( $filtered_record->field('020'), undef, isnt( $unfiltered_record->field('020'), undef, isnt( $filtered_record->field('008'), undef, isnt( $unfiltered_record->field('008'), undef, Spelling checks should exclude “isnt(“, right? GPML, Mark Tompsett

3 3

Accidental ban from bugzilla
by Remi MP 08 Mar '16

08 Mar '16

Hi, Here at inLibro we are developping a perl script that will allow us to automatically test bugs for conflicts when their statuses are "New", "Needs Signoff","Signed Off" and also "In Discussion". The script will change the bugs' statuses to "patch doesn't apply" and notify the people involved. My issue right now is that when I started testing my put requests on a bug I created on my own, my account got banned until 15:30 this afternoon because of too many login attempts : Your IP (127.0.0.1) has been locked out of this account until 2016-03-04 15:28 UTC, as you have exceeded the maximum number of login attempts. Is there a way I could get unbanned? I will install bugzilla locally to continue testing, but still I need to be able to access bugzilla today. Thank you!

9 11