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

[SOLVED] Re: Adding logging support to / for custom Koha plugins
by Indranil Das Gupta 11 Jun '14

11 Jun '14

On Wed, Jun 11, 2014 at 5:05 AM, Indranil Das Gupta <indradg(a)gmail.com> wrote: > I would like add logging support. > > My question : how easy or difficult would that be? Well, that was a *dumb* question! *facepalm* Anyways, I got it figured it out. In case someone is looking for something similar, here are the steps involved. 1. include the C4::Log module in the <custom_koha_plugin>.pm file 2. call logaction() with the necessary parameters from the module where ever logging is required. 3. (if necessary, in my case it was) add an additional option to 'modules' select dropdown in log viewer template i.e. viewlog.tt Setting up a syspref to enable / disable the PluginLog was not required in my case. if required it would be simple enough to add. cheers -indra -- Indranil Das Gupta Phone : +91-98300-20971 Blog : http://indradg.randomink.org/blog IRC : indradg on irc://irc.freenode.net Twitter : indradg -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=- Please exchange editable Office documents only in ODF Format. No other format is acceptable. Support Open Standards. For a free editor supporting ODF, please visit LibreOffice - http://www.documentfoundation.org

1 0

Adding logging support to / for custom Koha plugins
by Indranil Das Gupta 11 Jun '14

11 Jun '14

Hi, I've written a couple of custom Koha plugins by following Kyle's KitchenSink example. Things are working fine. I would like add logging support. My question : how easy or difficult would that be? thanks in advance -- Indranil Das Gupta Phone : +91-98300-20971 Blog : http://indradg.randomink.org/blog IRC : indradg on irc://irc.freenode.net Twitter : indradg -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=- Please exchange editable Office documents only in ODF Format. No other format is acceptable. Support Open Standards. For a free editor supporting ODF, please visit LibreOffice - http://www.documentfoundation.org

1 0

On Koha Debian apt repository layout and package versions
by Tomas Cohen Arazi 10 Jun '14

10 Jun '14

---------- Forwarded message ---------- From: Lars Wirzenius <liw(a)liw.fi> Date: Wed, Apr 30, 2014 at 12:21 PM Subject: On Koha Debian apt repository layout and package versions To: tomascohen(a)gmail.com Hi, I made some Debian packages for Koha in 2010, on contract to Catalyst, Ltd, and then left the Koha community. The packages are now maintained by Robin and others. I still lurk on the IRC channel, but I don't follow the mailing lists. I happened to notice recently that there was some discussion on maybe renaming the apt package repositories. I spoke up, and was directed to the mailing list thread starting at [0]. It's a short thread. I offer the following thoughts on the topic, in the hope they're useful. [0] http://lists.koha-community.org/pipermail/koha-devel/2014-April/040428.html First, a little background. Debian apt package repositories may contain many versions of a package, by grouping things into "pockets". The concept has various names in various corners within Debian, and the greater Debian derivatives community, but I'll use this name for simplicity. Each pocket has a name, which is a subdirectory under the "dists" directory in the apt repository. This provides a single dimension for supporting multiple versions, and is used for different Debian releases. Debian has the pockets "stable", "testing", "unstable", and "experimental", where "stable" is the release users are expected to use, unless they're interested in participating in Debian development. Those pockets are actually aliases (via symbolic links) for code names for Debian releases: "squeeze", "wheezy", and "jessie" are names of three Debian releases. The releases also have version numbers, but this is not evident in the apt repository. In addition to the major pockets (one per release), there are some additional ones, such as one for "backports" (e.g., "wheezy-backports"). This allows the apt repository to allow more versions of a package, for different users. For example, the "wheezy" pocket might have version 1.1 of some application, and "wheezy-backports" might have version 2.0, but built for the "wheezy" release. This is different from having 2.0 in the "jessie" pocket, since the binary package is different depending on where it is built. For example, the build for "wheezy-backports" might depend on different versions of, say, some Perl modules, than the one in the "jessie" pocket. This structure works reasonably well for Debian. For Koha, I suggest that the following questions should be answered before changes are made to the repository structure. * Which versions of Koha does the community want to support? Do you have stable versus alpha versus beta versus some other branches? Do you have "long-term support" releases? * When do you want sysadmins to upgrade their Koha packages? Do you want to give them maximum flexibility on this, or do you want to force upgrades when you make a Koha release? * Do you care about producing builds for a variety of releases of Debian or Debian derivatives? Do you care about building for more than the current Debian stable release? Maybe the current stable, and the previous stable release? My knowledge of Koha is years out of date, but from what I remember and from what I understand from lurking, here are my thoughts (and please excuse me if you know all of this already, and already do all of it): * I think it makes sense, if you can automate it, to build for the current Debian release ("stable"), and the previous Debian release ("oldstable"), and also the current Debian development version ("unstable"). Building for the two releases means that those who install the packages get to choose when they upgrade their operating system, without Koha forcing an upgrade. If you only build for the current Debian stable, you force Koha sysadmins to upgrade when Debian makes a release. Building for Debian unstable (or possibly testing) means that you catch incoming changes in Debian sooner rather than later. For example, when Debian upgrades their Perl, you'll learn soon if it affects Koha. These pockets should probably be named after the Debian releases. Currently that would mean pockets named "squeeze", "wheezy", and "unstable". That is, the pocket should be named according what the user is running, not what version of Koha it contains. This keeps things simple for the user, and keeps the number of pockets manageable. * I think it makes sense to build at least two versions of Koha: the current Koha release, and the current tip of the master branch. These packages should have different names, so they do not conflict in the apt repository. The apt repository keeps all package files in "the pool", whereas the "dists" directory only contains lists of packages and versions. The stable Koha release should probably be called "koha". The tip-of-master should be called something else, perhaps "koha-dangerous" to scare people away from installing it without knowing what they do. The two packages could be co-installable, if that make sense for Koha. The dangerous package would allow anyone to easily try out the latest Koha, and if the package is built any time master changes, it'll be easy to keep up to date. This may be easier than running Koha directly from git. * If you think it is worth it, it may be worthwhile to have more than one Koha release in each pocket. It might be to support the latest release plus an LTS release, or to have several stable releases, for example to release bug fixes to older releases as well. If you decide to do this, the cleanest way, in my opinion, is to have packages for each supported release or branch: "koha-3.10", "koha-3.12", and "koha-3.14". These packages would have the latest version of that branch. For example, there might be version 3.10.07 of the koha-3.10 package. This way, someone who wants to stay with Koha 3.10, will install the koha-3.10 package. If there's a new bug fix release of 3.10, the package is updated, and they upgrade to the new package version in the usual way ("apt-get upgrade"). However, they're not forced to upgrade to a newer version of Koha and can do so when they're ready. In addition, there would be an empty package "koha", which would depend on the latest Koha release, for those who do want to have that, with a minimum of fuss. This would allow one to install the package koha, and then get the latest version, even when latest version changes from 3.14 to 3.16. So, in summary, I recommend: * Have pockets "squeeze", "wheezy", and "unstable". * Have packages "koha", "koha-x.y" (for a set of versions you want to provide), and "koha-dangerous" (for latest git commit). I hope this helps, and I apologise for the verbosity of this. I had some time while waiting for a train, but the train came before I had time to squeeze out the fluff from this. (Please Cc me on any replies you wish me to see, as I unfortunately do not have the cerebral cycles to follow the Koha mailing list at this time.) PS. Despite only participating in the community for three months, I remember it very fondly. You do good work, and you make the world a better place. And you're nice and polite while doing it. Inconceivable! -- http://www.cafepress.com/trunktees -- geeky funny T-shirts http://gtdfh.branchable.com/ -- GTD for hackers

3 2

Re: [Koha-devel] Build failed in Jenkins: Koha_master #1913
by Jonathan Druart 09 Jun '14

09 Jun '14

Hello, Jenkins failed ("Failed to determine") because of a git error on fetching. I launched the following commands: root@ks356124:/var/lib/jenkins/jobs/Koha_master/workspace# git remote -v origin git://git.koha-community.org/koha.git (fetch) origin git://git.koha-community.org/koha.git (push) root@ks356124:/var/lib/jenkins/jobs/Koha_master/workspace# git fetch origin error: unable to resolve reference refs/remotes/origin/MM-OPAC/bug_11169: Not a directory >From git://git.koha-community.org/koha ! [new branch] MM-OPAC/bug_11169 -> origin/MM-OPAC/bug_11169 (unable to update local ref) error: some local refs could not be updated; try running 'git remote prune origin' to remove any old, conflicting branches root@ks356124:/var/lib/jenkins/jobs/Koha_master/workspace# git remote prune origin Pruning origin URL: git://git.koha-community.org/koha.git * [pruned] origin/MM-OPAC * [pruned] origin/biblibre-acq-preview-only * [pruned] origin/biblibre-integration * [pruned] origin/biblibre-sopac * [pruned] origin/labels_recon * [pruned] origin/new/3_6_0_po_files * [pruned] origin/new/awaiting_qa/analytical_records * [pruned] origin/new/awaiting_qa/biblibre_various * [pruned] origin/new/awaiting_qa/bug_4506 * [pruned] origin/new/awaiting_qa/bug_4903 * [pruned] origin/new/awaiting_qa/bug_4990 [...] 2014-06-09 8:48 GMT+02:00 <chris(a)bigballofwax.co.nz>: > See <http://jenkins.koha-community.org/job/Koha_master/1913/> > > ------------------------------------------ > Started by an SCM change > Building on master in workspace <http://jenkins.koha-community.org/job/Koha_master/ws/> > > git rev-parse --is-inside-work-tree > Fetching changes from the remote Git repository > > git config remote.origin.url git://git.koha-community.org/koha.git > Fetching upstream changes from git://git.koha-community.org/koha.git > > git --version > > git fetch --tags --progress git://git.koha-community.org/koha.git +refs/heads/*:refs/remotes/origin/* > FATAL: Failed to fetch from git://git.koha-community.org/koha.git > hudson.plugins.git.GitException: Failed to fetch from git://git.koha-community.org/koha.git > at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:625) > at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:847) > at hudson.plugins.git.GitSCM.checkout(GitSCM.java:872) > at hudson.model.AbstractProject.checkout(AbstractProject.java:1252) > at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:604) > at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) > at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:513) > at hudson.model.Run.execute(Run.java:1706) > at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) > at hudson.model.ResourceController.execute(ResourceController.java:88) > at hudson.model.Executor.run(Executor.java:231) > Caused by: hudson.plugins.git.GitException: Command "git fetch --tags --progress git://git.koha-community.org/koha.git +refs/heads/*:refs/remotes/origin/*" returned status code 1: > stdout: > stderr: error: unable to resolve reference refs/remotes/origin/MM-OPAC/bug_11169: Not a directory > From git://git.koha-community.org/koha > ! [new branch] MM-OPAC/bug_11169 -> origin/MM-OPAC/bug_11169 (unable to update local ref) > error: some local refs could not be updated; try running > 'git remote prune git://git.koha-community.org/koha.git' to remove any old, conflicting branches > > at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1325) > at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1186) > at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$200(CliGitAPIImpl.java:87) > at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:257) > at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:623) > ... 10 more

1 0

Re: [Koha-devel] [Koha] US librarians seeking help with Koha APIs
by Chris Cormack 08 Jun '14

08 Jun '14

On 8 June 2014 13:41, Joann Ransom <JoannR(a)tetakere.org.nz> wrote: > Hi James > > Im not clever enough to answer your question but have forwarded it to the > Koha lists because you can't be the first to have hit this issue. Lets > cross fingers simeone can help! > > Cheers jo > > > > > Sent from Samsung tablet > > > > -------- Original message -------- > From: James LaRue <jlarue(a)jlarue.com> > Date: 08/06/2014 9:22 AM (GMT+12:00) > To: Joann Ransom <JoannR(a)tetakere.org.nz> > Subject: US librarians seeking help with Koha APIs > > > Hello Joann, > > I'm Jamie LaRue from Colorado, USA (formerly of Douglas County Libraries), > and Ross Balharrie recommended that I talk with you. > > Colorado is working on a statewide ebook content management platform. > That's well underway, but we've hit a snag in our attempts to integrate the > product with a Koha-based consortium. The administrator of that system > don't have a lot of experience with APIs. It's probably too late for us to > find a magic solution to accomplish this by the time our grant is up, but I > wonder if you might have some suggestions for programmers who do have that > expertise? This is the perfect prototype for an international cooperation, > and Koha is very definitely picking up speed here. > > I'd appreciate any leads you might provide. Thanks! > > > The first thing we would need to know is what version of Koha are they running, because otherwise whatever answer we give will be wrong :) Chris

1 0

Apache configuration for UTF-8
by Zeno Tajoli 06 Jun '14

06 Jun '14

Hi to all, I have update the wiki page http://wiki.koha-community.org/wiki/Encoding_and_Character_Sets_in_Koha in the section about apache. Now there are those lines: AddCharset UTF-8 .utf8 AddDefaultCharset utf-8 I check the use of utf-8 instead of UTF-8 in official Apache manual (2.0, 2.2, 2.4). Bye Zeno Tajoli -- Dr. Zeno Tajoli Dipartimento Gestione delle Informazioni e della Conoscenza z.tajoli(a)cineca.it fax +39 02 2135520 CINECA - Sede operativa di Segrate

4 4

Koha Community Newsletter: April 2014
by Koha Newsletter 05 Jun '14

05 Jun '14

Fellow Koha users: The Koha Community Newsletter for April 2014 is here: http://koha-community.org/koha-community-newsletter-april-2014/ Many thanks to all the folks who submitted articles and news to this month's newsletter. Please feel free to email us with any corrections or suggestions. Thanks! Chad Roseburg Joanne Dillon Editors, Koha Community Newsletter

3 3

Jenkins usage
by Tomas Cohen Arazi 03 Jun '14

03 Jun '14

Hi fellows, I've asked our IT guys to set 4 virtual machines running different OS versions to run the master branch test suit on all of them. The OSs would be: - Debian 6 - Debian 7 - Ubuntu 12.04 - Ubuntu 14.04 All of them 'amd64' atchitecture. Do you think this OS selection is right? I was thinking that a 'Debian testing' might be better than Debian 6, but I'm all ears. Regards To+ -- Tomás Cohen Arazi Prosecretaría de Informática Universidad Nacional de Córdoba ✆ +54 351 5353750 ext 13168 GPG: B76C 6E7C 2D80 551A C765 E225 0A27 2EA1 B2F3 C15F

5 4

Introducing - New member
by Yohann Dufour 03 Jun '14

03 Jun '14

Hello, I've subscribed to this mailing list because I'm a new trainee at BibLibre for the next 3 months. During this 3 months, my work will be to develop unit test, test and write patch. See you Yohann Dufour

3 2

Introduction from Viktor
by Viktor.Sarge＠regionhalland.se 03 Jun '14

03 Jun '14

Dear subscribers of the devel list! My name is Viktor Sarge and as I am now extending my lurking about from IRC and the general list to this list I think a presentation might be in order. I work as a senior regional library development officer at the regional library of Halland in Sweden. I’ve been involved with Koha for a few years now and presently run a project trying to do as much as possible to make Koha a relevant free infrastructure for Swedish libraries. This includes both funding development in Koha and helping interested libraries get hold of the right information. The reason I subscribe to this list is that I want to learn more about the inner workings of Koha and plan to submit one or two line patches once in a while. I’m not really a programmer very often but am dusting of my old SQL and learning a bit of Perl to be able to better understand what’s going on. Some of you I have already met on IRC, the lists and KohaCon2012 but I look forward to follow the discussion here, learn and hopefully get to know some of you a little better in the process. I must say I’ve come to readjust my view of Koha over the years from the code being the valuable resource to the community being the most valuable part of Koha. Kind regards! /Viktor Sarge Viktor Sarge Utvecklingsledare Regionbibliotek Halland Kultur i Halland TFN: 035-17 98 73 E-POST: Viktor.Sarge(a)regionhalland.se BESÖKSADRESS: Södra vägen 9, 30180 Halmstad WEBB: www.regionhalland.se/regionbibliotek

2 1