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

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

anyone have plans to update Koha's MARC21 framework?
by Mason James 01 Jun '13

01 Jun '13

hi Folks does anyone have any plans to update the MARC21 fields and subfields, for Koha? (...or has someone already done this, and is about to send a patch) i plan to start on this task soon, and i wanted to do a quick check that i was not duplicating this work ps: i have seen some awesome patches from Bernardo++ recently! - updating some 008 and 007 stuff ;o) cheers, Mason

2 2

RFC: Plugins QA
by Tomas Cohen Arazi 31 May '13

31 May '13

Hi, with the inclusion of a plugin system we provide a convenient way of injecting functionalities to Koha. I was about to write one myself for implementing some cute graphics (jqPlot) and circulation statistics we had in our 3.0.x fork prior to our 3.8 upgrade. Then I came to think this should indeed be proposed as a new Koha feature (for which there's even a bug). I ended up thinking: - Plugins provide a convenient way to deploy some stuff early (which I need for our 3.12 move), like stuff won't make it into a specific release. - If I succeed I should post it somewhere so people can use it. - There's not a convenient way for it to get QAed so we cannot provide any warranty (not legal but in terms of confidence on Koha as a product) it won't break sensitive stuff (a reports plugin sounds harmless but what limits are imposed to plugins? I guess none). So, I belive we should discuss the creation of a sort of "Official plugins repository" where QAed plugins could be uploaded. I'm thinking out loud and not an native english speaker, so I'm sorry if this is not understandable. Just let me know :-D Regards To+

5 8

May 2013 Koha Community Newsletter has been published
by Daniel Grobani 31 May '13

31 May '13

Hi, The May 2013 edition of the Koha Community Newsletter has been posted to http://koha-community.org/koha-community-newsletter-may-2013/. Cheers, Daniel Grobani Koha Community Newsletter Editor

1 0

Packaging: Adding a perl dependency
by Marcel de Rooy 31 May '13

31 May '13

Hi Robin or one of the other packaging guru's: On report 9032 I plan to add Email::Valid. After adding it to PerlDependencies.pm, some things may need to be done for packaging. Could you give some steps or add a wiki page for such ? Or should I just leave it to you :) Thanks, Marcel

2 1

"IP address has changed. Please log in again"
by Paul Poulain 30 May '13

30 May '13

Hello koha-devel, Some of our customers are reporting that they sometimes need to login after getting this message on the staff interface. - one of them is running Plack (in production), he faces this problem many times an hour, on every workstation (we've commented the lines in C4/Auth.pm to avoid this problem, because it was really a nightmare) - some of them are in CGI mode, behind a proxy, and the problem occurs a few times a day, or even less. Has anyone faced this problem ? how did you solve it ? -- Paul POULAIN - BibLibre http://www.biblibre.com Free & Open Source Softwares for libraries Koha, Drupal, Piwik, Jasper

4 6

Memcached support in packages
by Tomas Cohen Arazi 29 May '13

29 May '13

Hi, i want to add out-of-the-box support for memcached for packages. There are two possible approaches to this: - As a required or suggested dependency that enables it globally if present - As an optional enable/disable per instance service. I'd like to hear what you devs see as the best approach with pros and cons. Regards To+

5 5