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

software error
by kazi 14 Jan '12

14 Jan '12

Dear community, Is this a bug or some other error in 3.6.3.001. How to fix it? Date::Calc::Add_Delta_Days(): not a valid date at /usr/share/koha/opac/cgi-bin/opac/opac-user.pl line 113. With regards, Kazi -- View this message in context: http://koha.1045719.n5.nabble.com/software-error-tp5106744p5106744.html Sent from the Koha-devel mailing list archive at Nabble.com.

2 3

Bugzilla workflow (bug 7245)
by Zeno Tajoli 14 Jan '12

14 Jan '12

Hi to all, this questyion is about Bugzilla workflow. The bug 7245 is fixed, code is updated in HEAD and in 3.6.x But the status is ASSIGNED and no 'RESOLVED'. Why ? Bye Zeno Tajoli -- Dott. Zeno Tajoli tajoliAT_SPAM_no_prendiATcilea.it fax +39 02 2135520 CILEA - Consorzio Interuniversitario http://www.cilea.it/disclaimer

5 7

Perl - Files missed on config
by Tom Hanstra 13 Jan '12

13 Jan '12

Koha Developers, I'm a bit of a lurker on the list and don't do much in the line of development. So, I'm not sure how best to officially get some fixes requested. But each time I install or upgrade a new version of Koha, I consistently have to edit a number of files in the koha software because I run a different version of perl than the default /usr/bin/perl. I just upgraded one of my instances to 3.6.2 and ran into this again with this set of files, which I then have to manually edit: 1029$ find . -type f -exec grep "/usr/bin/perl" {} \; -ls #!/usr/bin/perl 28955751 4 -rwxr-xr-x 1 root root 3313 Dec 22 17:55 ./misc/translator/translate #!/usr/bin/perl 28340370 16 -rw-r--r-- 1 root root 8457 Dec 22 17:55 ./lib/C4/ShelfBrowser.pm #!/usr/bin/perl 28341122 4 -rwxr-xr-x 1 root root 3153 Dec 22 17:55 ./bin/maintenance/borrowers-force-messaging-defaults #!/usr/bin/perl 28341185 16 -rwxr-xr-x 1 root root 8703 Dec 22 17:55 ./bin/admin/koha-preferences #!/usr/bin/perl 28337824 12 -rwxr-xr-x 1 root root 7848 Dec 22 17:55 ./opac/cgi-bin/opac/unapi #!/usr/bin/perl 5923679 4 -rwxr-xr-x 1 root root 2775 Dec 22 17:55 ./intranet/cgi-bin/svc/new_bib #!/usr/bin/perl 5923680 4 -rwxr-xr-x 1 root root 3255 Dec 22 17:55 ./intranet/cgi-bin/svc/bib #!/usr/bin/perl 5923681 12 -rwxr-xr-x 1 root root 4659 Dec 22 17:55 ./intranet/cgi-bin/svc/bib_profile #!/usr/bin/perl 5923685 4 -rwxr-xr-x 1 root root 2709 Dec 22 17:55 ./intranet/cgi-bin/svc/config/systempreferences #!/usr/bin/perl 5923684 4 -rwxr-xr-x 1 root root 1948 Dec 22 17:55 ./intranet/cgi-bin/svc/authentication #!/usr/bin/perl 5923910 16 -rwxr-xr-x 1 root root 9502 Dec 22 17:55 ./intranet/cgi-bin/acqui/pdfformat/layout2pages.pm #!/usr/bin/perl 5923914 24 -rwxr-xr-x 1 root root 16999 Dec 22 17:55 ./intranet/cgi-bin/acqui/pdfformat/layout3pages.pm #!/usr/bin/perl 28948350 4 -rwxr-xr-x 1 root root 3407 Dec 22 17:55 ./intranet/cgi-bin/reports/itemtypes.plugin #!/usr/bin/perl 28948413 12 -rwxr-xr-x 1 root root 7939 Dec 22 17:55 ./intranet/cgi-bin/reports/issues_by_borrower_category.plugin Is there a (preferably low overhead) way to report these other than the way I'm doing by hitting the list? Thanks, Tom -- ----------------------------------------------------------------------------- Tom Hanstra Systems Administrator University Libraries of Notre Dame Phone: (574)631-4686 213 Hesburgh Library Email: tom(a)nd.edu Notre Dame, IN 46556 Time flies like an arrow. Fruit flies like a banana. -----------------------------------------------------------------------------

3 2

Solr integration and kaizen (bug 7430)
by Jared Camins-Esakov 09 Jan '12

09 Jan '12

Good time of day! In an effort to help myself understand the issues that are facing the solr integration project, I have written a proof-of-concept patch for bug 7430 that moves ModZebra out of C4::Biblio into Koha::Search::Engine*. Let me repeat that. This is a proof-of-concept. I may or may not continue working on it, depending on whether the mood takes me at a moment when I have free time for playing. However, I wanted to point it out so that people could look at it, think about it, and maybe discuss it, if anyone had anything they wanted to discuss. Without further ado, the commit message follows. This proof-of-concept commit does the following: * Moves all the functionality from C4::Biblio::ModZebra into a new Koha::Search::Engine namespace, breaking it up into Zebra and NoZebra classes for the relevant sections. * Rather than calling ModZebra, callers should now use Koha::Search and call AddToIndexQueue() with the same arguments. * Creates a new Koha::Utils class with GetMarcFromKohaField and GetAuthType methods, in an attempt to begin the process of reducing circular dependencies * Adds a syspref SearchEngine to specify whether Zebra or NoZebra is to be used, based on the setting of NoZebra. This syspref is checked *only* in ModZebra replacement code. The NoZebra is still relied upon by *all other* search-related code. IMPORTANT NOTE: The syspref is added by the atomicupdate in installer/data/mysql/atomicupdate/bug_7430_add_searchengine_syspref IMPORTANT NOTE: NoZebra indexing is currently broken due to the lack of a get_auth_type_location() method that can be used by the Koha::Search::Engine::NoZebra class. IMPORTANT NOTE: This patch depends on the patches for bug 7284. One point on that last important note: the patch for bug 7284 centralizes calls to GetAuthType, but it has no functional relation to bug 7430, and it would be easy enough to cherry-pick this patch onto Master by simply removing the merge conflict, if anyone cared. Also, possibly the key question: anyone have any ideas on dealing with get_auth_type_location() so that NoZebra could go back to working as well as it ever has in recent memory? Regards, Jared -- 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/

1 0

Active borrowers report
by Cab Vinton 09 Jan '12

09 Jan '12

A couple years ago Jesse Weaver came up with this report for active borrowers (i.e., patrons checking out materials): SELECT YEAR(issuedate), MONTH(issuedate), categorycode, COUNT(DISTINCT borrowernumber) FROM old_issues LEFT JOIN borrowers USING (borrowernumber) GROUP BY YEAR(issuedate), MONTH(issuedate), categorycode; I'm wondering if the caveat he notes is still true: Because it uses old_issues, it won't include anything that's still checked out; getting around that requires either ugly subqueries or running the report with old_issues and issues and manually combining the results. Is there a relatively easy way to modify the report so it includes patrons who may still have items checked out? Thanks for any assistance! Cab Vinton, Director Sanbornton Public Library Sanbornton, NH "Politeness and consideration for others is like investing pennies and getting dollars back." Thomas Sowell

5 7

Position Open with ByWater Solutions
by Nathan Curulla 09 Jan '12

09 Jan '12

Greetings! We are currently seeking an individual to fulfill a Development Specialist role with ByWater Solutions. The candidate must be self motivated and comfortable with working from home. The core responsibilities of this position will include: Determination of the root of support ticket issues and resolving the problem Identification and resolution of bugs within development projects Creation of bug reports and patches, and submittal of these fixes to the Koha community Determination of the technical requirements needed to get the end goal the client expects from a development project Identify and resolve multiple recurring issues, and creating a solution that will fix all issues simultaneously. Required skills: Perl experience, including working with Modules and Object Oriented Perl Extensive experience with Debian Linux command line operations MySQL XHTML/CSS Git version control knowledge of MARC21 Library/Library Software experience Excellent communication skills Excellent problem solving skills Commitment to open source Comfortable working from home Preferred: Knowledge of the Koha open source ILS MLIS/MIS/MLS from ALA accredited library school 5+ years library experience experience with: Indexdata's Zebra Selenium Bugzilla Postfix/exim4 or other MTAs Template Toolkit JQuery HTML5 and CSS3 NYTProf Please let us know if you have any questions regarding this position, or if you would like to schedule an interview, and we will get back to you directly. Thank you very much and have a great day! All the best, -Nate > Nathan A. Curulla > Executive Vice President > ByWater Solutions > VISIT US AT ALA MIDWINTER BOOTH # 2048 > Support and Consulting for Open Source Software > Headquarters: Santa Barbara, CA. > Office: West Haven, CT. > Phone/Fax # (888) 900-8944 xt 2 > Cell # (203) 685-7207 > http://bywatersolutions.com > nate(a)bywatersolutions.com

1 0

Proposal to change Bugzilla Status and Patch Status values
by Ian Walls 09 Jan '12

09 Jan '12

Fellow Koha-ckers, A comment on bug 7167 ( http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7167) has gotten my interest re-awakened about a proposed Bugzilla revision that had been floated earlier this release cycle. I'd like to remove Patch Status, and move all those values to the regular Status field. This has the following advantages: - Status is a built-in field, so it's got much richer support in Bugzilla. For example, status workflows can be added. Patch Status is a custom field, and is just a list of values - We would no longer lose the Priority value of a bug by having to set it to Patch Sent in order to get the Patch Status values visible - Statuses can be updated as part of submitting an attachment like a patch, streamlining the patch submission process (fewer clicks to keep all the fields up to date). I'd also like to add a new status, "In Discussion", for bug reports that have deeper procedural, philsophical or technical implications outside that of mere coding (bug 7167 being an example). We're not using Status for anything else, so there is no trade-off there. This is really how the Status field is meant to be used. We will, however, have to rebuild the canned searches that look for patches that Need Signoff, are Signed Off, and are Passed QA/Failed QA. The other difficulty of this proposal is that we'll need to turn off automatic bug emails for a bit while we make the bulk changes to the Patch Statuses; otherwise, we'll all get spammed to high heaven with meaningless updates when the migration occurs. What do people think? Does this sound like a reasonable change to make? Any objections? Cheers, -Ian -- Ian Walls Lead Development Specialist ByWater Solutions ALA Midwinter Booth #2048 Phone # (888) 900-8944 http://bywatersolutions.com ian.walls(a)bywatersolutions.com Twitter: @sekjal

11 13

Re: [Koha-devel] link_bibs_to_authorities.pl can corrupt records
by Archives and Collections Society 06 Jan '12

06 Jan '12

At 03:02 PM 1/6/2012 -0500, Ian Walls wrote: >Paul, >The <http://link_bibs_to_authorities.pl>link_bibs_to_authorities.pl script >is hardcoded to ALWAYS erase manual links.Â I'm not sure what the >reasoning is behind that.Â But, every time you run it, any link you've >done manually that the script can't automatically figure out will be >removed.Â Nature of the beast (for now, at least). What is "any link you've done manually"?, please. More than 90% of our input is Z39.50 and "default" item cataloguing. OK - a total screw-up that is included without any warning whatsoever in the standard distribution of 3.6.1 ??? From the bug report <http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5683> Chris Cormack 2011-06-01 21:13:23 UTC Pushed to master Jared Camins-Esakov 2011-07-08 14:37:02 UTC Seems to be working now. Closing. If it's "nature of the beast" why isn't the "beast" mentioned somewhere? What on earth is the reason for this .pl to be included in any distribution? More... >2012/1/6 Chris Cormack ><<mailto:chris@bigballofwax.co.nz>chris(a)bigballofwax.co.nz> >Im assuming you did this on your testing/staging server right? >Id restore that from backup, then try applying the patch and see if you >get better behaviour. >If so, then do it on your production machine. what "patch"??? And yes -- I can restore from a previous sqldump, and only lose +/- 100 biblios. We're in pre-production and when we got the zebra indexing working properly, I told our volunteers to start inputting to 3.6.1 *only* (not duplicate on 3.2) so that I could look into any difficulties they experienced as cataloguers. I had no way at all of knowing that a pl script included in the "latest stable distribution" could possibly demolish the whole db. Again, what "patch" and where do I find it? Might I suggest that someone re-opens the bug (I have attempted to annotate it) and removes this dangerous script from public distribution (or at least includes a very visible warning.) Best - Paul >Chris >On 7 Jan 2012 08:47, "Paul" <<mailto:paul.a@aandc.org>paul.a(a)aandc.org> wrote: >Bug 5683 (<http://link_bibs_to_authorities.pl>link_bibs_to_authorities.pl >can corrupt records) was signed off some months ago, but is perhaps a >little too cryptic for me to follow in detail. Â Can someone help? As far >as I can see, without remedial action, this is catastrophic. > >Following difficulties we have had migrating 3.2 to 3.6.1, someone on the >users mailing list suggested we should run ><http://link_bibs_to_authorities.pl>link_bibs_to_authorities.pl -- (db has >~10k authorities and ~15k biblios) -- so I did just that, and have >APPARENTLY DEMOLISHED *EVERY* LINK IN THE DB. Â From my notes: > >paul@nelson:/usr/share/koha$ >./bin/<http://link_bibs_to_authorities.pl>link_bibs_to_authorities.pl > >Bib authority heading linking report >------------------------------------ >Number of bibs checked: Â Â Â 14911 >Number of bibs modified: Â Â Â 14886 >Number of bibs with errors: Â 0 > >but - the staff interface no longer correctly finds authorities !!! > >[1] Manually link (staff client) auth "Lubbock" to bib "Arctic Whalers" -- >now linked, 35 other Lubbock bibs not linked. Â Is this a question of >zebra re-indexing? > >So: Â KOHA_CONF=/etc/koha/koha-conf.xml PERL5LIB=/usr/share/koha/lib >./bin/migration_tools/<http://rebuild_zebra.pl>rebuild_zebra.pl -a -r -v >and Â KOHA_CONF=/etc/koha/koha-conf.xml PERL5LIB=/usr/share/koha/lib >./bin/migration_tools/<http://rebuild_zebra.pl>rebuild_zebra.pl -b -r -v -x > >koha@nelson:/usr/share/koha$ >./bin/<http://link_bibs_to_authorities.pl>link_bibs_to_authorities.pl >... processed 100 records >/ ... / >... processed 14900 records > >Bib authority heading linking report >------------------------------------ >Number of bibs checked: Â Â Â 14911 >Number of bibs modified: Â Â Â 1 >Number of bibs with errors: Â 0 >koha@nelson:/usr/share/koha$ > >All this did was to *un-link" the bib/auth link that I had manually >entered at [1] above. Could someone involved with signing off bug 5683 >please explain why link==unlink? > >Help - please. > >Paul > >_______________________________________________ >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 ><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/ > > > > >-- >Ian Walls >Lead Development Specialist >ByWater Solutions >ALA Midwinter Booth #2048 >Phone # (888) 900-8944 ><http://bywatersolutions.com>http://bywatersolutions.com ><mailto:ian.walls@bywatersolutions.com>ian.walls(a)bywatersolutions.com >Twitter: @sekjal >_______________________________________________ >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/ --- Archives and Collections (ACS) Society 205, Main Street, Picton, Ontario, K0K 2T0, Canada http://www.AandC.org Canadian Charitable Organization 88721 9921 RR0001 Dedicated to maritime conservation and education.

2 1

link_bibs_to_authorities.pl can corrupt records
by Paul 06 Jan '12

06 Jan '12

Bug 5683 (link_bibs_to_authorities.pl can corrupt records) was signed off some months ago, but is perhaps a little too cryptic for me to follow in detail. Can someone help? As far as I can see, without remedial action, this is catastrophic. Following difficulties we have had migrating 3.2 to 3.6.1, someone on the users mailing list suggested we should run link_bibs_to_authorities.pl -- (db has ~10k authorities and ~15k biblios) -- so I did just that, and have APPARENTLY DEMOLISHED *EVERY* LINK IN THE DB. From my notes: paul@nelson:/usr/share/koha$ ./bin/link_bibs_to_authorities.pl Bib authority heading linking report ------------------------------------ Number of bibs checked: 14911 Number of bibs modified: 14886 Number of bibs with errors: 0 but - the staff interface no longer correctly finds authorities !!! [1] Manually link (staff client) auth "Lubbock" to bib "Arctic Whalers" -- now linked, 35 other Lubbock bibs not linked. Is this a question of zebra re-indexing? So: KOHA_CONF=/etc/koha/koha-conf.xml PERL5LIB=/usr/share/koha/lib ./bin/migration_tools/rebuild_zebra.pl -a -r -v and KOHA_CONF=/etc/koha/koha-conf.xml PERL5LIB=/usr/share/koha/lib ./bin/migration_tools/rebuild_zebra.pl -b -r -v -x koha@nelson:/usr/share/koha$ ./bin/link_bibs_to_authorities.pl ... processed 100 records / ... / ... processed 14900 records Bib authority heading linking report ------------------------------------ Number of bibs checked: 14911 Number of bibs modified: 1 Number of bibs with errors: 0 koha@nelson:/usr/share/koha$ All this did was to *un-link" the bib/auth link that I had manually entered at [1] above. Could someone involved with signing off bug 5683 please explain why link==unlink? Help - please. Paul

4 3

Database updates on master [IMPORTANT]
by Paul Poulain 06 Jan '12

06 Jan '12

Hello, a very important information: After a long discussion with chris_c and chris_n, it seems I made a mistake and have found a hidden problem. * the hidden problem (that was hidden for me, and probably for most of you. both chris where aware) : in 3.4 and 3.6, when a patch with a updatedatabase was backported, it was backported with another number. It means that when you upgrade from 3.2 to 3.4 then 3.6, you get some error message about duplicate key of things like that. I've checked, those SQL errors are all harmless (and chris already had checked in fact). * my mistake: as I thought patches for 3.6 should have a 3.6 number and patches for master (future 3.8) should have a 3.7 number, i've pushed 3 patches with an updatedatabase numbered 3.6.x That was a bad idea, and I'll have to modify those updatedatabase, i'll do it now. So, anyone running master should get a "free" updatedatabase in the next hours. By free I mean the 3 DB revs that will be applied have already been applied, that will just be a number change. So, 1-take care, 2- don't worry. Also note that this problem will be solved once the new database mechanism will be pushed, as it will be non-linear, so the numbering won't refer to a release number anymore. HTH -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

1 0