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

3.4.x String Freeze and Road Map Update
by Chris Nighswonger 26 Oct '11

26 Oct '11

As of 0016 UTC, the 3.4.x branch is in string freeze. Only patches not affecting strings and critical and blocker bugfixes will be pushed. My plans are to release 3.4.6 on 1 November 2011, and to move all subsequent 3.4.x releases to the first of the month. 3.4.7 will release 1 December 2011, and then I plan to move to a bi-monthly release schedule for the 3.4.x branch as long as there are applicable commits. After the release of 3.4.12 (or if several months pass with no applicable commits submitted) I will enter a motion to EOL the 3.4.x branch at the next nearest monthly IRC meeting. If you have any comments/suggestions/critiques of this road map, feel free to respond to this thread with them. Also, if you see something in master which I have missed or know of a 3.4.x patch in bugzilla missed, please feel free to point it out. I'll be glad to catch it in the next release. Kind Regards, Chris Nighswonger Koha 3.4/3.6 Release Maintainer

1 0

Re: [Koha-devel] Koha uninstalled by Debian Linux "update"
by Jared Camins-Esakov 26 Oct '11

26 Oct '11

Brian and David, Please keep these discussions on the list, so that anyone else encountering these issues in the future will be able to find the fix. It looks to me like your problem is the GPG key for the indexdata repository. The good news is, you don't need the indexdata repository anymore, I don't think. Try removing that line from /etc/apt/sources.list, rerunning apt-get update, and reinstalling koha-common. Regards, Jared On Fri, Oct 21, 2011 at 10:05 AM, Weissman, Brian S. < Brian.S.Weissman(a)disney.com> wrote: > Here is what I have found so far. It looks like something in the automatic > updates told the system to remove koha. This excerpt seems to be the > relevant bit from history.log: > > Start-Date: 2011-10-20 10:28:54 > Install: libidzebra-2.0:i386 (2.0.49-1indexdata, automatic) > Upgrade: libidzebra-2.0-mod-grs-regx:i386 (2.0.44-2, 2.0.49-1indexdata), > libidzebra-2.0-dev:i386 (2.0.44-2, 2.0.49-1indexdata), > libidzebra-2.0-mod-grs-xml:i386 (2.0.44-2, 2.0.49-1indexdata) > Remove: koha-common:i386 (3.5-1~git+20111017180723.41928b08), > libidzebra-2.0-mod-dom:i386 (2.0.44-2), libidzebra-2.0-0:i386 (2.0.44-2), > libidzebra-2.0-modules:i386 (2.0.49-1indexdata), > libidzebra-2.0-mod-grs-marc:i386 (2.0.44-2), idzebra-2.0:i386 (2.0.44-2), > libidzebra-2.0-mod-alvis:i386 (2.0.44-2), idzebra-2.0-utils:i386 (2.0.44-2), > libidzebra-2.0-mod-text:i386 (2.0.44-2) > End-Date: 2011-10-20 10:29:03 > > Start-Date: 2011-10-20 10:29:28 > Install: libreadline5:i386 (5.2-7, automatic) > Upgrade: tzdata:i386 (2011k-0squeeze1, 2011l-0squeeze1) > End-Date: 2011-10-20 10:29:32 > > And this is from the term.log: > > Log started: 2011-10-20 10:28:54 > Removing koha-common ... > Stopping Zebra server for koha > Removing idzebra-2.0 ... > Removing idzebra-2.0-utils ... > Removing libidzebra-2.0-modules ... > Removing libidzebra-2.0-mod-text ... > Processing triggers for man-db ... > Preparing to replace libidzebra-2.0-mod-grs-xml 2.0.44-2 (using ... > Unpacking replacement libidzebra-2.0-mod-grs-xml ... > Preparing to replace libidzebra-2.0-mod-grs-regx 2.0.44-2 (using ... > Unpacking replacement libidzebra-2.0-mod-grs-regx ... > Removing libidzebra-2.0-mod-grs-marc ... > Removing libidzebra-2.0-mod-dom ... > Removing libidzebra-2.0-mod-alvis ... > Preparing to replace libidzebra-2.0-dev 2.0.44-2 (using ... > Unpacking replacement libidzebra-2.0-dev ... > Processing triggers for man-db ... > Removing libidzebra-2.0-0 ... > Selecting previously deselected package libidzebra-2.0. > Unpacking libidzebra-2.0 (from ... > Setting up libidzebra-2.0 (2.0.49-1indexdata) ... > Setting up libidzebra-2.0-mod-grs-xml (2.0.49-1indexdata) ... > Setting up libidzebra-2.0-mod-grs-regx (2.0.49-1indexdata) ... > Setting up libidzebra-2.0-dev (2.0.49-1indexdata) ... > Log ended: 2011-10-20 10:29:03 > > Log started: 2011-10-20 10:29:28 > Preparing to replace tzdata 2011k-0squeeze1 (using ... > Unpacking replacement tzdata ... > Setting up tzdata (2011l-0squeeze1) ... > > Current default time zone: 'America/New_York' > Local time is now: Thu Oct 20 10:29:30 EDT 2011. > Universal Time is now: Thu Oct 20 14:29:30 UTC 2011. > Run 'dpkg-reconfigure tzdata' if you wish to change it. > > Selecting previously deselected package libreadline5. > Unpacking libreadline5 (from ... > Setting up libreadline5 (5.2-7) ... > Log ended: 2011-10-20 10:29:32 > > I have since tried to reinstall koha and followed a string of dependencies > and had no success. Here is the chain with the errors. Let me know if you > want more details. > > koha-koha@WW-R-ITLWDW1K5M:~$ sudo apt-get update > (list of gets deleted for space) > Fetched 11.6 MB in 10s (1,091 kB/s) > Reading package lists... Done > W: GPG error: http://ftp.indexdata.dk wheezy Release: The following > signatures w ere invalid: KEYEXPIRED 1319102732 KEYEXPIRED 1319102732 > KEYEXPIRED 1319102732 > > > koha-koha@WW-R-ITLWDW1K5M:~$ sudo apt-get install koha > > The following packages have unmet dependencies: > koha : Depends: koha-common but it is not going to be installed > E: Broken packages > > koha-koha@WW-R-ITLWDW1K5M:~$ sudo apt-get install koha-common > > The following packages have unmet dependencies: > koha-common : Depends: idzebra-2.0 but it is not going to be installed > E: Broken packages > > koha-koha@WW-R-ITLWDW1K5M:~$ sudo apt-get install idzebra-2.0 > > The following packages have unmet dependencies: > idzebra-2.0 : Depends: idzebra-2.0-utils (= 2.0.49-1indexdata) but it is > not going to be installed > Depends: libidzebra-2.0-modules but it is not going to be > installed > E: Broken packages > > koha-koha@WW-R-ITLWDW1K5M:~$ sudo apt-get install idzebra-2.0-utils > > The following packages have unmet dependencies: > idzebra-2.0-utils : Depends: libyaz4 (>= 4.2.10) but 4.0.11-1 is to be > installed > E: Broken packages > > koha-koha@WW-R-ITLWDW1K5M:~$ sudo apt-get install libidzebra-2.0-modules > > The following packages have unmet dependencies: > libidzebra-2.0-modules : Depends: libidzebra-2.0-mod-alvis but it is not > going to be installed > Depends: libidzebra-2.0-mod-dom but it is not > going to be installed > Depends: libidzebra-2.0-mod-grs-marc but it is not > going to be installed > Depends: libidzebra-2.0-mod-text but it is not > going to be installed > E: Broken packages > > koha-koha@WW-R-ITLWDW1K5M:~$ sudo apt-get install libyaz4 > > The following packages have unmet dependencies: > libyaz4 : Depends: libgnutls26 (>= 2.12.6.1-0) but 2.8.6-1 is to be > installed > E: Broken packages > > koha-koha@WW-R-ITLWDW1K5M:~$ sudo apt-get install libgnutls26 > > libgnutls26 is already the newest version. > 0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded. > > koha-koha@WW-R-ITLWDW1K5M:~$ sudo apt-get upgrade libgnutls26 > Reading package lists... Done > Building dependency tree > Reading state information... Done > The following packages have been kept back: > libyaz4 yaz > 0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded. > > That is where I dead end. > > > Brian Weissman > WDW BT, Technical Specialist > Team Disney North - 303B > Office: 407.828.4751 > Brian.S.Weissman(a)Disney.com > > > > -----Original Message----- > From: Hartman, David W. - GBTS Library > Sent: Thursday, October 20, 2011 6:18 PM > To: Robin Sheat > Cc: Weissman, Brian S. > Subject: Re: [Koha-devel] Koha uninstalled by Debian Linux "update" > > Yes, we'll report what we can and thanks for your help! > > Sent from my iPhone! Pardon typos, etc. > > > On Oct 20, 2011, at 6:12 PM, "Robin Sheat" <robin(a)catalyst.net.nz> wrote: > > > Hartman, David W. - GBTS Library schreef op do 20-10-2011 om 11:44 > > [-0400]: > >> Just a heads up that a recent “update” by Debian Linux removed the > >> application Koha – my apache and data files apparently are fine. > >> > >> How do I reinstall Koha without damaging or overwriting my data? If > >> anyone has any experience with this, please let me know. > >> > > Just reinstall the koha-common package. Grab a backup if you want to be > > safe, but I'd expect it would be fine. If everything in /etc/ is > > untouched (which I'd expect) then it should just magically work again. > > > >> If you see the red “burst” in the upper right hand corner, only do the > >> safe install .. or else… > > > > Are you able to provide me with more information? Perhaps the logs > > in /var/log/apt or so. I'd like to see what was going on there. > > > > Robin. > > <signature.asc> > > _______________________________________________ > > 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/ > -- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins(a)cpbibliography.com (web) http://www.cpbibliography.com/

5 5

Bugzilla changes/improvements
by Paul Poulain 25 Oct '11

25 Oct '11

Hello koha-devel, I'm doing a checking of our bugzilla usage. I've added some pages on the wiki about submitting a patch, and have some questions/propositions. Please give me your opinion about them. The propositions that won't be agreed by all (unanimity) will be discussed in a later IRC meeting. Here they are, in random order. • what's the difference between master and Rel_3_8 versions ? I feel "master" should not be used for bugs, only for ENH, and, when a patch is submitted for an ENH, it should be attached to "next planned version" (ie : Rel_3_8 those days) • The priority is used to set "patch sent". This is a problem as we completly loose Priority field usage. A solution would be to have a patch status "patch sent" added, have the patch status always visible, and keep priority for what it's supposed to be, the priority. Patch status could then be "--" (patch not sent), "needs signoff", "does not apply"... as we have today. • QA contact : could we do a better use of this field ? I know Ian & QA team are working/thinking to this question, so it's here just for reminder. • Signed-off & passed QA = The signature and the QA process could be in any order: if a patch does not meet our QA rules, there's no need to test it if the QA team sees it. So maybe we have a field for "QA status" (-- / passed QA / failed) and the patch status for sign-off (-- / signed off / does not apply) • For instance, I don't know how we could keep track of the "patch submitter" ? do we want/need ? I throw an open question here. • bug status : it's NEW/ASSIGNED/RESOLVED and it's not really correctly used. Many bugs stay "new" = as of today, 12 bugs have a patch for version Rel_3_8 and are still marked "new". They should be "assigned". I propose to enforce the use of the "ASSIGNED". This question is connected to the question of the use of the default assignee i've asked a few weeks ago. • Components : I proposed to clean them a while ago. Now I have concrete & detailled propositions. http://bugs.koha-community.org/bugzilla3/report.cgi?x_axis_field=&y_axis_fi… I've checked all entries with less than 30 bugs open, and propose something for each of them. The global idea is to have component entries close from modules we have in Koha. ∘ About, importedbugs, = no bugs, drop those entries. ∘ Authentication = 19 bugs, move them to "architecture, Internals and plumbing" ∘ Browser compatibility = 10 bugs, move them to "Architecture internals and plumbing" or "templates" ∘ bugs.koha-community.org = 2 bugs, move them to "websites, mailing lists,..." ∘ contribs.koha-community.org = 1 bug, move it to "websites, mailing lists,..." ∘ Developer documentation = 5 bugs, move them to "Architecture, internals and plumbing" ∘ Documentation = 11 bugs, keep them here, interesting for Nicole & doc writers ∘ Holidays = 2 bugs, move them to "Tools" ∘ Installation and upgrade = merge "command line" and "web-based" (20 and 24 repectively) ∘ Label printing = 27 bugs, move them to "Tools" ∘ MARC authority and MARC bibliographic (26 and 27 repectively) = we could merge them, not sure, i'm not proposing that, your opinion/thoughts about that ? ∘ MARC bibliographic staging/import = 14 bugs, move them to tools ∘ Self-checkout = 4, move them to "circulation" ∘ SIP2 = 18, move them to "circulation" or "Architecture, plumbing" ∘ Test suite = only 3, but keep them as we want to improve test coverage, it's to encourage ppl ! ∘ Transaction logs = 5, move them to "Tools" ∘ translate.koha-community.org = 2, move them to "Websites, Mailing lists,..." ∘ Z39.50, SRU, OpenSearch = 14, move them to searching • The "hardware" field is useless. http://bugs.koha-community.org/bugzilla3/report.cgi?x_axis_field=&y_axis_fi… 12 are reported "MacIntosh", and not related to Mac specifically, others are PC/All/Other. I propose we remove it completly from the forms (Can we ? Use it for something else & what ?) • The 'OS' field is useless. http://bugs.koha-community.org/bugzilla3/report.cgi?x_axis_field=&y_axis_fi… ∘ 5 bugs are "windows", and 3 are "others", it does not seem they are relevant. I propose we remove it completly from the forms (Can we ? Use it for something else & what ?) • Version field : there are many, only a few are used : http://bugs.koha-community.org/bugzilla3/report.cgi?x_axis_field=&y_axis_fi… Could we hide all versions that are unsupported and have no bug opened now ? (all 1.x & 2.x versions, many 3.0.x and 3.2.x versions) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

3 8

another suggestion for bugzilla
by Paul Poulain 25 Oct '11

25 Oct '11

Hello, I have an idea I submit here, let's see if it's a good one. What about ordering patch status by adding a number in front of each : 1- needs signoff 2- signed-off 2b- does not apply 3- passed QA 3b- failed QA 4- patch pushed I'm always searching "where is the value I want to set" ... -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

3 4

problem in cataloging
by Christian Calle Jahuira 25 Oct '11

25 Oct '11

Hello Friends I write from La Paz Bolivia, install Koha version v3.06 and I have the following problem in cataloging in MARC21: Can't call method "fields" on an undefined value at /usr/share/koha/lib/C4/Biblio.pm line 2261. Can you help please. Thank you. -- Christian Jhonny Calle Jahuira TUTOR ELEARNING - UMSA Consultor Sistemas de Informacion de Bibliotecas de la UMSA Email: christianjcj(a)gmail.com Cel: 73017301 - 65151595

2 2

Proposed changes to our Patch Submission and QA workflows
by Ian Walls 25 Oct '11

25 Oct '11

Everyone, In an effort to make patch submission and quality assurance easier on everyone for this next release cycle, I've got some proposals to run by you all. 1. In Bugzilla, move the Koha Bugs List from being the Default QA Contact to a Global Watcher. This has two advantages: 1. It frees up the QA Contact field for use by the QA Team 2. It guarantees that the Bugs List always gets included on the changes; with the current set up, someone could in theory remove the Bugs List as QA contact, preventing the list from getting updates. 2. To reduce email traffic, I propose we stop sending SIGNED OFF patches to the patches list. We've got Bugzilla lists (which can be connected to RSS and daily croned emails) which will inform the QA team on what patches are ready for QA. I did not use the patches list much this last release cycle to direct my QA work; it was all based of the Bugzilla statuses 2a. Ideally, I'd like to set up Bugzilla to automatically send the patches to the listserv for us, or to be able to accept patches sent to the listserv as attachments. This is going to take some custom coding, so it's probably not practical for right now. 3. Now that I'm not the only QA person for the release cycle, I'd like to formalize our rules about making sure that any submitted patch doesn't get processed solely by one company. I felt uncomfortable every time I passed a patch both written and signed off by ByWater teammates, because while I was sure it was good code, I knew I had a bias (often times, the code was fixing an issue one of our partners had reported). My strategy for 3.6 was to acknowledge the bias, and ask if anyone had any objections. With 3.8, I can pass anything that I write, or that is written/signed-off by ByWater alone, to Marcel or Jonathan for QA testing. Here're the rules I'd like to see in place: 1. A patch may not be written and signed off by the same person (existing rule) 2. The QA team consists of the Release Manager, the Quality Assurance Manager, and the Quality Assurance Assistants. This team has the right to move a patch through QA. 3. The QAM delegates the QA work between himself and the QAAs, in accordance with the rules. 4. A patch may not be written and QA'ed by the same person 5. A patch may not be written, signed off and QA'ed by any group of people in the same institution 6. A patch MAY be signed off and QA'ed by the same member of the QA team, but the RM may challenge this if he feels the patch needs more testing. Rule 5 still applies in this case. Comments? Ideas? Counter-proposals? -Ian -- Ian Walls Lead Development Specialist ByWater Solutions Phone # (888) 900-8944 http://bywatersolutions.com ian.walls(a)bywatersolutions.com Twitter: @sekjal

2 2

Cleaning up import tables and action log
by Marcel de Rooy 25 Oct '11

25 Oct '11

Hi, Is anyone of you using code to periodically purge records from import_records, import_biblios, import_batches and/or action_logs ? If so, would it be an idea to include such code into cleanup_database.pl in misc/cronjobs ? Thanks for sharing, Marcel

3 2

Koha 3.6 is out, starting Koha 3.8 !
by Paul Poulain 25 Oct '11

25 Oct '11

Hello happy hackers, As Koha 3.6 has been released on saturday, it's time to start officially Koha 3.8 I don't have all doors opened yet, but chris is in a plane back to NZ and will grant all access I need and explain some things he did as RM once he has recovered from his trip. === Bugzilla === In the meantime, I've started some work on bugzilla : * all ENH that are "needs signoff" and/or "signed off" have been switched to Rel_3_8 version. * I've added a "Koha 3.8 patches" shared query that you can add to your footers if you want. * i'll also investigate ENH that are "failed QA" and either bump them to 3.8 or close the bug as "abandonned" if it seems it's abandonned. Of course, the author will always be welcomed to reopen it and submit an acceptable patch. I'll decide looking at the age of the patch, how far is it to be acceptable, how active is the patch original author, how interesting is it to have this ENH. * looking at all ENH, I see there are 920 that are open. A large part of them have had no activity for more than 1 year. A few of them maybe good ideas, but they are not sponsored. I do the following proposition : "i'll close all ENH bugs that are not sponsored and have had no activity for more than nine months. For sponsored entries that have more than 9 months, i'll add a comment to ask wether we should wait for a patch or close the bug". If you disagree, please argue. If it's OK, I'll add this rule to the wiki. === Koha roadmap === I plan to start a wiki page with the roadmap. I'll store on this page : * what *will* be in Koha 3.8 = features/patches that have been validated and are already merged into master * what *should* be in Koha 3.8 = features/patches that have been submitted * what *could* be in Koha 3.8 = features/patches that have been announced, should be submitted in time, but you know, sometimes you don't do what you would like to do... I'll mark "could/should" only important things. I'll add in "will" everything (like what chris did with http://koha-releasemanagement.branchable.com/ ). I'll add in "could/should" only "important" things (ie : not a minor improvement to display a missing field, or add a link/control/...) I also plan to split the roadmap in 2 parts : * functionnal => for patches that are interesting for librarians. * technical => for patches that are interesting for developers I'll submit in the next days a first draft of all changes we could do in the next months (year(s) ?). That will be ambitious, of course that will be a 1st draft to discuss from what you want , my main goal being to have a clear visibility of where we would like to go and who want to endorse what. You won't probably be surprised by what will be in this list, as it's things we already have speaking of. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

4 4

utf-8 handling in Koha
by Dobrica Pavlinusic 24 Oct '11

24 Oct '11

In our migration to new koha, we hit bug 6554. We are having similar problem, but in our case we don't use localized templates but have utf-8 characters inside MySQL which get double utf-8 encoded before they are sent to browser. 1: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6554 Below is short summary of changes from patch: This patch tries to clean up utf-8 handling in Koha. In current implementation (mostly commented out in this patch) uses heuristic to guess which strings need decoding from utf-8 to binary representation and doesn't support utf-8 characters in templates and has problems with utf-8 data from database. With this changes, Koha perl code always uses utf-8 encoding correctly. All incomming data from database is allready correctly marked as utf-8, and decoding of utf8 is required only from Zebra and XSLT transfers which don't set utf-8 flag correctly. For output, standard perl :utf8 handler is used removing various "wide character" warnings as side-effect. I would love to hear your thoughts on this approach. So far, I know that it breaks CGI::Session (which is documented as known bug in it's documentation) so after first reload library names, shelfs and other data returned from session isn't encoded correctly. I would also need to check if this change affect LDAP, Z39.50 encoding and SIP server, but before I start down this road do you see any reasons not to persueue it? Compatibility with older perl versions might be one reason. I'm running perl v5.10.1 from Debian squeeze. -- Dobrica Pavlinusic 2share!2flame dpavlin(a)rot13.org Unix addict. Internet consultant. http://www.rot13.org/~dpavlin

1 0

Authority data import fail (UTF-8)
by Partha Mukhopadhyay 24 Oct '11

24 Oct '11

2 2