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

Broken url in arabic facets.. and fix
by Bernardo Gonzalez Kriegel 06 Jun '13

06 Jun '13

Hi, Karam made an interesting discovery for Bug 10176 [1], putting "use utf8;" on Search.pm fixes URL of facets (not display well for me, but url works). Digging a little I found that on line 574 of master Search.pm there is a strange symbol (last between []). Seems to be an inverted question mark. Karam saids that is Arabic one. 572:# Sanitize the link value : parenthesis, question and exclamation mark will cause errors with CCL 573- my $facet_link_value = $one_facet; 574- $facet_link_value =~ s/[()!?¡¿؟]/ /g; 575- Question: this char is a typo? Was introduced on Bug 9183 [2] 'use utf8;' fixes the substitute, and the URLs. Also removing that char gives the same effect (without 'use utf8:' Patch is from jcamins Regards, bernardo [1] http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10176 [2] http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9183 -- Bernardo Gonzalez Kriegel bgkriegel(a)gmail.com

4 6

does anyone have any updates to the XSLT stylesheets in Koha, to the latest MARC21 specs?
by Mason James 06 Jun '13

06 Jun '13

hi Folks has anyone made any start on updating the XSLT stylesheets in Koha to the latest MARC21 specs i am about to start on this task and i do not want to duplicate any existing effort :) i guess i should look at the Kobli code, to see if they have made some updates… thanks, Mason

1 0

OPAC dir structure redesign
by Mason James 05 Jun '13

05 Jun '13

hi All Owen and I were talking recently about a plan to improve the current OPAC directory structure... the big problem is there is currently much duplication of unnecessary dirs/files. each theme has many duplicated files - and each language for each theme has many duplicated files all this duplication means that subtle bugs can occur... now that we have got the awesome new CCSR theme added, the next step is to fix the OPAC dir structure to accommodate multiple themes easily and safely :) i have a proposed redesign, which i think is the best balance of removing all duplication, and making the least number of changes to the existing structure in the new design there are 2 new top-level dirs, 'themes' and 'langs'. note: these are the *only* newly created dirs - the rest of the redesign is simply moving existing dirs from one location to another location each theme's dir (eg: prog or ccsr) only needs a 'css' dir, all other theme's existing subdirs can be moved to the shared top-level 'lib' and 'images' dirs again, with the language subdirs… each 'langs' subdir (eg: en or fr-FR) only needs an 'includes', 'modules', and 'xslt' dir (as these are the only dirs that have any actual language translation/substiution applied to them) all other existing language's subdirs can be moved to the shared top-level 'lib' and 'images' dirs, too below is an example of a redesigned OPAC dir structure, for 2 themes, with 2 languages (en and fr-FR) the directory/file count has been reduced from from 124 directories, 2542 files… to 60 directories, 1857 files any thoughts or improvements...? opac-tmpl └── themes (new) ├── ccsr │ └── css └── prog └── css ├── langs (new) │ ├── en │ │ ├── includes │ │ │ └── search │ │ ├── modules │ │ │ ├── errors │ │ │ ├── sco │ │ │ ├── search │ │ │ ├── svc │ │ │ └── text │ │ └── xslt │ └── fr-FR │ ├── includes │ │ └── search │ ├── modules │ │ ├── errors │ │ ├── sco │ │ ├── search │ │ ├── svc │ │ └── text │ └── xslt ├── images (existing, shared for all themes and langs) │ ├── datatables │ └── itemtypeimg │ ├── bridge │ ├── carredart │ ├── colors │ ├── crystal-clear │ ├── liblime-kids │ ├── npl │ ├── Seshat │ └── vokal ├── lib (existing, shared for all themes and langs) │ ├── famfamfam │ │ ├── mini │ │ └── silk │ ├── greybox │ │ └── GreyBox_v5_5 │ │ ├── adobe_images │ │ ├── compression_lib │ │ ├── greybox_source │ │ │ ├── base │ │ │ ├── gallery │ │ │ ├── set │ │ │ └── window │ │ └── static_files │ ├── jquery │ │ ├── images │ │ └── plugins │ │ └── themes │ │ └── classic │ └── yui │ ├── container │ ├── menu │ └── utilities

13 22

git koha >koha 3.12.00
by Samuel Desseaux 05 Jun '13

05 Jun '13

hi, i've a git question: I've made a git remote update and a git rebase v3.12.00 on my test instance but i keep the same version( 3.11.00.203), An idea? Best regards, Samuel

3 3

search on opac: no results
by Samuel Desseaux 04 Jun '13

04 Jun '13

Hi, We have a bug with the opac since a few days. Whatever the search give no results. I don't know what happen and it seems very strange. I put here all the logs i have. The ownership of the files are ok but something is missing.... koha@tst-koha:~/var/log$ ls koha-error_log koha-opac-error_log koha-zebradaemon.err koha-zebradaemon-output.log README koha@tst-koha:~/var/log$ tail -f koha-opac-error_log [Tue Jun 04 15:55:32 2013] [error] [client 138.195.30.33] [Tue Jun 4 15:55:32 2013] suggestion: Odd number of elements in anonymous hash at /home/koha/kohaclone/C4/AuthoritiesMarc.pm line 972., referer: http://tst-koha.ecp.fr/cgi-bin/koha/opac-search.pl?idx=&q=design [Tue Jun 04 15:55:32 2013] [error] [client 138.195.30.33] [Tue Jun 4 15:55:32 2013] suggestion: Odd number of elements in anonymous hash at /home/koha/kohaclone/C4/AuthoritiesMarc.pm line 972., referer: http://tst-koha.ecp.fr/cgi-bin/koha/opac-search.pl?idx=&q=design [Tue Jun 04 15:55:32 2013] [error] [client 138.195.30.33] [Tue Jun 4 15:55:32 2013] suggestion: Odd number of elements in anonymous hash at /home/koha/kohaclone/C4/AuthoritiesMarc.pm line 972., referer: http://tst-koha.ecp.fr/cgi-bin/koha/opac-search.pl?idx=&q=design [Tue Jun 04 15:55:32 2013] [error] [client 138.195.30.33] [Tue Jun 4 15:55:32 2013] suggestion: Odd number of elements in anonymous hash at /home/koha/kohaclone/C4/AuthoritiesMarc.pm line 972., referer: http://tst-koha.ecp.fr/cgi-bin/koha/opac-search.pl?idx=&q=design [Tue Jun 04 15:55:32 2013] [error] [client 138.195.30.33] [Tue Jun 4 15:55:32 2013] suggestion: Odd number of elements in anonymous hash at /home/koha/kohaclone/C4/AuthoritiesMarc.pm line 972., referer: http://tst-koha.ecp.fr/cgi-bin/koha/opac-search.pl?idx=&q=design [Tue Jun 04 15:55:32 2013] [error] [client 138.195.30.33] [Tue Jun 4 15:55:32 2013] suggestion: Odd number of elements in anonymous hash at /home/koha/kohaclone/C4/AuthoritiesMarc.pm line 972., referer: http://tst-koha.ecp.fr/cgi-bin/koha/opac-search.pl?idx=&q=design [Tue Jun 04 15:55:32 2013] [error] [client 138.195.30.33] [Tue Jun 4 15:55:32 2013] suggestion: Odd number of elements in anonymous hash at /home/koha/kohaclone/C4/AuthoritiesMarc.pm line 972., referer: http://tst-koha.ecp.fr/cgi-bin/koha/opac-search.pl?idx=&q=design [Tue Jun 04 15:55:32 2013] [error] [client 138.195.30.33] [Tue Jun 4 15:55:32 2013] suggestion: Odd number of elements in anonymous hash at /home/koha/kohaclone/C4/AuthoritiesMarc.pm line 972., referer: http://tst-koha.ecp.fr/cgi-bin/koha/opac-search.pl?idx=&q=design [Tue Jun 04 15:55:32 2013] [error] [client 138.195.30.33] [Tue Jun 4 15:55:32 2013] suggestion: Odd number of elements in anonymous hash at /home/koha/kohaclone/C4/AuthoritiesMarc.pm line 972., referer: http://tst-koha.ecp.fr/cgi-bin/koha/opac-search.pl?idx=&q=design [Tue Jun 04 15:55:38 2013] [error] [client 138.195.30.33] File does not exist: /home/koha/kohaclone/koha-tmpl/images, referer: http://tst-koha.ecp.fr/cgi-bin/koha/opac-search-history.pl ^C koha@tst-koha:~/var/log$ tail -f koha-zebradaemon.err 20130529 14:03:41 koha-zebra-ctl.bibecp: client (pid 17514) exited with 1 status 20130529 14:03:41 koha-zebra-ctl.bibecp: client (pid 17515) exited with 1 status 20130529 14:03:41 koha-zebra-ctl.bibecp: terminating too quickly, waiting 30 seconds 20130529 14:04:11 koha-zebra-ctl.bibecp: client (pid 17521) exited with 1 status 20130529 14:04:11 koha-zebra-ctl.bibecp: client (pid 17522) exited with 1 status 20130529 14:04:11 koha-zebra-ctl.bibecp: client (pid 17523) exited with 1 status 20130529 14:04:12 koha-zebra-ctl.bibecp: client (pid 17524) exited with 1 status 20130529 14:04:12 koha-zebra-ctl.bibecp: client (pid 17525) exited with 1 status 20130529 14:04:12 koha-zebra-ctl.bibecp: terminating too quickly, waiting 30 seconds 20130529 14:04:19 koha-zebra-ctl.bibecp: fatal: terminated ^C koha@tst-koha:~/var/log$ tail -f koha-zebradaemon-output.log 14:03:41-29/05 [fatal] lock file /home/koha/var/lock/zebradb/biblios/zebrasrv.pid [Permission denied] 14:03:41-29/05 [fatal] lock file /home/koha/var/lock/zebradb/biblios/zebrasrv.pid [Permission denied] 14:03:41-29/05 [fatal] lock file /home/koha/var/lock/zebradb/biblios/zebrasrv.pid [Permission denied] 14:03:41-29/05 [fatal] lock file /home/koha/var/lock/zebradb/biblios/zebrasrv.pid [Permission denied] 14:03:41-29/05 [fatal] lock file /home/koha/var/lock/zebradb/biblios/zebrasrv.pid [Permission denied] 14:04:11-29/05 [fatal] lock file /home/koha/var/lock/zebradb/biblios/zebrasrv.pid [Permission denied] 14:04:11-29/05 [fatal] lock file /home/koha/var/lock/zebradb/biblios/zebrasrv.pid [Permission denied] 14:04:11-29/05 [fatal] lock file /home/koha/var/lock/zebradb/biblios/zebrasrv.pid [Permission denied] 14:04:12-29/05 [fatal] lock file /home/koha/var/lock/zebradb/biblios/zebrasrv.pid [Permission denied] 14:04:12-29/05 [fatal] lock file /home/koha/var/lock/zebradb/biblios/zebrasrv.pid [Permission denied] koha@tst-koha:~/var/log$ ps -aux | grep zebra Warning: bad ps syntax, perhaps a bogus '-'? See http://procps.sf.net/faq.html koha 17633 0.0 0.3 99752 8224 ? S May29 0:00 zebrasrv -f /home/koha/etc/koha-conf.xml koha 29582 0.0 0.0 9616 908 pts/0 S+ 16:05 0:00 grep zebra koha@tst-koha:~/var/log$ Thank you for your help samuel

2 1

Re: [Koha-devel] Extracting bibliographic records with specified
by Stefano Bargioni 04 Jun '13

04 Jun '13

A possibile solution: mysql_prompt> SELECT marc FROM biblioitems WHERE ExtractValue(marcxml,'count(//datafield[@tag="040"]/subfield[@code="a"])>0') into outfile '/full/path/to/yourfile.mrc' fields terminated by '' lines terminated by ''; HTH. Stefano On 04/giu/2013, at 12.00, Mohamed zalabany wrote: > Date: Tue, 4 Jun 2013 07:28:27 +0000 > From: Mohamed zalabany <mh_zalabany(a)hotmail.com> > To: koha_developers <koha-devel(a)lists.koha-community.org> > Subject: [Koha-devel] Extracting bibliographic records with specified > criteria > Message-ID: <BLU165-W99C24B66C171B9107F681979E0(a)phx.gbl> > Content-Type: text/plain; charset="iso-8859-1" > > Hi all > i wish you all fine > I need to extract some bibliographic record from my catalog depanding on search criterea in MARC field 040$c > how could i do that and extract this records in one file > i think i could do that from the reports but how to make one file of all the record to import it later in another system > Thanks, > Best Regrades > > Mohamed El-Zalabany > Librotech group > for library systems and information technology

1 0

Extracting bibliographic records with specified criteria
by Mohamed zalabany 04 Jun '13

04 Jun '13

Hi all i wish you all fine I need to extract some bibliographic record from my catalog depanding on search criterea in MARC field 040$c how could i do that and extract this records in one file i think i could do that from the reports but how to make one file of all the record to import it later in another system Thanks, Best Regrades Mohamed El-Zalabany Librotech group for library systems and information technology

1 0

Re: [Koha-devel] anyone have plans to update Koha's MARC21 framework?
by Mason James 03 Jun '13

03 Jun '13

On 2013-06-2, at 1:45 PM, Bernardo Gonzalez Kriegel wrote: > Hey Mason, > I attached 2 files with all tags/subtags of LOC as of today. > I wrote a script to download all relevant LOC pages and parse tags/subtags > > I have a script that check in database if a tag/subtag is present or has a different > legend in liblabrarian/libopac. But the result must be inserted by hand :-( awesome!. could you put these scripts on a git repo on the web? > > I tried to write a script to update the SQL file directly, but failed until now. > Another possibility I tested today is update directly in the database and > then use a touched dump to regenerate framework files. > > We need an automated way to update bibs and authority framework, yeah, we really do… good news is… from LOC's ecbdlist.html page, it's possible to auto-build a correct default fwrk (i think) http://www.loc.gov/marc/bibliographic/ecbdlist.html i have been thinking about using pootle to handle string translations in the frameworks, too so, we have 2 tasks... 1/ a script to build a default MARC21 framework from LOC's ecbdlist.html file 2/ translate default framework strings to various languages via a .po file > but right now I'm stuck with the update of pootle (in translate.k-c) > > Perhaps you can do it :-) > If I can be of any assistance, I'll be glad. i cant promise anything soon, but i'll see what i can do > > PS: > 1) Why we use tag legends in uppercase?, I hate that yep, me too. this is a bug > 2) In SQL file, numbered subtags comes before character ones, in LOC pages the other way yes, i noticed that too :) i think the important thing is the order that they are display to the user but... Koha's displays this in the wrong order?, so... another bug? > 3) In many tag legends we use 2 dashes '--' as separator, in LOC pages only one dash '-' yes, another bug :)

1 1

Cherry-picking and SIPServer unification
by Galen Charlton 03 Jun '13

03 Jun '13

Hi, Via the magic of git cherry-pick -X ignore-space-change, it turns out that at least some patches made on Koha's fork of SipServer (a.k.a. OpenNCIP) can be brought over mostly as is. For example, consider Koha bug 3723 [1], SIPServer bug 1180479 [2], and the patch of Colin's I was able to cherry-pick as a proposed fix for SIPServer [3]. SIPServer is a GPL2+ project (though note that although the license change from GPL2 to GPL2+ has been agreed to by all significantly copyright holders, there's a patch pending to update the source files accordingly). Koha, of course, is GPL3+ and once was GPL2+. Per my reading of the GPL compatibility matrix [4], I don't see any licensing bar to cherry-picking patches over from Koha to SIPServer, because future releases of SIPServer can be "conveyed" as GPL3. Consequently, I intend to do some cherry-picking to help move us to the point where Koha can fold its fork into. If anybody sees a technical or licensing problem with this, please let me know. [1] http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3723 [2] https://bugs.launchpad.net/sipserver/+bug/1180479 [3] http://git.evergreen-ils.org/?p=working/SIPServer.git;a=commit;h=bbee352fc8… [4] http://www.gnu.org/licenses/gpl-faq.html#AllCompatibility Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts 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

2 1

Re: [Koha-devel] RFC: Plugins QA
by Paul 01 Jun '13

01 Jun '13

At 01:02 PM 5/31/2013 -0400, Kyle Hall wrote (and maybe some attributions got lost): >[snip] >Agreed. Most plugin logic would make for a very good basis for an Koha >patch. [snip] > >I'm getting a bit of a twitch here -- I see the utility of this as a >workaround, but I hope that this plugin has a very short life on >account of the underlying bugs getting fixed. > >Agreed. This utility is a workaround for an as-of-yet unidentified bug. [snip] > >If I had known this would be of interest to more users, I would have >started with a patch instead of a plugin. I'd be more than happy to >patch-ify this plugin when I have the time. [snip] Tarballs, packages, gits (including vendors), stables, latest, bugs and patches, wikis (various), tools, reports, live-DVDs, mailing lists, chat, maybe more, and now plug-ins? Could we please look at what the "open source" world is doing? Apache, SendMail, Perl, PostFix, FireFox, Debian, Ubuntu, OpenOffice, LibreOffice ... are fairly stable with an established security update capability. Even Java and MySQL are simplifying. I had a "rather important" librarian from Quebec drop in, out of the blue, yesterday to talk about Koha. Her group (37 libraries) had previously been burned by a trial commercial implementation of Koha (no need to quote names), so they're using Opals, but "liked the idea" of Koha. First question: "stability?" She was well aware that we announce on our OPAC: "System change / Koha v3.8.4 on line 14 September 2012" (I think that was fairly timely) so she asked about 3.10 and 3.12; my answer "we're happy; two year cycle; look at it again in September 2014." I know that a number of you will ... whatever ... Paul's a pain in the neck, doesn't understand, does his own thing, but the bottom line is that <http://opac.navalmarinearchive.com/> is fully functional and is intrinsically Koha. It's (reasonably) secure (without https) and meets the needs of our users and librarians. It runs itself with minimal ( < 1 hour/week statistically ) intervention by IT personnel. There are very few institutions that have "happiness" in the form of unlimited budgets and unlimited IT departments. I'm personally intrigued by the creativity of the Koha community, so try and follow what's happening -- which is magnificent -- but doubt that your average library has the same passion. Koha needs the credibility and stability of a *system*, install, forget (except security), and put on your two-three year review list. </rant> Most respectfully, after nearly three years of getting to "know Koha" and some of the dedicated people involved, Paul --- Maritime heritage and history, preservation and conservation, research and education through the written word and the arts. <http://NavalMarineArchive.com> and <http://UltraMarine.ca>

2 1