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

Kohacon11 : Getting there
by Koustubha Kale 29 Oct '11

29 Oct '11

Hi All, Kohacon11 is here. The venue is at : Vidya Prasarak Mandal's Thane College Campus, Thorle Bajirao Peshwe Sabhagriha, Near CIDCO Bus Stop, Chendani, Thane (west ) Maharashtra, India. Google Maps link : < http://maps.google.com/maps/place?ftid=0x3be7b927cd6912b9:0xcd4b44329d5ed6b… > The college campus is 5 minutes walking distance from Thane railway station. Once you are in Thane, you can take an auto-rikshaw to the campus. Just tell the driver you want to go to Thane College near CIDCO. The program start at 9.00am on 31st October 2011. Please find the program and a formal invitation attached. I have included my mobile number in the contact details below. Do not hesitate to call me if you need any assistance. Looking forward to meeting you all there :) Regards, Koustubha Kale Anant Corporation Contact Details : Address : 103, Armaan Residency, R. W Sawant Road, Nr. Golden Dyes Naka, Thane (w), Maharashtra, India, Pin : 400601. TeleFax : +91-22-21720108, +91-22-21720109 Mobile : +919820715876 Website : http://www.anantcorp.com Blog : http://www.anantcorp.com/blog/?author=2

1 0

October newsletter publication delayed
by Daniel Grobani 28 Oct '11

28 Oct '11

Hi, I missed the customary newsletter publication date of the 25th this month due to a bad cold. Although I haven't been able to marshal the energy and attention needed to publish it, I hope to be able to do so before October becomes November. Cheers, Daniel P.S. Happy conferring, you lucky KohaConners!

1 0

Kohacon11 Mumbai day trip on 3rd November details
by Koustubha Kale 26 Oct '11

26 Oct '11

Hi All, Here is tentative itinerary and cost of the planned Mumbai day trip on 3rd November. Itinerary : 1. 8am : Leave from Thane by bus 2. 9.30am : arrive at Gateway of India and leave by ferry for Elephanta caves <http://en.wikipedia.org/wiki/Elephanta_Caves> ( designated a UNESCO World Heritage Site) 3. 10.30am to 12.30 : arrive at Elephanta Caves, site seeing with a guide, lunch either at the MTDC hotel on the island or back on mainland near Gateway of India. 4. 12.30pm to 1.30pm : ferry back to Gateway of India. ( if lunch on mainland , then lunch 1.30pm to 2.30pm near Gateway of India ) Else 1.30pm to 2.30 pm lunch in MTDC hotel on Elephanta caves and 1.30pm to 2.30 pm ferry back to Gateway of India 5. 2.30pm onwards local shopping, drive back while seeing local sites such as Mumbai University building, Marine Drive, Girgaon Chaupaty ( beach ) etc. 6. Around 6 to 7pm arrive back in Thane Approximate cost per person : INR 2000 Includes all costs such as travel, entry tickets, guide fees, lunch and afternoon tea/coffee. Please let me know urgently if you would llike to join the trip so that we can do the bookings.. Regards, Koustubha Kale Anant Corporation Contact Details : Address : 103, Armaan Residency, R. W Sawant Road, Nr. Golden Dyes Naka, Thane (w), Maharashtra, India, Pin : 400601. TeleFax : +91-22-21720108, +91-22-21720109 Mobile : +919820715876 Website : http://www.anantcorp.com Blog : http://www.anantcorp.com/blog/?author=2

3 2

tt style point
by Colin Campbell 26 Oct '11

26 Oct '11

Hi I noticed that in QA someone is changing tt constructs from [% IF variable %] to [% IF (variable) %] as style issues I think this is very bad style for the following reasons: You'll not see it in any of the documentation for tt either the perldoc, on the tt site or in the badger book. (and I've never seen it on any tt using project). It adds nothing (we hope) syntactically. My initial response is that as we are not using normal tt syntax, something "clever" or magic is going on here rather than a usual [% IF %] It detracts from readability. (ok slightly subjective but the environment already makes full use of the top row of the keyboard.) Whats its relation with the legitimate use of brackets e.g. to call vmethods in regexps [% IF variable1( variable2 ) %] The authors didn't require brackets around more complex boolean expressions [% IF variable == 0 %] why bring em back in for simple variables. Could it have unforeseen side effects (don't know but I don't want to spend time researching it) It confuses the reader of the code and the writer of subsequent code - 'should I use () no? when? why? It strikes me as weird (!!) In short I'm arguing for clarity... I realise that Chris bracketed things in the great template conversion but I think that was defensive programming when he couldn't rely on variable always being one. And we shouldn't be encouraging or enforcing others to use a peculiar idiolect rather than standard practice. Colin -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 845 557 5634 (phone) +44 (0) 7759 633626 (mobile) colin.campbell(a)ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com

11 24

Proposal for Global Bug Squashing Day: 2011-11-04
by Magnus Enger 26 Oct '11

26 Oct '11

Dear Community! After colluding with my fellow bug wrangler Katrin I'd like to propose a date for the next GBSD: http://wiki.koha-community.org/wiki/2011-11-04_Global_bug_squashing_day This coincides with the first day of the hackfest at KohaCon11. Maybe we could get a bit of a Google Hangout going, or something? We'll see... Anyway: Be there or be [_]! Best regards, Magnus

2 2

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 25 Oct '11

25 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