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

Call for Development news - June Newsletter
by Koha News 16 Jun '14

16 Jun '14

Koha Development community ~ If you have any bugs or projects you'd like us to highlight or promote in the June newsletter, please let us know. Maybe it'll attract some additional eyes, testers and sign-offs. k o h a news AT gmail dot com Thank you! -- Chad Roseburg Joanne Dillon Editors, Koha Newsletter

1 0

Call for news for June Newsletter
by Koha News 16 Jun '14

16 Jun '14

Fellow Koha users ~ We're collecting news for the June newsletter. Send anything noteworthy to: k o h a news AT gmail dot com News criteria: --------------------------- * News items can be of any length. * Anything and everything Koha. * Submit by the 26th. If you are working on an interesting project or development related to Koha, please let us know and we'll include it in the development section. -- Chad Roseburg Joanne Dillon Editors, Koha Newsletter

1 0

My work - Unit tests progress
by Yohann Dufour 13 Jun '14

13 Jun '14

As announced in my introduction, during my traineeship in BibLibre, I will work on unit tests. If you are interested, you can follow the progress of my work with this link : https://trello.com/b/dYnECluA/koha-unit-tests-progress Have a nice day, Yohann Dufour

1 0

Sandboxes and bug 11944 (Cleanup Koha UTF-8)
by Jonathan Druart 12 Jun '14

12 Jun '14

Hello all, I pushed a patch on the contrib/sandboxes repo in order to create the sandboxes' DB with charset utf8 and collapse utf8_unicode_ci (see http://git.koha-community.org/gitweb/?p=contrib/global.git;a=summary) All Biblibre's sandboxes are up-to-date and use this code. The 2 sandboxes 6 (MARC21) and 16 (UNIMARC) have been "frozen". They use the bug 11944 branch (http://git.biblibre.com/biblibre/kohac/commits/ft/bug_11944 == master + 11944's patches). On the sandbox 16, I imported some arabic and japanese bibliographic records (biblionumber from 21654 to 21660). Feel free to add more. I generated translations for fr-FR and it-IT (it seems there is a bug for ar-Arab with the bootstrap theme: the title tag is not closed), I can add more if needed. For more information about sandboxes, see the wiki page http://wiki.koha-community.org/wiki/Sandboxes. Regards, Jonathan

1 0

Reminder: Koha Developer IRC Meeting today - 11 June 15:00 and 22:00 UTC
by Katrin Fischer 11 Jun '14

11 Jun '14

Hi all, just a quick reminder about the Koha Developer IRC Meeting today at 15:00 and 22:00 UTC: http://wiki.koha-community.org/wiki/Development_IRC_meeting,_11_June_2014 See you there :) Katrin

1 0

[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