From paul.a at aandc.org  Wed Oct  2 00:34:14 2013
From: paul.a at aandc.org (Paul)
Date: Tue, 01 Oct 2013 18:34:14 -0400
Subject: [Koha-devel] 952$j
Message-ID: <5.2.1.1.2.20131001182725.03775a28@stormy.ca>

Our cataloguers have asked for additional precision in specific stacks -- 
952$j "Shelving control number" would appear to be perfect :=)

However, any value entered (eg: LLF15 -- loose leaf folder #15) 
systematically saves as 0 and SchemaSpy doesn't appear to even mention this 
field which is in the "default template" with no apparent restrictions.

Can anyone with good "corporate memory" of 952$j use and programming please 
assist?

Many thanks and best regards -- Paul


From joy at bywatersolutions.com  Wed Oct  2 01:01:06 2013
From: joy at bywatersolutions.com (Joy Nelson)
Date: Tue, 1 Oct 2013 18:01:06 -0500
Subject: [Koha-devel] 952$j
In-Reply-To: <5.2.1.1.2.20131001182725.03775a28@stormy.ca>
References: <5.2.1.1.2.20131001182725.03775a28@stormy.ca>
Message-ID: <CAFpshE9_PdVOxRU0fi3nUVwBG=AL5v4kpPU6kiQezWS3MeWt-A@mail.gmail.com>

Paul-
If you are using the $i and it is linked in the maps and frameworks to
items.stack, you may be having a problem since the stack field is a tinyint
field and can't hold the data you are using.  You may want to consider
using the stocknumber field in the items table.  I have been able to add
data using the $j (stocknumber) field (through importing data- editing the
items was not my priority in that particular usage).

Joy Nelson



On Tue, Oct 1, 2013 at 5:34 PM, Paul <paul.a at aandc.org> wrote:

> Our cataloguers have asked for additional precision in specific stacks --
> 952$j "Shelving control number" would appear to be perfect :=)
>
> However, any value entered (eg: LLF15 -- loose leaf folder #15)
> systematically saves as 0 and SchemaSpy doesn't appear to even mention this
> field which is in the "default template" with no apparent restrictions.
>
> Can anyone with good "corporate memory" of 952$j use and programming
> please assist?
>
> Many thanks and best regards -- Paul
>
> ______________________________**_________________
> Koha-devel mailing list
> Koha-devel at lists.koha-**community.org<Koha-devel at lists.koha-community.org>
> http://lists.koha-community.**org/cgi-bin/mailman/listinfo/**koha-devel<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/ <http://bugs.koha-community.org/>
>



-- 
Joy Nelson
Director of Migrations

ByWater Solutions <http://bywatersolutions.com>
Support and Consulting for Open Source Software
**Office: Fort Worth, TX
Phone/Fax (888)900-8944
What is Koha? <http://bywatersolutions.com/what-is-koha/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131001/b77409cb/attachment.html>

From barry at oslo.ie  Wed Oct  2 11:51:05 2013
From: barry at oslo.ie (Barry Cannon)
Date: Wed, 2 Oct 2013 10:51:05 +0100
Subject: [Koha-devel] Bug (or something) repeatedly loading the same URL
 over and over.
In-Reply-To: <52466618.1010501@catalyst.net.nz>
References: <1380249410.4718.15.camel@zarathud>
	<CAPLnt66VW-D88AVW1z4iikpi639mzfkDYS4Bfh25i9ueLm34Og@mail.gmail.com>
	<CAPLnt66U+=hgDyxwkjZ+w-B4_dVL3dvy5P0OWQcz3LJM1AkZWA@mail.gmail.com>
	<CAPLnt65Um5RtNg48_ZckTMarKEzt9oAzbnhxQ01JnUGwa-wv_g@mail.gmail.com>
	<52466618.1010501@catalyst.net.nz>
Message-ID: <CAOmVZJ-suyHN7ZKamj-0D6XNwdA313fQvUh_fcw6fJKCz5N1QQ@mail.gmail.com>

This has just starting happening to one of our sites. While I can recreate
a server crash by holding down the enter key on certain pages I am not
certain this is the issue. When holding down the enter key and forcing a
crash I can see the apache logs showing multiple posts. The kernel log
shows the end result of a server crash and OOM starts picking off
processes, as expected.
However, when the event happens in the wild, so to speak, there isn't
anything unusual about the apache logs. The syslog show the details below
suggesting opac-main.pl is the culprit but I am struggling to find any form
that posts to opac-main.pl in order to cause multipl form submissions.

/var/log/syslog.1:Oct  1 11:49:26 srv1 kernel: opac-main.pl invoked
oom-killer: gfp_mask=0x201da, order=0, oom_adj=0, oom_score_adj=0
/var/log/syslog.1:Oct  1 11:49:26 srv1 kernel: [<c10a3408>]
oom_kill_process+0x68/0x220
/var/log/syslog.1:Oct  1 11:49:26 srv1 kernel: Out of memory: Kill process
6774 (mysqld) score 42 or sacrifice child
/var/log/syslog.1:Oct  1 11:49:26 srv1 kernel: Killed process 6774 (mysqld)
total-vm:335720kB, anon-rss:183608kB, file-rss:0kB
/var/log/syslog.1:Oct  1 11:49:26 srv1 kernel: init: mysql main process
(6774) killed by KILL signal


Regards
Barry




On Sat, Sep 28, 2013 at 6:16 AM, Robin Sheat <robin at catalyst.net.nz> wrote:

> op 28-09-13 07:45, Galen Charlton schreef:
> > Adapting a JavaScript technique [1] to disable multiple form submission
> > prevented holding down on the enter key from spamming patron searches
> > for me.  Of course, that's not a bulletproof technique for various
> > reasons, but something like it should probably be part of Koha's toolkit.
>
> I'm not completely convinced that it's someone holding down enter on the
> search form. However, if it is, or if it's something that has that
> effect, blocking multiple submits seems like a good defensive approach
> anyway.
>
> Robin.
>
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131002/a6bf5d3c/attachment.html>

From colin.campbell at ptfs-europe.com  Wed Oct  2 13:16:09 2013
From: colin.campbell at ptfs-europe.com (Colin Campbell)
Date: Wed, 2 Oct 2013 12:16:09 +0100
Subject: [Koha-devel] Bug (or something) repeatedly loading the same URL
 over and over.
In-Reply-To: <CAOmVZJ-suyHN7ZKamj-0D6XNwdA313fQvUh_fcw6fJKCz5N1QQ@mail.gmail.com>
References: <1380249410.4718.15.camel@zarathud>
	<CAPLnt66VW-D88AVW1z4iikpi639mzfkDYS4Bfh25i9ueLm34Og@mail.gmail.com>
	<CAPLnt66U+=hgDyxwkjZ+w-B4_dVL3dvy5P0OWQcz3LJM1AkZWA@mail.gmail.com>
	<CAPLnt65Um5RtNg48_ZckTMarKEzt9oAzbnhxQ01JnUGwa-wv_g@mail.gmail.com>
	<52466618.1010501@catalyst.net.nz>
	<CAOmVZJ-suyHN7ZKamj-0D6XNwdA313fQvUh_fcw6fJKCz5N1QQ@mail.gmail.com>
Message-ID: <20131002111609.GA8658@zazou.cscnet.co.uk>

On Wed, Oct 02, 2013 at 10:51:05AM +0100, Barry Cannon wrote:
> However, when the event happens in the wild, so to speak, there isn't
> anything unusual about the apache logs. The syslog show the details below
> suggesting opac-main.pl is the culprit but I am struggling to find any form
> that posts to opac-main.pl in order to cause multipl form submissions.

If a session gets restarted that would call opac-main.pl. I wonder if
something has failed/blown up without logging and what we are seeing
here is an attempt to restart an opac session after some other part of
the system has caused the damage silently.

Colin

-- 
Colin Campbell
Chief Software Engineer,
PTFS Europe Limited
Content Management and Library Solutions
+44 (0) 800 756 6803 (phone)
+44 (0) 7759 633626  (mobile)
colin.campbell at ptfs-europe.com
skype: colin_campbell2

http://www.ptfs-europe.com

From philippe.blouin at inLibro.com  Wed Oct  2 22:14:00 2013
From: philippe.blouin at inLibro.com (Philippe Blouin)
Date: Wed, 02 Oct 2013 16:14:00 -0400
Subject: [Koha-devel] General questions from a first-patcher
In-Reply-To: <C6FEE3D6-D835-47BA-A620-4BE4A040B23B@kohaaloha.com>
References: <52449437.9080609@inLibro.com> <1380238190.6514.15.camel@zarathud>
	<C6FEE3D6-D835-47BA-A620-4BE4A040B23B@kohaaloha.com>
Message-ID: <524C7E88.9030700@inLibro.com>

Still no luck with git-bz.  After entering

Attach? [yn] y
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
                       "http://www.w3.org/TR/html4/loose.dtd">
<html lang="en">
   <head>
     <title>Suspicious Action</title>

/...//
//a very long xml//
//..../
*Failed to attach patch to bug 10986, status=200*





On 13-09-30 02:38 PM, Mason James wrote:
> On 2013-09-27, at 11:29 AM, Robin Sheat wrote:
>
>> Philippe Blouin schreef op do 26-09-2013 om 16:08 [-0400]:
>>> First to present myself, I'm a new developper on Koha.  I work for
>>> inLibro, which has been a Koha proponent for a while now.
>
>>> Questions:
>>> - I work with patches.  I used git-bz for one, and manual for the
>>> others.  Now how to I email to patch mailing list?  I just copy the
>>> content?  I comment it?  Do I add the [PATCH] in the header or some
>>> tool could have done all that for me?  (my server can't send email, so
>>> I'm not sure if git-bz should have done it)
>> Git can do it. I use:
>>
>> git send-email --to=kpatches HEAD^
>>
>> where ~/.git_aliases contains:
>>
>> alias kpatches koha-patches at lists.koha-community.org
>>
>> Git-bz is the best thing for interacting with bugzilla. It makes life
>> substantially easier. And if you format patches like above, just do:
>>
>> git bz attach HEAD
>>
>> and it'll figure out the bug to apply it to.
>
> hi Philippe
>
> also, git-bz will email your patch(es) to the patches list, via the '--mail' arg
>
> $ git bz attach --mail 9999 HEAD
>
>
> (for this to work, you do need to subscribe to the list first)
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/

-- 
Philippe Blouin,
Responsable du d?veloppement informatique

T?l.  : (888) 604-2627
philippe.blouin at inLibro.com <mailto:philippe.blouin at inLibro.com>

inLibro | pour esprit libre | www.inLibro.com <http://www.inLibro.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131002/6b58e319/attachment.html>

From robin at catalyst.net.nz  Thu Oct  3 01:02:54 2013
From: robin at catalyst.net.nz (Robin Sheat)
Date: Thu, 03 Oct 2013 12:02:54 +1300
Subject: [Koha-devel] General questions from a first-patcher
In-Reply-To: <524C7E88.9030700@inLibro.com>
References: <52449437.9080609@inLibro.com> <1380238190.6514.15.camel@zarathud>
	<C6FEE3D6-D835-47BA-A620-4BE4A040B23B@kohaaloha.com>
	<524C7E88.9030700@inLibro.com>
Message-ID: <1380754974.9200.0.camel@zarathud>

Philippe Blouin schreef op wo 02-10-2013 om 16:14 [-0400]:
> Still no luck with git-bz.  After entering 

>     <title>Suspicious Action</title>

Can you find the bit where it says what the suspicious action is?

-- 
Robin Sheat
Catalyst IT Ltd.
? +64 4 803 2204
GPG: 5FA7 4B49 1E4D CAA4 4C38  8505 77F5 B724 F871 3BDF
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131003/540e51ad/attachment.pgp>

From robin at catalyst.net.nz  Thu Oct  3 01:06:02 2013
From: robin at catalyst.net.nz (Robin Sheat)
Date: Thu, 03 Oct 2013 12:06:02 +1300
Subject: [Koha-devel] Bug (or something) repeatedly loading the same URL
 over and over.
In-Reply-To: <CAOmVZJ-suyHN7ZKamj-0D6XNwdA313fQvUh_fcw6fJKCz5N1QQ@mail.gmail.com>
References: <1380249410.4718.15.camel@zarathud>
	<CAPLnt66VW-D88AVW1z4iikpi639mzfkDYS4Bfh25i9ueLm34Og@mail.gmail.com>
	<CAPLnt66U+=hgDyxwkjZ+w-B4_dVL3dvy5P0OWQcz3LJM1AkZWA@mail.gmail.com>
	<CAPLnt65Um5RtNg48_ZckTMarKEzt9oAzbnhxQ01JnUGwa-wv_g@mail.gmail.com>
	<52466618.1010501@catalyst.net.nz>
	<CAOmVZJ-suyHN7ZKamj-0D6XNwdA313fQvUh_fcw6fJKCz5N1QQ@mail.gmail.com>
Message-ID: <1380755162.9200.3.camel@zarathud>

Barry Cannon schreef op wo 02-10-2013 om 10:51 [+0100]:
> The syslog show the details below suggesting opac-main.pl is the
> culprit but I am struggling to find any form that posts to
> opac-main.pl in order to cause multipl form submissions. 

The syslog just shows what was killed, it's not necessarily (but still
quite possibly) the same thing that is causing the problem.

The apache logs are probably more useful.

A note about the apache logs: 
* the log line is written to the file when the request finishes,
* the timestamp in the log line is from when the request was received.

This means that a 30-second request can show after stuff that has a
later time, and can be quite confusing at first glance.

-- 
Robin Sheat
Catalyst IT Ltd.
? +64 4 803 2204
GPG: 5FA7 4B49 1E4D CAA4 4C38  8505 77F5 B724 F871 3BDF
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131003/892025b5/attachment.pgp>

From philippe.blouin at inLibro.com  Thu Oct  3 14:21:27 2013
From: philippe.blouin at inLibro.com (Philippe Blouin)
Date: Thu, 03 Oct 2013 08:21:27 -0400
Subject: [Koha-devel] General questions from a first-patcher
In-Reply-To: <1380754974.9200.0.camel@zarathud>
References: <52449437.9080609@inLibro.com> <1380238190.6514.15.camel@zarathud>
	<C6FEE3D6-D835-47BA-A620-4BE4A040B23B@kohaaloha.com>
	<524C7E88.9030700@inLibro.com> <1380754974.9200.0.camel@zarathud>
Message-ID: <524D6147.4060009@inLibro.com>

Hi Robin!

I attached the response (conveniently put in a .html file for easier 
display).  That's the whole response, minus the little non-html bits 
I've already given.

And the maybe relevant git config stuff:
user.email=philippe.blouin at inlibro.com
bz-tracker.bugs.koha-community.org.path=/bugzilla3
bz-tracker.bugs.koha-community.org.bz-user=philippe.blouin at inlibro.com
bz-tracker.bugs.koha-community.org.bz-password=XXXXXXXXXXXX
bz.default-tracker=bugs.koha-community.org

Thanks again,
Blou



On 13-10-02 07:02 PM, Robin Sheat wrote:
> Philippe Blouin schreef op wo 02-10-2013 om 16:14 [-0400]:
>> Still no luck with git-bz.  After entering
>>      <title>Suspicious Action</title>
> Can you find the bit where it says what the suspicious action is?
>
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/

-- 
Philippe Blouin,
Responsable du d?veloppement informatique

T?l.  : (888) 604-2627
philippe.blouin at inLibro.com <mailto:philippe.blouin at inLibro.com>

inLibro | pour esprit libre | www.inLibro.com <http://www.inLibro.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131003/53c9e4cc/attachment.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131003/53c9e4cc/attachment-0001.html>

From tomascohen at gmail.com  Thu Oct  3 14:52:49 2013
From: tomascohen at gmail.com (Tomas Cohen Arazi)
Date: Thu, 3 Oct 2013 09:52:49 -0300
Subject: [Koha-devel] General questions from a first-patcher
In-Reply-To: <524D6147.4060009@inLibro.com>
References: <52449437.9080609@inLibro.com> <1380238190.6514.15.camel@zarathud>
	<C6FEE3D6-D835-47BA-A620-4BE4A040B23B@kohaaloha.com>
	<524C7E88.9030700@inLibro.com>
	<1380754974.9200.0.camel@zarathud> <524D6147.4060009@inLibro.com>
Message-ID: <CABZfb=WTiPRM=Ww1qckVqv-V-eE6Afy2Caj1FJy8F0cHh6+L1w@mail.gmail.com>

On Thu, Oct 3, 2013 at 9:21 AM, Philippe Blouin <philippe.blouin at inlibro.com
> wrote:

>  Hi Robin!
>
> I attached the response (conveniently put in a .html file for easier
> display).  That's the whole response, minus the little non-html bits I've
> already given.
>
> And the maybe relevant git config stuff:
> user.email=philippe.blouin at inlibro.com
> bz-tracker.bugs.koha-community.org.path=/bugzilla3
> bz-tracker.bugs.koha-community.org.bz-user=philippe.blouin at inlibro.com
> bz-tracker.bugs.koha-community.org.bz-password=XXXXXXXXXXXX
> bz.default-tracker=bugs.koha-community.org
>

I only have this in .gitconfig

[bz-tracker "bugs.koha-community.org"]
        path = /bugzilla3
        bz-user = tomascohen at gmail.com
        bz-password = XXX

Regards
To+

-- 
Tom?s Cohen Arazi
Prosecretar?a de Inform?tica
Universidad Nacional de C?rdoba
? +54 351 4333190 ext 13168
GPG: B76C 6E7C 2D80 551A C765  E225 0A27 2EA1 B2F3 C15F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131003/2297a6d4/attachment-0001.html>

From philippe.blouin at inLibro.com  Thu Oct  3 15:42:49 2013
From: philippe.blouin at inLibro.com (Philippe Blouin)
Date: Thu, 03 Oct 2013 09:42:49 -0400
Subject: [Koha-devel] General questions from a first-patcher
In-Reply-To: <CABZfb=WTiPRM=Ww1qckVqv-V-eE6Afy2Caj1FJy8F0cHh6+L1w@mail.gmail.com>
References: <52449437.9080609@inLibro.com> <1380238190.6514.15.camel@zarathud>
	<C6FEE3D6-D835-47BA-A620-4BE4A040B23B@kohaaloha.com>
	<524C7E88.9030700@inLibro.com> <1380754974.9200.0.camel@zarathud>
	<524D6147.4060009@inLibro.com>
	<CABZfb=WTiPRM=Ww1qckVqv-V-eE6Afy2Caj1FJy8F0cHh6+L1w@mail.gmail.com>
Message-ID: <524D7459.3070406@inLibro.com>

I gave extra info, but once limited to .gitconfig, I have exactly the 
same parameters.

[bz-tracker "bugs.koha-community.org"]
      path = /bugzilla3
      bz-user = philippe.blouin at inlibro.com
      bz-password = "XXXXXXXX"

well, beside the "" around the password.

On 13-10-03 08:52 AM, Tomas Cohen Arazi wrote:
>
>
>
> On Thu, Oct 3, 2013 at 9:21 AM, Philippe Blouin 
> <philippe.blouin at inlibro.com <mailto:philippe.blouin at inlibro.com>> wrote:
>
>     Hi Robin!
>
>     I attached the response (conveniently put in a .html file for
>     easier display).  That's the whole response, minus the little
>     non-html bits I've already given.
>
>     And the maybe relevant git config stuff:
>     user.email=philippe.blouin at inlibro.com
>     <mailto:user.email=philippe.blouin at inlibro.com>
>     bz-tracker.bugs.koha-community.org.path=/bugzilla3
>     bz-tracker.bugs.koha-community.org.bz-user=philippe.blouin at inlibro.com
>     <mailto:bz-tracker.bugs.koha-community.org.bz-user=philippe.blouin at inlibro.com>
>     bz-tracker.bugs.koha-community.org.bz-password=XXXXXXXXXXXX
>     bz.default-tracker=bugs.koha-community.org
>     <http://bugs.koha-community.org>
>
>
> I only have this in .gitconfig
>
> [bz-tracker "bugs.koha-community.org <http://bugs.koha-community.org>"]
>         path = /bugzilla3
>         bz-user = tomascohen at gmail.com <mailto:tomascohen at gmail.com>
>         bz-password = XXX
> Regards
> To+
>
> -- 
> Tom?s Cohen Arazi
> Prosecretar?a de Inform?tica
> Universidad Nacional de C?rdoba
> ? +54 351 4333190 ext 13168
> GPG: B76C 6E7C 2D80 551A C765  E225 0A27 2EA1 B2F3 C15F

-- 
Philippe Blouin,
Responsable du d?veloppement informatique

T?l.  : (888) 604-2627
philippe.blouin at inLibro.com <mailto:philippe.blouin at inLibro.com>

inLibro | pour esprit libre | www.inLibro.com <http://www.inLibro.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131003/3d30c6b7/attachment.html>

From jcamins at cpbibliography.com  Thu Oct  3 15:46:51 2013
From: jcamins at cpbibliography.com (Jared Camins-Esakov)
Date: Thu, 3 Oct 2013 09:46:51 -0400
Subject: [Koha-devel] General questions from a first-patcher
In-Reply-To: <524D7459.3070406@inLibro.com>
References: <52449437.9080609@inLibro.com> <1380238190.6514.15.camel@zarathud>
	<C6FEE3D6-D835-47BA-A620-4BE4A040B23B@kohaaloha.com>
	<524C7E88.9030700@inLibro.com> <1380754974.9200.0.camel@zarathud>
	<524D6147.4060009@inLibro.com>
	<CABZfb=WTiPRM=Ww1qckVqv-V-eE6Afy2Caj1FJy8F0cHh6+L1w@mail.gmail.com>
	<524D7459.3070406@inLibro.com>
Message-ID: <CALVDfQytJg=aoYen2CsteMhN0_7G+i7hbEWD68zTfExEfMM=mg@mail.gmail.com>

Philippe,

That error looks to me like the one you would get if you had an old version
of git-bz. Did you clone the git-bz repo on git.koha-community.org and
check out the fishsoup branch?

Regards,
Jared


On Thu, Oct 3, 2013 at 9:42 AM, Philippe Blouin <philippe.blouin at inlibro.com
> wrote:

>  I gave extra info, but once limited to .gitconfig, I have exactly the
> same parameters.
>
>
> [bz-tracker "bugs.koha-community.org"]
>      path = /bugzilla3
>      bz-user = philippe.blouin at inlibro.com
>      bz-password = "XXXXXXXX"
>
> well, beside the "" around the password.
>
>
> On 13-10-03 08:52 AM, Tomas Cohen Arazi wrote:
>
>
>
>
> On Thu, Oct 3, 2013 at 9:21 AM, Philippe Blouin <
> philippe.blouin at inlibro.com> wrote:
>
>>  Hi Robin!
>>
>> I attached the response (conveniently put in a .html file for easier
>> display).  That's the whole response, minus the little non-html bits I've
>> already given.
>>
>> And the maybe relevant git config stuff:
>> user.email=philippe.blouin at inlibro.com
>> bz-tracker.bugs.koha-community.org.path=/bugzilla3
>> bz-tracker.bugs.koha-community.org.bz-user=philippe.blouin at inlibro.com
>> bz-tracker.bugs.koha-community.org.bz-password=XXXXXXXXXXXX
>> bz.default-tracker=bugs.koha-community.org
>>
>
>  I only have this in .gitconfig
>
>  [bz-tracker "bugs.koha-community.org"]
>         path = /bugzilla3
>         bz-user = tomascohen at gmail.com
>         bz-password = XXX
>
> Regards
> To+
>
>  --
>  Tom?s Cohen Arazi
> Prosecretar?a de Inform?tica
> Universidad Nacional de C?rdoba
> ? +54 351 4333190 ext 13168
> GPG: B76C 6E7C 2D80 551A C765  E225 0A27 2EA1 B2F3 C15F
>
>
> --
>  Philippe Blouin,
> Responsable du d?veloppement informatique
>
> T?l.  : (888) 604-2627
> philippe.blouin at inLibro.com
>  inLibro | pour esprit libre | www.inLibro.com
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/
>



-- 
Jared Camins-Esakov
Bibliographer, C & P Bibliography Services, LLC
(phone) +1 (917) 727-3445
(e-mail) jcamins at cpbibliography.com
(web) http://www.cpbibliography.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131003/eff9cf04/attachment.html>

From philippe.blouin at inLibro.com  Thu Oct  3 16:22:34 2013
From: philippe.blouin at inLibro.com (Philippe Blouin)
Date: Thu, 03 Oct 2013 10:22:34 -0400
Subject: [Koha-devel] General questions from a first-patcher
In-Reply-To: <CALVDfQytJg=aoYen2CsteMhN0_7G+i7hbEWD68zTfExEfMM=mg@mail.gmail.com>
References: <52449437.9080609@inLibro.com> <1380238190.6514.15.camel@zarathud>
	<C6FEE3D6-D835-47BA-A620-4BE4A040B23B@kohaaloha.com>
	<524C7E88.9030700@inLibro.com> <1380754974.9200.0.camel@zarathud>
	<524D6147.4060009@inLibro.com>
	<CABZfb=WTiPRM=Ww1qckVqv-V-eE6Afy2Caj1FJy8F0cHh6+L1w@mail.gmail.com>
	<524D7459.3070406@inLibro.com>
	<CALVDfQytJg=aoYen2CsteMhN0_7G+i7hbEWD68zTfExEfMM=mg@mail.gmail.com>
Message-ID: <524D7DAA.4010501@inLibro.com>

Interesting.

I switched computer yesterday and that one WAS NOT on fishsoup.  I 
ignored the advice earlier as I knew I was on fishsoup on the server.  
Well, *thank you!* that solved my local problem.  Not my server's, but 
I'll work on that ... later :)

Now I get
Incorrect authentication data
65280

The patch is attached, so I guess that issue was to send the email:
git bz attach --mail 10986 HEAD


Thanks a gain for your time!
Blou


On 13-10-03 09:46 AM, Jared Camins-Esakov wrote:
> Philippe,
>
> That error looks to me like the one you would get if you had an old 
> version of git-bz. Did you clone the git-bz repo on 
> git.koha-community.org <http://git.koha-community.org> and check out 
> the fishsoup branch?
>
> Regards,
> Jared
>
>
> On Thu, Oct 3, 2013 at 9:42 AM, Philippe Blouin 
> <philippe.blouin at inlibro.com <mailto:philippe.blouin at inlibro.com>> wrote:
>
>     I gave extra info, but once limited to .gitconfig, I have exactly
>     the same parameters.
>
>
>     [bz-tracker "bugs.koha-community.org
>     <http://bugs.koha-community.org>"]
>          path = /bugzilla3
>          bz-user = philippe.blouin at inlibro.com
>     <mailto:philippe.blouin at inlibro.com>
>          bz-password = "XXXXXXXX"
>
>     well, beside the "" around the password.
>
>
>     On 13-10-03 08 <tel:13-10-03%2008>:52 AM, Tomas Cohen Arazi wrote:
>>
>>
>>
>>     On Thu, Oct 3, 2013 at 9:21 AM, Philippe Blouin
>>     <philippe.blouin at inlibro.com
>>     <mailto:philippe.blouin at inlibro.com>> wrote:
>>
>>         Hi Robin!
>>
>>         I attached the response (conveniently put in a .html file for
>>         easier display). That's the whole response, minus the little
>>         non-html bits I've already given.
>>
>>         And the maybe relevant git config stuff:
>>         user.email=philippe.blouin at inlibro.com
>>         <mailto:user.email=philippe.blouin at inlibro.com>
>>         bz-tracker.bugs.koha-community.org.path=/bugzilla3
>>         bz-tracker.bugs.koha-community.org.bz-user=philippe.blouin at inlibro.com
>>         <mailto:bz-tracker.bugs.koha-community.org.bz-user=philippe.blouin at inlibro.com>
>>         bz-tracker.bugs.koha-community.org.bz-password=XXXXXXXXXXXX
>>         bz.default-tracker=bugs.koha-community.org
>>         <http://bugs.koha-community.org>
>>
>>
>>     I only have this in .gitconfig
>>
>>     [bz-tracker "bugs.koha-community.org
>>     <http://bugs.koha-community.org>"]
>>             path = /bugzilla3
>>             bz-user = tomascohen at gmail.com <mailto:tomascohen at gmail.com>
>>             bz-password = XXX
>>     Regards
>>     To+
>>
>>     -- 
>>     Tom?s Cohen Arazi
>>     Prosecretar?a de Inform?tica
>>     Universidad Nacional de C?rdoba
>>     ? +54 351 4333190 ext 13168 <tel:%2B54%20351%204333190%20ext%2013168>
>>     GPG: B76C 6E7C 2D80 551A C765  E225 0A27 2EA1 B2F3 C15F
>
>     -- 
>     Philippe Blouin,
>     Responsable du d?veloppement informatique
>
>     T?l.  : (888) 604-2627 <tel:%28888%29%20604-2627>
>     philippe.blouin at inLibro.com <mailto:philippe.blouin at inLibro.com>
>
>     inLibro | pour esprit libre | www.inLibro.com
>     <http://www.inLibro.com>
>
>     _______________________________________________
>     Koha-devel mailing list
>     Koha-devel at lists.koha-community.org
>     <mailto:Koha-devel at 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/
>
>
>
>
> -- 
> Jared Camins-Esakov
> Bibliographer, C & P Bibliography Services, LLC
> (phone) +1 (917) 727-3445
> (e-mail) jcamins at cpbibliography.com <mailto:jcamins at cpbibliography.com>
> (web) http://www.cpbibliography.com/

-- 
Philippe Blouin,
Responsable du d?veloppement informatique

T?l.  : (888) 604-2627
philippe.blouin at inLibro.com <mailto:philippe.blouin at inLibro.com>

inLibro | pour esprit libre | www.inLibro.com <http://www.inLibro.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131003/8d4482d6/attachment-0001.html>

From mathieu.saby at univ-rennes2.fr  Thu Oct  3 23:34:23 2013
From: mathieu.saby at univ-rennes2.fr (Mathieu Saby)
Date: Thu, 03 Oct 2013 23:34:23 +0200
Subject: [Koha-devel] Zebra : left truncation and left+right truncation with
	ICU
Message-ID: <524DE2DF.7060207@univ-rennes2.fr>

Hello

Since dec. 2012, the new version of Zebra (2.0.53) has fix the support 
of @attr 5=2, @attr 5=3 for ICU records.
http://www.indexdata.com/zebra/doc/NEWS

This could be a good news for people using ICU, for example French 
libraries.

When Koha is installed, I don't know if a specific version of Zebra is 
installed with it, or if it is the last available version of Zebra. 
Could you tell me how it works?
If it is not the last available version, it could be interesting to 
install 2.0.53 version, so we could support @attr 5=2, @attr 5=3. But 
maybe some changes must also be made to Koha's code for taking advantage 
of this bugfix?

Regards,
M. Saby
Rennes 2 University

-- 
Mathieu Saby
Service d'Informatique Documentaire
Service Commun de Documentation
Universit? Rennes 2
T?l?phone : 02 99 14 12 65
Courriel : mathieu.saby at univ-rennes2.fr


From gmc at esilibrary.com  Fri Oct  4 04:52:18 2013
From: gmc at esilibrary.com (Galen Charlton)
Date: Thu, 3 Oct 2013 19:52:18 -0700
Subject: [Koha-devel] Feature freeze nearly upon us
Message-ID: <CAPLnt64Cmb4jGom-CN2JgFG0-GvAe5os5K=7Ft0h-ZcpxFY7yw@mail.gmail.com>

Hi,

I have marked the enhancement and new feature freeze bugs that have either
passed QA or are on my exception list with the keyword rel_3_14_candidates.
 You can view the list here:

http://bugs.koha-community.org/bugzilla3/buglist.cgi?keywords=rel_3_14_candidate&list_id=76458

Tomorrow morning I'll mark any that may have passed QA in the next four
hours since the writing of this email.

I'll be doing a lot of merging over the next few days, and aim to cut an
alpha tarball towards the end of next week, with a beta tarball to follow
some time during KohaCon.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  gmc at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131003/64dadb96/attachment.html>

From Katrin.Fischer.83 at web.de  Fri Oct  4 22:01:40 2013
From: Katrin.Fischer.83 at web.de (Katrin Fischer)
Date: Fri, 04 Oct 2013 22:01:40 +0200
Subject: [Koha-devel] Kohacon: Hackfest planning and arrivals
Message-ID: <524F1EA4.6030409@web.de>

Hi all,

Only a bit over a week until KohaCon!

There is page to gather some ideas for topics, presentations, tutorials
and whatever you'd like to see happen regarding the hackfest on the wiki
now:
http://wiki.koha-community.org/wiki/Kohacon13/Hackfest

And if you want to, there is also a wiki page where you can note your
arrival and departure times:
http://wiki.koha-community.org/wiki/Kohacon13/Arrivals

Maybe someone is on the same flights as you are?

Looking forward to meet you all soon.

Katrin

From 5p4m at gmx.de  Sun Oct  6 17:03:28 2013
From: 5p4m at gmx.de (Mirko)
Date: Sun, 06 Oct 2013 17:03:28 +0200
Subject: [Koha-devel] Kohacon 2014 location vote closing in ~9 hours
Message-ID: <52517BC0.8040700@gmx.de>

Hi everybody,

this is a short reminder that the voting for the location of next
year's conference is closing tonight at 23:59:59 UTC. That is in
about 9 hours, if you have not voted yet, this is your last chance.
There have been a few hundred votes so far.

http://abunchofthings.net/limesurvey/index.php/952665/lang-en

-- Mirko

From mathieu.saby at univ-rennes2.fr  Sun Oct  6 20:10:12 2013
From: mathieu.saby at univ-rennes2.fr (Mathieu Saby)
Date: Sun, 06 Oct 2013 20:10:12 +0200
Subject: [Koha-devel] software error after last Koha update
Message-ID: <5251A784.6050909@univ-rennes2.fr>

Hello

2 says ago, I updated my Koha instance and got a nasty error.
I thought it was my fault, but today I tried to test BZ 10309 (the new 
opac theme ) on sandbox1, and I experienced the same error :

http://pro.test1.biblibre.com/
Software error:
Can't locate Crypt/Eksblowfish/Bcrypt.pm in @INC (@INC contains: 
/home/koha/src /etc/perl /usr/local/lib/perl/5.10.1 
/usr/local/share/perl/5.10.1 /usr/lib/perl5 /usr/share/perl5 
/usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl .) at 
/home/koha/src/C4/Auth.pm line 26.
BEGIN failed--compilation aborted at /home/koha/src/C4/Auth.pm line 26.
Compilation failed in require at /home/koha/src/mainpage.pl line 25.
BEGIN failed--compilation aborted at /home/koha/src/mainpage.pl line 25.

http://catalogue.test1.biblibre.com/
Internal Server Error
The server encountered an internal error or misconfiguration and was 
unable to complete your request.


Do you know if it could be related to some patch recently pushed?

Regards,
M. Saby

-- 
Mathieu Saby
Service d'Informatique Documentaire
Service Commun de Documentation
Universit? Rennes 2
T?l?phone : 02 99 14 12 65
Courriel : mathieu.saby at univ-rennes2.fr


From chris at bigballofwax.co.nz  Sun Oct  6 20:18:04 2013
From: chris at bigballofwax.co.nz (Chris Cormack)
Date: Mon, 7 Oct 2013 07:18:04 +1300
Subject: [Koha-devel] software error after last Koha update
In-Reply-To: <5251A784.6050909@univ-rennes2.fr>
References: <5251A784.6050909@univ-rennes2.fr>
Message-ID: <CA+95qVSD7ZGxAp5zx6fbc1dV=qCSgn+MBoC7M9LF+S8KLovHaw@mail.gmail.com>

On 7 October 2013 07:10, Mathieu Saby <mathieu.saby at univ-rennes2.fr> wrote:
> Hello
>
> 2 says ago, I updated my Koha instance and got a nasty error.
> I thought it was my fault, but today I tried to test BZ 10309 (the new opac
> theme ) on sandbox1, and I experienced the same error :
>
> http://pro.test1.biblibre.com/
> Software error:
> Can't locate Crypt/Eksblowfish/Bcrypt.pm in @INC (@INC contains:
> /home/koha/src /etc/perl /usr/local/lib/perl/5.10.1
> /usr/local/share/perl/5.10.1 /usr/lib/perl5 /usr/share/perl5
> /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl .) at
> /home/koha/src/C4/Auth.pm line 26.
> BEGIN failed--compilation aborted at /home/koha/src/C4/Auth.pm line 26.
> Compilation failed in require at /home/koha/src/mainpage.pl line 25.
> BEGIN failed--compilation aborted at /home/koha/src/mainpage.pl line 25.
>
> http://catalogue.test1.biblibre.com/
> Internal Server Error
> The server encountered an internal error or misconfiguration and was unable
> to complete your request.
>

Yes, there is a new dependency, if you check your dependencies (which
is a good thing to do after upgrading your test site)

./koha_perl_deps.pl -m

It will show you the missing modules.

(libcrypt-eksblowfish-perl in debian)
This is for the very useful and timely upgrading of our password
storage to a much more secure format (BCrypt).

Chris

From mathieu.saby at univ-rennes2.fr  Sun Oct  6 22:12:09 2013
From: mathieu.saby at univ-rennes2.fr (Mathieu Saby)
Date: Sun, 06 Oct 2013 22:12:09 +0200
Subject: [Koha-devel] software error after last Koha update
In-Reply-To: <CA+95qVSD7ZGxAp5zx6fbc1dV=qCSgn+MBoC7M9LF+S8KLovHaw@mail.gmail.com>
References: <5251A784.6050909@univ-rennes2.fr>
	<CA+95qVSD7ZGxAp5zx6fbc1dV=qCSgn+MBoC7M9LF+S8KLovHaw@mail.gmail.com>
Message-ID: <5251C419.5020602@univ-rennes2.fr>

Thank you Chris, I did not have the habit of testing dependencies after 
update...

Mathieu

Le 06/10/2013 20:18, Chris Cormack a ?crit :
> On 7 October 2013 07:10, Mathieu Saby <mathieu.saby at univ-rennes2.fr> wrote:
>> Hello
>>
>> 2 says ago, I updated my Koha instance and got a nasty error.
>> I thought it was my fault, but today I tried to test BZ 10309 (the new opac
>> theme ) on sandbox1, and I experienced the same error :
>>
>> http://pro.test1.biblibre.com/
>> Software error:
>> Can't locate Crypt/Eksblowfish/Bcrypt.pm in @INC (@INC contains:
>> /home/koha/src /etc/perl /usr/local/lib/perl/5.10.1
>> /usr/local/share/perl/5.10.1 /usr/lib/perl5 /usr/share/perl5
>> /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl .) at
>> /home/koha/src/C4/Auth.pm line 26.
>> BEGIN failed--compilation aborted at /home/koha/src/C4/Auth.pm line 26.
>> Compilation failed in require at /home/koha/src/mainpage.pl line 25.
>> BEGIN failed--compilation aborted at /home/koha/src/mainpage.pl line 25.
>>
>> http://catalogue.test1.biblibre.com/
>> Internal Server Error
>> The server encountered an internal error or misconfiguration and was unable
>> to complete your request.
>>
> Yes, there is a new dependency, if you check your dependencies (which
> is a good thing to do after upgrading your test site)
>
> ./koha_perl_deps.pl -m
>
> It will show you the missing modules.
>
> (libcrypt-eksblowfish-perl in debian)
> This is for the very useful and timely upgrading of our password
> storage to a much more secure format (BCrypt).
>
> Chris


-- 
Mathieu Saby
Service d'Informatique Documentaire
Service Commun de Documentation
Universit? Rennes 2
T?l?phone : 02 99 14 12 65
Courriel : mathieu.saby at univ-rennes2.fr


From jonathan.druart at biblibre.com  Mon Oct  7 09:01:17 2013
From: jonathan.druart at biblibre.com (Jonathan Druart)
Date: Mon, 7 Oct 2013 09:01:17 +0200
Subject: [Koha-devel] software error after last Koha update
In-Reply-To: <5251A784.6050909@univ-rennes2.fr>
References: <5251A784.6050909@univ-rennes2.fr>
Message-ID: <CAJzKNY4zA8RW59t6ZN7adsXmYSkF4+gV8ZBeSRJHChvknf=x7A@mail.gmail.com>

Hello,

I installed the new dependency on sandboxes.

Regard,
Jonathan

From 5p4m at gmx.de  Mon Oct  7 12:48:14 2013
From: 5p4m at gmx.de (Mirko)
Date: Mon, 07 Oct 2013 12:48:14 +0200
Subject: [Koha-devel] =?iso-8859-15?q?Kohacon_2014_in_C=F3rdoba=2C_Argenti?=
	=?iso-8859-15?q?na?=
Message-ID: <5252916E.3000205@gmx.de>

Hi everybody,

Kohacon 2014 will take place in C?rdoba, Argentina! Congratulations!

We have a clear vote of roughly 3:1. There are some duplicate votes
on both sides which I will consider software or server errors :P and
I will have a look at the unfinished votes later. I had one person
saying they could not finish the vote, later telling me that it
worked eventually. I cannot present final numbers at this point but
the result is clear.

I'd like to thank both C?rdoba and Ibadan very much for offering to
be hosts for our conference!

-- Mirko

From tomascohen at gmail.com  Mon Oct  7 14:38:17 2013
From: tomascohen at gmail.com (Tomas Cohen Arazi)
Date: Mon, 7 Oct 2013 09:38:17 -0300
Subject: [Koha-devel]
	=?utf-8?q?Kohacon_2014_in_C=C3=B3rdoba=2C_Argentina?=
In-Reply-To: <5252916E.3000205@gmx.de>
References: <5252916E.3000205@gmx.de>
Message-ID: <CABZfb=UNnBbaPGC2TNek-Zqc_USSAEmC+qpOpbQR2WcoKZN2mg@mail.gmail.com>

On Mon, Oct 7, 2013 at 7:48 AM, Mirko <5p4m at gmx.de> wrote:

> Hi everybody,
>
> Kohacon 2014 will take place in C?rdoba, Argentina! Congratulations!
>

Yay!

Thanks fellows for trusting us for such an important event. We will put all
our efforts to make KohaCon14 unforgetable :-D

To+

-- 
Tom?s Cohen Arazi
Prosecretar?a de Inform?tica
Universidad Nacional de C?rdoba
? +54 351 4333190 ext 13168
GPG: B76C 6E7C 2D80 551A C765  E225 0A27 2EA1 B2F3 C15F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131007/cc3af3dc/attachment.html>

From pablo.bianchi at gmail.com  Mon Oct  7 17:16:44 2013
From: pablo.bianchi at gmail.com (Pablo Bianchi)
Date: Mon, 7 Oct 2013 12:16:44 -0300
Subject: [Koha-devel]
	=?utf-8?q?Kohacon_2014_in_C=C3=B3rdoba=2C_Argentina?=
In-Reply-To: <CABZfb=UNnBbaPGC2TNek-Zqc_USSAEmC+qpOpbQR2WcoKZN2mg@mail.gmail.com>
References: <5252916E.3000205@gmx.de>
	<CABZfb=UNnBbaPGC2TNek-Zqc_USSAEmC+qpOpbQR2WcoKZN2mg@mail.gmail.com>
Message-ID: <CAH2zftEEWMY7sRAR0B3NiBKM33Fw9V=gWu49ut4c2LTJh2Xdtw@mail.gmail.com>

2013/10/7 Tomas Cohen Arazi <tomascohen at gmail.com>

> On Mon, Oct 7, 2013 at 7:48 AM, Mirko <5p4m at gmx.de> wrote:
>
>> Hi everybody,
>>
>> Kohacon 2014 will take place in C?rdoba, Argentina! Congratulations!
>>
>
> Yay!
>
> Thanks fellows for trusting us for such an important event. We will put
> all our efforts to make KohaCon14 unforgetable :-D
>

Congratulations! I'll be very proud and happy to have you all in my
country! *:)*

Pablo Bianchi
Buenos Aires, Argentina
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131007/a7754bc6/attachment.html>

From robin at catalyst.net.nz  Tue Oct  8 05:52:20 2013
From: robin at catalyst.net.nz (Robin Sheat)
Date: Tue, 08 Oct 2013 16:52:20 +1300
Subject: [Koha-devel] Copyright headers in new Koha files
Message-ID: <1381204340.20604.11.camel@zarathud>

Hi, just a bit of a poke as I've noticed this in a number of places when
I go looking to copy-paste an example from somewhere else: a lot of
newly created files don't have a copyright header.

As well as just being a good thing to do, it's necessary should Koha go
into something like Debian.

And while you're thinking about copyright headers, think about code
documentation. Some of it has none at all. I'll let someone else figure
out how to identify that though :)

This is just looking in the Koha:: namespace, as that's mostly new
stuff. If these files were created/edited by you, you should go paste a
header in.

$ for f in `ack -L 'Copyright'` ; 
	do echo "$f:" ; 
	git blame --porcelain $f 
		| grep -E '^author ' 
		| sort | uniq | sed -e 's/^author /    /' ; 
done

SearchEngine.pm:
    Jonathan Druart
QueryParser/Driver/PQF/query_plan/node/atom.pm:
    Jared Camins-Esakov
QueryParser/Driver/PQF/query_plan/facet.pm:
    Jared Camins-Esakov
QueryParser/Driver/PQF/query_plan/node.pm:
    Jared Camins-Esakov
QueryParser/Driver/PQF/query_plan/modifier.pm:
    Jared Camins-Esakov
QueryParser/Driver/PQF/query_plan/filter.pm:
    Jared Camins-Esakov
QueryParser/Driver/PQF/query_plan.pm:
    Jared Camins-Esakov
QueryParser/Driver/PQF/Util.pm:
    Jared Camins-Esakov
QueryParser/Driver/PQF.pm:
    Jared Camins-Esakov
SearchEngine/ConfigRole.pm:
    Jonathan Druart
SearchEngine/Index.pm:
    Jonathan Druart
SearchEngine/Search.pm:
    Jonathan Druart
SearchEngine/Zebra.pm:
    Jonathan Druart
SearchEngine/QueryBuilder.pm:
    Jonathan Druart
SearchEngine/Solr.pm:
    Jonathan Druart
SearchEngine/SearchRole.pm:
    Jonathan Druart
SearchEngine/IndexRole.pm:
    Jonathan Druart
SearchEngine/FacetsBuilderRole.pm:
    Jonathan Druart
SearchEngine/QueryBuilderRole.pm:
    Jonathan Druart
SearchEngine/FacetsBuilder.pm:
    Jonathan Druart
SearchEngine/Solr/Index.pm:
    Colin Campbell
    Jared Camins-Esakov
    Jonathan Druart
SearchEngine/Solr/Search.pm:
    Jonathan Druart
    Mason James
SearchEngine/Solr/QueryBuilder.pm:
    Jonathan Druart
SearchEngine/Solr/FacetsBuilder.pm:
    Jonathan Druart
SearchEngine/Solr/Config.pm:
    Jonathan Druart
SearchEngine/Config.pm:
    Jonathan Druart
SearchEngine/Zebra/Search.pm:
    Jonathan Druart
SearchEngine/Zebra/QueryBuilder.pm:
    Jonathan Druart


-- 
Robin Sheat
Catalyst IT Ltd.
? +64 4 803 2204
GPG: 5FA7 4B49 1E4D CAA4 4C38  8505 77F5 B724 F871 3BDF
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131008/74009008/attachment.pgp>

From jonathan.druart at biblibre.com  Tue Oct  8 09:17:02 2013
From: jonathan.druart at biblibre.com (Jonathan Druart)
Date: Tue, 8 Oct 2013 09:17:02 +0200
Subject: [Koha-devel] Copyright headers in new Koha files
In-Reply-To: <1381204340.20604.11.camel@zarathud>
References: <1381204340.20604.11.camel@zarathud>
Message-ID: <CAJzKNY7k7VEd2yMhLp_25aZmfPhzkCHF8U3UC7=FdQb7uph=hQ@mail.gmail.com>

Hi,

I created a new report (bug 11015). I will provide a patch.

Jonathan

From mjr at phonecoop.coop  Tue Oct  8 13:25:59 2013
From: mjr at phonecoop.coop (MJ Ray)
Date: Tue, 08 Oct 2013 12:25:59 +0100
Subject: [Koha-devel] Zebra : left truncation and left+right truncation
 with ICU
In-Reply-To: <524DE2DF.7060207@univ-rennes2.fr>
References: <524DE2DF.7060207@univ-rennes2.fr>
Message-ID: <5253EBC7.20801@phonecoop.coop>

On 10/03/13 22:34, Mathieu Saby wrote:
> When Koha is installed, I don't know if a specific version of Zebra is
> installed with it, or if it is the last available version of Zebra.
> Could you tell me how it works?

It will be the last available version, unless it's a package-based
installation and there is a restriction on the koha-common package
metadata.  At the moment, there is no such restriction.

Hope that explains,
-- 
MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op
http://koha-community.org supporter, web and library systems developer.
In My Opinion Only: see http://mjr.towers.org.uk/email.html
Available for hire (including development) at http://www.software.coop/

From robin at catalyst.net.nz  Tue Oct  8 13:28:58 2013
From: robin at catalyst.net.nz (Robin Sheat)
Date: Wed, 09 Oct 2013 00:28:58 +1300
Subject: [Koha-devel] Copyright headers in new Koha files
In-Reply-To: <CAJzKNY7k7VEd2yMhLp_25aZmfPhzkCHF8U3UC7=FdQb7uph=hQ@mail.gmail.com>
References: <1381204340.20604.11.camel@zarathud>
	<CAJzKNY7k7VEd2yMhLp_25aZmfPhzkCHF8U3UC7=FdQb7uph=hQ@mail.gmail.com>
Message-ID: <5253EC7A.8080300@catalyst.net.nz>

op 08-10-13 20:17, Jonathan Druart schreef:
> Hi,
> 
> I created a new report (bug 11015). I will provide a patch.

Thanks, I'll check it out and sign it off tomorrow.

Robin.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131009/6ad00ba2/attachment.pgp>

From oleonard at myacpl.org  Wed Oct  9 02:25:42 2013
From: oleonard at myacpl.org (Owen Leonard)
Date: Tue, 8 Oct 2013 20:25:42 -0400
Subject: [Koha-devel] Koha General IRC Meeting 9 October 2013 at 10:00 UTC
Message-ID: <CAO4qe2NLqrJgjjhgieB4kJ=axdxEyPDSGT1=-gQk+E+S0fpDLg@mail.gmail.com>

The next Koha General IRC Meeting is taking place 9 October 2013 at 10:00 UTC

http://www.timeanddate.com/worldclock/fixedtime.html?msg=Koha+IRC+General+Meeting&iso=20131009T10

The agenda is here:

http://wiki.koha-community.org/wiki/General_IRC_meeting,_9_October_2013

I hope to see you there,

Owen

--
Web Developer
Athens County Public Libraries
http://www.myacpl.org

From gmc at esilibrary.com  Wed Oct  9 06:41:00 2013
From: gmc at esilibrary.com (Galen Charlton)
Date: Tue, 8 Oct 2013 21:41:00 -0700
Subject: [Koha-devel] Koha General IRC Meeting 9 October 2013 at 10:00
	UTC
In-Reply-To: <CAO4qe2NLqrJgjjhgieB4kJ=axdxEyPDSGT1=-gQk+E+S0fpDLg@mail.gmail.com>
References: <CAO4qe2NLqrJgjjhgieB4kJ=axdxEyPDSGT1=-gQk+E+S0fpDLg@mail.gmail.com>
Message-ID: <CAPLnt6594NYYPivEY5m6_UnqFaCRPga4Gqdd2ejs_96seqYQvw@mail.gmail.com>

Hi,

On Tue, Oct 8, 2013 at 5:25 PM, Owen Leonard <oleonard at myacpl.org> wrote:

> http://wiki.koha-community.org/wiki/General_IRC_meeting,_9_October_2013
>

As I hope to still be asleep at 3 a.m. my time, I have updated the wiki
with a brief update on the march to 3.14.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  gmc at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131008/9ff301d9/attachment.html>

From paul.poulain at biblibre.com  Wed Oct  9 22:28:49 2013
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Wed, 09 Oct 2013 22:28:49 +0200
Subject: [Koha-devel]
 =?iso-8859-15?q?=5BKoha=5D_Kohacon_2014_in_C=F3rdoba?=
 =?iso-8859-15?q?=2C_Argentina?=
In-Reply-To: <5252916E.3000205@gmx.de>
References: <5252916E.3000205@gmx.de>
Message-ID: <5255BC81.20502@biblibre.com>

Le 07/10/2013 12:48, Mirko a ?crit :
> Hi everybody,
Hi,

> I'd like to thank both C?rdoba and Ibadan very much for offering to
> be hosts for our conference!
I'd like to encourage strongly Idaban to apply again next year: Africa
is the only continent that did not host a KohaCon:
* Europe  = Paris 2006 and Edinburgh 2012
* Asia    = Mumbai 2011
* Oceania = New Zealand 2010
* North-america = Plano,TX 2009 and Reno,NV 2013
* South-Africa  = Cordoba, 2014
So, let's come to Africa in 2015

(I don't think there will ever be a KohaCon in antartica ;-) )

-- 
Paul POULAIN - BibLibre
http://www.biblibre.com
Free & Open Source Softwares for libraries
Koha, Drupal, Piwik, Jasper


From chris at bigballofwax.co.nz  Wed Oct  9 22:34:31 2013
From: chris at bigballofwax.co.nz (Chris Cormack)
Date: Thu, 10 Oct 2013 09:34:31 +1300
Subject: [Koha-devel]
	=?utf-8?q?=5BKoha=5D_Kohacon_2014_in_C=C3=B3rdoba=2C?=
	=?utf-8?q?_Argentina?=
In-Reply-To: <5255BC81.20502@biblibre.com>
References: <5252916E.3000205@gmx.de> <5255BC81.20502@biblibre.com>
Message-ID: <CA+95qVTrP7QeO3CjKS6r1DE7wWKhM7iNTb2m5FDAxnCc2Y9CbQ@mail.gmail.com>

On 10 October 2013 09:28, Paul Poulain <paul.poulain at biblibre.com> wrote:
> Le 07/10/2013 12:48, Mirko a ?crit :
>> Hi everybody,
> Hi,
>
>> I'd like to thank both C?rdoba and Ibadan very much for offering to
>> be hosts for our conference!
> I'd like to encourage strongly Idaban to apply again next year: Africa
> is the only continent that did not host a KohaCon:
> * Europe  = Paris 2006 and Edinburgh 2012
> * Asia    = Mumbai 2011
> * Oceania = New Zealand 2010
> * North-america = Plano,TX 2009 and Reno,NV 2013
> * South-Africa  = Cordoba, 2014

South America :)

> So, let's come to Africa in 2015

And yes +1 from me!!

Chris

>
> (I don't think there will ever be a KohaCon in antartica ;-) )
>
> --
> Paul POULAIN - BibLibre
> http://www.biblibre.com
> Free & Open Source Softwares for libraries
> Koha, Drupal, Piwik, Jasper
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/

From paul.poulain at biblibre.com  Wed Oct  9 22:51:23 2013
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Wed, 09 Oct 2013 22:51:23 +0200
Subject: [Koha-devel]
	=?utf-8?q?=5BKoha=5D_Kohacon_2014_in_C=C3=B3rdoba=2C?=
	=?utf-8?q?_Argentina?=
In-Reply-To: <CAK95CouBJoMZDE=9FETq9f=6KhRxFEy+kHMAkB6SOvru7B1KRQ@mail.gmail.com>
References: <5252916E.3000205@gmx.de>	<5255BC81.20502@biblibre.com>
	<CAK95CouBJoMZDE=9FETq9f=6KhRxFEy+kHMAkB6SOvru7B1KRQ@mail.gmail.com>
Message-ID: <5255C1CB.3030608@biblibre.com>

Le 09/10/2013 22:35, Luis Maguina a ?crit :
> Cordoba is in South - America ... Argentina :)
In french, we say "lapsus r?v?lateur". Google translate this to
"revealing slip" ;-)

-- 
Paul POULAIN - Associ?-g?rant
Tel : (33) 4 91 81 35 08
http://www.biblibre.com
Logiciels Libres pour les biblioth?ques et les centres de documentation

From vanoudt at gmail.com  Thu Oct 10 11:21:43 2013
From: vanoudt at gmail.com (Nicholas van Rheede van Oudtshoorn)
Date: Thu, 10 Oct 2013 17:21:43 +0800
Subject: [Koha-devel] OAuth2 Authentication of users
Message-ID: <CAJ1eDORcrh=X9nScoc=D0N7pHmsvGa1rObP2XZ=TsUiydkErrQ@mail.gmail.com>

Hello list!

Wondering if there is anyone interested in giving me some feedback on the
OAuth2 login system that I've written for Google OAuth. The login system is
live and fully operational here at Perth Bible College (
library.pbc.wa.edu.au) -  not that any of you will be able to test that,
since your emails aren't registered to our system! :-)

I would love someone with a bit more Perl-fu than me to let me know if
there's anything glaringly stupid that I shouldn't have done / could do
better. This is all the result of about 2 1/2 days of my fiddling!

All the patches etc. are in bug 10988 (
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10988 )

God bless,
Nicholas van Oudtshoorn
Perth Bible College
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131010/1ad64bf0/attachment.html>

From M.de.Rooy at rijksmuseum.nl  Thu Oct 10 12:17:11 2013
From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy)
Date: Thu, 10 Oct 2013 10:17:11 +0000
Subject: [Koha-devel] Crashes on new Opac Recent Searches cookie in older
	Koha versions
Message-ID: <809BE39CD64BFD4EB9036172EBCCFA311647A3CA@S-MAIL-1B.rijksmuseum.intra>

Hi,

Recently two commits were added that move the search history cookie to a new format.

commit 961617765ef25bde32cb050ad016f3b063661ef8  (no bug number, from Galen)
commit 488a3d6fed57b4e0d773157ee4a6ab7e4775e7a4 (no bug number, from Galen)

I have been looking for these patches on Bugzilla, but I cannot find them. Perhaps they are there, but I may have used the wrong search terms.

These patches have a nasty side-effect. If you use an older Koha version and also current master on the same system for testing, the old Koha version will stumble over this (shared) cookie:

            Storable binary image v45.123 more recent than I am (v2.8) at /usr/lib64/perl5/Storable.pm line 416, at /usr/share/koha/maintclone/C4/Auth.pm line 293.

So to overcome this problem,  you must delete the KohaOpacRecentSearches cookie AND set preference EnableOpacSearchHistory to off in the old system.
Deleting the search cookie every time, as updated by the master clone, is not really an option :)

Since I cannot find the bug where this development was documented, I do not know if this side-effect was discussed, tested etc.
But for changes like this, a question like: Can this change affect older Koha versions somehow? would be fine to address at the least..

Thanks,

Marcel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131010/ef120c69/attachment.html>

From M.de.Rooy at rijksmuseum.nl  Thu Oct 10 12:27:15 2013
From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy)
Date: Thu, 10 Oct 2013 10:27:15 +0000
Subject: [Koha-devel] Crashes on new Opac Recent Searches cookie in
 older	Koha versions
In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA311647A3CA@S-MAIL-1B.rijksmuseum.intra>
References: <809BE39CD64BFD4EB9036172EBCCFA311647A3CA@S-MAIL-1B.rijksmuseum.intra>
Message-ID: <809BE39CD64BFD4EB9036172EBCCFA311647A42A@S-MAIL-1B.rijksmuseum.intra>

The commits below date back from end of July.  Is there any additional relation to the Bcrypt patches pushed more recently?


Van: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] Namens Marcel de Rooy
Verzonden: donderdag 10 oktober 2013 12:17
Aan: koha-devel at lists.koha-community.org
Onderwerp: [Koha-devel] Crashes on new Opac Recent Searches cookie in older Koha versions

Hi,

Recently two commits were added that move the search history cookie to a new format.

commit 961617765ef25bde32cb050ad016f3b063661ef8  (no bug number, from Galen)
commit 488a3d6fed57b4e0d773157ee4a6ab7e4775e7a4 (no bug number, from Galen)

I have been looking for these patches on Bugzilla, but I cannot find them. Perhaps they are there, but I may have used the wrong search terms.

These patches have a nasty side-effect. If you use an older Koha version and also current master on the same system for testing, the old Koha version will stumble over this (shared) cookie:

            Storable binary image v45.123 more recent than I am (v2.8) at /usr/lib64/perl5/Storable.pm line 416, at /usr/share/koha/maintclone/C4/Auth.pm line 293.

So to overcome this problem,  you must delete the KohaOpacRecentSearches cookie AND set preference EnableOpacSearchHistory to off in the old system.
Deleting the search cookie every time, as updated by the master clone, is not really an option :)

Since I cannot find the bug where this development was documented, I do not know if this side-effect was discussed, tested etc.
But for changes like this, a question like: Can this change affect older Koha versions somehow? would be fine to address at the least..

Thanks,

Marcel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131010/d3b6903f/attachment.html>

From robin at catalyst.net.nz  Thu Oct 10 12:30:08 2013
From: robin at catalyst.net.nz (Robin Sheat)
Date: Thu, 10 Oct 2013 23:30:08 +1300
Subject: [Koha-devel] Crashes on new Opac Recent Searches cookie in
 older Koha versions
In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA311647A3CA@S-MAIL-1B.rijksmuseum.intra>
References: <809BE39CD64BFD4EB9036172EBCCFA311647A3CA@S-MAIL-1B.rijksmuseum.intra>
Message-ID: <525681B0.8020807@catalyst.net.nz>

op 10-10-13 23:17, Marcel de Rooy schreef:
> Recently two commits were added that move the search history cookie to a
> new format.
> 
> commit 961617765ef25bde32cb050ad016f3b063661ef8  (no bug number, from Galen)
> commit 488a3d6fed57b4e0d773157ee4a6ab7e4775e7a4 (no bug number, from Galen)

If memory serves, these were a security patch, but I can't find an
associated bug number (as you found too.)

This might be a hint though.

Robin.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131010/f1ab6450/attachment.pgp>

From Katrin.Fischer at bsz-bw.de  Thu Oct 10 13:01:19 2013
From: Katrin.Fischer at bsz-bw.de (Fischer, Katrin)
Date: Thu, 10 Oct 2013 13:01:19 +0200
Subject: [Koha-devel] Crashes on new Opac Recent Searches cookie in
	older Koha versions
In-Reply-To: <525681B0.8020807@catalyst.net.nz>
References: <809BE39CD64BFD4EB9036172EBCCFA311647A3CA@S-MAIL-1B.rijksmuseum.intra>
	<525681B0.8020807@catalyst.net.nz>
Message-ID: <028B1A54D03E7B4482CDCA4EC8F06BFD0310E5DD@Bodensee.bsz-bw.de>

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10657

I think it's unrelated to the bcrypt patches, as they should only affect how we store passwords.

Katrin

> -----Original Message-----
> From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-
> bounces at lists.koha-community.org] On Behalf Of Robin Sheat
> Sent: Thursday, October 10, 2013 12:30 PM
> To: koha-devel at lists.koha-community.org
> Subject: Re: [Koha-devel] Crashes on new Opac Recent Searches cookie in
> older Koha versions
> 
> op 10-10-13 23:17, Marcel de Rooy schreef:
> > Recently two commits were added that move the search history cookie to
> > a new format.
> >
> > commit 961617765ef25bde32cb050ad016f3b063661ef8  (no bug number, from
> > Galen) commit 488a3d6fed57b4e0d773157ee4a6ab7e4775e7a4 (no bug number,
> > from Galen)
> 
> If memory serves, these were a security patch, but I can't find an
> associated bug number (as you found too.)
> 
> This might be a hint though.
> 
> Robin.


From chris at bigballofwax.co.nz  Thu Oct 10 21:04:17 2013
From: chris at bigballofwax.co.nz (Chris Cormack)
Date: Fri, 11 Oct 2013 08:04:17 +1300
Subject: [Koha-devel] OAuth2 Authentication of users
In-Reply-To: <CAJ1eDORcrh=X9nScoc=D0N7pHmsvGa1rObP2XZ=TsUiydkErrQ@mail.gmail.com>
References: <CAJ1eDORcrh=X9nScoc=D0N7pHmsvGa1rObP2XZ=TsUiydkErrQ@mail.gmail.com>
Message-ID: <CA+95qVQfBDquAtpKF81450rLKZ9cD8VKNo8rm8W5HK1kmkhQQg@mail.gmail.com>

On 10 October 2013 22:21, Nicholas van Rheede van Oudtshoorn
<vanoudt at gmail.com> wrote:
> Hello list!
>
> Wondering if there is anyone interested in giving me some feedback on the
> OAuth2 login system that I've written for Google OAuth. The login system is
> live and fully operational here at Perth Bible College
> (library.pbc.wa.edu.au) -  not that any of you will be able to test that,
> since your emails aren't registered to our system! :-)
>
> I would love someone with a bit more Perl-fu than me to let me know if
> there's anything glaringly stupid that I shouldn't have done / could do
> better. This is all the result of about 2 1/2 days of my fiddling!
>
> All the patches etc. are in bug 10988 (
> http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10988 )
>
Ive put it on my To Do list for the Kohacon13 hackfest

Chris

From vanoudt at gmail.com  Fri Oct 11 05:30:53 2013
From: vanoudt at gmail.com (Nicholas van Rheede van Oudtshoorn)
Date: Fri, 11 Oct 2013 11:30:53 +0800
Subject: [Koha-devel] OAuth2 Authentication of users
In-Reply-To: <CA+95qVQfBDquAtpKF81450rLKZ9cD8VKNo8rm8W5HK1kmkhQQg@mail.gmail.com>
References: <CAJ1eDORcrh=X9nScoc=D0N7pHmsvGa1rObP2XZ=TsUiydkErrQ@mail.gmail.com>
	<CA+95qVQfBDquAtpKF81450rLKZ9cD8VKNo8rm8W5HK1kmkhQQg@mail.gmail.com>
Message-ID: <CAJ1eDOSbu27uL9s5JCKp=73QZwqY114DDNGqN9sEfyrFLaCh4Q@mail.gmail.com>

Thanks Chris!


On Fri, Oct 11, 2013 at 3:04 AM, Chris Cormack <chris at bigballofwax.co.nz>wrote:

> On 10 October 2013 22:21, Nicholas van Rheede van Oudtshoorn
> <vanoudt at gmail.com> wrote:
> > Hello list!
> >
> > Wondering if there is anyone interested in giving me some feedback on the
> > OAuth2 login system that I've written for Google OAuth. The login system
> is
> > live and fully operational here at Perth Bible College
> > (library.pbc.wa.edu.au) -  not that any of you will be able to test
> that,
> > since your emails aren't registered to our system! :-)
> >
> > I would love someone with a bit more Perl-fu than me to let me know if
> > there's anything glaringly stupid that I shouldn't have done / could do
> > better. This is all the result of about 2 1/2 days of my fiddling!
> >
> > All the patches etc. are in bug 10988 (
> > http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10988 )
> >
> Ive put it on my To Do list for the Kohacon13 hackfest
>
> Chris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131011/65ba48d2/attachment.html>

From gmc at esilibrary.com  Fri Oct 11 21:26:02 2013
From: gmc at esilibrary.com (Galen Charlton)
Date: Fri, 11 Oct 2013 12:26:02 -0700
Subject: [Koha-devel] Crashes on new Opac Recent Searches cookie in
 older Koha versions
In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA311647A3CA@S-MAIL-1B.rijksmuseum.intra>
References: <809BE39CD64BFD4EB9036172EBCCFA311647A3CA@S-MAIL-1B.rijksmuseum.intra>
Message-ID: <CAPLnt65ke+DvjOjhowdq26EBvhRxBJy1ORRiYfATAhiCdFXRTA@mail.gmail.com>

Hi,

On Thu, Oct 10, 2013 at 3:17 AM, Marcel de Rooy <M.de.Rooy at rijksmuseum.nl>wrote:

>  Recently two commits were added that move the search history cookie to a
> new format.
>
> **
>
> ** **
>
> commit 961617765ef25bde32cb050ad016f3b063661ef8  (no bug number, from
> Galen)****
>
> commit 488a3d6fed57b4e0d773157ee4a6ab7e4775e7a4 (no bug number, from Galen)
> ****
>
> ** **
>
> I have been looking for these patches on Bugzilla, but I cannot find them.
> Perhaps they are there, but I may have used the wrong search terms.
>

As Katrin pointed out, these were part of bug 10657 for the July security
release.  The patches lack a bug number because of a chicken-and-egg
problem, as the bug couldn't be posted before the patches and the release
announcement were.


> These patches have a nasty side-effect. If you use an older Koha version
> and also current master on the same system for testing, the old Koha
> version will stumble over this (shared) cookie:****
>
> ** **
>
>             Storable binary image v45.123 more recent than I am (v2.8) at
> /usr/lib64/perl5/Storable.pm line 416, at
> /usr/share/koha/maintclone/C4/Auth.pm line 293.****
>
> ** **
>
> So to overcome this problem,  you must delete the KohaOpacRecentSearches
> cookie AND set preference EnableOpacSearchHistory to off in the old system.
> ****
>
> Deleting the search cookie every time, as updated by the master clone, is
> not really an option :)
>

An alternative configuration which may better suit your needs is to use
name-based virtual hosts rather than port-based ones, which will perforce
ensure that the two versions don't share cookies.


> Since I cannot find the bug where this development was documented, I do
> not know if this side-effect was discussed, tested etc. ****
>
> But for changes like this, a question like: Can this change affect older
> Koha versions somehow? would be fine to address at the least..
>

Considering that the security release was made at the end of July, was
targeted at supported *and* unsupported versions, and was heavily
publicized, there is already a fair amount of negative data (in the form of
no new bug reports that include the keyword "storable") that would indicate
that the configuration you use for testing is rarely used by production
sites.  However, the existence of this thread will hopefully provide hints
if anybody else does do use this configuration.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  gmc at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131011/6b070359/attachment.html>

From paul.a at aandc.org  Sat Oct 12 00:16:47 2013
From: paul.a at aandc.org (Paul)
Date: Fri, 11 Oct 2013 18:16:47 -0400
Subject: [Koha-devel] Crashes on new Opac Recent Searches cookie in
 older Koha versions
In-Reply-To: <CAPLnt65ke+DvjOjhowdq26EBvhRxBJy1ORRiYfATAhiCdFXRTA@mail.g
	mail.com>
References: <809BE39CD64BFD4EB9036172EBCCFA311647A3CA@S-MAIL-1B.rijksmuseum.intra>
	<809BE39CD64BFD4EB9036172EBCCFA311647A3CA@S-MAIL-1B.rijksmuseum.intra>
Message-ID: <5.2.1.1.2.20131011180252.0849bcd8@localhost>

At 12:26 PM 10/11/2013 -0700, Galen Charlton wrote:
>On Thu, Oct 10, 2013 at 3:17 AM, Marcel de Rooy 
><<mailto:M.de.Rooy at rijksmuseum.nl>M.de.Rooy at rijksmuseum.nl> wrote:
>I have been looking for these patches on Bugzilla, but I cannot find them.
[snip]
>The patches lack a bug number because of a chicken-and-egg problem, as the 
>bug couldn't be posted before the patches and the release announcement were.
>These patches have a nasty side-effect. If you use an older Koha version 
>and also current master on the same system for testing, the old Koha 
>version will stumble over this (shared) cookie:
[snip]
>An alternative configuration which may better suit your needs is to use 
>name-based virtual hosts rather than port-based ones, which will perforce 
>ensure that the two versions don't share cookies.
[snip]
>Considering that the security release was made at the end of July, was 
>targeted at supported *and* unsupported versions, and was heavily 
>publicized, there is already a fair amount of negative data

"Name based" v. "port based", "Nasty side effects" and "negative data" 
raise flags with me. I've just looked up bug 10657 which either blind-sides 
me with science or baffles me with bull.  "Storable" and references to 
"checked for JSON-correctness and is ignored" are meaningless without context.

If there really is a security aspect would someone please explain it?

OFF-LIST if need be.

Many thanks - Paul 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131011/42a875c3/attachment.html>

From chris at bigballofwax.co.nz  Sat Oct 12 01:54:37 2013
From: chris at bigballofwax.co.nz (Chris Cormack)
Date: Sat, 12 Oct 2013 12:54:37 +1300
Subject: [Koha-devel] Crashes on new Opac Recent Searches cookie in
 older Koha versions
In-Reply-To: <5.2.1.1.2.20131011180252.0849bcd8@localhost>
References: <809BE39CD64BFD4EB9036172EBCCFA311647A3CA@S-MAIL-1B.rijksmuseum.intra>
	<5.2.1.1.2.20131011180252.0849bcd8@localhost>
Message-ID: <CA+95qVQqZcEV3DBi6w9LRA=_86qFC12K6=LRWTMvXMC9YnPAhw@mail.gmail.com>

On 12 October 2013 11:16, Paul <paul.a at aandc.org> wrote:
> At 12:26 PM 10/11/2013 -0700, Galen Charlton wrote:
>

> "Name based" v. "port based", "Nasty side effects" and "negative data" raise
> flags with me. I've just looked up bug 10657 which either blind-sides me
> with science or baffles me with bull.  "Storable" and references to "

I totally would not have gone there with the inference that Galen was
talking bull, but hey if that's how you want to go, each to their own.
>
> checked for JSON-correctness and is ignored" are
> meaningless without context.
>
> If there really is a security aspect would someone please explain it?
>
Or the implication that he was lying.

Of course there was a security aspect, and that's why we did security
releases for 3.12.x, 3.10.x and 3.8.x.
If you read the release notes
 http://koha-community.org/security-release-july-2013/

And you snipped some lines out of context, and complain for them being
out of context.

Here is the whole thing, for context.

"When EnableOpacSearchHistory system preference is enabled, Koha
stores recent search history for anonymous OPAC sessions in a cookie
called KohaOpacRecentSearches.  In particular, it used to use the
Storable Perl module to serialize the array of hashrefs representing
the recent searches.

However, the documentation for Storable strongly recommends [1] that
data to be deserialized *not* come from untrusted sources -- and
cookies cannot be considered trustworthy, as most web browsers (to say
nothing of curl) allow the user to modify them.  There is a
theoretical possibility that a modification to the
KohaOpacRecentSearches cookie could result in the execution of
unauthorized code with the privileges of the Apache backend process.

The 29 July 2013 security update resolves the security issuing by
replacing use of the Storable module with the JSON, which doesn't by
default serialize blessed references and does not attempt to
deserialize and execute coderefs.  The payload of the cookie is
checked for JSON-correctness and is ignored if it doesn't contain a
valid (double-URI-encoded) JSON object.  In particularly, any old
Storable-based cookies are silently ignored.

[1] http://perldoc.perl.org/Storable.html#SECURITY-WARNING "

If you read the link that is provided there it says

"Do not accept Storable documents from untrusted sources!
Some features of Storable can lead to security vulnerabilities if you
accept Storable documents from untrusted sources. Most obviously, the
optional (off by default) CODE reference serialization feature allows
transfer of code to the deserializing process. Furthermore, any
serialized object will cause Storable to helpfully load the module
corresponding to the class of the object in the deserializing module.
For manipulated module names, this can load almost arbitrary code.
Finally, the deserialized object's destructors will be invoked when
the objects get destroyed in the deserializing process. Maliciously
crafted Storable documents may put such objects in the value of a hash
key that is overridden by another key/value pair in the same hash,
thus causing immediate destructor execution.
In a future version of Storable, we intend to provide options to
disable loading modules for classes and to disable deserializing
objects altogether. Nonetheless, Storable deserializing documents from
untrusted sources is expected to have other, yet undiscovered,
security concerns such as allowing an attacker to cause the
deserializer to crash hard.
Therefore, let me repeat: Do not accept Storable documents from
untrusted sources!
If your application requires accepting data from untrusted sources,
you are best off with a less powerful and more-likely safe
serialization format and implementation. If your data is sufficently
simple, JSON is a good choice and offers maximum interoperability."

So we were accepting Storable documents from untrusted sources (the
entire internet) and this bug stops that happening.

I respectfully request you think about the way you phrase your
questions in the future, so they sound like questions not insults.

Chris

From paul.a at aandc.org  Sat Oct 12 16:25:20 2013
From: paul.a at aandc.org (Paul)
Date: Sat, 12 Oct 2013 10:25:20 -0400
Subject: [Koha-devel] Crashes on new Opac Recent Searches cookie in
 older Koha versions
In-Reply-To: <CA+95qVQqZcEV3DBi6w9LRA=_86qFC12K6=LRWTMvXMC9YnPAhw@mail.g
	mail.com>
References: <5.2.1.1.2.20131011180252.0849bcd8@localhost>
	<809BE39CD64BFD4EB9036172EBCCFA311647A3CA@S-MAIL-1B.rijksmuseum.intra>
	<5.2.1.1.2.20131011180252.0849bcd8@localhost>
Message-ID: <5.2.1.1.2.20131012092940.036a6d28@localhost>

At 12:54 PM 10/12/2013 +1300, Chris Cormack wrote:
>On 12 October 2013 11:16, Paul <paul.a at aandc.org> wrote:
> > At 12:26 PM 10/11/2013 -0700, Galen Charlton wrote:
> >
> > "Name based" v. "port based", "Nasty side effects" and "negative data" 
> raise
> > flags with me. I've just looked up bug 10657 which either blind-sides me
> > with science or baffles me with bull.  "Storable" and references to "
>
>I totally would not have gone there with the inference that Galen was
>talking bull, but hey if that's how you want to go, each to their own.

Please... I was only saying that *I* was confused (blind-sided or baffled) 
by the Subject: of the email "Crashes..." in the context of Bug 10657. The 
Perl references to "crashing" were (I believed, perhaps incorrectly) taken 
care of when I disabled EnableOpacSearchHistory.

The phrases that I quoted (maybe out of context?) did not reassure me.

I still haven't had time to fully sandbox test the changes 
<http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=eeedee8c98776eb52c039649f94331de0596db3c;hp=aefc58585340508d110094890410edc45edd91ec> 
to C4/Auth.pm, opac/opac-search-history.pl and opac/opac-search.pl for use 
within our stable production 3.8.5 -- nor to consider a full system upgrade 
from 3.8.5.

As you well know, I'm a believer in system stability over a two year 
period, ? la LTS, with only security upgrades. In 2014, we'll look into 
whatever the latest Koha release might be. In the meanwhile, I believed 
(again perhaps incorrectly) that by disabling some functionality (OPAC 
search history) we had the well-publicized security concern under control. 
Until I saw "crashing" in the context of Bug 10657 and the mention by 
Marcel de Rooy of two commits not referencing bug numbers ....

I was asking for clarification -- and certainly had no intention whatsoever 
of questioning Galen's integrity. If Galen read it that way, I apologize 
unreservedly to him. Without wanting to excuse myself, please remember that 
I am generally much more comfortable writing in French rather than in English.

Regards - Paul

> >
> > checked for JSON-correctness and is ignored" are
> > meaningless without context.
> >
> > If there really is a security aspect would someone please explain it?
> >
>Or the implication that he was lying.
>
>Of course there was a security aspect, and that's why we did security
>releases for 3.12.x, 3.10.x and 3.8.x.
>If you read the release notes
>  http://koha-community.org/security-release-july-2013/
>
>And you snipped some lines out of context, and complain for them being
>out of context.
>
>Here is the whole thing, for context.
>
>"When EnableOpacSearchHistory system preference is enabled, Koha
>stores recent search history for anonymous OPAC sessions in a cookie
>called KohaOpacRecentSearches.  In particular, it used to use the
>Storable Perl module to serialize the array of hashrefs representing
>the recent searches.
>
>However, the documentation for Storable strongly recommends [1] that
>data to be deserialized *not* come from untrusted sources -- and
>cookies cannot be considered trustworthy, as most web browsers (to say
>nothing of curl) allow the user to modify them.  There is a
>theoretical possibility that a modification to the
>KohaOpacRecentSearches cookie could result in the execution of
>unauthorized code with the privileges of the Apache backend process.
>
>The 29 July 2013 security update resolves the security issuing by
>replacing use of the Storable module with the JSON, which doesn't by
>default serialize blessed references and does not attempt to
>deserialize and execute coderefs.  The payload of the cookie is
>checked for JSON-correctness and is ignored if it doesn't contain a
>valid (double-URI-encoded) JSON object.  In particularly, any old
>Storable-based cookies are silently ignored.
>
>[1] http://perldoc.perl.org/Storable.html#SECURITY-WARNING "
>
>If you read the link that is provided there it says
>
>"Do not accept Storable documents from untrusted sources!
>Some features of Storable can lead to security vulnerabilities if you
>accept Storable documents from untrusted sources. Most obviously, the
>optional (off by default) CODE reference serialization feature allows
>transfer of code to the deserializing process. Furthermore, any
>serialized object will cause Storable to helpfully load the module
>corresponding to the class of the object in the deserializing module.
>For manipulated module names, this can load almost arbitrary code.
>Finally, the deserialized object's destructors will be invoked when
>the objects get destroyed in the deserializing process. Maliciously
>crafted Storable documents may put such objects in the value of a hash
>key that is overridden by another key/value pair in the same hash,
>thus causing immediate destructor execution.
>In a future version of Storable, we intend to provide options to
>disable loading modules for classes and to disable deserializing
>objects altogether. Nonetheless, Storable deserializing documents from
>untrusted sources is expected to have other, yet undiscovered,
>security concerns such as allowing an attacker to cause the
>deserializer to crash hard.
>Therefore, let me repeat: Do not accept Storable documents from
>untrusted sources!
>If your application requires accepting data from untrusted sources,
>you are best off with a less powerful and more-likely safe
>serialization format and implementation. If your data is sufficently
>simple, JSON is a good choice and offers maximum interoperability."
>
>So we were accepting Storable documents from untrusted sources (the
>entire internet) and this bug stops that happening.
>
>I respectfully request you think about the way you phrase your
>questions in the future, so they sound like questions not insults.
>
>Chris

---
Maritime heritage and history, preservation and conservation,
research and education through the written word and the arts.
<http://NavalMarineArchive.com> and <http://UltraMarine.ca>


From mathieu.saby at univ-rennes2.fr  Sun Oct 13 10:45:24 2013
From: mathieu.saby at univ-rennes2.fr (Mathieu Saby)
Date: Sun, 13 Oct 2013 10:45:24 +0200
Subject: [Koha-devel] find old bugs to sign off
Message-ID: <525A5DA4.20805@univ-rennes2.fr>

Hi
The bot on bugzilla is really a great great idea :-)
But now, we can't find really old bugs to sign off, because if the bot 
can sign off, the date of "last change" of the bug is updated.
So for ex, this patch that I submitted in april 2013 is marked "modified 
2013-09-24" http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10138
and the "10 oldest bugs to sign off" on Koha dashboard are not the 
oldest at all. http://dashboard.koha-community.org/

Do you think it would be possible to keep the advantage of having bot 
running on BZ and to restore the ability to see the oldest bugs waiting 
for sign off (maybe there is a way to find the date when the "Need sign 
off" status was given to a bug?) ?

By the way, is someone in community, or within some vendor staff, 
dedicated to the signing off of oldest bugs?

M. Saby

-- 
Mathieu Saby
Service d'Informatique Documentaire
Service Commun de Documentation
Universit? Rennes 2
T?l?phone : 02 99 14 12 65
Courriel : mathieu.saby at univ-rennes2.fr


From samuel.desseaux at ecp.fr  Mon Oct 14 09:44:31 2013
From: samuel.desseaux at ecp.fr (Samuel Desseaux)
Date: Mon, 14 Oct 2013 09:44:31 +0200
Subject: [Koha-devel] vm for koha
Message-ID: <525BA0DF.3080905@ecp.fr>

Hi,

I'm preparing vm for koha, as i've said a few weeks ago.

I've 2 vm

*one, in french, for unimarc users

*the other, in english, for marc21 users

the size is nearly 1 Go. Is it ok for upload it to one of the koha servers ?

Best regards

Samuel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: samuel_desseaux.vcf
Type: text/x-vcard
Size: 317 bytes
Desc: not available
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131014/a59b08bb/attachment.vcf>

From gmc at esilibrary.com  Mon Oct 14 16:21:09 2013
From: gmc at esilibrary.com (Galen Charlton)
Date: Mon, 14 Oct 2013 07:21:09 -0700
Subject: [Koha-devel] vm for koha
In-Reply-To: <525BA0DF.3080905@ecp.fr>
References: <525BA0DF.3080905@ecp.fr>
Message-ID: <CAPLnt67kyXbGof85Vp=6COzmX-rcaW8uG6iC7TJPg3CLZU=FvQ@mail.gmail.com>

Hi,

On Mon, Oct 14, 2013 at 12:44 AM, Samuel Desseaux <samuel.desseaux at ecp.fr>wrote:

> I've 2 vm
>
> *one, in french, for unimarc users
>
> *the other, in english, for marc21 users
>
> the size is nearly 1 Go. Is it ok for upload it to one of the koha servers
> ?
>

There is space available on the Koha download server.  Please send me an
SSH public key and I will set you up with an account.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  gmc at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131014/4193778a/attachment.html>

From danielg.koha at gmail.com  Tue Oct 15 00:26:25 2013
From: danielg.koha at gmail.com (Daniel Grobani)
Date: Mon, 14 Oct 2013 15:26:25 -0700
Subject: [Koha-devel] Call for news for the October newsletter (especially
	re KohaCon13!)
Message-ID: <CAOeKewhfwj7XoTbXBR_eRNamxyepQX+NCtf=LXVTgtq1YJK9+g@mail.gmail.com>

Dear Koha kommunitarians,

I'm harvesting news for this month's newsletter. Please send me by the
27th anything you think your fellow community members might like to
know about.

And all you lucky #kohacon13 attendees, here's your chance to share
your experience with the community in more than 140-character chunks!

"News" can be as short as a sentence or as long as a paper. I
especially encourage you to send me a line or two for the
gossip/society column about what you're currently working on.

And if you know of a go-live not announced on the list, please be sure
to let me know about it.

Thanks,
Daniel Grobani

From gmc at esilibrary.com  Tue Oct 15 02:01:52 2013
From: gmc at esilibrary.com (Galen Charlton)
Date: Mon, 14 Oct 2013 17:01:52 -0700
Subject: [Koha-devel] First alpha of Koha 3.14 released
Message-ID: <CAPLnt67wMjrO0d195WnYEUCM2mwuYSKJdq1Q9Q9p5SoJ5X8Wcw@mail.gmail.com>

Hi,

I have tagged and cut the first alpha of Koha 3.14.  The tarball can be
retrieved from:

http://download.koha-community.org/koha-3.14.00-alpha1.tar.gz

The following files can be used to check the integrity of the tarball:

http://download.koha-community.org/koha-3.14.00-alpha1.tar.gz.sig
http://download.koha-community.org/koha-3.14.00-alpha1.tar.gz.MD5
http://download.koha-community.org/koha-3.14.00-alpha1.tar.gz.MD5.asc


The script-generated release notes can be read at:

http://git.koha-community.org/gitweb/?p=koha.git;a=blob_plain;f=misc/release_notes/release_notes_3_14_0.txt;hb=5e8abb1191f3076ed006dc4f10472ddf5a760291

This first alpha should be considered a preliminary smoke testing version,
as I have some more large merges to get through this week.  I expect to cut
a second alpha during KohaCon's hackfest, with a beta to follow shortly
thereafter as the condition of master warrants.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  gmc at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131014/f0d29caf/attachment.html>

From carlos.cordovas at gmail.com  Tue Oct 15 02:25:25 2013
From: carlos.cordovas at gmail.com (Carlos Rodrigo Cordova Sandoval)
Date: Mon, 14 Oct 2013 21:25:25 -0300
Subject: [Koha-devel] Error circulation
Message-ID: <CA+Vrneup9iS9uN_-1nEtP-TD9nduqaSqYpkZVeQ1wf30LJoFGA@mail.gmail.com>

Hello,

I am using koha 3.8.10.2 and I have problems when I return a book gives the
following message:

screenshot:

http://snag.gy/Rio25.jpg


and the apache log is:

[Mon Oct 14 21:17:27 2013] [error] [client 186.105.227.88] [Mon Oct 14
21:17:27 2013] returns.pl: Invalid local time for date in time zone:
America/Santiago, referer:
http://catalogo.ipciisa.cl:8080/cgi-bin/koha/mainpage.pl



thank you very much.

-Carlos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131014/fafd66de/attachment.html>

From carlos.cordovas at gmail.com  Tue Oct 15 02:26:08 2013
From: carlos.cordovas at gmail.com (Carlos Rodrigo Cordova Sandoval)
Date: Mon, 14 Oct 2013 21:26:08 -0300
Subject: [Koha-devel] error circulation
Message-ID: <CA+VrnetCfB6oZk3vh5Y8pEVEVDUnRzit+VVQ52MwurMY6kZzrg@mail.gmail.com>

Hello,

I am using koha 3.8.10.2 and I have problems when I return a book gives the
following message:

screenshot:

http://snag.gy/Rio25.jpg


and the apache log is:

[Mon Oct 14 21:17:27 2013] [error] [client 186.105.227.88] [Mon Oct 14
21:17:27 2013] returns.pl: Invalid local time for date in time zone:
America/Santiago, referer:
http://catalogo.ipciisa.cl:8080/cgi-bin/koha/mainpage.pl



thank you very much.

-Carlos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131014/99432ed2/attachment.html>

From robin at catalyst.net.nz  Tue Oct 15 07:25:51 2013
From: robin at catalyst.net.nz (Robin Sheat)
Date: Tue, 15 Oct 2013 18:25:51 +1300
Subject: [Koha-devel] Optimisation and DBI::ping
Message-ID: <1381814751.8373.45.camel@zarathud>

I've been doing a bit of profiling, focussing on opac-search, as it's
terribly slow at times. See:
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11051
for what I've looked at so far.

There's one thing I'd like some comments on. 

http://debian.koha-community.org/~robin/opac-search-cached/nytprof/usr-share-koha-lib-C4-Context-pm-7-line.html#856

All the pings take 1.36 seconds, which is a huge amount. It's not helped
that Context::dbh is called 1423 times, I'm working on that too (many
things that are called inside a tight loop, rather than grabbing all the
data you might need in one go and putting it into a hash or something.)

Is there a situation where the ping is likely to be required? It'd be
easy to strip it out, but are there likely to be bad effects that can't
be worked around?

For context, I'm profiling this on a system with a remote database so
that latency shows up a bit more than it would in a typical dev
environment. As that's what many production systems are using, this is
not atypical.

The DBI docs:
http://search.cpan.org/~timb/DBI-1.623/DBI.pm#ping
say "Few applications would have direct use for this method. See the
specialized Apache::DBI module for one example usage" so it might be
reasonable to just pull it out.

Any thoughts?

Also have a look at the two other patches: one illustrating that caching
actually slows things down some times, and the other just changing a
query repeated once per branch, to just run once.

-- 
Robin Sheat
Catalyst IT Ltd.
? +64 4 803 2204
GPG: 5FA7 4B49 1E4D CAA4 4C38  8505 77F5 B724 F871 3BDF
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131015/0d5e5837/attachment.pgp>

From jonathan.druart at biblibre.com  Tue Oct 15 09:11:55 2013
From: jonathan.druart at biblibre.com (Jonathan Druart)
Date: Tue, 15 Oct 2013 09:11:55 +0200
Subject: [Koha-devel] Optimisation and DBI::ping
In-Reply-To: <1381814751.8373.45.camel@zarathud>
References: <1381814751.8373.45.camel@zarathud>
Message-ID: <CAJzKNY4OLgkc3F3mGGVz6_gdkd7=agNreUnKjFc13rRe-ZVAgQ@mail.gmail.com>

Hi Robin,

We (at BibLibre) encounter the same problem with remote DB.
I submitted a patch (bug 10611) in order to enable the
mysql_autoreconnect flag and remove the ping calls. It is certainly
not the best way given that it is specific for MySQL.
It is not in production yet, so I cannot assure it is useful.
Maybe it could be useful in your case.

Regards,
Jonathan

2013/10/15 Robin Sheat <robin at catalyst.net.nz>:
> I've been doing a bit of profiling, focussing on opac-search, as it's
> terribly slow at times. See:
> http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11051
> for what I've looked at so far.
>
> There's one thing I'd like some comments on.
>
> http://debian.koha-community.org/~robin/opac-search-cached/nytprof/usr-share-koha-lib-C4-Context-pm-7-line.html#856
>
> All the pings take 1.36 seconds, which is a huge amount. It's not helped
> that Context::dbh is called 1423 times, I'm working on that too (many
> things that are called inside a tight loop, rather than grabbing all the
> data you might need in one go and putting it into a hash or something.)
>
> Is there a situation where the ping is likely to be required? It'd be
> easy to strip it out, but are there likely to be bad effects that can't
> be worked around?
>
> For context, I'm profiling this on a system with a remote database so
> that latency shows up a bit more than it would in a typical dev
> environment. As that's what many production systems are using, this is
> not atypical.
>
> The DBI docs:
> http://search.cpan.org/~timb/DBI-1.623/DBI.pm#ping
> say "Few applications would have direct use for this method. See the
> specialized Apache::DBI module for one example usage" so it might be
> reasonable to just pull it out.
>
> Any thoughts?
>
> Also have a look at the two other patches: one illustrating that caching
> actually slows things down some times, and the other just changing a
> query repeated once per branch, to just run once.
>
> --
> Robin Sheat
> Catalyst IT Ltd.
> ? +64 4 803 2204
> GPG: 5FA7 4B49 1E4D CAA4 4C38  8505 77F5 B724 F871 3BDF
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/

From robin at catalyst.net.nz  Wed Oct 16 03:50:05 2013
From: robin at catalyst.net.nz (Robin Sheat)
Date: Wed, 16 Oct 2013 14:50:05 +1300
Subject: [Koha-devel] Optimisation and DBI::ping
In-Reply-To: <CAJzKNY4OLgkc3F3mGGVz6_gdkd7=agNreUnKjFc13rRe-ZVAgQ@mail.gmail.com>
References: <1381814751.8373.45.camel@zarathud>
	<CAJzKNY4OLgkc3F3mGGVz6_gdkd7=agNreUnKjFc13rRe-ZVAgQ@mail.gmail.com>
Message-ID: <1381888205.8373.67.camel@zarathud>

Jonathan Druart schreef op di 15-10-2013 om 09:11 [+0200]:
> We (at BibLibre) encounter the same problem with remote DB.
> I submitted a patch (bug 10611) in order to enable the
> mysql_autoreconnect flag and remove the ping calls. It is certainly
> not the best way given that it is specific for MySQL.
> It is not in production yet, so I cannot assure it is useful.
> Maybe it could be useful in your case.

Thanks, I've added that as a dependency to the bug I've created.
Hopefully we can get a good few seconds shaved off the search time,
which seems to have been increasing quite badly lately (or I've just
noticed it more recently...)

-- 
Robin Sheat
Catalyst IT Ltd.
? +64 4 803 2204
GPG: 5FA7 4B49 1E4D CAA4 4C38  8505 77F5 B724 F871 3BDF
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131016/a8733c63/attachment.pgp>

From mjr at phonecoop.coop  Wed Oct 16 12:11:49 2013
From: mjr at phonecoop.coop (MJ Ray)
Date: Wed, 16 Oct 2013 11:11:49 +0100
Subject: [Koha-devel] Error circulation
In-Reply-To: <CA+Vrneup9iS9uN_-1nEtP-TD9nduqaSqYpkZVeQ1wf30LJoFGA@mail.gmail.com>
References: <CA+Vrneup9iS9uN_-1nEtP-TD9nduqaSqYpkZVeQ1wf30LJoFGA@mail.gmail.com>
Message-ID: <525E6665.1090507@phonecoop.coop>

On 10/15/13 01:25, Carlos Rodrigo Cordova Sandoval wrote:
> [Mon Oct 14 21:17:27 2013] [error] [client 186.105.227.88] [Mon Oct 14
> 21:17:27 2013] returns.pl: Invalid local time for date in time zone:
> America/Santiago, referer:
> http://catalogo.ipciisa.cl:8080/cgi-bin/koha/mainpage.pl

That suggests it's somehow hitting a time that doesn't exist for some
reason (mostly I've seen this with Daylight Savings changes).  Please
enable backtraces (add SetEnv KOHA_BACKTRACES 1 to the apache config)
and try again?

Hope that helps,
-- 
MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op
http://koha-community.org supporter, web and library systems developer.
In My Opinion Only: see http://mjr.towers.org.uk/email.html
Available for hire (including development) at http://www.software.coop/

From fridolyn.somers at biblibre.com  Thu Oct 17 17:53:57 2013
From: fridolyn.somers at biblibre.com (Fridolyn SOMERS)
Date: Thu, 17 Oct 2013 17:53:57 +0200
Subject: [Koha-devel] Linking bibs to authorities
In-Reply-To: <51FBD0FD.4020304@ptfs-europe.com>
References: <51FBD0FD.4020304@ptfs-europe.com>
Message-ID: <52600815.80400@biblibre.com>

Hie,

It is because in Zebra, exact search does not work.
It can find a phrase (all words in same order) but not say if this 
phrase fits the entire (sub)field. This is the purpose of PQF attribut 
6, but is does not work.
So when linking bibs to authorities, linker will match more authorities 
than needed. For example, in biblio record "History" will match 
authorities with headings "History", "History of art", "History of 
science", ...

That is wy I created Bug 9072 : 
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9072

Le 02/08/2013 17:32, Ian Bays a ?crit :
> Hi.
> I mentioned we also have a problem with linking bibs to authorities.
>
> We use authorities and want to link them to bibs.  Over previous
> versions of Koha this has sometimes worked quite well.  However on a few
> systems we have at version 3.12 it seems that the Zebra search into the
> authorities (used by link_bib_to_authorities) is returning all terms
> that contain any of the words in the bib field.
>
> So if the linkage is set to "default" then most authority searches will
> return multiple answers which means they do not link.
> If the linkage syspref is set to first or last then most of the bibs
> will link to the wrong authority as it is pot luck which will be first
> (or last) of the many authorities found by searching all the words ORed
> together.
> The only terms that will link are single-word authorities that are not
> used in any other authorities.
>
> If anyone has any pointers or knows how to get round or over this
> problem I would love to hear from you.  More details on request...
>
> We are using Zebra dom indexing and icu chains and are using Koha 3.12
> on Debian.  We are not yet using QueryParser.  Sysprefs and Help > About
> are here:
>
> Sysprefs are:
>
> +--------------------------+-------+
> | variable                 | value |
> +--------------------------+-------+
> | IncludeSeeFromInSearches | 0     |
> | QueryAutoTruncate        | 0     |
> | QueryFuzzy               | 0     |
> | QueryStemming            | 0     |
> | QueryWeightFields        | 1     |
> | TraceCompleteSubfields   | 0     |
> | TraceSubjectSubdivisions | 0     |
> | UseICU                   | 1     |
> | UseQueryParser           | 0     |
> +--------------------------+-------+
>
>
> Koha> About:
>
> Koha version:     3.12.01.000
> OS version ('uname -a'):     Linux dclg.koha.ptfsadmin.uk0.bigv.io
> 3.2.0-4-amd64 #1 SMP Debian 3.2.46-1 x86_64 GNU/Linux
> Perl interpreter:     /usr/bin/perl
> Perl version:     5.014002
> Perl @INC:     /home/koha/kohaclone
> /etc/perl
> /usr/local/lib/perl/5.14.2
> /usr/local/share/perl/5.14.2
> /usr/lib/perl5
> /usr/share/perl5
> /usr/lib/perl/5.14
> /usr/share/perl/5.14
> /usr/local/lib/site_perl
> .
> MySQL version:     mysql Ver 14.14 Distrib 5.5.31, for debian-linux-gnu
> (x86_64) using readline 6.2
> Apache version:     Server version: Apache/2.2.22 (Debian)
> Zebra version:     Zebra 2.0.55 (C) 1994-2013, Index Data ApS Zebra is
> free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain
> conditions. SHA1 ID: bd2bc9360225e695bbaba2c2d1cd6925c4eb23a5 Using ICU
>
> Many thanks folks.
> Ian
>
>

-- 
Fridolyn SOMERS
Biblibre - P?le support
fridolyn.somers at biblibre.com

From colin.campbell at ptfs-europe.com  Thu Oct 17 18:35:02 2013
From: colin.campbell at ptfs-europe.com (Colin Campbell)
Date: Thu, 17 Oct 2013 17:35:02 +0100
Subject: [Koha-devel] Linking bibs to authorities
In-Reply-To: <52600815.80400@biblibre.com>
References: <51FBD0FD.4020304@ptfs-europe.com>
 <52600815.80400@biblibre.com>
Message-ID: <20131017163502.GA12310@zazou.cscnet.co.uk>

On Thu, Oct 17, 2013 at 05:53:57PM +0200, Fridolyn SOMERS wrote:
> Hie,
> 
> It is because in Zebra, exact search does not work.
> It can find a phrase (all words in same order) but not say if this
> phrase fits the entire (sub)field.

Just an vague idea but I wonder if using zebra (or similar search
utilities) for authorities is really a good idea. They are great for
general bib search where you want to find more, even unexpected results.
But with authorities your concern is to find a specific record as such
the search facilities in a standard db are probably more useful. Just
because a tool works well in one context it does not mean its the best
in another (pick your favourite hammers & scredrivers analogy)
Cheers
Colin

-- 
Colin Campbell
Chief Software Engineer,
PTFS Europe Limited
Content Management and Library Solutions
+44 (0) 800 756 6803 (phone)
+44 (0) 7759 633626  (mobile)
colin.campbell at ptfs-europe.com
skype: colin_campbell2

http://www.ptfs-europe.com

From ian.bays at ptfs-europe.com  Thu Oct 17 19:06:50 2013
From: ian.bays at ptfs-europe.com (Ian Bays)
Date: Thu, 17 Oct 2013 18:06:50 +0100
Subject: [Koha-devel] Linking bibs to authorities
In-Reply-To: <52600815.80400@biblibre.com>
References: <51FBD0FD.4020304@ptfs-europe.com> <52600815.80400@biblibre.com>
Message-ID: <5260192A.9030800@ptfs-europe.com>

Hi Fridolyn,
Thank you for this.  I was beginning to wonder if nobody was interested 
in the question.

The bug you mention is a useful addition, but we achieved considerable 
success by correcting the contents of the default.idx 
(~/koha-dev/etc/zebradb/etc/default.idx) to use phrases-icu.xml for 
index p, and to ensure phrases-icu.xml and words-icu.xml have the 
correct stanzas for searching accent-blind.

With these both in place I believe we have a very good hit rate for 
linking bib to authorities as long as the authority terms have been 
de-duplicated.

I think Colin has submitted patches so that these are in place for all 
moving forwards, but it is good to know that others are using these 
features.

What we were seeing before was if the term in the bib was (say) "History 
of Art" it would only match on the first word so would match an 
authority of (say) "History Books".

All the best.

Ian
On 17/10/2013 16:53, Fridolyn SOMERS wrote:
> Hie,
>
> It is because in Zebra, exact search does not work.
> It can find a phrase (all words in same order) but not say if this 
> phrase fits the entire (sub)field. This is the purpose of PQF attribut 
> 6, but is does not work.
> So when linking bibs to authorities, linker will match more 
> authorities than needed. For example, in biblio record "History" will 
> match authorities with headings "History", "History of art", "History 
> of science", ...
>
> That is wy I created Bug 9072 : 
> http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9072
>
> Le 02/08/2013 17:32, Ian Bays a ?crit :
>> Hi.
>> I mentioned we also have a problem with linking bibs to authorities.
>>
>> We use authorities and want to link them to bibs.  Over previous
>> versions of Koha this has sometimes worked quite well.  However on a few
>> systems we have at version 3.12 it seems that the Zebra search into the
>> authorities (used by link_bib_to_authorities) is returning all terms
>> that contain any of the words in the bib field.
>>
>> So if the linkage is set to "default" then most authority searches will
>> return multiple answers which means they do not link.
>> If the linkage syspref is set to first or last then most of the bibs
>> will link to the wrong authority as it is pot luck which will be first
>> (or last) of the many authorities found by searching all the words ORed
>> together.
>> The only terms that will link are single-word authorities that are not
>> used in any other authorities.
>>
>> If anyone has any pointers or knows how to get round or over this
>> problem I would love to hear from you.  More details on request...
>>
>> We are using Zebra dom indexing and icu chains and are using Koha 3.12
>> on Debian.  We are not yet using QueryParser.  Sysprefs and Help > About
>> are here:
>>
>> Sysprefs are:
>>
>> +--------------------------+-------+
>> | variable                 | value |
>> +--------------------------+-------+
>> | IncludeSeeFromInSearches | 0     |
>> | QueryAutoTruncate        | 0     |
>> | QueryFuzzy               | 0     |
>> | QueryStemming            | 0     |
>> | QueryWeightFields        | 1     |
>> | TraceCompleteSubfields   | 0     |
>> | TraceSubjectSubdivisions | 0     |
>> | UseICU                   | 1     |
>> | UseQueryParser           | 0     |
>> +--------------------------+-------+
>>
>>
>> Koha> About:
>>
>> Koha version:     3.12.01.000
>> OS version ('uname -a'):     Linux dclg.koha.ptfsadmin.uk0.bigv.io
>> 3.2.0-4-amd64 #1 SMP Debian 3.2.46-1 x86_64 GNU/Linux
>> Perl interpreter:     /usr/bin/perl
>> Perl version:     5.014002
>> Perl @INC:     /home/koha/kohaclone
>> /etc/perl
>> /usr/local/lib/perl/5.14.2
>> /usr/local/share/perl/5.14.2
>> /usr/lib/perl5
>> /usr/share/perl5
>> /usr/lib/perl/5.14
>> /usr/share/perl/5.14
>> /usr/local/lib/site_perl
>> .
>> MySQL version:     mysql Ver 14.14 Distrib 5.5.31, for debian-linux-gnu
>> (x86_64) using readline 6.2
>> Apache version:     Server version: Apache/2.2.22 (Debian)
>> Zebra version:     Zebra 2.0.55 (C) 1994-2013, Index Data ApS Zebra is
>> free software, covered by the GNU General Public License, and you are
>> welcome to change it and/or distribute copies of it under certain
>> conditions. SHA1 ID: bd2bc9360225e695bbaba2c2d1cd6925c4eb23a5 Using ICU
>>
>> Many thanks folks.
>> Ian
>>
>>
>


-- 
Ian Bays
Director of Projects, PTFS Europe Limited
Content Management and Library Solutions
+44 (0) 800 756 6803 (phone)
+44 (0) 7774 995297 (mobile)
+44 (0) 800 756 6384 (fax)
skype: ian.bays
email: ian.bays at ptfs-europe.com


From gmc at esilibrary.com  Thu Oct 17 19:17:46 2013
From: gmc at esilibrary.com (Galen Charlton)
Date: Thu, 17 Oct 2013 10:17:46 -0700
Subject: [Koha-devel] Linking bibs to authorities
In-Reply-To: <20131017163502.GA12310@zazou.cscnet.co.uk>
References: <51FBD0FD.4020304@ptfs-europe.com> <52600815.80400@biblibre.com>
	<20131017163502.GA12310@zazou.cscnet.co.uk>
Message-ID: <CAPLnt64HKvDQG3usPRttfrF_sLq+0mv49pY=XuobP=m4aKR5rQ@mail.gmail.com>

Hi,

On Thu, Oct 17, 2013 at 9:35 AM, Colin Campbell <
colin.campbell at ptfs-europe.com> wrote:

> Just an vague idea but I wonder if using zebra (or similar search
> utilities) for authorities is really a good idea. They are great for
> general bib search where you want to find more, even unexpected results.
> But with authorities your concern is to find a specific record as such
> the search facilities in a standard db are probably more useful. Just
> because a tool works well in one context it does not mean its the best
> in another (pick your favourite hammers & scredrivers analogy)
>

Well, the original motivation for implementing the Zebra DOM filter for
MARC21 authority records was to enable the construction of normalized index
strings for authority headings that included details such as the thesaurus
for subject headings, thereby allowing precise matching that went beyond
just the equivalent of keyword searches.

Of course, the equivalent could be done in a database, but I think it would
be fruitful to first properly investigate the bug.

To that end, I request that a bug report actually be filed -- I see nothing
apropos on Bugzilla -- preferably with sample records.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  gmc at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131017/b556a81e/attachment.html>

From martin.renvoize at ptfs-europe.com  Thu Oct 17 20:06:39 2013
From: martin.renvoize at ptfs-europe.com (Martin Renvoize)
Date: Thu, 17 Oct 2013 19:06:39 +0100
Subject: [Koha-devel] Linking bibs to authorities
In-Reply-To: <CAPLnt64HKvDQG3usPRttfrF_sLq+0mv49pY=XuobP=m4aKR5rQ@mail.gmail.com>
References: <51FBD0FD.4020304@ptfs-europe.com> <52600815.80400@biblibre.com>
	<20131017163502.GA12310@zazou.cscnet.co.uk>
	<CAPLnt64HKvDQG3usPRttfrF_sLq+0mv49pY=XuobP=m4aKR5rQ@mail.gmail.com>
Message-ID: <CAB7SL8DYFAt5yKObGpuWFHatN8QLLo5BRLwLjQVAGcU2K3OAAA@mail.gmail.com>

Hi Galen,

The patch in question that Ian mentions regarding adding phrases config to
zebra for dom with icu.. which also heavily affects the authority linking
results that he is talking about is under bug: 10729.

I'm just about to update the bug with a description so it can be seen the
two things relate.. The patch affects more than just the authorities
linking script, but I believe using the linking script is possibly the
easiest way to show that the patch is actually doing somthing.

Just chipping in,

Martin
On 17 Oct 2013 10:17, "Galen Charlton" <gmc at esilibrary.com> wrote:

> Hi,
>
> On Thu, Oct 17, 2013 at 9:35 AM, Colin Campbell <
> colin.campbell at ptfs-europe.com> wrote:
>
>> Just an vague idea but I wonder if using zebra (or similar search
>>  utilities) for authorities is really a good idea. They are great for
>> general bib search where you want to find more, even unexpected results.
>> But with authorities your concern is to find a specific record as such
>> the search facilities in a standard db are probably more useful. Just
>> because a tool works well in one context it does not mean its the best
>> in another (pick your favourite hammers & scredrivers analogy)
>>
>
> Well, the original motivation for implementing the Zebra DOM filter for
> MARC21 authority records was to enable the construction of normalized index
> strings for authority headings that included details such as the thesaurus
> for subject headings, thereby allowing precise matching that went beyond
> just the equivalent of keyword searches.
>
> Of course, the equivalent could be done in a database, but I think it
> would be fruitful to first properly investigate the bug.
>
> To that end, I request that a bug report actually be filed -- I see
> nothing apropos on Bugzilla -- preferably with sample records.
>
> Regards,
>
> Galen
> --
> Galen Charlton
> Manager of Implementation
> Equinox Software, Inc. / The Open Source Experts
> email:  gmc at 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
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131017/1068e6dd/attachment-0001.html>

From mathieu.saby at univ-rennes2.fr  Thu Oct 17 22:10:23 2013
From: mathieu.saby at univ-rennes2.fr (Mathieu Saby)
Date: Thu, 17 Oct 2013 22:10:23 +0200
Subject: [Koha-devel] Linking bibs to authorities
In-Reply-To: <CAB7SL8DYFAt5yKObGpuWFHatN8QLLo5BRLwLjQVAGcU2K3OAAA@mail.gmail.com>
References: <51FBD0FD.4020304@ptfs-europe.com>
	<52600815.80400@biblibre.com>	<20131017163502.GA12310@zazou.cscnet.co.uk>	<CAPLnt64HKvDQG3usPRttfrF_sLq+0mv49pY=XuobP=m4aKR5rQ@mail.gmail.com>
	<CAB7SL8DYFAt5yKObGpuWFHatN8QLLo5BRLwLjQVAGcU2K3OAAA@mail.gmail.com>
Message-ID: <5260442F.3010200@univ-rennes2.fr>

Hi
Your discussion is beyond my understanding of Zebra, but if some changes 
are needed to marcflavor specific conf files, please consider not doing 
the changes only for MARC21.
Now we have a freshly working UNIMARC DOM indexing, bugs about DOM must 
also take UNIMARC into consideration if it is relevant.

Regards
Mathieu

Le 17/10/2013 20:06, Martin Renvoize a ?crit :
>
> Hi Galen,
>
> The patch in question that Ian mentions regarding adding phrases 
> config to zebra for dom with icu.. which also heavily affects the 
> authority linking results that he is talking about is under bug: 10729.
>
> I'm just about to update the bug with a description so it can be seen 
> the two things relate.. The patch affects more than just the 
> authorities linking script, but I believe using the linking script is 
> possibly the easiest way to show that the patch is actually doing 
> somthing.
>
> Just chipping in,
>
> Martin
>
> On 17 Oct 2013 10:17, "Galen Charlton" <gmc at esilibrary.com 
> <mailto:gmc at esilibrary.com>> wrote:
>
>     Hi,
>
>     On Thu, Oct 17, 2013 at 9:35 AM, Colin Campbell
>     <colin.campbell at ptfs-europe.com
>     <mailto:colin.campbell at ptfs-europe.com>> wrote:
>
>         Just an vague idea but I wonder if using zebra (or similar search
>         utilities) for authorities is really a good idea. They are
>         great for
>         general bib search where you want to find more, even
>         unexpected results.
>         But with authorities your concern is to find a specific record
>         as such
>         the search facilities in a standard db are probably more
>         useful. Just
>         because a tool works well in one context it does not mean its
>         the best
>         in another (pick your favourite hammers & scredrivers analogy)
>
>
>     Well, the original motivation for implementing the Zebra DOM
>     filter for MARC21 authority records was to enable the construction
>     of normalized index strings for authority headings that included
>     details such as the thesaurus for subject headings, thereby
>     allowing precise matching that went beyond just the equivalent of
>     keyword searches.
>
>     Of course, the equivalent could be done in a database, but I think
>     it would be fruitful to first properly investigate the bug.
>
>     To that end, I request that a bug report actually be filed -- I
>     see nothing apropos on Bugzilla -- preferably with sample records.
>
>     Regards,
>
>     Galen
>     -- 
>     Galen Charlton
>     Manager of Implementation
>     Equinox Software, Inc. / The Open Source Experts
>     email: gmc at esilibrary.com <mailto:gmc at esilibrary.com>
>     direct: +1 770-709-5581 <tel:%2B1%20770-709-5581>
>     cell: +1 404-984-4366 <tel:%2B1%20404-984-4366>
>     skype:  gmcharlt
>     web: http://www.esilibrary.com/
>     Supporting Koha and Evergreen: http://koha-community.org &
>     http://evergreen-ils.org
>
>     _______________________________________________
>     Koha-devel mailing list
>     Koha-devel at lists.koha-community.org
>     <mailto:Koha-devel at 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/
>
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/


-- 
Mathieu Saby
Service d'Informatique Documentaire
Service Commun de Documentation
Universit? Rennes 2
T?l?phone : 02 99 14 12 65
Courriel : mathieu.saby at univ-rennes2.fr

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131017/e908ac80/attachment.html>

From gmc at esilibrary.com  Thu Oct 17 22:29:46 2013
From: gmc at esilibrary.com (Galen Charlton)
Date: Thu, 17 Oct 2013 13:29:46 -0700
Subject: [Koha-devel] Linking bibs to authorities
In-Reply-To: <5260442F.3010200@univ-rennes2.fr>
References: <51FBD0FD.4020304@ptfs-europe.com> <52600815.80400@biblibre.com>
	<20131017163502.GA12310@zazou.cscnet.co.uk>
	<CAPLnt64HKvDQG3usPRttfrF_sLq+0mv49pY=XuobP=m4aKR5rQ@mail.gmail.com>
	<CAB7SL8DYFAt5yKObGpuWFHatN8QLLo5BRLwLjQVAGcU2K3OAAA@mail.gmail.com>
	<5260442F.3010200@univ-rennes2.fr>
Message-ID: <CAPLnt661KmH9o3tuuxBFoFoY7qS+pAPjFcJqOosefxvNWcZ9eA@mail.gmail.com>

Hi,

On Thu, Oct 17, 2013 at 1:10 PM, Mathieu Saby
<mathieu.saby at univ-rennes2.fr>wrote:

>  Your discussion is beyond my understanding of Zebra, but if some changes
> are needed to marcflavor specific conf files, please consider not doing the
> changes only for MARC21.
> Now we have a freshly working UNIMARC DOM indexing, bugs about DOM must
> also take UNIMARC into consideration if it is relevant.
>

Agreed, and some of the techniques used to generate heading match indexes
for MARC21 using the DOM filter can be applied to UNIMARC.

Is there some documentation online about rules for matching bib headings to
authority headings in a UNIMARC context?  I assume that there would be
points of similarity with MARC21, but I don't want to assume too much.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  gmc at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131017/e518eabc/attachment.html>

From martin.renvoize at ptfs-europe.com  Thu Oct 17 23:15:14 2013
From: martin.renvoize at ptfs-europe.com (Martin Renvoize)
Date: Thu, 17 Oct 2013 22:15:14 +0100
Subject: [Koha-devel] Linking bibs to authorities
In-Reply-To: <CAPLnt661KmH9o3tuuxBFoFoY7qS+pAPjFcJqOosefxvNWcZ9eA@mail.gmail.com>
References: <51FBD0FD.4020304@ptfs-europe.com> <52600815.80400@biblibre.com>
	<20131017163502.GA12310@zazou.cscnet.co.uk>
	<CAPLnt64HKvDQG3usPRttfrF_sLq+0mv49pY=XuobP=m4aKR5rQ@mail.gmail.com>
	<CAB7SL8DYFAt5yKObGpuWFHatN8QLLo5BRLwLjQVAGcU2K3OAAA@mail.gmail.com>
	<5260442F.3010200@univ-rennes2.fr>
	<CAPLnt661KmH9o3tuuxBFoFoY7qS+pAPjFcJqOosefxvNWcZ9eA@mail.gmail.com>
Message-ID: <CAB7SL8Dxb7=kfbXfuT5DTXSBJn6y2QJE0xoagOHL9VjsSMkW-Q@mail.gmail.com>

Taking a quick look at Colin's patch, I don't see anything MARC21 specific
in it.. It's mostly an addition to the MakeFile.pl to add the a default
phrases-icu.xml config file to the system (whether that be MARC21, UNIMARK
or even NORMARK).

It's a simple patch which doesn't touch the linking scripts.. The linking
script is just a great way to prove it's validity..
On 17 Oct 2013 13:29, "Galen Charlton" <gmc at esilibrary.com> wrote:

> Hi,
>
> On Thu, Oct 17, 2013 at 1:10 PM, Mathieu Saby <
> mathieu.saby at univ-rennes2.fr> wrote:
>
>>  Your discussion is beyond my understanding of Zebra, but if some
>> changes are needed to marcflavor specific conf files, please consider not
>> doing the changes only for MARC21.
>> Now we have a freshly working UNIMARC DOM indexing, bugs about DOM must
>> also take UNIMARC into consideration if it is relevant.
>>
>
> Agreed, and some of the techniques used to generate heading match indexes
> for MARC21 using the DOM filter can be applied to UNIMARC.
>
> Is there some documentation online about rules for matching bib headings
> to authority headings in a UNIMARC context?  I assume that there would be
> points of similarity with MARC21, but I don't want to assume too much.
>
> Regards,
>
> Galen
> --
> Galen Charlton
> Manager of Implementation
> Equinox Software, Inc. / The Open Source Experts
> email:  gmc at 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
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131017/8f4b50a1/attachment-0001.html>

From gmc at esilibrary.com  Mon Oct 21 06:10:19 2013
From: gmc at esilibrary.com (Galen Charlton)
Date: Sun, 20 Oct 2013 21:10:19 -0700
Subject: [Koha-devel] Hackfest update #1
Message-ID: <CAPLnt64s7XYoD0zx1LapLh+c5Y6kkqWifMY3ohwo8R=PygzSTA@mail.gmail.com>

Hi,

Here are some notes from the first day of hackfest:

* A total of 34 kittens were saved [1].  In other words, a number of bugs
were worked on, tested, QAed, and pushed.
* Several tutorial sessions took place, including a session on Koha bug
reporting and patch testing fundamentals led by Bob Birchall and a tutorial
on Git and navigating the Koha source tree lead by myself.
* Several folks had a lengthy discussion about various issues regarding
search and indexing.  A couple short-term projects initiated today include
dealing with a bug concerning retrieving oversize ISO 2709 records from
Zebra and a project to switch facet calculation over to using Zebra's
built-in faceting.  There was also discussion of the idea of using
Elasticsearch as a complement to Zebra and Solr.
* Chris Cormack helped a library upgrade their Koha database from (I think)
3.6 all the way to 3.12 ... in 27 minutes.

Tomorrow tutorial sessions on DBIx::Class and Class::Accessor are planned
as well as a roundtable on digging into Zebra's internals.

For folks wanting to play along at home, lists of wishlist items [2] and
notes from the conference roundtables [3] are available on the wiki.

I'm sure this summary is incomplete, and I encourage other hackfest
attendees to supplement it.

[1] http://scoreboard.koha-community.org/
[2] http://wiki.koha-community.org/wiki/KohaCon13/Hackfest/Wishlist
[3] http://wiki.koha-community.org/wiki/KohaCon13/Roundtable_Notes

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  gmc at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131020/5a3758ca/attachment.html>

From mathieu.saby at univ-rennes2.fr  Mon Oct 21 09:32:17 2013
From: mathieu.saby at univ-rennes2.fr (Mathieu Saby)
Date: Mon, 21 Oct 2013 09:32:17 +0200
Subject: [Koha-devel] Hackfest update #1
In-Reply-To: <CAPLnt64s7XYoD0zx1LapLh+c5Y6kkqWifMY3ohwo8R=PygzSTA@mail.gmail.com>
References: <CAPLnt64s7XYoD0zx1LapLh+c5Y6kkqWifMY3ohwo8R=PygzSTA@mail.gmail.com>
Message-ID: <5264D881.2050404@univ-rennes2.fr>

Galen Charlton a ?crit :
> Hi,
>
> Here are some notes from the first day of hackfest:
>

> * Several folks had a lengthy discussion about various issues 
> regarding search and indexing.  A couple short-term projects initiated 
> today include dealing with a bug concerning retrieving oversize ISO 
> 2709 records from Zebra and a project to switch facet calculation over 
> to using Zebra's built-in faceting.

Hi
I read in old messages of Zebra list (msg from Henri Damien Laurent and 
other Koha dev), whose general thrust was that Zebra built-in facets 
were not working well for strings with diacritics, or maybe with ICU.
https://www.google.fr/search?q=facets+zebra+icu+site:lists.indexdata.dk&client=firefox-a&hs=9nq&rls=org.mozilla:fr:official&channel=fflb
Is it still true?
I don't see any improvement about facets in Zebra changelog 
(http://www.indexdata.com/zebra/doc/NEWS), except "Facets can now be 
performed on sort registers (:s), not just regular indexes (:w, :p) 
etc.." (2008).
Did you consider working with Indexdata on that issue?

Mathieu




-- 
Mathieu Saby
Service d'Informatique Documentaire
Service Commun de la Documentation
Universit? Rennes 2
T?l?phone : 02 99 14 12 65
Courriel : mathieu.saby at univ-rennes2.fr


From jcamins at cpbibliography.com  Mon Oct 21 14:38:55 2013
From: jcamins at cpbibliography.com (Jared Camins-Esakov)
Date: Mon, 21 Oct 2013 08:38:55 -0400
Subject: [Koha-devel] Hackfest update #1
In-Reply-To: <5264D881.2050404@univ-rennes2.fr>
References: <CAPLnt64s7XYoD0zx1LapLh+c5Y6kkqWifMY3ohwo8R=PygzSTA@mail.gmail.com>
	<5264D881.2050404@univ-rennes2.fr>
Message-ID: <CALVDfQzFus8fyf8hcuUNN5deA9vOnmWW=0emw30+1TGaxxOxdQ@mail.gmail.com>

Mathieu,

I read in old messages of Zebra list (msg from Henri Damien Laurent and
> other Koha dev), whose general thrust was that Zebra built-in facets were
> not working well for strings with diacritics, or maybe with ICU.
> https://www.google.fr/search?**q=facets+zebra+icu+site:lists.**
> indexdata.dk&client=firefox-a&**hs=9nq&rls=org.mozilla:fr:**
> official&channel=fflb<https://www.google.fr/search?q=facets+zebra+icu+site:lists.indexdata.dk&client=firefox-a&hs=9nq&rls=org.mozilla:fr:official&channel=fflb>
> Is it still true?


No. I demonstrated that it works fine now. I used ICU and a search for
German records returned facets with properly encoded umlauts. The changes
that you note in 2.0.34 may be what makes it work, but I'm actually not
sure that we didn't just always have Zebra configured incorrectly, using
tokenized indexes rather than untokenized indexes.

Regards,
Jared

-- 
Jared Camins-Esakov
Bibliographer, C & P Bibliography Services, LLC
(phone) +1 (917) 727-3445
(e-mail) jcamins at cpbibliography.com
(web) http://www.cpbibliography.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131021/85242216/attachment.html>

From mathieu.saby at univ-rennes2.fr  Mon Oct 21 14:40:58 2013
From: mathieu.saby at univ-rennes2.fr (Mathieu Saby)
Date: Mon, 21 Oct 2013 14:40:58 +0200
Subject: [Koha-devel] Hackfest update #1
In-Reply-To: <CALVDfQzFus8fyf8hcuUNN5deA9vOnmWW=0emw30+1TGaxxOxdQ@mail.gmail.com>
References: <CAPLnt64s7XYoD0zx1LapLh+c5Y6kkqWifMY3ohwo8R=PygzSTA@mail.gmail.com>	<5264D881.2050404@univ-rennes2.fr>
	<CALVDfQzFus8fyf8hcuUNN5deA9vOnmWW=0emw30+1TGaxxOxdQ@mail.gmail.com>
Message-ID: <526520DA.7000803@univ-rennes2.fr>

Great news!


Jared Camins-Esakov a ?crit :
> Mathieu,
>
>     I read in old messages of Zebra list (msg from Henri Damien
>     Laurent and other Koha dev), whose general thrust was that Zebra
>     built-in facets were not working well for strings with diacritics,
>     or maybe with ICU.
>     https://www.google.fr/search?q=facets+zebra+icu+site:lists.indexdata.dk&client=firefox-a&hs=9nq&rls=org.mozilla:fr:official&channel=fflb
>     <https://www.google.fr/search?q=facets+zebra+icu+site:lists.indexdata.dk&client=firefox-a&hs=9nq&rls=org.mozilla:fr:official&channel=fflb>
>     Is it still true?
>
>
> No. I demonstrated that it works fine now. I used ICU and a search for 
> German records returned facets with properly encoded umlauts. The 
> changes that you note in 2.0.34 may be what makes it work, but I'm 
> actually not sure that we didn't just always have Zebra configured 
> incorrectly, using tokenized indexes rather than untokenized indexes.
>
> Regards,
> Jared
>
> -- 
> Jared Camins-Esakov
> Bibliographer, C & P Bibliography Services, LLC
> (phone) +1 (917) 727-3445
> (e-mail) jcamins at cpbibliography.com <mailto:jcamins at cpbibliography.com>
> (web) http://www.cpbibliography.com/


-- 
Mathieu Saby
Service d'Informatique Documentaire
Service Commun de la Documentation
Universit? Rennes 2
T?l?phone : 02 99 14 12 65
Courriel : mathieu.saby at univ-rennes2.fr

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131021/02860a94/attachment.html>

From martin.renvoize at ptfs-europe.com  Mon Oct 21 15:50:17 2013
From: martin.renvoize at ptfs-europe.com (Martin Renvoize)
Date: Mon, 21 Oct 2013 14:50:17 +0100
Subject: [Koha-devel] Hackfest update #1
In-Reply-To: <526520DA.7000803@univ-rennes2.fr>
References: <CAPLnt64s7XYoD0zx1LapLh+c5Y6kkqWifMY3ohwo8R=PygzSTA@mail.gmail.com>
	<5264D881.2050404@univ-rennes2.fr>
	<CALVDfQzFus8fyf8hcuUNN5deA9vOnmWW=0emw30+1TGaxxOxdQ@mail.gmail.com>
	<526520DA.7000803@univ-rennes2.fr>
Message-ID: <CAB7SL8A17s1TNqBYWSREV01ymm8QD3haGfe_T2AUNJ8rad09=w@mail.gmail.com>

I'll back that up, the facets Jared demonstrated certainly were pretty in
all their diacritics glory :-)
On 21 Oct 2013 05:41, "Mathieu Saby" <mathieu.saby at univ-rennes2.fr> wrote:

> **
> Great news!
>
>
> Jared Camins-Esakov a ?crit :
>
> Mathieu,
>
>  I read in old messages of Zebra list (msg from Henri Damien Laurent and
>> other Koha dev), whose general thrust was that Zebra built-in facets were
>> not working well for strings with diacritics, or maybe with ICU.
>>
>> https://www.google.fr/search?q=facets+zebra+icu+site:lists.indexdata.dk&client=firefox-a&hs=9nq&rls=org.mozilla:fr:official&channel=fflb
>> Is it still true?
>
>
>  No. I demonstrated that it works fine now. I used ICU and a search for
> German records returned facets with properly encoded umlauts. The changes
> that you note in 2.0.34 may be what makes it work, but I'm actually not
> sure that we didn't just always have Zebra configured incorrectly, using
> tokenized indexes rather than untokenized indexes.
>
>  Regards,
> Jared
>
>  --
> Jared Camins-Esakov
> Bibliographer, C & P Bibliography Services, LLC
> (phone) +1 (917) 727-3445
> (e-mail) jcamins at cpbibliography.com
> (web) http://www.cpbibliography.com/
>
>
>
> --
> Mathieu Saby
> Service d'Informatique Documentaire
> Service Commun de la Documentation
> Universit? Rennes 2
> T?l?phone : 02 99 14 12 65
> Courriel : mathieu.saby at univ-rennes2.fr
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131021/142e1ec4/attachment.html>

From fridolyn.somers at biblibre.com  Mon Oct 21 18:38:38 2013
From: fridolyn.somers at biblibre.com (Fridolyn SOMERS)
Date: Mon, 21 Oct 2013 18:38:38 +0200
Subject: [Koha-devel] odd tag
Message-ID: <5265588E.4090400@biblibre.com>

Hie all,

After a git remote update on koha git sources, I noticed an odd tag :
* [new tag]         3772f30a0c50db7b993ce68b10b27aeeb09f1f4b -> 
3772f30a0c50db7b993ce68b10b27aeeb09f1f4b

This is an error I bet.

Also, clone over HTTP seems to never respond.

Regards,

-- 
Fridolyn SOMERS
Biblibre - P?le support
fridolyn.somers at biblibre.com

From gmc at esilibrary.com  Tue Oct 22 07:37:44 2013
From: gmc at esilibrary.com (Galen Charlton)
Date: Mon, 21 Oct 2013 22:37:44 -0700
Subject: [Koha-devel] Hackfest update #2
Message-ID: <CAPLnt64qOxuuEoySg4Cn0ezJtrv7aVy6qrpzeGpoGVir3bv0zw@mail.gmail.com>

Hi,

Here are some notes from the second day of hackfest:

* The total number of kittens now gamboling in the fields is 102. [1]
* Two tutorial sessions were done.  Chris Cormack conducted one on
Class::Accessor and Object::Tiny, while I conducted one on DBIx::Class.
 Some discussion of moving forward now that DBIx::Class is in master took
place, which I'll be writing up later this week.
* Petter Goks?yr ?se gave a presentation on plans by the Oslo Public
Library to use Koha as a library transaction manager while the discovery
system will be based on an RDF triple-store.  The metadata layer would
generate MARC records for ingest into Koha.
* Chris Cormack helped a librarian set up a Koha development environment.
* Several librarians attending the LIANZA conference in New Zealand
submitted first-time patches to Koha under the guidance of Liz Rea.
* Several of us visited one of the branches of the Washoe County Library to
inspect the self-check stations that they've been building using open
source software and inexpensive computer hardware and cabinetry.

[1] http://scoreboard.koha-community.org/

-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  gmc at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131021/3235e53c/attachment-0001.html>

From paul.poulain at biblibre.com  Wed Oct 23 01:18:41 2013
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Wed, 23 Oct 2013 01:18:41 +0200
Subject: [Koha-devel] SearchEngine, a step by step plan
Message-ID: <526707D1.3080800@biblibre.com>

Hello koha-devel,

Chris & I had a discussion during KohaCon, to try to have a step by step
(and small steps) plan to move ahead and introduce searchengine options
into Koha.

The result of our discussion (no code provided) is on the wiki:
http://wiki.koha-community.org/wiki/KohaCon13_searchengine_plan

Feedback/comments welcomed !
-- 
Paul POULAIN - BibLibre
http://www.biblibre.com
Free & Open Source Softwares for libraries
Koha, Drupal, Piwik, Jasper


From gmc at esilibrary.com  Wed Oct 23 06:41:54 2013
From: gmc at esilibrary.com (Galen Charlton)
Date: Tue, 22 Oct 2013 21:41:54 -0700
Subject: [Koha-devel] Hackfest update #3
Message-ID: <CAPLnt66iqQbKybG+u-B7Fw8dc0H3xgiz8Ge6dQdG8tZRpeCrcQ@mail.gmail.com>

Hi,

Some notes from the last day of hackfest:

* A total of 132 kittens have been saved during hackfest.  As the
scoreboard leader, Katrin Fischer won a bottle of Nevada wine donated by
Brendan Gallagher.
* Tomas Cohen Arazi gave an update on his progress on work to get Koha to
not use ISO 2709 internally, thereby avoiding search and display issues for
MARC records that are larger than the ISO 2709 limit.  David Cook also
worked on this.
* I conducted a tutorial on Zebra's configuration files, released version
2.0.6 of MARC::Record, and cut the second alpha of 3.14.
* Chris Cormack and Paul Poulain discussed potential steps for replacing
C4::Search.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  gmc at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131022/691135cd/attachment.html>

From mathieu.saby at univ-rennes2.fr  Wed Oct 23 09:27:57 2013
From: mathieu.saby at univ-rennes2.fr (Mathieu Saby)
Date: Wed, 23 Oct 2013 09:27:57 +0200
Subject: [Koha-devel] SearchEngine, a step by step plan
In-Reply-To: <526707D1.3080800@biblibre.com>
References: <526707D1.3080800@biblibre.com>
Message-ID: <52677A7D.7090604@univ-rennes2.fr>

Hi
Just a note about "

    * Fix zebra facet things. Jared is working on fixing zebra
      configuration file, so we can get facets from Zebra. that would
      remove a large part of getRecords sub code."


For improving the facets, I began to work on a patch to make them 
configurable with
- a separate page on staff interface for chosing the facets to show and 
their order (jquery used for drag/dropping the facets)
- the config encoded in a json string, stored in a syspref (not to be 
edited by hand).
It is not testable yet.
But of course I did not try to use zebra built in facets, so this patch 
won't change the construction of facets.

Mathieu


Paul Poulain a ?crit :
> Hello koha-devel,
>
> Chris & I had a discussion during KohaCon, to try to have a step by step
> (and small steps) plan to move ahead and introduce searchengine options
> into Koha.
>
> The result of our discussion (no code provided) is on the wiki:
> http://wiki.koha-community.org/wiki/KohaCon13_searchengine_plan
>
> Feedback/comments welcomed !
>   


-- 
Mathieu Saby
Service d'Informatique Documentaire
Service Commun de la Documentation
Universit? Rennes 2
T?l?phone : 02 99 14 12 65
Courriel : mathieu.saby at univ-rennes2.fr

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131023/751307a0/attachment.html>

From mathieu.saby at univ-rennes2.fr  Wed Oct 23 09:30:51 2013
From: mathieu.saby at univ-rennes2.fr (Mathieu Saby)
Date: Wed, 23 Oct 2013 09:30:51 +0200
Subject: [Koha-devel] SearchEngine, a step by step plan
In-Reply-To: <52677A7D.7090604@univ-rennes2.fr>
References: <526707D1.3080800@biblibre.com> <52677A7D.7090604@univ-rennes2.fr>
Message-ID: <52677B2B.1040603@univ-rennes2.fr>

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10891

Mathieu Saby a ?crit :
> Hi
> Just a note about "
>
>     * Fix zebra facet things. Jared is working on fixing zebra
>       configuration file, so we can get facets from Zebra. that would
>       remove a large part of getRecords sub code."
>
>
> For improving the facets, I began to work on a patch to make them 
> configurable with
> - a separate page on staff interface for chosing the facets to show 
> and their order (jquery used for drag/dropping the facets)
> - the config encoded in a json string, stored in a syspref (not to be 
> edited by hand).
> It is not testable yet.
> But of course I did not try to use zebra built in facets, so this 
> patch won't change the construction of facets.
>
> Mathieu
>
>
> Paul Poulain a ?crit :
>> Hello koha-devel,
>>
>> Chris & I had a discussion during KohaCon, to try to have a step by step
>> (and small steps) plan to move ahead and introduce searchengine options
>> into Koha.
>>
>> The result of our discussion (no code provided) is on the wiki:
>> http://wiki.koha-community.org/wiki/KohaCon13_searchengine_plan
>>
>> Feedback/comments welcomed !
>>   
>
>
> -- 
> Mathieu Saby
> Service d'Informatique Documentaire
> Service Commun de la Documentation
> Universit? Rennes 2
> T?l?phone : 02 99 14 12 65
> Courriel : mathieu.saby at univ-rennes2.fr
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/


-- 
Mathieu Saby
Service d'Informatique Documentaire
Service Commun de la Documentation
Universit? Rennes 2
T?l?phone : 02 99 14 12 65
Courriel : mathieu.saby at univ-rennes2.fr

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131023/4cb79c2f/attachment.html>

From philippe.blouin at inLibro.com  Wed Oct 23 22:20:09 2013
From: philippe.blouin at inLibro.com (Philippe Blouin)
Date: Wed, 23 Oct 2013 16:20:09 -0400
Subject: [Koha-devel] jquery.hotkeys.min.js  (bug 11035)
In-Reply-To: <52677B2B.1040603@univ-rennes2.fr>
References: <526707D1.3080800@biblibre.com> <52677A7D.7090604@univ-rennes2.fr>
	<52677B2B.1040603@univ-rennes2.fr>
Message-ID: <52682F79.4000109@inLibro.com>

Hi!

I've replaced jquery.hotkeys.min.js in *bug 11035* (in waiting for sign 
off), and got a message today that a new file was using it, 
*circ/offline-mf.tt*.

No biggy, such things can happen: rebase, patch again.

Now, my question is that I couldn't understand what this file was doing 
with it.  Can anyone enlighten me on the usage of offline-mf.tt ?  It 
looks kinda like a .inc file, but I grep all usages and found nothing.

Your feedbacks could help me ... not break things :-)

Thanks a lot,
Blou

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131023/e776152f/attachment.html>

From jcamins at cpbibliography.com  Wed Oct 23 22:23:11 2013
From: jcamins at cpbibliography.com (Jared Camins-Esakov)
Date: Wed, 23 Oct 2013 16:23:11 -0400
Subject: [Koha-devel] jquery.hotkeys.min.js (bug 11035)
In-Reply-To: <52682F79.4000109@inLibro.com>
References: <526707D1.3080800@biblibre.com> <52677A7D.7090604@univ-rennes2.fr>
	<52677B2B.1040603@univ-rennes2.fr> <52682F79.4000109@inLibro.com>
Message-ID: <CALVDfQziQBgqiHu7RA0XLujrHsON4nw=gE9-mrg8MaGo2RMezg@mail.gmail.com>

Blou,

That file is the HTML5 manifest for the Koha offline circulation. It lists
all the files that are required by the circ interface (including JS, CSS,
etc.) so that the web browser will know to download them.

Regards,
Jared



On Wed, Oct 23, 2013 at 4:20 PM, Philippe Blouin <
philippe.blouin at inlibro.com> wrote:

>  Hi!
>
> I've replaced jquery.hotkeys.min.js in *bug 11035* (in waiting for sign
> off), and got a message today that a new file was using it, *circ/
> offline-mf.tt*.
>
> No biggy, such things can happen: rebase, patch again.
>
> Now, my question is that I couldn't understand what this file was doing
> with it.  Can anyone enlighten me on the usage of offline-mf.tt ?  It
> looks kinda like a .inc file, but I grep all usages and found nothing.
>
> Your feedbacks could help me ... not break things :-)
>
> Thanks a lot,
> Blou
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/
>



-- 
Jared Camins-Esakov
Bibliographer, C & P Bibliography Services, LLC
(phone) +1 (917) 727-3445
(e-mail) jcamins at cpbibliography.com
(web) http://www.cpbibliography.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131023/f7176f68/attachment.html>

From philippe.blouin at inLibro.com  Wed Oct 23 22:30:17 2013
From: philippe.blouin at inLibro.com (Philippe Blouin)
Date: Wed, 23 Oct 2013 16:30:17 -0400
Subject: [Koha-devel] jquery.hotkeys.min.js (bug 11035)
In-Reply-To: <CALVDfQziQBgqiHu7RA0XLujrHsON4nw=gE9-mrg8MaGo2RMezg@mail.gmail.com>
References: <526707D1.3080800@biblibre.com> <52677A7D.7090604@univ-rennes2.fr>
	<52677B2B.1040603@univ-rennes2.fr> <52682F79.4000109@inLibro.com>
	<CALVDfQziQBgqiHu7RA0XLujrHsON4nw=gE9-mrg8MaGo2RMezg@mail.gmail.com>
Message-ID: <526831D9.308@inLibro.com>

Ah, nice.  But is it possible it wasn't used yet?

The "plan" was to replace that script because it doesn't work with 
latest jquery.
So I've removed it from the main Koha code.

thanks,
Blou

On 13-10-23 04:23 PM, Jared Camins-Esakov wrote:
> Blou,
>
> That file is the HTML5 manifest for the Koha offline circulation. It 
> lists all the files that are required by the circ interface (including 
> JS, CSS, etc.) so that the web browser will know to download them.
>
> Regards,
> Jared
>
>
>
> On Wed, Oct 23, 2013 at 4:20 PM, Philippe Blouin 
> <philippe.blouin at inlibro.com <mailto:philippe.blouin at inlibro.com>> wrote:
>
>     Hi!
>
>     I've replaced jquery.hotkeys.min.js in *bug 11035* (in waiting for
>     sign off), and got a message today that a new file was using it,
>     *circ/offline-mf.tt <http://offline-mf.tt>*.
>
>     No biggy, such things can happen: rebase, patch again.
>
>     Now, my question is that I couldn't understand what this file was
>     doing with it.  Can anyone enlighten me on the usage of
>     offline-mf.tt <http://offline-mf.tt> ?  It looks kinda like a .inc
>     file, but I grep all usages and found nothing.
>
>     Your feedbacks could help me ... not break things :-)
>
>     Thanks a lot,
>     Blou
>
>
>     _______________________________________________
>     Koha-devel mailing list
>     Koha-devel at lists.koha-community.org
>     <mailto:Koha-devel at 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/
>
>
>
>
> -- 
> Jared Camins-Esakov
> Bibliographer, C & P Bibliography Services, LLC
> (phone) +1 (917) 727-3445
> (e-mail) jcamins at cpbibliography.com <mailto:jcamins at cpbibliography.com>
> (web) http://www.cpbibliography.com/

-- 
Philippe Blouin,
Responsable du d?veloppement informatique

T?l.  : (888) 604-2627
philippe.blouin at inLibro.com <mailto:philippe.blouin at inLibro.com>

inLibro | pour esprit libre | www.inLibro.com <http://www.inLibro.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131023/d7545e18/attachment.html>

From jcamins at cpbibliography.com  Wed Oct 23 22:35:06 2013
From: jcamins at cpbibliography.com (Jared Camins-Esakov)
Date: Wed, 23 Oct 2013 16:35:06 -0400
Subject: [Koha-devel] jquery.hotkeys.min.js (bug 11035)
In-Reply-To: <526831D9.308@inLibro.com>
References: <526707D1.3080800@biblibre.com> <52677A7D.7090604@univ-rennes2.fr>
	<52677B2B.1040603@univ-rennes2.fr> <52682F79.4000109@inLibro.com>
	<CALVDfQziQBgqiHu7RA0XLujrHsON4nw=gE9-mrg8MaGo2RMezg@mail.gmail.com>
	<526831D9.308@inLibro.com>
Message-ID: <CALVDfQzt-_6a5N71Bc+Ta-2dq129AgefjNpqeHyOOLLpBMGc+Q@mail.gmail.com>

Blou,

 Ah, nice.  But is it possible it wasn't used yet?
>

The manifest is used in offline.tt:

[% IF (AllowOfflineCirculation) %]
[% SET manifestattr = 'manifest="/cgi-bin/koha/circ/offline-mf.pl"' %]
[% END %]

The hotkey script is required because it's included in doc-head-close.inc.

The "plan" was to replace that script because it doesn't work with latest
> jquery.
> So I've removed it from the main Koha code.
>

Yay! I'm all for that!

Regards,
Jared

-- 
Jared Camins-Esakov
Bibliographer, C & P Bibliography Services, LLC
(phone) +1 (917) 727-3445
(e-mail) jcamins at cpbibliography.com
(web) http://www.cpbibliography.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131023/23e234ec/attachment.html>

From philippe.blouin at inLibro.com  Wed Oct 23 22:41:22 2013
From: philippe.blouin at inLibro.com (Philippe Blouin)
Date: Wed, 23 Oct 2013 16:41:22 -0400
Subject: [Koha-devel] jquery.hotkeys.min.js (bug 11035)
In-Reply-To: <CALVDfQzt-_6a5N71Bc+Ta-2dq129AgefjNpqeHyOOLLpBMGc+Q@mail.gmail.com>
References: <526707D1.3080800@biblibre.com> <52677A7D.7090604@univ-rennes2.fr>
	<52677B2B.1040603@univ-rennes2.fr> <52682F79.4000109@inLibro.com>
	<CALVDfQziQBgqiHu7RA0XLujrHsON4nw=gE9-mrg8MaGo2RMezg@mail.gmail.com>
	<526831D9.308@inLibro.com>
	<CALVDfQzt-_6a5N71Bc+Ta-2dq129AgefjNpqeHyOOLLpBMGc+Q@mail.gmail.com>
Message-ID: <52683472.9050804@inLibro.com>

Excellent,  thanks a lot for the clarifications!

The patch fix doc-head-close.inc as well, so it's all good.

regards,
Blou


On 13-10-23 04:35 PM, Jared Camins-Esakov wrote:
> Blou,
>
>     Ah, nice.  But is it possible it wasn't used yet?
>
>
> The manifest is used in offline.tt <http://offline.tt>:
>
> [% IF (AllowOfflineCirculation) %]
> [% SET manifestattr = 'manifest="/cgi-bin/koha/circ/offline-mf.pl 
> <http://offline-mf.pl>"' %]
> [% END %]
>
> The hotkey script is required because it's included in doc-head-close.inc.
>
>     The "plan" was to replace that script because it doesn't work with
>     latest jquery.
>     So I've removed it from the main Koha code.
>
>
> Yay! I'm all for that!
>
> Regards,
> Jared
> -- 
> Jared Camins-Esakov
> Bibliographer, C & P Bibliography Services, LLC
> (phone) +1 (917) 727-3445
> (e-mail) jcamins at cpbibliography.com <mailto:jcamins at cpbibliography.com>
> (web) http://www.cpbibliography.com/

-- 
Philippe Blouin,
Responsable du d?veloppement informatique

T?l.  : (888) 604-2627
philippe.blouin at inLibro.com <mailto:philippe.blouin at inLibro.com>

inLibro | pour esprit libre | www.inLibro.com <http://www.inLibro.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131023/1ec5267f/attachment-0001.html>

From jonathan.druart at biblibre.com  Thu Oct 24 14:53:24 2013
From: jonathan.druart at biblibre.com (Jonathan Druart)
Date: Thu, 24 Oct 2013 14:53:24 +0200
Subject: [Koha-devel] Jenkins status [was Jenkins build is back to stable :
	Koha_master #1475]
Message-ID: <CAJzKNY6GNtbUiSpoE6e9KnQNcSmXhSm+TpoAdB70CkSv2OVqww@mail.gmail.com>

Hi all!

I often receive emails from Jenkins: "master is unstable", "master is
back to stable".
Last unstable status was caused by a fail in
t/db_dependent/Acquisition/Invoices.t (I think).
Here Jenkins says : "it is stable, see changes". But changes are about
a tt change.
I don't know who fixed the failure and how it was fixed. It is
frustrating not to know :)
Especially because the tests pass on master with my data!

Do you think it would be possible to put something in place in order
to follow Jenkins ' moods?

For discussion.
Regards,
Jonathan

2013/10/23  <chris at bigballofwax.co.nz>:
> See <http://jenkins.koha-community.org/job/Koha_master/1475/changes>
>

From fridolyn.somers at biblibre.com  Thu Oct 24 16:18:54 2013
From: fridolyn.somers at biblibre.com (Fridolyn SOMERS)
Date: Thu, 24 Oct 2013 16:18:54 +0200
Subject: [Koha-devel] Linking bibs to authorities
In-Reply-To: <5260192A.9030800@ptfs-europe.com>
References: <51FBD0FD.4020304@ptfs-europe.com> <52600815.80400@biblibre.com>
	<5260192A.9030800@ptfs-europe.com>
Message-ID: <52692C4E.1070508@biblibre.com>

Hie,

phrases-icu.xml ? this does not exist in current master.
Could you give it ?

Regards,

Le 17/10/2013 19:06, Ian Bays a ?crit :
> Hi Fridolyn,
> Thank you for this.  I was beginning to wonder if nobody was interested
> in the question.
>
> The bug you mention is a useful addition, but we achieved considerable
> success by correcting the contents of the default.idx
> (~/koha-dev/etc/zebradb/etc/default.idx) to use phrases-icu.xml for
> index p, and to ensure phrases-icu.xml and words-icu.xml have the
> correct stanzas for searching accent-blind.
>
> With these both in place I believe we have a very good hit rate for
> linking bib to authorities as long as the authority terms have been
> de-duplicated.
>
> I think Colin has submitted patches so that these are in place for all
> moving forwards, but it is good to know that others are using these
> features.
>
> What we were seeing before was if the term in the bib was (say) "History
> of Art" it would only match on the first word so would match an
> authority of (say) "History Books".
>
> All the best.
>
> Ian
> On 17/10/2013 16:53, Fridolyn SOMERS wrote:
>> Hie,
>>
>> It is because in Zebra, exact search does not work.
>> It can find a phrase (all words in same order) but not say if this
>> phrase fits the entire (sub)field. This is the purpose of PQF attribut
>> 6, but is does not work.
>> So when linking bibs to authorities, linker will match more
>> authorities than needed. For example, in biblio record "History" will
>> match authorities with headings "History", "History of art", "History
>> of science", ...
>>
>> That is wy I created Bug 9072 :
>> http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9072
>>
>> Le 02/08/2013 17:32, Ian Bays a ?crit :
>>> Hi.
>>> I mentioned we also have a problem with linking bibs to authorities.
>>>
>>> We use authorities and want to link them to bibs.  Over previous
>>> versions of Koha this has sometimes worked quite well.  However on a few
>>> systems we have at version 3.12 it seems that the Zebra search into the
>>> authorities (used by link_bib_to_authorities) is returning all terms
>>> that contain any of the words in the bib field.
>>>
>>> So if the linkage is set to "default" then most authority searches will
>>> return multiple answers which means they do not link.
>>> If the linkage syspref is set to first or last then most of the bibs
>>> will link to the wrong authority as it is pot luck which will be first
>>> (or last) of the many authorities found by searching all the words ORed
>>> together.
>>> The only terms that will link are single-word authorities that are not
>>> used in any other authorities.
>>>
>>> If anyone has any pointers or knows how to get round or over this
>>> problem I would love to hear from you.  More details on request...
>>>
>>> We are using Zebra dom indexing and icu chains and are using Koha 3.12
>>> on Debian.  We are not yet using QueryParser.  Sysprefs and Help > About
>>> are here:
>>>
>>> Sysprefs are:
>>>
>>> +--------------------------+-------+
>>> | variable                 | value |
>>> +--------------------------+-------+
>>> | IncludeSeeFromInSearches | 0     |
>>> | QueryAutoTruncate        | 0     |
>>> | QueryFuzzy               | 0     |
>>> | QueryStemming            | 0     |
>>> | QueryWeightFields        | 1     |
>>> | TraceCompleteSubfields   | 0     |
>>> | TraceSubjectSubdivisions | 0     |
>>> | UseICU                   | 1     |
>>> | UseQueryParser           | 0     |
>>> +--------------------------+-------+
>>>
>>>
>>> Koha> About:
>>>
>>> Koha version:     3.12.01.000
>>> OS version ('uname -a'):     Linux dclg.koha.ptfsadmin.uk0.bigv.io
>>> 3.2.0-4-amd64 #1 SMP Debian 3.2.46-1 x86_64 GNU/Linux
>>> Perl interpreter:     /usr/bin/perl
>>> Perl version:     5.014002
>>> Perl @INC:     /home/koha/kohaclone
>>> /etc/perl
>>> /usr/local/lib/perl/5.14.2
>>> /usr/local/share/perl/5.14.2
>>> /usr/lib/perl5
>>> /usr/share/perl5
>>> /usr/lib/perl/5.14
>>> /usr/share/perl/5.14
>>> /usr/local/lib/site_perl
>>> .
>>> MySQL version:     mysql Ver 14.14 Distrib 5.5.31, for debian-linux-gnu
>>> (x86_64) using readline 6.2
>>> Apache version:     Server version: Apache/2.2.22 (Debian)
>>> Zebra version:     Zebra 2.0.55 (C) 1994-2013, Index Data ApS Zebra is
>>> free software, covered by the GNU General Public License, and you are
>>> welcome to change it and/or distribute copies of it under certain
>>> conditions. SHA1 ID: bd2bc9360225e695bbaba2c2d1cd6925c4eb23a5 Using ICU
>>>
>>> Many thanks folks.
>>> Ian
>>>
>>>
>>
>
>

-- 
Fridolyn SOMERS
Biblibre - P?le support
fridolyn.somers at biblibre.com

From colin.campbell at ptfs-europe.com  Thu Oct 24 16:38:46 2013
From: colin.campbell at ptfs-europe.com (Colin Campbell)
Date: Thu, 24 Oct 2013 15:38:46 +0100
Subject: [Koha-devel] Linking bibs to authorities
In-Reply-To: <52692C4E.1070508@biblibre.com>
References: <51FBD0FD.4020304@ptfs-europe.com> <52600815.80400@biblibre.com>
	<5260192A.9030800@ptfs-europe.com> <52692C4E.1070508@biblibre.com>
Message-ID: <20131024143846.GA29814@zazou.cscnet.co.uk>

On Thu, Oct 24, 2013 at 04:18:54PM +0200, Fridolyn SOMERS wrote:
> Hie,
> 
> phrases-icu.xml ? this does not exist in current master.
> Could you give it ?
> 
Its in the patch for bug 10729 based on the one distributed with zebra.
The patch also makes the default reference it

Cheers
Colin

-- 
Colin Campbell
Chief Software Engineer,
PTFS Europe Limited
Content Management and Library Solutions
+44 (0) 800 756 6803 (phone)
+44 (0) 7759 633626  (mobile)
colin.campbell at ptfs-europe.com
skype: colin_campbell2

http://www.ptfs-europe.com

From gmc at esilibrary.com  Thu Oct 24 16:44:09 2013
From: gmc at esilibrary.com (Galen Charlton)
Date: Thu, 24 Oct 2013 07:44:09 -0700
Subject: [Koha-devel] Default indexing and search options for 3.14
Message-ID: <CAPLnt64ThLSDKSSYXVoWkrEK+W1C0Z0yzi0GQp8z=J-wyrY_cg@mail.gmail.com>

Hi,

I would like to have a discussion regarding making certain options the
default for new installations of Koha 3.14 and deprecating other options.
 Here's the list of proposals:

Enable DOM mode by default for both bibs and authorities
-----------------------------------------------------------------------------------

Now that MARC21, NORMARC, and UNIMARC have DOM indexing configurations
available, this is now possible.

Deprecating the GRS-1 filter
-----------------------------------------

Giving that DOM has significant advantages of GRS-1 in its flexibility, and
as the DOM filter would be required for non-MARC metadata support by Zebra,
I propose that we announce a deprecation of the GRS-1 configuration with it
to be removed by 3.16.  I foresee several features coming down the pike for
3.16 that would require a reindexing during upgrade anyway, so switching to
DOM for 3.16 would not impose a burden that wouldn't be present anyway.

Enable QueryParser by default
---------------------------------------------

Bug 10542 might be a blocker for this, and doing something about bug 10831
would be nice in order to do this.

Deprecating non-QueryParser mode
---------------------------------------------------

Removing the non-QueryParser code would go a long way towards easing the
rewrite of C4::Search.

Enable ICU by default
-------------------------------

This was discussed during hackfest.  One precondition I see is that bug
10729 would have to pass QA

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  gmc at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131024/c7c06bc1/attachment.html>

From gmc at esilibrary.com  Thu Oct 24 17:04:51 2013
From: gmc at esilibrary.com (Galen Charlton)
Date: Thu, 24 Oct 2013 08:04:51 -0700
Subject: [Koha-devel] OPAC theme defaults for 3.14
Message-ID: <CAPLnt66M2pyj=PV5bQ+EMCbsr+yUqngWukmW0M=Wjr5LcDH=4A@mail.gmail.com>

Hi,

Another point for discussion: I propose that the Bootstrap OPAC theme be
made the installation default for 3.14, and that we announce deprecation of
the prog and CCSR themes at the same time, with those themes to be removed
(or split into separate packages, if somebody really wants to maintain one
or both) in 3.16.

Why deprecate prog?  For one thing, I don't think we have enough people to
successfully maintain both prog and Bootstrap.

Why deprecate CCSR?  The Bootstrap theme, since it's responsive, provides
support for both mobile devices and desktop screens, thereby addressing the
mobile concerns that motivated the creation of CCSR.  Furthermore, since
CCSR is a derivative of prog, maintaining support for CCSR would
effectively mean maintaining support for prog as well.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  gmc at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131024/a80cdecc/attachment.html>

From ian.bays at ptfs-europe.com  Thu Oct 24 17:32:10 2013
From: ian.bays at ptfs-europe.com (Ian Bays)
Date: Thu, 24 Oct 2013 16:32:10 +0100
Subject: [Koha-devel] Default indexing and search options for 3.14
In-Reply-To: <CAPLnt64ThLSDKSSYXVoWkrEK+W1C0Z0yzi0GQp8z=J-wyrY_cg@mail.gmail.com>
References: <CAPLnt64ThLSDKSSYXVoWkrEK+W1C0Z0yzi0GQp8z=J-wyrY_cg@mail.gmail.com>
Message-ID: <52693D7A.2010701@ptfs-europe.com>

Hi.
Going forward we expect to use DOM and ICU with MARC21.  Broadly we are 
getting good behaviour.  However at present searching authorities gives 
the same results for "starts with" and "contains".  On some 
installations we have that are older versions of zebra and Koha and 
probably not using DOM or ICU the two authority searches do give results 
that are more-expected.
Colin has been trying to track down why "starts with" is treated the 
same as "contains", but it would be good to have this resolved so we are 
improving searching for all and not breaking existing functions.  If 
anyone can shine any light on this problem or a solution that would be 
most helpful.
+1 for the roadmap.

Ian

On 24/10/2013 15:44, Galen Charlton wrote:
> Hi,
>
> I would like to have a discussion regarding making certain options the 
> default for new installations of Koha 3.14 and deprecating other 
> options.  Here's the list of proposals:
>
> Enable DOM mode by default for both bibs and authorities
> -----------------------------------------------------------------------------------
>
> Now that MARC21, NORMARC, and UNIMARC have DOM indexing configurations 
> available, this is now possible.
>
> Deprecating the GRS-1 filter
> -----------------------------------------
>
> Giving that DOM has significant advantages of GRS-1 in its 
> flexibility, and as the DOM filter would be required for non-MARC 
> metadata support by Zebra, I propose that we announce a deprecation of 
> the GRS-1 configuration with it to be removed by 3.16.  I foresee 
> several features coming down the pike for 3.16 that would require a 
> reindexing during upgrade anyway, so switching to DOM for 3.16 would 
> not impose a burden that wouldn't be present anyway.
>
> Enable QueryParser by default
> ---------------------------------------------
>
> Bug 10542 might be a blocker for this, and doing something about 
> bug 10831 would be nice in order to do this.
>
> Deprecating non-QueryParser mode
> ---------------------------------------------------
>
> Removing the non-QueryParser code would go a long way towards easing 
> the rewrite of C4::Search.
>
> Enable ICU by default
> -------------------------------
>
> This was discussed during hackfest.  One precondition I see is that 
> bug 10729 would have to pass QA
>
> Regards,
>
> Galen
> -- 
> Galen Charlton
> Manager of Implementation
> Equinox Software, Inc. / The Open Source Experts
> email: gmc at esilibrary.com <mailto:gmc at 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
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/


-- 
Ian Bays
Director of Projects, PTFS Europe Limited
Content Management and Library Solutions
+44 (0) 800 756 6803 (phone)
+44 (0) 7774 995297 (mobile)
+44 (0) 800 756 6384 (fax)
skype: ian.bays
email: ian.bays at ptfs-europe.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131024/3bf5a700/attachment-0001.html>

From colin.campbell at ptfs-europe.com  Thu Oct 24 17:32:48 2013
From: colin.campbell at ptfs-europe.com (Colin Campbell)
Date: Thu, 24 Oct 2013 16:32:48 +0100
Subject: [Koha-devel] Default indexing and search options for 3.14
In-Reply-To: <CAPLnt64ThLSDKSSYXVoWkrEK+W1C0Z0yzi0GQp8z=J-wyrY_cg@mail.gmail.com>
References: <CAPLnt64ThLSDKSSYXVoWkrEK+W1C0Z0yzi0GQp8z=J-wyrY_cg@mail.gmail.com>
Message-ID: <20131024153248.GA14131@zazou.cscnet.co.uk>

On Thu, Oct 24, 2013 at 07:44:09AM -0700, Galen Charlton wrote:
> 
> Deprecating non-QueryParser mode
> ---------------------------------------------------
> 
> Removing the non-QueryParser code would go a long way towards easing the
> rewrite of C4::Search.
> 
I find after switching to use QueryParser searches return no
hits. I've not searched very deeply for a cause. But I'm a bit sceptical
that its ready for prime time yet

Colin

-- 
Colin Campbell
Chief Software Engineer,
PTFS Europe Limited
Content Management and Library Solutions
+44 (0) 800 756 6803 (phone)
+44 (0) 7759 633626  (mobile)
colin.campbell at ptfs-europe.com
skype: colin_campbell2

http://www.ptfs-europe.com

From colin.campbell at ptfs-europe.com  Thu Oct 24 19:49:12 2013
From: colin.campbell at ptfs-europe.com (Colin Campbell)
Date: Thu, 24 Oct 2013 18:49:12 +0100
Subject: [Koha-devel] Default indexing and search options for 3.14
In-Reply-To: <52693D7A.2010701@ptfs-europe.com>
References: <CAPLnt64ThLSDKSSYXVoWkrEK+W1C0Z0yzi0GQp8z=J-wyrY_cg@mail.gmail.com>
	<52693D7A.2010701@ptfs-europe.com>
Message-ID: <20131024174912.GA16053@zazou.cscnet.co.uk>

On Thu, Oct 24, 2013 at 04:32:10PM +0100, Ian Bays wrote:
> Colin has been trying to track down why "starts with" is treated the
> same as "contains", but it would be good to have this resolved so we
> are improving searching for all and not breaking existing functions.

This problem exists irrespective of the ICU and DOM settings so is not
relevant to the question Galen posed.
I think the problem is that we assume starts with is searching headings,
zebra is returning keywords that start with i.e. starts with O returns
O'Reilly but also Duke of Argyll because both contain keywords starting
with o. As I posted earlier I suspect a search tool which is keyword
oriented is possibly not the best tool for authority headings. 

Colin

-- 
Colin Campbell
Chief Software Engineer,
PTFS Europe Limited
Content Management and Library Solutions
+44 (0) 800 756 6803 (phone)
+44 (0) 7759 633626  (mobile)
colin.campbell at ptfs-europe.com
skype: colin_campbell2

http://www.ptfs-europe.com

From nengard at gmail.com  Thu Oct 24 20:30:39 2013
From: nengard at gmail.com (Nicole Engard)
Date: Thu, 24 Oct 2013 13:30:39 -0500
Subject: [Koha-devel] OPAC theme defaults for 3.14
In-Reply-To: <CAPLnt66M2pyj=PV5bQ+EMCbsr+yUqngWukmW0M=Wjr5LcDH=4A@mail.gmail.com>
References: <CAPLnt66M2pyj=PV5bQ+EMCbsr+yUqngWukmW0M=Wjr5LcDH=4A@mail.gmail.com>
Message-ID: <CAC0K6VG5M9R=9DUXCpqPA+VTmH7N6q7hgtUeK7OhkW=U7D5uLQ@mail.gmail.com>

I agree that we should deprecate prog with 3.16, but I think that CCSR
should wait another release so that people have time to transition their
customizations from CCSR to the Bootstrap theme before it disappears.

Nicole


On Thu, Oct 24, 2013 at 10:04 AM, Galen Charlton <gmc at esilibrary.com> wrote:

> Hi,
>
> Another point for discussion: I propose that the Bootstrap OPAC theme be
> made the installation default for 3.14, and that we announce deprecation of
> the prog and CCSR themes at the same time, with those themes to be removed
> (or split into separate packages, if somebody really wants to maintain one
> or both) in 3.16.
>
> Why deprecate prog?  For one thing, I don't think we have enough people to
> successfully maintain both prog and Bootstrap.
>
> Why deprecate CCSR?  The Bootstrap theme, since it's responsive, provides
> support for both mobile devices and desktop screens, thereby addressing the
> mobile concerns that motivated the creation of CCSR.  Furthermore, since
> CCSR is a derivative of prog, maintaining support for CCSR would
> effectively mean maintaining support for prog as well.
>
> Regards,
>
> Galen
> --
> Galen Charlton
> Manager of Implementation
> Equinox Software, Inc. / The Open Source Experts
> email:  gmc at 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
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131024/91362025/attachment.html>

From oleonard at myacpl.org  Thu Oct 24 20:41:47 2013
From: oleonard at myacpl.org (Owen Leonard)
Date: Thu, 24 Oct 2013 14:41:47 -0400
Subject: [Koha-devel] OPAC theme defaults for 3.14
In-Reply-To: <CAC0K6VG5M9R=9DUXCpqPA+VTmH7N6q7hgtUeK7OhkW=U7D5uLQ@mail.gmail.com>
References: <CAPLnt66M2pyj=PV5bQ+EMCbsr+yUqngWukmW0M=Wjr5LcDH=4A@mail.gmail.com>
	<CAC0K6VG5M9R=9DUXCpqPA+VTmH7N6q7hgtUeK7OhkW=U7D5uLQ@mail.gmail.com>
Message-ID: <CAO4qe2P+RG58Xg2D9+6fdGBU-og2=WbhQywQgHyofWDP5hbTBA@mail.gmail.com>

> I agree that we should deprecate prog with 3.16, but I think that CCSR
> should wait another release

I know a lot of folks have been switching to CCSR, but I wouldn't be
surprised if the number of customized prog templates wasn't higher
just because it was around longer.

Anyway, CCSR is a sub-theme of prog, so keeping one longer means
keeping both longer as far as I know.

I don't want to have to maintain them both any longer than necessary,
but I recognize that porting over customizations could be
time-consuming.

  -- Owen

-- 
Web Developer
Athens County Public Libraries
http://www.myacpl.org

From paul.a at navalmarinearchive.com  Thu Oct 24 21:35:28 2013
From: paul.a at navalmarinearchive.com (Naval Marine Archive)
Date: Thu, 24 Oct 2013 15:35:28 -0400
Subject: [Koha-devel] OPAC theme defaults for 3.14
In-Reply-To: <CAPLnt66M2pyj=PV5bQ+EMCbsr+yUqngWukmW0M=Wjr5LcDH=4A@mail.g
	mail.com>
Message-ID: <5.2.1.1.2.20131024134343.04c34a68@pop.navalmarinearchive.com>

At 08:04 AM 10/24/2013 -0700, it was written:
>I propose that the Bootstrap OPAC theme be made the installation default 
>for 3.14, and that we announce deprecation of the prog and CCSR themes at 
>the same time [snip] I don't think we have enough people to successfully 
>maintain both prog and Bootstrap. [snip]

The first mention I can find for "bootstrap" is bug 10309 and is less than 
six months old: "I started the redesign by throwing out everything in 
opac.css and starting from scratch..."

I'm not sure what exactly is meant by "bootstrap" in the Koha context (in 
years gone by I did occasionally get involved in programming bootstrap 
hardware which were independent boxes for starting-up main-frames) 
particularly as regards continuity. We spent quite some time getting our 
OPAC to "look the way we wanted it" -- basically a seamless continuation of 
our main website -- and when we upgrade Koha next year I'd like to thing 
that we don't have to totally reinvent the wheel.

Is it possible to point me towards an overview of what is being suggested? 
What is being "deleted" and what is being "added"? I can only guess "start 
from zero."

As a possible non-sequitur, a W3 css verification of one of our OPAC pages 
comes up with 256 "errors", all of them, as far as I can see, from .yui 
style sheets. So there is most probably enormous room for improvement.

Many thanks and best regards,
Paul



From nengard at gmail.com  Thu Oct 24 22:24:04 2013
From: nengard at gmail.com (Nicole Engard)
Date: Thu, 24 Oct 2013 15:24:04 -0500
Subject: [Koha-devel] OPAC theme defaults for 3.14
In-Reply-To: <CAO4qe2P+RG58Xg2D9+6fdGBU-og2=WbhQywQgHyofWDP5hbTBA@mail.gmail.com>
References: <CAPLnt66M2pyj=PV5bQ+EMCbsr+yUqngWukmW0M=Wjr5LcDH=4A@mail.gmail.com>
	<CAC0K6VG5M9R=9DUXCpqPA+VTmH7N6q7hgtUeK7OhkW=U7D5uLQ@mail.gmail.com>
	<CAO4qe2P+RG58Xg2D9+6fdGBU-og2=WbhQywQgHyofWDP5hbTBA@mail.gmail.com>
Message-ID: <CAC0K6VFckpJ5KtRfSZdCKj2ySBEo+kV-9z6FwGhfHhfjLMpHmA@mail.gmail.com>

On Thu, Oct 24, 2013 at 1:41 PM, Owen Leonard <oleonard at myacpl.org> wrote:

>
> I don't want to have to maintain them both any longer than necessary,
> but I recognize that porting over customizations could be
> time-consuming.
>

I think we need some sort of announcement that this is officially going to
be deprecated so that we have time to port the customizations from both
themes, but I don't think that one release cycle is enough.

Nicole
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131024/c9bc00cb/attachment.html>

From joy at bywatersolutions.com  Thu Oct 24 22:48:07 2013
From: joy at bywatersolutions.com (Joy Nelson)
Date: Thu, 24 Oct 2013 15:48:07 -0500
Subject: [Koha-devel] OPAC theme defaults for 3.14
In-Reply-To: <CAC0K6VFckpJ5KtRfSZdCKj2ySBEo+kV-9z6FwGhfHhfjLMpHmA@mail.gmail.com>
References: <CAPLnt66M2pyj=PV5bQ+EMCbsr+yUqngWukmW0M=Wjr5LcDH=4A@mail.gmail.com>
	<CAC0K6VG5M9R=9DUXCpqPA+VTmH7N6q7hgtUeK7OhkW=U7D5uLQ@mail.gmail.com>
	<CAO4qe2P+RG58Xg2D9+6fdGBU-og2=WbhQywQgHyofWDP5hbTBA@mail.gmail.com>
	<CAC0K6VFckpJ5KtRfSZdCKj2ySBEo+kV-9z6FwGhfHhfjLMpHmA@mail.gmail.com>
Message-ID: <CAFpshE9sBP-4ngHyFcE2EJG65qgTu_t_81OZb-G2kWP2XadHJA@mail.gmail.com>

I agree with Nicole.  One release cycle is probably not adequate.

-joy


On Thu, Oct 24, 2013 at 3:24 PM, Nicole Engard <nengard at gmail.com> wrote:

>
> On Thu, Oct 24, 2013 at 1:41 PM, Owen Leonard <oleonard at myacpl.org> wrote:
>
>>
>> I don't want to have to maintain them both any longer than necessary,
>> but I recognize that porting over customizations could be
>> time-consuming.
>>
>
> I think we need some sort of announcement that this is officially going to
> be deprecated so that we have time to port the customizations from both
> themes, but I don't think that one release cycle is enough.
>
> Nicole
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/
>



-- 
Joy Nelson
Director of Migrations

ByWater Solutions <http://bywatersolutions.com>
Support and Consulting for Open Source Software
**Office: Fort Worth, TX
Phone/Fax (888)900-8944
What is Koha? <http://bywatersolutions.com/what-is-koha/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131024/d51bb259/attachment-0001.html>

From robin at catalyst.net.nz  Thu Oct 24 22:50:59 2013
From: robin at catalyst.net.nz (Robin Sheat)
Date: Fri, 25 Oct 2013 09:50:59 +1300
Subject: [Koha-devel] OPAC theme defaults for 3.14
In-Reply-To: <5.2.1.1.2.20131024134343.04c34a68@pop.navalmarinearchive.com>
References: <5.2.1.1.2.20131024134343.04c34a68@pop.navalmarinearchive.com>
Message-ID: <52698833.3070705@catalyst.net.nz>

op 25-10-13 08:35, Naval Marine Archive schreef:
> I'm not sure what exactly is meant by "bootstrap" in the Koha context

Bootstrap is a web framework that makes it easy to make responsive (i.e.
works seamlessly on mobile and desktop browsers) websites.

see http://responsive.mykoha.co.nz/ for an example.

see https://www.google.com/search?q=bootstrap for more general
information about it.

Robin.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131025/e4655b77/attachment.pgp>

From mathieu.saby at univ-rennes2.fr  Thu Oct 24 23:25:50 2013
From: mathieu.saby at univ-rennes2.fr (Mathieu Saby)
Date: Thu, 24 Oct 2013 23:25:50 +0200
Subject: [Koha-devel] OPAC theme defaults for 3.14
In-Reply-To: <CAFpshE9sBP-4ngHyFcE2EJG65qgTu_t_81OZb-G2kWP2XadHJA@mail.gmail.com>
References: <CAPLnt66M2pyj=PV5bQ+EMCbsr+yUqngWukmW0M=Wjr5LcDH=4A@mail.gmail.com>	<CAC0K6VG5M9R=9DUXCpqPA+VTmH7N6q7hgtUeK7OhkW=U7D5uLQ@mail.gmail.com>	<CAO4qe2P+RG58Xg2D9+6fdGBU-og2=WbhQywQgHyofWDP5hbTBA@mail.gmail.com>	<CAC0K6VFckpJ5KtRfSZdCKj2ySBEo+kV-9z6FwGhfHhfjLMpHmA@mail.gmail.com>
	<CAFpshE9sBP-4ngHyFcE2EJG65qgTu_t_81OZb-G2kWP2XadHJA@mail.gmail.com>
Message-ID: <5269905E.4050702@univ-rennes2.fr>

Hi
Congrats everybody for the work done during KohaCon and Hackfest!

I haven't followed the development of Boostrap opac and Queryparser, but 
I give you my personal opinion. Maybe I don't understand things well...

For the 3 OPAC themes :
Some patchs recently made for UNIMARC XSLT were only pushed in prog 
template, because we did not knew that it needed to be too in CCSR (was 
it needed?) and in Bootstrap.
So, maintaining 3 themes for a long time is obviously impossible, as 
only a few weeks after the push of Boostrap them, there is already 
little discrepancies between Boostrap and prog theme :(
I would appreciate a clear rule for developpers making changes to OPAC 
templates, including XSLT (and for QA team) to take into account 
Bootstrap AND prog (and maybe CCSR?), for the 3.14 version at least.

If you want to announce the death of prog and CCSR for 3.16 it is not a 
problem for me, as we don't really like it, and made huge changes to it 
with css and jquery hacks.
BUT I'm not a big fan for saying that Boostrap theme will be the default 
theme in 3.14. It is too fresh. The only time I tried to test it, it 
crashed on my VM ;-)

Maybe the rule could be : in 3.15 make your changes for Bootstrap first, 
and port them to prog and CCSR for maintenance releases including 3.14 ?

For the Queryparser : It need to be more documented, so that we know 
exactly what to do to edit or improve config settings, and what behavior 
is expected.
There is a big RFC page, but now that it is include in Koha's code, we 
need a different documentation, more directly usable by developers, AND 
by librarians.
For example, I made a patch adding new indexes in Search.pm. From 
Jared's comments, I guess something is needed in queryparser.yaml, but I 
don't know exactly what.

Idem : what about a rule asking to make changes to QP conf first in 
3.15, and in the other parts of Search.pm only for maintenance releases 
including 3.14 ?

For DOM and GRS-1 : Consider that DOM UNIMARC never worked properly, for 
us DOM is a really fresh thing. Nobody has really tried DOM UNIMARC in a 
real size Koha, only in VM. I would like to be sure that DOM is not 
somehow causing some regression.
Especially, I wonder if DOM is not going to make the search more "noisy" 
(we say that in french, not sure in english).
If so, some improvements must be made before GRS-1 is deprecated. For 
example something in the spirit of Bug  8962.


Regards,
M. Saby

ILe 24/10/2013 22:48, Joy Nelson a ?crit :
> I agree with Nicole.  One release cycle is probably not adequate.
>
> -joy
>
>
> On Thu, Oct 24, 2013 at 3:24 PM, Nicole Engard <nengard at gmail.com 
> <mailto:nengard at gmail.com>> wrote:
>
>
>     On Thu, Oct 24, 2013 at 1:41 PM, Owen Leonard <oleonard at myacpl.org
>     <mailto:oleonard at myacpl.org>> wrote:
>
>
>         I don't want to have to maintain them both any longer than
>         necessary,
>         but I recognize that porting over customizations could be
>         time-consuming.
>
>
>     I think we need some sort of announcement that this is officially
>     going to be deprecated so that we have time to port the
>     customizations from both themes, but I don't think that one
>     release cycle is enough.
>
>     Nicole
>
>     _______________________________________________
>     Koha-devel mailing list
>     Koha-devel at lists.koha-community.org
>     <mailto:Koha-devel at 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/
>
>
>
>
> -- 
> Joy Nelson
> Director of Migrations
>
> ByWater Solutions <http://bywatersolutions.com>
> Support and Consulting for Open Source Software
> Office: Fort Worth, TX
> Phone/Fax (888)900-8944
> What is Koha? <http://bywatersolutions.com/what-is-koha/>
>
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/


-- 
Mathieu Saby
Service d'Informatique Documentaire
Service Commun de Documentation
Universit? Rennes 2
T?l?phone : 02 99 14 12 65
Courriel : mathieu.saby at univ-rennes2.fr

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131024/37f5b601/attachment.html>

From paul.a at navalmarinearchive.com  Fri Oct 25 00:20:02 2013
From: paul.a at navalmarinearchive.com (Naval Marine Archive)
Date: Thu, 24 Oct 2013 18:20:02 -0400
Subject: [Koha-devel] OPAC theme defaults for 3.14
In-Reply-To: <52698833.3070705@catalyst.net.nz>
References: <5.2.1.1.2.20131024134343.04c34a68@pop.navalmarinearchive.com>
	<5.2.1.1.2.20131024134343.04c34a68@pop.navalmarinearchive.com>
Message-ID: <5.2.1.1.2.20131024175806.04c34a68@pop.navalmarinearchive.com>

At 09:50 AM 10/25/2013 +1300, Robin Sheat wrote:
>op 25-10-13 08:35, Naval Marine Archive schreef:
> > I'm not sure what exactly is meant by "bootstrap" in the Koha context
>Bootstrap is a web framework that makes it easy to make responsive (i.e.
>works seamlessly on mobile and desktop browsers) websites.
>see http://responsive.mykoha.co.nz/ for an example.

Many thanks Robin -- but if you compare your example with our 
<http://opac.navalmarinearchive.com/> (and possibly click to our "home" 
page, etc, in the left column, which have the same header and "feel") I 
think you'll understand why I'm looking for the background code differences 
and philosophy...

>see https://www.google.com/search?q=bootstrap for more general
>information about it.

I'd already done that (perhaps not exhaustively) and found bootstrap.zip 
from the Apache foundation, developed for?/by? twitterers which has a .css 
file way over 100 kB -- that was why I mentioned that the [extensive] .yui 
css file is giving grief [1]. I just get the impression that well written 
templates with shorter css could probably meet at least 99.9% of all OPAC 
needs.

Is there something that my "KISS attitude" is missing?

I'd also add that I'm experimenting with LDAP logins to https on Apache 
2.4, and that "external" files (like .yui) are painful; you lose the 
security aspects covered by your own certificate. This is another reason 
for my KISS approach.

[1] Try 
<http://jigsaw.w3.org/css-validator/validator?uri=http%3A%2F%2Fopac.navalmarinearchive.com%2Fcgi-bin%2Fkoha%2Fopac-search.pl%3Fidx%3Dau%26q%3De&profile=css3&usermedium=all&warning=1&vextwarning=&lang=en>

Best - Paul 


From robin at catalyst.net.nz  Fri Oct 25 00:53:45 2013
From: robin at catalyst.net.nz (Robin Sheat)
Date: Fri, 25 Oct 2013 11:53:45 +1300
Subject: [Koha-devel] OPAC theme defaults for 3.14
In-Reply-To: <5.2.1.1.2.20131024175806.04c34a68@pop.navalmarinearchive.com>
References: <5.2.1.1.2.20131024134343.04c34a68@pop.navalmarinearchive.com>
	<5.2.1.1.2.20131024134343.04c34a68@pop.navalmarinearchive.com>
	<5.2.1.1.2.20131024175806.04c34a68@pop.navalmarinearchive.com>
Message-ID: <1382655225.27939.47.camel@zarathud>

Naval Marine Archive schreef op do 24-10-2013 om 18:20 [-0400]:
> Many thanks Robin -- but if you compare your example with our 
> <http://opac.navalmarinearchive.com/> (and possibly click to our "home" 
> page, etc, in the left column, which have the same header and "feel") I 
> think you'll understand why I'm looking for the background code differences 
> and philosophy...

It's a redesign of the whole thing to make it more maintainable, more
useful across devices, also hopefully easier to theme and removing
legacy cruft.

> I'd already done that (perhaps not exhaustively) and found bootstrap.zip 
> from the Apache foundation,

No you didn't. It's not associated with the Apache foundation in any way
at all, aside from using the Apache software license.

>  developed for?/by? twitterers 

http://en.wikipedia.org/wiki/Bootstrap_(front-end_framework)

"Bootstrap was developed by Mark Otto and Jacob Thornton at Twitter" ...
the wikipedia article is the fourth result for searching for me.

> which has a .css file way over 100 kB -- that was why I mentioned that the [extensive] .yui 

So? It'll get loaded once and then cached. It'll also gzip down to about
21k when being transferred.

> css file is giving grief [1]. I just get the impression that well written 
> templates with shorter css could probably meet at least 99.9% of all OPAC 
> needs.

Correlation isn't causation, a big CSS file doesn't mean things are bad.
YUI is also in the process of being phased out of Koha.

> Is there something that my "KISS attitude" is missing?

Yes, it adds a whole lot more work if you want to avoid things looking
like this:

http://ubuntuone.com/0KWjMx3mSPE1MnxGJxzkaE

when viewed on a phone, which more and more people do these days.

Additionally, if we build our own, then we're just reinventing the
wheel, and making ourselves need to implement things that are already
done better than we could probably do them in a reasonable timeframe. 

Not to mention browser testing, are you going to do that, or are you
going to go with something that is already known to work?

Don't even mention right-to-left support.

Basically your idea of "simple" means a lot more work for everyone in
order to get a much worse result.

> I'd also add that I'm experimenting with LDAP logins to https on Apache 
> 2.4, and that "external" files (like .yui) are painful; you lose the 
> security aspects covered by your own certificate. This is another reason 
> for my KISS approach.

No you don't. We run many Koha instances over HTTPS, and the only issue
(recently partially resolved) is book covers being fetched over HTTP,
therefore giving warnings about mixed content. If you have YUI resources
being fetched from another server, then change the syspref that controls
that. I'm somewhat sure serving them locally is the default.

-- 
Robin Sheat
Catalyst IT Ltd.
? +64 4 803 2204
GPG: 5FA7 4B49 1E4D CAA4 4C38  8505 77F5 B724 F871 3BDF
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131025/828a8e25/attachment.pgp>

From robin at catalyst.net.nz  Fri Oct 25 02:44:03 2013
From: robin at catalyst.net.nz (Robin Sheat)
Date: Fri, 25 Oct 2013 13:44:03 +1300
Subject: [Koha-devel] OPAC theme defaults for 3.14
In-Reply-To: <CAFpshE9sBP-4ngHyFcE2EJG65qgTu_t_81OZb-G2kWP2XadHJA@mail.gmail.com>
References: <CAPLnt66M2pyj=PV5bQ+EMCbsr+yUqngWukmW0M=Wjr5LcDH=4A@mail.gmail.com>
	<CAC0K6VG5M9R=9DUXCpqPA+VTmH7N6q7hgtUeK7OhkW=U7D5uLQ@mail.gmail.com>
	<CAO4qe2P+RG58Xg2D9+6fdGBU-og2=WbhQywQgHyofWDP5hbTBA@mail.gmail.com>
	<CAC0K6VFckpJ5KtRfSZdCKj2ySBEo+kV-9z6FwGhfHhfjLMpHmA@mail.gmail.com>
	<CAFpshE9sBP-4ngHyFcE2EJG65qgTu_t_81OZb-G2kWP2XadHJA@mail.gmail.com>
Message-ID: <1382661843.27939.51.camel@zarathud>

Joy Nelson schreef op do 24-10-2013 om 15:48 [-0500]:
> I agree with Nicole.  One release cycle is probably not adequate.

My feeling is that it might be better to have it for two cycles. One is
perhaps not enough to get everyone in line to get their theme updated,
finding budget for it, etc.

-- 
Robin Sheat
Catalyst IT Ltd.
? +64 4 803 2204
GPG: 5FA7 4B49 1E4D CAA4 4C38  8505 77F5 B724 F871 3BDF
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131025/0b724bae/attachment.pgp>

From z.tajoli at cineca.it  Fri Oct 25 09:47:37 2013
From: z.tajoli at cineca.it (Zeno Tajoli)
Date: Fri, 25 Oct 2013 09:47:37 +0200
Subject: [Koha-devel] OPAC theme defaults for 3.14
In-Reply-To: <CAPLnt66M2pyj=PV5bQ+EMCbsr+yUqngWukmW0M=Wjr5LcDH=4A@mail.gmail.com>
References: <CAPLnt66M2pyj=PV5bQ+EMCbsr+yUqngWukmW0M=Wjr5LcDH=4A@mail.gmail.com>
Message-ID: <526A2219.9070805@cineca.it>

Hi to all,

Il 24/10/2013 17:04, Galen Charlton ha scritto:
> Another point for discussion: I propose that the Bootstrap OPAC theme be
> made the installation default for 3.14, and that we announce deprecation
> of the prog and CCSR themes at the same time, with those themes to be
> removed (or split into separate packages, if somebody really wants to
> maintain one or both) in 3.16.

my position on the topic is:
-- Bootstrap OPAC theme as default in 3.14
-- Themes prog and CCSR deprecated from 3.14
-- Themes prog and CCSR deleted from 3.18 [two release cycle]

So there is more time to port opac costumixations.

Bye
Zeno Tajoli

-- 
Dr. Zeno Tajoli
Dipartimento Gestione delle Informazioni e della Conoscenza
z.tajoli at cineca.it
fax +39 02 2135520
CINECA - Sede operativa di Segrate

From M.de.Rooy at rijksmuseum.nl  Fri Oct 25 10:10:11 2013
From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy)
Date: Fri, 25 Oct 2013 08:10:11 +0000
Subject: [Koha-devel] Default indexing and search options for 3.14
In-Reply-To: <CAPLnt64ThLSDKSSYXVoWkrEK+W1C0Z0yzi0GQp8z=J-wyrY_cg@mail.gmail.com>
References: <CAPLnt64ThLSDKSSYXVoWkrEK+W1C0Z0yzi0GQp8z=J-wyrY_cg@mail.gmail.com>
Message-ID: <809BE39CD64BFD4EB9036172EBCCFA31164920C5@S-MAIL-1B.rijksmuseum.intra>

Hi,

Just a question on this topic:



Some time ago I tested the SRU server on ports 9998/9999 with Zebra/DOM, and at that time it would not work (rightaway, or as quick as it did with Zebra/GRS). (But I did not spend much time on sorting it out btw.) Any chance that someone can confirm that this problem has been resolved? (Are you working with it?) I think we should not deprecate GRS if this still needs more attention..



Marcel



________________________________
Van: koha-devel-bounces at lists.koha-community.org [koha-devel-bounces at lists.koha-community.org] namens Galen Charlton [gmc at esilibrary.com]
Verzonden: donderdag 24 oktober 2013 16:44
Aan: koha-devel at lists.koha-community.org
Onderwerp: [Koha-devel] Default indexing and search options for 3.14

Hi,

I would like to have a discussion regarding making certain options the default for new installations of Koha 3.14 and deprecating other options.  Here's the list of proposals:

Enable DOM mode by default for both bibs and authorities
-----------------------------------------------------------------------------------

Now that MARC21, NORMARC, and UNIMARC have DOM indexing configurations available, this is now possible.

Deprecating the GRS-1 filter
-----------------------------------------

Giving that DOM has significant advantages of GRS-1 in its flexibility, and as the DOM filter would be required for non-MARC metadata support by Zebra, I propose that we announce a deprecation of the GRS-1 configuration with it to be removed by 3.16.  I foresee several features coming down the pike for 3.16 that would require a reindexing during upgrade anyway, so switching to DOM for 3.16 would not impose a burden that wouldn't be present anyway.

Enable QueryParser by default
---------------------------------------------

Bug 10542 might be a blocker for this, and doing something about bug 10831 would be nice in order to do this.

Deprecating non-QueryParser mode
---------------------------------------------------

Removing the non-QueryParser code would go a long way towards easing the rewrite of C4::Search.

Enable ICU by default
-------------------------------

This was discussed during hackfest.  One precondition I see is that bug 10729 would have to pass QA

Regards,

Galen
--
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  gmc at esilibrary.com<mailto:gmc at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131025/a879098a/attachment.html>

From martin.renvoize at ptfs-europe.com  Fri Oct 25 10:23:58 2013
From: martin.renvoize at ptfs-europe.com (Martin Renvoize)
Date: Fri, 25 Oct 2013 09:23:58 +0100
Subject: [Koha-devel] OPAC theme defaults for 3.14
In-Reply-To: <526A2219.9070805@cineca.it>
References: <CAPLnt66M2pyj=PV5bQ+EMCbsr+yUqngWukmW0M=Wjr5LcDH=4A@mail.gmail.com>
	<526A2219.9070805@cineca.it>
Message-ID: <CAB7SL8BPGJ3Qi8XYy36P8sjXV20DtYZN27E-zetFj1V236BTjw@mail.gmail.com>

I'de agree with Zeno's timeframe.

That give's people time to port their customisation to the new theme
without adding too much work for the developers in coding for three theme's
simultaneously.  We, at PTFS Europe have been enabling CCSR by default for
new installs, and often 'upgrading' to CCSR during koha upgrades.  Not
everyone is going to suddenly be upgraded at the same time, so it shouldn't
be too harsh a problem to take OPAC customisations into account during an
upgrade.

As for Paul's comments, Robin has pretty much covered it.  Bootstrap is a
framework of well supported JS and CSS that we could not hope to create and
maintain for ourselves, not using one of these frameworks (Bootstrap,
Foundation) in the foreseeable future is just plain silly given the work it
takes to create fully responsive themes the meet current expectations.
 Using bootstrap is much more likely to pass tests than us reinventing the
wheel.

So.. all in all the bootstrap theme gets my vote!

Martin Renvoize
Software Engineer, PTFS Europe Ltd
Content Management and Library Solutions
Skype:
Landline: 0203 286 8685
Mobile: 07725985636

http://www.ptfs-europe.com


On 25 October 2013 08:47, Zeno Tajoli <z.tajoli at cineca.it> wrote:

> Hi to all,
>
> Il 24/10/2013 17:04, Galen Charlton ha scritto:
>
>  Another point for discussion: I propose that the Bootstrap OPAC theme be
>> made the installation default for 3.14, and that we announce deprecation
>> of the prog and CCSR themes at the same time, with those themes to be
>> removed (or split into separate packages, if somebody really wants to
>> maintain one or both) in 3.16.
>>
>
> my position on the topic is:
> -- Bootstrap OPAC theme as default in 3.14
> -- Themes prog and CCSR deprecated from 3.14
> -- Themes prog and CCSR deleted from 3.18 [two release cycle]
>
> So there is more time to port opac costumixations.
>
> Bye
> Zeno Tajoli
>
> --
> Dr. Zeno Tajoli
> Dipartimento Gestione delle Informazioni e della Conoscenza
> z.tajoli at cineca.it
> fax +39 02 2135520
> CINECA - Sede operativa di Segrate
>
> ______________________________**_________________
> Koha-devel mailing list
> Koha-devel at lists.koha-**community.org<Koha-devel at lists.koha-community.org>
> http://lists.koha-community.**org/cgi-bin/mailman/listinfo/**koha-devel<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/ <http://bugs.koha-community.org/>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131025/8b338c4f/attachment-0001.html>

From martin.renvoize at ptfs-europe.com  Fri Oct 25 10:37:30 2013
From: martin.renvoize at ptfs-europe.com (Martin Renvoize)
Date: Fri, 25 Oct 2013 09:37:30 +0100
Subject: [Koha-devel] Default indexing and search options for 3.14
In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA31164920C5@S-MAIL-1B.rijksmuseum.intra>
References: <CAPLnt64ThLSDKSSYXVoWkrEK+W1C0Z0yzi0GQp8z=J-wyrY_cg@mail.gmail.com>
	<809BE39CD64BFD4EB9036172EBCCFA31164920C5@S-MAIL-1B.rijksmuseum.intra>
Message-ID: <CAB7SL8BLM72ArxOOAj84+C7CU9gTCnpTc5g10CcnJPXCFsGUSg@mail.gmail.com>

DOM and ICU are definitely the newer technologies and have been built
explicitly to fix a number of shortcomings in GRS-1 and chr.

As Ian mentioned we have been slowly moving all our customers to using this
combination, and admittedly it has been a relatively painful process whilst
we iron out the various bugs.  However, for MARC21 at least, most of these
are now fixed, and trying to support both sets of configs is only going to
be a burden in the future.  Whilst we support the both DOM and GRS-1 we
will inevitably keep getting the configurations are out of sync, and should
we try to keep them in sync we will be limiting the DOM config with the
limitations of GRS-1.

My vote is to make the move to DOM with ICU, advocating that getting it
right once is much easier than trying to maintain two disparate
configurations.

Martin Renvoize
Software Engineer, PTFS Europe Ltd
Content Management and Library Solutions
Skype:
Landline: 0203 286 8685
Mobile: 07725985636

http://www.ptfs-europe.com


On 25 October 2013 09:10, Marcel de Rooy <M.de.Rooy at rijksmuseum.nl> wrote:

>  Hi,
>
> Just a question on this topic:
>
>
>
> Some time ago I tested the SRU server on ports 9998/9999 with Zebra/DOM,
> and at that time it would not work (rightaway, or as quick as it did with
> Zebra/GRS). (But I did not spend much time on sorting it out btw.) Any
> chance that someone can confirm that this problem has been resolved? (Are
> you working with it?) I think we should not deprecate GRS if this still
> needs more attention..
>
>
>
> Marcel
>
>
>  ------------------------------
> *Van:* koha-devel-bounces at lists.koha-community.org [
> koha-devel-bounces at lists.koha-community.org] namens Galen Charlton [
> gmc at esilibrary.com]
> *Verzonden:* donderdag 24 oktober 2013 16:44
> *Aan:* koha-devel at lists.koha-community.org
> *Onderwerp:* [Koha-devel] Default indexing and search options for 3.14
>
>   Hi,
>
>  I would like to have a discussion regarding making certain options the
> default for new installations of Koha 3.14 and deprecating other options.
>  Here's the list of proposals:
>
>  Enable DOM mode by default for both bibs and authorities
>
> -----------------------------------------------------------------------------------
>
>  Now that MARC21, NORMARC, and UNIMARC have DOM indexing configurations
> available, this is now possible.
>
>  Deprecating the GRS-1 filter
> -----------------------------------------
>
>  Giving that DOM has significant advantages of GRS-1 in its flexibility,
> and as the DOM filter would be required for non-MARC metadata support by
> Zebra, I propose that we announce a deprecation of the GRS-1 configuration
> with it to be removed by 3.16.  I foresee several features coming down the
> pike for 3.16 that would require a reindexing during upgrade anyway, so
> switching to DOM for 3.16 would not impose a burden that wouldn't be
> present anyway.
>
>  Enable QueryParser by default
> ---------------------------------------------
>
>  Bug 10542 might be a blocker for this, and doing something about
> bug 10831 would be nice in order to do this.
>
>  Deprecating non-QueryParser mode
> ---------------------------------------------------
>
>  Removing the non-QueryParser code would go a long way towards easing the
> rewrite of C4::Search.
>
>  Enable ICU by default
> -------------------------------
>
>  This was discussed during hackfest.  One precondition I see is that bug
> 10729 would have to pass QA
>
>  Regards,
>
> Galen
> --
>  Galen Charlton
> Manager of Implementation
> Equinox Software, Inc. / The Open Source Experts
> email:  gmc at 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
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131025/478943d9/attachment.html>

From colin.campbell at ptfs-europe.com  Fri Oct 25 11:10:08 2013
From: colin.campbell at ptfs-europe.com (Colin Campbell)
Date: Fri, 25 Oct 2013 10:10:08 +0100
Subject: [Koha-devel] Default indexing and search options for 3.14
In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA31164920C5@S-MAIL-1B.rijksmuseum.intra>
References: <CAPLnt64ThLSDKSSYXVoWkrEK+W1C0Z0yzi0GQp8z=J-wyrY_cg@mail.gmail.com>
	<809BE39CD64BFD4EB9036172EBCCFA31164920C5@S-MAIL-1B.rijksmuseum.intra>
Message-ID: <20131025091008.GA12328@zazou.cscnet.co.uk>

On Fri, Oct 25, 2013 at 08:10:11AM +0000, Marcel de Rooy wrote:
> 
> Some time ago I tested the SRU server on ports 9998/9999 with Zebra/DOM, and at that time it would not work
Anybody using SRU might want to take a look at indexdata's site. A new
version of yaz has been released which supports a different (possibly
incompatible) version of SRU. Not sure what implications this may have
Colin

-- 
Colin Campbell
Chief Software Engineer,
PTFS Europe Limited
Content Management and Library Solutions
+44 (0) 800 756 6803 (phone)
+44 (0) 7759 633626  (mobile)
colin.campbell at ptfs-europe.com
skype: colin_campbell2

http://www.ptfs-europe.com

From fridolyn.somers at biblibre.com  Fri Oct 25 11:58:43 2013
From: fridolyn.somers at biblibre.com (Fridolyn SOMERS)
Date: Fri, 25 Oct 2013 11:58:43 +0200
Subject: [Koha-devel] error circulation
In-Reply-To: <CA+VrnetCfB6oZk3vh5Y8pEVEVDUnRzit+VVQ52MwurMY6kZzrg@mail.gmail.com>
References: <CA+VrnetCfB6oZk3vh5Y8pEVEVDUnRzit+VVQ52MwurMY6kZzrg@mail.gmail.com>
Message-ID: <526A40D3.10009@biblibre.com>

Hie,

You may do the reconfiguration of debian package 'tzdata' :
https://wiki.debian.org/TimeZoneChanges

Le 15/10/2013 02:26, Carlos Rodrigo Cordova Sandoval a ?crit :
> Hello,
>
> I am using koha 3.8.10.2 and I have problems when I return a book gives the
> following message:
>
> screenshot:
>
> http://snag.gy/Rio25.jpg
>
>
> and the apache log is:
>
> [Mon Oct 14 21:17:27 2013] [error] [client 186.105.227.88] [Mon Oct 14
> 21:17:27 2013] returns.pl: Invalid local time for date in time zone:
> America/Santiago, referer:
> http://catalogo.ipciisa.cl:8080/cgi-bin/koha/mainpage.pl
>
>
>
> thank you very much.
>
> -Carlos
>
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/
>

-- 
Fridolyn SOMERS
Biblibre - P?le support
fridolyn.somers at biblibre.com

From philippe.blouin at inLibro.com  Fri Oct 25 13:23:05 2013
From: philippe.blouin at inLibro.com (Philippe Blouin)
Date: Fri, 25 Oct 2013 07:23:05 -0400
Subject: [Koha-devel] Acquisitions - taxes and friends (if any)
In-Reply-To: <526A40D3.10009@biblibre.com>
References: <CA+VrnetCfB6oZk3vh5Y8pEVEVDUnRzit+VVQ52MwurMY6kZzrg@mail.gmail.com>
	<526A40D3.10009@biblibre.com>
Message-ID: <526A5499.4000709@inLibro.com>

Hol? Koha,

I know the experts on Acquisitions are rare and far in-between, but we 
got and issue here with the way the taxes are calculated _before 
applying shipping charges_.

I talked with Paul Poulain about it (before you refer me to him), and it 
seems that in France as well, taxes should apply on shipping.

*My question*: is there any place where the shipping is untaxed?

Because I'd like to determine the easiest and cleanest way to fix it.
1) if taxes should always apply on shipping, just fix the code (and the 
invoice presentation)
2) otherwise, if a majority apply the tax (if any) on shipping, but not 
all, make it some system preference (and find a way to make it cute in 
the invoice)
3) If there are convoluted ways to apply taxes around the world (_that 
uses koha-acquisition_ :)), see how we can satisfy everybody.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131025/3d739029/attachment.html>

From philippe.blouin at inLibro.com  Fri Oct 25 13:54:23 2013
From: philippe.blouin at inLibro.com (Philippe Blouin)
Date: Fri, 25 Oct 2013 07:54:23 -0400
Subject: [Koha-devel] OPAC theme defaults for 3.14
In-Reply-To: <CAB7SL8BPGJ3Qi8XYy36P8sjXV20DtYZN27E-zetFj1V236BTjw@mail.gmail.com>
References: <CAPLnt66M2pyj=PV5bQ+EMCbsr+yUqngWukmW0M=Wjr5LcDH=4A@mail.gmail.com>
	<526A2219.9070805@cineca.it>
	<CAB7SL8BPGJ3Qi8XYy36P8sjXV20DtYZN27E-zetFj1V236BTjw@mail.gmail.com>
Message-ID: <526A5BEF.4090503@inLibro.com>

The timeframe is all good for deprecation, but what about the immediate 
issues?
For us, it's the first time we hear that this move is coming so we've 
been developping and contributing on the /prog/ branch solely.

What is the plan for the discrepencies already in?
What is the plan for the changes in wait of sign-off (or push) ?

A short, immediate pain is prefered to a long, drawn, endless itching... :)




On 13-10-25 04:23 AM, Martin Renvoize wrote:
> I'de agree with Zeno's timeframe.
>
> That give's people time to port their customisation to the new theme 
> without adding too much work for the developers in coding for three 
> theme's simultaneously.  We, at PTFS Europe have been enabling CCSR by 
> default for new installs, and often 'upgrading' to CCSR during koha 
> upgrades.  Not everyone is going to suddenly be upgraded at the same 
> time, so it shouldn't be too harsh a problem to take OPAC 
> customisations into account during an upgrade.
>
> As for Paul's comments, Robin has pretty much covered it.  Bootstrap 
> is a framework of well supported JS and CSS that we could not hope to 
> create and maintain for ourselves, not using one of these frameworks 
> (Bootstrap, Foundation) in the foreseeable future is just plain silly 
> given the work it takes to create fully responsive themes the meet 
> current expectations.  Using bootstrap is much more likely to pass 
> tests than us reinventing the wheel.
>
> So.. all in all the bootstrap theme gets my vote!
>
> Martin Renvoize
> Software Engineer, PTFS Europe Ltd
> Content Management and Library Solutions
> Skype:
> Landline: 0203 286 8685
> Mobile: 07725985636
>
> http://www.ptfs-europe.com
>
>
> On 25 October 2013 08:47, Zeno Tajoli <z.tajoli at cineca.it 
> <mailto:z.tajoli at cineca.it>> wrote:
>
>     Hi to all,
>
>     Il 24/10/2013 17:04, Galen Charlton ha scritto:
>
>         Another point for discussion: I propose that the Bootstrap
>         OPAC theme be
>         made the installation default for 3.14, and that we announce
>         deprecation
>         of the prog and CCSR themes at the same time, with those
>         themes to be
>         removed (or split into separate packages, if somebody really
>         wants to
>         maintain one or both) in 3.16.
>
>
>     my position on the topic is:
>     -- Bootstrap OPAC theme as default in 3.14
>     -- Themes prog and CCSR deprecated from 3.14
>     -- Themes prog and CCSR deleted from 3.18 [two release cycle]
>
>     So there is more time to port opac costumixations.
>
>     Bye
>     Zeno Tajoli
>
>     -- 
>     Dr. Zeno Tajoli
>     Dipartimento Gestione delle Informazioni e della Conoscenza
>     z.tajoli at cineca.it <mailto:z.tajoli at cineca.it>
>     fax +39 02 2135520 <tel:%2B39%2002%202135520>
>     CINECA - Sede operativa di Segrate
>
>     _______________________________________________
>     Koha-devel mailing list
>     Koha-devel at lists.koha-community.org
>     <mailto:Koha-devel at 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/
>
>
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/

-- 
Philippe Blouin,
Responsable du d?veloppement informatique

T?l.  : (888) 604-2627
philippe.blouin at inLibro.com <mailto:philippe.blouin at inLibro.com>

inLibro | pour esprit libre | www.inLibro.com <http://www.inLibro.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131025/92f30983/attachment.html>

From oleonard at myacpl.org  Fri Oct 25 14:21:50 2013
From: oleonard at myacpl.org (Owen Leonard)
Date: Fri, 25 Oct 2013 08:21:50 -0400
Subject: [Koha-devel] OPAC theme defaults for 3.14
In-Reply-To: <526A5BEF.4090503@inLibro.com>
References: <CAPLnt66M2pyj=PV5bQ+EMCbsr+yUqngWukmW0M=Wjr5LcDH=4A@mail.gmail.com>
	<526A2219.9070805@cineca.it>
	<CAB7SL8BPGJ3Qi8XYy36P8sjXV20DtYZN27E-zetFj1V236BTjw@mail.gmail.com>
	<526A5BEF.4090503@inLibro.com>
Message-ID: <7E81F678-0C32-4BBC-8642-CCD9AAF90C8A@myacpl.org>

> The timeframe is all good for deprecation, but what about the immediate issues?

I hope everyone understands that a new default theme would *only* affect new installations, and that the old themes would continue to be maintained and available until the agreed deprecation time. 

We have worked with two available themes for a while now. We can work with three for as long as necessary. I just hope it not necessary for long. 

 -- Owen

-- 
Web Developer
Athens County Public Libraries
http://www.myacpl.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131025/5d747cbb/attachment.html>

From joy at bywatersolutions.com  Fri Oct 25 14:46:19 2013
From: joy at bywatersolutions.com (Joy Nelson)
Date: Fri, 25 Oct 2013 07:46:19 -0500
Subject: [Koha-devel] Acquisitions - taxes and friends (if any)
In-Reply-To: <526A5499.4000709@inLibro.com>
References: <CA+VrnetCfB6oZk3vh5Y8pEVEVDUnRzit+VVQ52MwurMY6kZzrg@mail.gmail.com>
	<526A40D3.10009@biblibre.com> <526A5499.4000709@inLibro.com>
Message-ID: <CAFpshE-qC1a-u7YaFoX=bipo02yHcopB06PEQcRcbmBpzvPJJA@mail.gmail.com>

Phillipe-
I can tell you in Texas, (and a few other US states I checked) tax is
charged on shipping as well as the item purchased.

-Joy


On Fri, Oct 25, 2013 at 6:23 AM, Philippe Blouin <
philippe.blouin at inlibro.com> wrote:

>  Hol? Koha,
>
> I know the experts on Acquisitions are rare and far in-between, but we got
> and issue here with the way the taxes are calculated *before applying
> shipping charges*.
>
> I talked with Paul Poulain about it (before you refer me to him), and it
> seems that in France as well, taxes should apply on shipping.
>
> *My question*: is there any place where the shipping is untaxed?
>
> Because I'd like to determine the easiest and cleanest way to fix it.
> 1) if taxes should always apply on shipping, just fix the code (and the
> invoice presentation)
> 2) otherwise, if a majority apply the tax (if any) on shipping, but not
> all, make it some system preference (and find a way to make it cute in the
> invoice)
> 3) If there are convoluted ways to apply taxes around the world (*that
> uses koha-acquisition* :)), see how we can satisfy everybody.
>
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/
>



-- 
Joy Nelson
Director of Migrations

ByWater Solutions <http://bywatersolutions.com>
Support and Consulting for Open Source Software
**Office: Fort Worth, TX
Phone/Fax (888)900-8944
What is Koha? <http://bywatersolutions.com/what-is-koha/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131025/2e271d7c/attachment-0001.html>

From philippe.blouin at inLibro.com  Fri Oct 25 15:01:44 2013
From: philippe.blouin at inLibro.com (Philippe Blouin)
Date: Fri, 25 Oct 2013 09:01:44 -0400
Subject: [Koha-devel] OPAC theme defaults for 3.14
In-Reply-To: <7E81F678-0C32-4BBC-8642-CCD9AAF90C8A@myacpl.org>
References: <CAPLnt66M2pyj=PV5bQ+EMCbsr+yUqngWukmW0M=Wjr5LcDH=4A@mail.gmail.com>
	<526A2219.9070805@cineca.it>
	<CAB7SL8BPGJ3Qi8XYy36P8sjXV20DtYZN27E-zetFj1V236BTjw@mail.gmail.com>
	<526A5BEF.4090503@inLibro.com>
	<7E81F678-0C32-4BBC-8642-CCD9AAF90C8A@myacpl.org>
Message-ID: <526A6BB8.60405@inLibro.com>

Hi,
> I hope everyone understands that a new default theme would *only* 
> affect new installations, and that the old themes would continue to be 
> maintained and available until the agreed deprecation time.
>
> We have worked with two available themes for a while now. We can work 
> with three for as long as necessary. I just hope it not necessary for 
> long.
That's the thing, I got fixes in the pipeline that only modify the 
/prog/ path.  Will I need to redo them all for the other path?  How has 
the RM been managing these situations in 3.13->3.14 ?

And for the future, if I hear that bootstrap is THE solution, we'll code 
only for it, and offer only bootstrapt fixes for the master. Mind you, I 
don't even know how different is bootstrap code from /prog/, but a +20% 
in dev time + doubling the testing time (very rough estimate) to get two 
paths out can kill our community budget, so maintaining two versions it 
probably out of our reach for us.

In short, I do not worry about our installations.  We'll redo all our 
libraries css, etc... (ok, yeah, it's a pain :)), but I would like some 
clarification on the community work and the difference in feature/fix 
between the three versions in the short future.

Best regards,
Blou



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131025/c88bae39/attachment.html>

From oleonard at myacpl.org  Fri Oct 25 15:48:18 2013
From: oleonard at myacpl.org (Owen Leonard)
Date: Fri, 25 Oct 2013 09:48:18 -0400
Subject: [Koha-devel] OPAC theme defaults for 3.14
In-Reply-To: <526A6BB8.60405@inLibro.com>
References: <CAPLnt66M2pyj=PV5bQ+EMCbsr+yUqngWukmW0M=Wjr5LcDH=4A@mail.gmail.com>
	<526A2219.9070805@cineca.it>
	<CAB7SL8BPGJ3Qi8XYy36P8sjXV20DtYZN27E-zetFj1V236BTjw@mail.gmail.com>
	<526A5BEF.4090503@inLibro.com>
	<7E81F678-0C32-4BBC-8642-CCD9AAF90C8A@myacpl.org>
	<526A6BB8.60405@inLibro.com>
Message-ID: <CAO4qe2O-vfa8637G3qNgUQ_miBNRLxhmY=kfavivekBZO9D26w@mail.gmail.com>

> That's the thing, I got fixes in the pipeline that only modify the /prog/
> path.  Will I need to redo them all for the other path?  How has the RM been
> managing these situations in 3.13->3.14 ?

If you've only been modifying the prog theme in the OPAC then chances
are you've left work for someone else to modify the CCSR template.
That's okay, it happens. Someone else usually picks up the slack.
That's the way it has worked in the past and that's the way it will
work in the future.

If you know of a divergence between prog and bootstrap, or prog and
CCSR, file a bug!

  -- Owen

-- 
Web Developer
Athens County Public Libraries
http://www.myacpl.org

From paul.a at navalmarinearchive.com  Sat Oct 26 17:33:35 2013
From: paul.a at navalmarinearchive.com (Paul A)
Date: Sat, 26 Oct 2013 11:33:35 -0400
Subject: [Koha-devel] 245$c in OPAC
Message-ID: <5.2.1.1.2.20131026112501.01ca7070@stormy.ca>

Is Bug 9490 - "Show responsibility statement (245c) under title and move 
authors down in OPAC XSLT" the best (only?) way to go?

Or is there a "quick" (js?) way to show MARC 245$s (statement of 
responsibility) in the OPAC "normal view"?  [Koha 3.8.5]

It's a request from our cataloguers who held a "Koha workshop" with a 
number of users (university profs and students) earlier this 
week.  Marcel's proposal seems to fit the requirement perfectly.

Thanks and br,
Paul


From karamqubsi at gmail.com  Mon Oct 28 06:01:10 2013
From: karamqubsi at gmail.com (Karam Qubsi)
Date: Mon, 28 Oct 2013 13:01:10 +0800
Subject: [Koha-devel] About cloning from GitHub
Message-ID: <CAML=htYNTbbWsEh3QcW2ua+E59hZnwrN_aMMbwDEdi4FAGttOw@mail.gmail.com>

Hi ,
I tried to clone from
git clone git://git.koha-community.org/koha.git
but it gave me the following error :
174.143.233.17[0: 174.143.233.17]: errno=Connection refused

Maybe port 9418 is blocked in my workplace anyway I cloned from github :

 git clone https://github.com/colinsc/koha.git


it's cloning now

Is it OK to clone from github ? or it's not Sync ?


many thanks :) .

-- 
*Karam Qubsi*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131028/4bc06d60/attachment.html>

From chris at bigballofwax.co.nz  Mon Oct 28 07:29:54 2013
From: chris at bigballofwax.co.nz (Chris Cormack)
Date: Sun, 27 Oct 2013 23:29:54 -0700
Subject: [Koha-devel] Bugzilla update, git bz attach no longer working
Message-ID: <CA+95qVRrKXXAv9V61vBBwXjSyPvF1HytCoDpq9d-xXcQmahDoQ@mail.gmail.com>

There was another security issue with bugzilla that has been fixed,
unfortunately it was a CSRF issue, which has meant that git bz needs
to be updated to deal with tokens better.

Until git-bz is fixed, the attach will no longer work

Chris

From z.tajoli at cineca.it  Mon Oct 28 12:43:46 2013
From: z.tajoli at cineca.it (Zeno Tajoli)
Date: Mon, 28 Oct 2013 12:43:46 +0100
Subject: [Koha-devel] Bug 10454, mysqlism to insert support to sequences
Message-ID: <526E4DF2.6090707@cineca.it>

Hi to all,

I write this mail to revamp the discussion about bug 10454 and to have 
more clear idea about MySQLism, Postgresism and DBIx::xxx

As I can  see  DBIx::xx is the ORM select for support different DB.
As I know DBIx::xxx doesn't cover the problem of sequences, so we still
need something like Koha::Sequence.pm.

I think it is mandatory to use inside it MySQLism, Postgresism, etc.
In fact it will became an 'ORM' for sequnces

So to improve it I need something that says me if I use MySQL, Postgres, 
etc.

What do you think about use C4::Context->db_scheme2dbi ?

Cheers
Zeno Tajoli
-- 
Dr. Zeno Tajoli
Dipartimento Gestione delle Informazioni e della Conoscenza
z.tajoli at cineca.it
fax +39 02 2135520
CINECA - Sede operativa di Segrate

From gmc at esilibrary.com  Mon Oct 28 18:16:10 2013
From: gmc at esilibrary.com (Galen Charlton)
Date: Mon, 28 Oct 2013 10:16:10 -0700
Subject: [Koha-devel] OPAC theme defaults for 3.14
In-Reply-To: <526A6BB8.60405@inLibro.com>
References: <CAPLnt66M2pyj=PV5bQ+EMCbsr+yUqngWukmW0M=Wjr5LcDH=4A@mail.gmail.com>
	<526A2219.9070805@cineca.it>
	<CAB7SL8BPGJ3Qi8XYy36P8sjXV20DtYZN27E-zetFj1V236BTjw@mail.gmail.com>
	<526A5BEF.4090503@inLibro.com>
	<7E81F678-0C32-4BBC-8642-CCD9AAF90C8A@myacpl.org>
	<526A6BB8.60405@inLibro.com>
Message-ID: <CAPLnt65hoEYBdfBnfxseEzWnw2K6yd6bUkLpVsJTH2Cp22nenw@mail.gmail.com>

Hi,

On Fri, Oct 25, 2013 at 6:01 AM, Philippe Blouin <
philippe.blouin at inlibro.com> wrote:

> I hope everyone understands that a new default theme would *only* affect
> new installations, and that the old themes would continue to be maintained
> and available until the agreed deprecation time.
>
> We have worked with two available themes for a while now. We can work with
> three for as long as necessary. I just hope it not necessary for long.
>
> That's the thing, I got fixes in the pipeline that only modify the /prog/
> path.  Will I need to redo them all for the other path?  How has the RM
> been managing these situations in 3.13->3.14 ?
>

Thus far I have been writing and pushing follow-ups patches in cases where
it was obvious how a patch written for prog should be applied to the
Bootstrap theme.  If a patch is too complicated to do that, most of the
time I will push the prog patch and open a bug for the corresponding change
to be made for Bootstrap.  However, I anticipate that during the 3.16 cycle
there may be cases where a major piece of functionality added to prog may
need to be held back until a Bootstrap implementation is available,
although I will assist in minimizing the number of times that happens.


> And for the future, if I hear that bootstrap is THE solution, we'll code
> only for it, and offer only bootstrapt fixes for the master.  Mind you, I
> don't even know how different is bootstrap code from /prog/, but a +20% in
> dev time + doubling the testing time (very rough estimate) to get two paths
> out can kill our community budget, so maintaining two versions it probably
> out of our reach for us.
>

For new work, I recommend coding for Bootstrap first.

Regards,

Galen
--
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  gmc at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131028/92e5ce46/attachment.html>

From gmc at esilibrary.com  Mon Oct 28 18:32:18 2013
From: gmc at esilibrary.com (Galen Charlton)
Date: Mon, 28 Oct 2013 10:32:18 -0700
Subject: [Koha-devel] OPAC theme proposal
Message-ID: <CAPLnt66_e5Zw3osow5vH-8zz5Zj62Z1jwPjfzkMEUAmiF8a5SQ@mail.gmail.com>

Hi,

Based on the feedback received last week, here is my current proposal for
managing the OPAC themes:

[1] We ship Bootstrap as the default theme for 3.14 for new installations.
[2] We announce deprecation of prog and CCSR when 3.14 is released and
issue a recommendation that libraries start switching to Bootstrap.
[3] At the same time, we announce that prog and CCSR will be removed in
3.18.  If some organization wishes to maintain either theme after then,
they can do so, but as a separate contrib.  However, if you are inclined to
support either theme after they've been removed ... please think carefully
about the amount of work that would entail.
[4] The RM will assist in getting OPAC template patches in the pipeline
that were written for prog updated to support Bootstrap as well.
[5] Starting with the 3.16, new OPAC patches should be targeted for
Bootstrap first.  During the 3.16 cycle, contributors are requested to make
an effort to update the prog theme as well, particularly for new features,
but this is a request, not a requirement.  In other words, this means that
for 3.16, libraries may need to switch to Bootstrap to take full advantage
of new OPAC functionality, but the prog theme will continue to be
functional.
[6] During the 3.18 cycle, no patches will be pushed for prog except
insofar as they may be needed to fix security issues in the maintenance
releases.  Before 3.18 is released, prog and CCSR will be taken out
entirely.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  gmc at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131028/6bda2040/attachment.html>

From mtompset at hotmail.com  Mon Oct 28 18:41:30 2013
From: mtompset at hotmail.com (Mark Tompsett)
Date: Mon, 28 Oct 2013 13:41:30 -0400
Subject: [Koha-devel] OPAC theme proposal
In-Reply-To: <CAPLnt66_e5Zw3osow5vH-8zz5Zj62Z1jwPjfzkMEUAmiF8a5SQ@mail.gmail.com>
References: <CAPLnt66_e5Zw3osow5vH-8zz5Zj62Z1jwPjfzkMEUAmiF8a5SQ@mail.gmail.com>
Message-ID: <BLU172-DS207D31DB4D555DAF65815C6080@phx.gbl>

Greetings,

What if 3.18 was 4.0 (or 5.0)? At some point we need to increment the major number, and the full drop of prog/CCSR and defaulting of Bootstrap seems like a good enough reason.

GPML,
Mark Tompsett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131028/d26d5ea0/attachment.html>

From gmc at esilibrary.com  Mon Oct 28 18:47:50 2013
From: gmc at esilibrary.com (Galen Charlton)
Date: Mon, 28 Oct 2013 10:47:50 -0700
Subject: [Koha-devel] OPAC theme proposal
In-Reply-To: <BLU172-DS207D31DB4D555DAF65815C6080@phx.gbl>
References: <CAPLnt66_e5Zw3osow5vH-8zz5Zj62Z1jwPjfzkMEUAmiF8a5SQ@mail.gmail.com>
	<BLU172-DS207D31DB4D555DAF65815C6080@phx.gbl>
Message-ID: <CAPLnt649S44Oio_2Pryeuo8T75_oKq1NJ8gUn765nAP-E5Bohw@mail.gmail.com>

Hi,

On Mon, Oct 28, 2013 at 10:41 AM, Mark Tompsett <mtompset at hotmail.com>wrote:
>
> What if 3.18 was 4.0 (or 5.0)? At some point we need to increment the
> major number, and the full drop of prog/CCSR and defaulting of Bootstrap
> seems like a good enough reason.
>

What the version happens to be called does not affect the substance of the
proposal.  For 3.16, you can read it as "the next major release after
3.14"; for 3.18, you can read it as "the second major release after 3.14".
 The wording for any public announcements can be made suitably vague as to
what the version number or monikers will be.

At this point I am going to be dictatorial and assert that what the
versions are called is off-topic for this particular email thread.  If a
discussion of version numbering is warranted, it should go in a separate
thread.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  gmc at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131028/8ad8d896/attachment-0001.html>

From chris at bigballofwax.co.nz  Mon Oct 28 18:56:23 2013
From: chris at bigballofwax.co.nz (Chris Cormack)
Date: Mon, 28 Oct 2013 10:56:23 -0700
Subject: [Koha-devel] OPAC theme proposal
In-Reply-To: <CAPLnt649S44Oio_2Pryeuo8T75_oKq1NJ8gUn765nAP-E5Bohw@mail.gmail.com>
References: <CAPLnt66_e5Zw3osow5vH-8zz5Zj62Z1jwPjfzkMEUAmiF8a5SQ@mail.gmail.com>
	<BLU172-DS207D31DB4D555DAF65815C6080@phx.gbl>
	<CAPLnt649S44Oio_2Pryeuo8T75_oKq1NJ8gUn765nAP-E5Bohw@mail.gmail.com>
Message-ID: <CA+95qVQkm10iuViJUkKoaQGKprh8-p_dBBgeR7q+x+3PeA601w@mail.gmail.com>

On 29/10/2013 6:47 AM, "Galen Charlton" <gmc at esilibrary.com> wrote:
>
> Hi,
>
> On Mon, Oct 28, 2013 at 10:41 AM, Mark Tompsett <mtompset at hotmail.com>
wrote:
>>
>> What if 3.18 was 4.0 (or 5.0)? At some point we need to increment the
major number, and the full drop of prog/CCSR and defaulting of Bootstrap
seems like a good enough reason.
>
>
> What the version happens to be called does not affect the substance of
the proposal.  For 3.16, you can read it as "the next major release after
3.14"; for 3.18, you can read it as "the second major release after 3.14".
 The wording for any public announcements can be made suitably vague as to
what the version number or monikers will be.
>
> At this point I am going to be dictatorial and assert that what the
versions are called is off-topic for this particular email thread.  If a
discussion of version numbering is warranted, it should go in a separate
thread.
>

+1

Also blue.

Chris
> Regards,
>
> Galen
> --
> Galen Charlton
> Manager of Implementation
> Equinox Software, Inc. / The Open Source Experts
> email:  gmc at 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
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131028/0d25a265/attachment.html>

From chris at bigballofwax.co.nz  Mon Oct 28 19:06:16 2013
From: chris at bigballofwax.co.nz (Chris Cormack)
Date: Mon, 28 Oct 2013 11:06:16 -0700
Subject: [Koha-devel] OPAC theme proposal
In-Reply-To: <CAPLnt66_e5Zw3osow5vH-8zz5Zj62Z1jwPjfzkMEUAmiF8a5SQ@mail.gmail.com>
References: <CAPLnt66_e5Zw3osow5vH-8zz5Zj62Z1jwPjfzkMEUAmiF8a5SQ@mail.gmail.com>
Message-ID: <CA+95qVQANMbS2cfSaOYy_3HRr=-eyZTFVDfpqTdm4One61BkvQ@mail.gmail.com>

On 28 October 2013 10:32, Galen Charlton <gmc at esilibrary.com> wrote:
> Hi,
>
> Based on the feedback received last week, here is my current proposal for
> managing the OPAC themes:
>
> [1] We ship Bootstrap as the default theme for 3.14 for new installations.
> [2] We announce deprecation of prog and CCSR when 3.14 is released and issue
> a recommendation that libraries start switching to Bootstrap.
> [3] At the same time, we announce that prog and CCSR will be removed in
> 3.18.  If some organization wishes to maintain either theme after then, they
> can do so, but as a separate contrib.  However, if you are inclined to
> support either theme after they've been removed ... please think carefully
> about the amount of work that would entail.
> [4] The RM will assist in getting OPAC template patches in the pipeline that
> were written for prog updated to support Bootstrap as well.
> [5] Starting with the 3.16, new OPAC patches should be targeted for
> Bootstrap first.  During the 3.16 cycle, contributors are requested to make
> an effort to update the prog theme as well, particularly for new features,
> but this is a request, not a requirement.  In other words, this means that
> for 3.16, libraries may need to switch to Bootstrap to take full advantage
> of new OPAC functionality, but the prog theme will continue to be
> functional.
> [6] During the 3.18 cycle, no patches will be pushed for prog except insofar
> as they may be needed to fix security issues in the maintenance releases.
> Before 3.18 is released, prog and CCSR will be taken out entirely.
>
>
Ooops in the midst of being derailed by a version numbering question,
I missed actually adding my support for the proposal
So
+1 for this scheme from me

Chris

From Katrin.Fischer.83 at web.de  Mon Oct 28 19:25:21 2013
From: Katrin.Fischer.83 at web.de (Katrin Fischer)
Date: Mon, 28 Oct 2013 19:25:21 +0100
Subject: [Koha-devel] OPAC theme proposal
In-Reply-To: <CA+95qVQANMbS2cfSaOYy_3HRr=-eyZTFVDfpqTdm4One61BkvQ@mail.gmail.com>
References: <CAPLnt66_e5Zw3osow5vH-8zz5Zj62Z1jwPjfzkMEUAmiF8a5SQ@mail.gmail.com>
	<CA+95qVQANMbS2cfSaOYy_3HRr=-eyZTFVDfpqTdm4One61BkvQ@mail.gmail.com>
Message-ID: <526EAC11.1050900@web.de>

Am 28.10.2013 19:06, schrieb Chris Cormack:
> On 28 October 2013 10:32, Galen Charlton <gmc at esilibrary.com> wrote:
>> Hi,
>>
>> Based on the feedback received last week, here is my current proposal for
>> managing the OPAC themes:
>>
>> [1] We ship Bootstrap as the default theme for 3.14 for new installations.
>> [2] We announce deprecation of prog and CCSR when 3.14 is released and issue
>> a recommendation that libraries start switching to Bootstrap.
>> [3] At the same time, we announce that prog and CCSR will be removed in
>> 3.18.  If some organization wishes to maintain either theme after then, they
>> can do so, but as a separate contrib.  However, if you are inclined to
>> support either theme after they've been removed ... please think carefully
>> about the amount of work that would entail.
>> [4] The RM will assist in getting OPAC template patches in the pipeline that
>> were written for prog updated to support Bootstrap as well.
>> [5] Starting with the 3.16, new OPAC patches should be targeted for
>> Bootstrap first.  During the 3.16 cycle, contributors are requested to make
>> an effort to update the prog theme as well, particularly for new features,
>> but this is a request, not a requirement.  In other words, this means that
>> for 3.16, libraries may need to switch to Bootstrap to take full advantage
>> of new OPAC functionality, but the prog theme will continue to be
>> functional.
>> [6] During the 3.18 cycle, no patches will be pushed for prog except insofar
>> as they may be needed to fix security issues in the maintenance releases.
>> Before 3.18 is released, prog and CCSR will be taken out entirely.
>>
>>
> Ooops in the midst of being derailed by a version numbering question,
> I missed actually adding my support for the proposal
> So
> +1 for this scheme from me
> 
> Chris

+1 from me too

Katrin



From oleonard at myacpl.org  Mon Oct 28 19:34:21 2013
From: oleonard at myacpl.org (Owen Leonard)
Date: Mon, 28 Oct 2013 14:34:21 -0400
Subject: [Koha-devel] OPAC theme proposal
In-Reply-To: <CAPLnt66_e5Zw3osow5vH-8zz5Zj62Z1jwPjfzkMEUAmiF8a5SQ@mail.gmail.com>
References: <CAPLnt66_e5Zw3osow5vH-8zz5Zj62Z1jwPjfzkMEUAmiF8a5SQ@mail.gmail.com>
Message-ID: <CAO4qe2NkciW9y_gvBWgfJNaMi0ra13HiWb5pf5RyuEtdSopqdw@mail.gmail.com>

+1 from me on the timeline.

> [4] The RM will assist in getting OPAC template patches in the pipeline that
> were written for prog updated to support Bootstrap as well.

I'm happy to help too.

  -- Owen

-- 
Web Developer
Athens County Public Libraries
http://www.myacpl.org

From mtj at kohaaloha.com  Mon Oct 28 19:45:48 2013
From: mtj at kohaaloha.com (Mason James)
Date: Tue, 29 Oct 2013 07:45:48 +1300
Subject: [Koha-devel] About cloning from GitHub
In-Reply-To: <CAML=htYNTbbWsEh3QcW2ua+E59hZnwrN_aMMbwDEdi4FAGttOw@mail.gmail.com>
References: <CAML=htYNTbbWsEh3QcW2ua+E59hZnwrN_aMMbwDEdi4FAGttOw@mail.gmail.com>
Message-ID: <05BFE94A-5C3F-4FF6-8D41-BA758547ABAB@kohaaloha.com>


On 2013-10-28, at 6:01 PM, Karam Qubsi wrote:

> Hi , 
> I tried to clone from 
> git clone git://git.koha-community.org/koha.git
> 

> Is it OK to clone from github ? or it's not Sync ? 
> 


hi

this is a synced repo ->   https://github.com/Koha-Community/Koha


From dpk at randomnotes.org  Mon Oct 28 21:26:04 2013
From: dpk at randomnotes.org (Doug Kingston)
Date: Mon, 28 Oct 2013 13:26:04 -0700
Subject: [Koha-devel] OPAC theme proposal
In-Reply-To: <CAO4qe2NkciW9y_gvBWgfJNaMi0ra13HiWb5pf5RyuEtdSopqdw@mail.gmail.com>
References: <CAPLnt66_e5Zw3osow5vH-8zz5Zj62Z1jwPjfzkMEUAmiF8a5SQ@mail.gmail.com>
	<CAO4qe2NkciW9y_gvBWgfJNaMi0ra13HiWb5pf5RyuEtdSopqdw@mail.gmail.com>
Message-ID: <CAGPaoUtDVm16k3NKXHuOCnt8anjMXM1+RCG8nH_zy-rnZYLF3Q@mail.gmail.com>

+1 on the strategy.


On Mon, Oct 28, 2013 at 11:34 AM, Owen Leonard <oleonard at myacpl.org> wrote:

> +1 from me on the timeline.
>
> > [4] The RM will assist in getting OPAC template patches in the pipeline
> that
> > were written for prog updated to support Bootstrap as well.
>
> I'm happy to help too.
>
>   -- Owen
>
> --
> Web Developer
> Athens County Public Libraries
> http://www.myacpl.org
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131028/74aca95d/attachment.html>

From martin.renvoize at ptfs-europe.com  Mon Oct 28 21:48:20 2013
From: martin.renvoize at ptfs-europe.com (Martin Renvoize)
Date: Mon, 28 Oct 2013 20:48:20 +0000
Subject: [Koha-devel] OPAC theme proposal
In-Reply-To: <CAGPaoUtDVm16k3NKXHuOCnt8anjMXM1+RCG8nH_zy-rnZYLF3Q@mail.gmail.com>
References: <CAPLnt66_e5Zw3osow5vH-8zz5Zj62Z1jwPjfzkMEUAmiF8a5SQ@mail.gmail.com>
	<CAO4qe2NkciW9y_gvBWgfJNaMi0ra13HiWb5pf5RyuEtdSopqdw@mail.gmail.com>
	<CAGPaoUtDVm16k3NKXHuOCnt8anjMXM1+RCG8nH_zy-rnZYLF3Q@mail.gmail.com>
Message-ID: <CAB7SL8B-J8uUXHxfTf+=JNwTG_S8H=3g=cBH4uDqqVMEV+B1oA@mail.gmail.com>

+1...
On 28 Oct 2013 20:26, "Doug Kingston" <dpk at randomnotes.org> wrote:

> +1 on the strategy.
>
>
> On Mon, Oct 28, 2013 at 11:34 AM, Owen Leonard <oleonard at myacpl.org>wrote:
>
>> +1 from me on the timeline.
>>
>> > [4] The RM will assist in getting OPAC template patches in the pipeline
>> that
>> > were written for prog updated to support Bootstrap as well.
>>
>> I'm happy to help too.
>>
>>   -- Owen
>>
>> --
>> Web Developer
>> Athens County Public Libraries
>> http://www.myacpl.org
>> _______________________________________________
>> Koha-devel mailing list
>> Koha-devel at 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/
>>
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131028/f6bcb442/attachment-0001.html>

From gmc at esilibrary.com  Mon Oct 28 22:51:36 2013
From: gmc at esilibrary.com (Galen Charlton)
Date: Mon, 28 Oct 2013 14:51:36 -0700
Subject: [Koha-devel] Bugzilla update, git bz attach no longer working
In-Reply-To: <CA+95qVRrKXXAv9V61vBBwXjSyPvF1HytCoDpq9d-xXcQmahDoQ@mail.gmail.com>
References: <CA+95qVRrKXXAv9V61vBBwXjSyPvF1HytCoDpq9d-xXcQmahDoQ@mail.gmail.com>
Message-ID: <CAPLnt65VS_+g0DyYX_LhDnKUXJVDbhaJofERDSzoe6UUAJQfGA@mail.gmail.com>

Hi,

On Sun, Oct 27, 2013 at 11:29 PM, Chris Cormack <chris at bigballofwax.co.nz>wrote:

> There was another security issue with bugzilla that has been fixed,
> unfortunately it was a CSRF issue, which has meant that git bz needs
> to be updated to deal with tokens better.
>
> Until git-bz is fixed, the attach will no longer work
>

It should now be possible to use git-bz normally to attach patches and
change bug statuses.  As it turns out, there was a Bugzilla patch [1] made
after the security release that fixes a problem with token-handling that
the security patch introduced.

Many thanks to Chris Cormack for wrangling Bazaar.

[1] http://bzr.mozilla.org/bugzilla/4.4/revision/8631#process_bug.cgi

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  gmc at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131028/fe724bb3/attachment.html>

From tomascohen at gmail.com  Mon Oct 28 23:17:51 2013
From: tomascohen at gmail.com (Tomas Cohen Arazi)
Date: Mon, 28 Oct 2013 20:17:51 -0200
Subject: [Koha-devel] OPAC theme proposal
In-Reply-To: <CABZfb=U7fh2b6oQAjjKZ6iZOmAfMD5Gr5A5BXE7w74gXXYc_8A@mail.gmail.com>
References: <CAPLnt66_e5Zw3osow5vH-8zz5Zj62Z1jwPjfzkMEUAmiF8a5SQ@mail.gmail.com>
	<CABZfb=U7fh2b6oQAjjKZ6iZOmAfMD5Gr5A5BXE7w74gXXYc_8A@mail.gmail.com>
Message-ID: <CABZfb=VkCZLFyBiC+45Hm2-tTxUH_2bwrZdAEapcNiLRNyAP2Q@mail.gmail.com>

+1

Six month seems enough for adjusting the css anyway.

El 28/10/2013 14:32, "Galen Charlton" <gmc at esilibrary.com> escribi?:
>
> Hi,
>
> Based on the feedback received last week, here is my current proposal for
managing the OPAC themes:
>
> [1] We ship Bootstrap as the default theme for 3.14 for new installations.
> [2] We announce deprecation of prog and CCSR when 3.14 is released and
issue a recommendation that libraries start switching to Bootstrap.
> [3] At the same time, we announce that prog and CCSR will be removed in
3.18.  If some organization wishes to maintain either theme after then,
they can do so, but as a separate contrib.  However, if you are inclined to
support either theme after they've been removed ... please think carefully
about the amount of work that would entail.
> [4] The RM will assist in getting OPAC template patches in the pipeline
that were written for prog updated to support Bootstrap as well.
> [5] Starting with the 3.16, new OPAC patches should be targeted for
Bootstrap first.  During the 3.16 cycle, contributors are requested to make
an effort to update the prog theme as well, particularly for new features,
but this is a request, not a requirement.  In other words, this means that
for 3.16, libraries may need to switch to Bootstrap to take full advantage
of new OPAC functionality, but the prog theme will continue to be
functional.
> [6] During the 3.18 cycle, no patches will be pushed for prog except
insofar as they may be needed to fix security issues in the maintenance
releases.  Before 3.18 is released, prog and CCSR will be taken out
entirely.
>
> Regards,
>
> Galen
> --
> Galen Charlton
> Manager of Implementation
> Equinox Software, Inc. / The Open Source Experts
> email:  gmc at 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
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131028/1bd77090/attachment.html>

From nengard at gmail.com  Tue Oct 29 02:58:13 2013
From: nengard at gmail.com (Nicole Engard)
Date: Mon, 28 Oct 2013 21:58:13 -0400
Subject: [Koha-devel] OPAC theme proposal
In-Reply-To: <CABZfb=VkCZLFyBiC+45Hm2-tTxUH_2bwrZdAEapcNiLRNyAP2Q@mail.gmail.com>
References: <CAPLnt66_e5Zw3osow5vH-8zz5Zj62Z1jwPjfzkMEUAmiF8a5SQ@mail.gmail.com>
	<CABZfb=U7fh2b6oQAjjKZ6iZOmAfMD5Gr5A5BXE7w74gXXYc_8A@mail.gmail.com>
	<CABZfb=VkCZLFyBiC+45Hm2-tTxUH_2bwrZdAEapcNiLRNyAP2Q@mail.gmail.com>
Message-ID: <CAC0K6VELiEoGWn=Ze3H_XW=WMBEKnDAnpLwqQXW7iEmNaNcVXg@mail.gmail.com>

+1


On Mon, Oct 28, 2013 at 6:17 PM, Tomas Cohen Arazi <tomascohen at gmail.com>wrote:

>
> +1
>
> Six month seems enough for adjusting the css anyway.
>
> El 28/10/2013 14:32, "Galen Charlton" <gmc at esilibrary.com> escribi?:
>
> >
> > Hi,
> >
> > Based on the feedback received last week, here is my current proposal
> for managing the OPAC themes:
> >
> > [1] We ship Bootstrap as the default theme for 3.14 for new
> installations.
> > [2] We announce deprecation of prog and CCSR when 3.14 is released and
> issue a recommendation that libraries start switching to Bootstrap.
> > [3] At the same time, we announce that prog and CCSR will be removed in
> 3.18.  If some organization wishes to maintain either theme after then,
> they can do so, but as a separate contrib.  However, if you are inclined to
> support either theme after they've been removed ... please think carefully
> about the amount of work that would entail.
> > [4] The RM will assist in getting OPAC template patches in the pipeline
> that were written for prog updated to support Bootstrap as well.
> > [5] Starting with the 3.16, new OPAC patches should be targeted for
> Bootstrap first.  During the 3.16 cycle, contributors are requested to make
> an effort to update the prog theme as well, particularly for new features,
> but this is a request, not a requirement.  In other words, this means that
> for 3.16, libraries may need to switch to Bootstrap to take full advantage
> of new OPAC functionality, but the prog theme will continue to be
> functional.
> > [6] During the 3.18 cycle, no patches will be pushed for prog except
> insofar as they may be needed to fix security issues in the maintenance
> releases.  Before 3.18 is released, prog and CCSR will be taken out
> entirely.
> >
> > Regards,
> >
> > Galen
> > --
> > Galen Charlton
> > Manager of Implementation
> > Equinox Software, Inc. / The Open Source Experts
> > email:  gmc at 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
> >
> > _______________________________________________
> > Koha-devel mailing list
> > Koha-devel at 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/
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131028/65036012/attachment.html>

From chrish at catalyst.net.nz  Tue Oct 29 08:47:31 2013
From: chrish at catalyst.net.nz (Chris Hall)
Date: Tue, 29 Oct 2013 20:47:31 +1300
Subject: [Koha-devel] Koha 3.8.19 released
Message-ID: <20131029074731.GA18983@0x1b.wgtn.cat-it.co.nz>

The koha community is proud to announce the release of 3.8.19.
This is a maintenance release and contains many bugfixes.

As always you can download the release from

http://download.koha-community.org

RELEASE NOTES FOR KOHA 3.8.19
29 Oct 2013
========================================================================

Koha is the first free and open source software library automation package 
(ILS). Development is sponsored by libraries of varying types and sizes, 
volunteers, and support companies from around the world.  
The website for the Koha project is 

    http://koha-community.org/

Koha 3.8.19 can be downloaded from:

    http://download.koha-community.org/koha-3.08.19.tar.gz

Installation instructions can be found at:

    http://wiki.koha-community.org/wiki/Installation_Documentation
    
    OR in the INSTALL files that come in the tarball


Koha 3.8.19 is a bugfix/maintenance release.


It includes 0 features, 0 enhancements and 11 bugfixes.


New features in 3.8.19
======================


----------


Enhancements in 3.8.19
======================


----------


Critical bugs fixed in 3.8.19
======================



----------


Other bugs fixed in 3.8.19
======================


Acquisitions
----------
	10483	normal	Check_uniqueness.pl does not work

Architecture, internals, and plumbing
----------
	10642	normal	Inappropriate uses of $sth->finish() in C4::RotatingCollections.pm

Cataloging
----------
	10715	trivial	MARC21 007 Plugin Editor doesn't load position 01

Circulation
----------
	10362	normal	On return with reserve or transfer the alerts are not shown

Documentation
----------
	10703	normal	Add/update database documentation

Installation and upgrade (command-line installer)
----------
	10712	normal	Some values not saved in koha install log

Notices
----------
	10664	normal	Software error in overdue_notices.pl if there is no active currency

Patrons
----------
	10481	normal	No enrollment fee when changing patron category

Serials
----------
	10728	trivial	Subscription-renew generates unnecessary warnings in logs

Staff Client
----------
	8887	normal	Search preferences: Strange behaviour with exact matches (default instead of custom favicon used, displays to much results)

Test Suite
----------
	10653	normal	UT : C4::RotatingCollections.pm needs unit tests.


New sysprefs in 3.8.19
======================



System requirements
======================

    Important notes:
    
    * Perl 5.10 is required
    * Zebra is required


Documentation
======================

The Koha manual is maintained in DocBook.The home page for Koha 
documentation is 

    http://koha-community.org/documentation/

As of the date of these release notes, only the English version of the
Koha manual is available:

    http://manual.koha-community.org/3.8/en/

The Git repository for the Koha manual can be found at

    http://git.koha-community.org/gitweb/?p=kohadocs.git;a=summary


Translations
======================

Complete or near-complete translations of the OPAC and staff
interface are available in this release for the following languages:


  * English (USA)
  * Arabic (84%)
  * Armenian (84%)
  * Chinese (China) (56%)
  * Chinese (Taiwan) (99%)
  * Czech (98%)
  * Danish (87%)
  * English (New Zealand) (84%)
  * French (99%)
  * French (Canada) (65%)
  * German (100%)
  * German (Switzerland) (83%)
  * Greek (80%)
  * Italian (100%)
  * Kurdish (83%)
  * Maori (58%)
  * Norwegian Bokm?l (57%)
  * Portuguese (100%)
  * Portuguese (Brazil) (84%)
  * Slovak (100%)
  * Spanish (100%)
  * Turkish (100%)


Partial translations are available for various other languages.

The Koha team welcomes additional translations; please see

    http://wiki.koha-community.org/wiki/Translating_Koha

for information about translating Koha, and join the koha-translate 
list to volunteer:

    http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-translate

The most up-to-date translations can be found at:

    http://translate.koha-community.org/


Release Team
======================

The release team for Koha 3.8.19 is

  Release Manager:       Paul Poulain <paul.poulain at biblibre.com>
  Documentation Manager: Nicole C Engard <nengard at gmail.com>
  Installation Documentation Managers:
                         Samuel Desseaux <samuel.desseaux at ecp.fr>
                         Mason James <mtj at kohaaloha.com>
  Translation Manager:   Bernardo Gonzalez Kriegel <bgkriegel at gmail.com>
  QA Manager:            Katrin Fischer <Katrin.Fischer at bsz-bw.de>
  QA Team:               Chris Cormack <chrisc at catalyst.net.nz>
                         Marcel de Rooy <M.de.Rooy at rijksmuseum.nl>,
                         Jonathan Druart <jonathan.druart at biblibre.com>,
                         Brendan Gallagher <brendan at bywatersolutions.com>
                         Kyle Hall <kyle at bywatersolutions.com>
                         Mason James <mtj at kohaaloha.com>
                         Paul Poulain <paul.poulain at biblibre.com>
  Bug Wranglers:         Magnus Enger <magnus at enger.priv.no>
  Packaging Manager:     Robin Sheat <robin at catalyst.net.nz>
  Live CD Manager:       Nguyen Quoc Uy <nguyenquocuy_1102 at yahoo.com>
  VM Manager:            Samuel Desseaux <samuel.desseaux at ecp.fr>

  Release Maintainer (3.8.x): Chris Hall <chrish at catalyst.net.nz>
  Release Maintainer (3.10.x): Bernardo Gonzalez Kriegel <bgkriegel at gmail.com>
  Release Maintainer (3.12.x): Tom?s Cohen Arazi <tomascohen at gmail.com>


Credits
======================

We thank the following libraries who are known to have sponsored
new features in Koha 3.8.19:

We thank the following individuals who contributed patches to Koha 3.8.19.
  *      2	Colin Campbell
  *      2	Galen Charlton
  *      1	David Cook
  *      2	Jonathan Druart
  *      1	Nicole Engard
  *      1	Kyle M Hall
  *      1	Bernardo Gonzalez Kriegel
  *      1	Sophie Meynieux
  *      2	Fridolyn SOMERS
  *      1	Marc Veron
  *      1	Kenza Zaki
  *      1	root

We thank the following companies who contributed patches to Koha 3.8.19
  *       6 BibLibre                                                                                    
  *       2 ByWater-Solutions                                                                   
  *       2 Equinox                                                                                   
  *       2 PTFS-Europe                                                                              
  *       1 Prosentient Systems
  *       1 kenza-VirtualBox
  *       1 unidentified
  *       1 veron.ch

We also especially thank the following individuals who tested patches
for Koha 3.8.19.
  *      15 Tomas Cohen Arazi
  *      19 Galen Charlton
  *       4 Chris Cormack
  *       2 Jonathan Druart
  *       7 Chris Hall
  *       9 Kyle M Hall
  *      17 Bernardo Gonzalez Kriegel
  *       1 Owen Leonard
  *       3 Srdjan
  *       1 Mirko Tietgen

We regret any omissions.  If a contributor has been inadvertently missed,
please send a patch against these release notes to 
koha-patches at lists.koha-community.org.


Revision control notes
======================

The Koha project uses Git for version control.  The current development 
version of Koha can be retrieved by checking out the master branch of 

    git://git.koha-community.org/koha.git

The branch for this version of Koha and future bugfixes in this release line is 3.8.x.

The last Koha release was 3.8.14, which was released on June 23, 2013.


Bugs and feature requests
======================

Bug reports and feature requests can be filed at the Koha bug
tracker at

    http://bugs.koha-community.org/


He rau ringa e oti ai.
(Many hands finish the work)


From fridolyn.somers at biblibre.com  Tue Oct 29 09:03:09 2013
From: fridolyn.somers at biblibre.com (Fridolyn SOMERS)
Date: Tue, 29 Oct 2013 09:03:09 +0100
Subject: [Koha-devel] 245$c in OPAC
In-Reply-To: <5.2.1.1.2.20131026112501.01ca7070@stormy.ca>
References: <5.2.1.1.2.20131026112501.01ca7070@stormy.ca>
Message-ID: <526F6BBD.5000600@biblibre.com>

Hie,

Using XSLT in  normal view is the best way to customize it.
I'm sure there is more than 245$s you wish to customize.

Using defaut XSLT is even recommanded.

Regards,

Le 26/10/2013 17:33, Paul A a ?crit :
> Is Bug 9490 - "Show responsibility statement (245c) under title and move
> authors down in OPAC XSLT" the best (only?) way to go?
>
> Or is there a "quick" (js?) way to show MARC 245$s (statement of
> responsibility) in the OPAC "normal view"?  [Koha 3.8.5]
>
> It's a request from our cataloguers who held a "Koha workshop" with a
> number of users (university profs and students) earlier this week.
> Marcel's proposal seems to fit the requirement perfectly.
>
> Thanks and br,
> Paul
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/

-- 
Fridolyn SOMERS
Biblibre - P?le support
fridolyn.somers at biblibre.com

From fridolyn.somers at biblibre.com  Tue Oct 29 09:26:51 2013
From: fridolyn.somers at biblibre.com (Fridolyn SOMERS)
Date: Tue, 29 Oct 2013 09:26:51 +0100
Subject: [Koha-devel] About cloning from GitHub
In-Reply-To: <05BFE94A-5C3F-4FF6-8D41-BA758547ABAB@kohaaloha.com>
References: <CAML=htYNTbbWsEh3QcW2ua+E59hZnwrN_aMMbwDEdi4FAGttOw@mail.gmail.com>
	<05BFE94A-5C3F-4FF6-8D41-BA758547ABAB@kohaaloha.com>
Message-ID: <526F714B.7020401@biblibre.com>

This repository seems not to be a real mirror.
Master is up-to-date, but not branches : 3.10.x is 1 year old and 3.12.x 
does not exist.
Also, there are no tags.

Le 28/10/2013 19:45, Mason James a ?crit :
>
> On 2013-10-28, at 6:01 PM, Karam Qubsi wrote:
>
>> Hi ,
>> I tried to clone from
>> git clone git://git.koha-community.org/koha.git
>>
>
>> Is it OK to clone from github ? or it's not Sync ?
>>
>
>
> hi
>
> this is a synced repo ->   https://github.com/Koha-Community/Koha
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/
>

-- 
Fridolyn SOMERS
Biblibre - P?le support
fridolyn.somers at biblibre.com

From joy at bywatersolutions.com  Tue Oct 29 15:18:18 2013
From: joy at bywatersolutions.com (Joy Nelson)
Date: Tue, 29 Oct 2013 09:18:18 -0500
Subject: [Koha-devel] OPAC theme proposal
In-Reply-To: <CAC0K6VELiEoGWn=Ze3H_XW=WMBEKnDAnpLwqQXW7iEmNaNcVXg@mail.gmail.com>
References: <CAPLnt66_e5Zw3osow5vH-8zz5Zj62Z1jwPjfzkMEUAmiF8a5SQ@mail.gmail.com>
	<CABZfb=U7fh2b6oQAjjKZ6iZOmAfMD5Gr5A5BXE7w74gXXYc_8A@mail.gmail.com>
	<CABZfb=VkCZLFyBiC+45Hm2-tTxUH_2bwrZdAEapcNiLRNyAP2Q@mail.gmail.com>
	<CAC0K6VELiEoGWn=Ze3H_XW=WMBEKnDAnpLwqQXW7iEmNaNcVXg@mail.gmail.com>
Message-ID: <CAFpshE-jhVm--x1SffXzYhC=6WYaY8Paj-8mUiCMuG5Zb_av=Q@mail.gmail.com>

+1


On Mon, Oct 28, 2013 at 8:58 PM, Nicole Engard <nengard at gmail.com> wrote:

> +1
>
>
> On Mon, Oct 28, 2013 at 6:17 PM, Tomas Cohen Arazi <tomascohen at gmail.com>wrote:
>
>>
>> +1
>>
>> Six month seems enough for adjusting the css anyway.
>>
>> El 28/10/2013 14:32, "Galen Charlton" <gmc at esilibrary.com> escribi?:
>>
>> >
>> > Hi,
>> >
>> > Based on the feedback received last week, here is my current proposal
>> for managing the OPAC themes:
>> >
>> > [1] We ship Bootstrap as the default theme for 3.14 for new
>> installations.
>> > [2] We announce deprecation of prog and CCSR when 3.14 is released and
>> issue a recommendation that libraries start switching to Bootstrap.
>> > [3] At the same time, we announce that prog and CCSR will be removed in
>> 3.18.  If some organization wishes to maintain either theme after then,
>> they can do so, but as a separate contrib.  However, if you are inclined to
>> support either theme after they've been removed ... please think carefully
>> about the amount of work that would entail.
>> > [4] The RM will assist in getting OPAC template patches in the pipeline
>> that were written for prog updated to support Bootstrap as well.
>> > [5] Starting with the 3.16, new OPAC patches should be targeted for
>> Bootstrap first.  During the 3.16 cycle, contributors are requested to make
>> an effort to update the prog theme as well, particularly for new features,
>> but this is a request, not a requirement.  In other words, this means that
>> for 3.16, libraries may need to switch to Bootstrap to take full advantage
>> of new OPAC functionality, but the prog theme will continue to be
>> functional.
>> > [6] During the 3.18 cycle, no patches will be pushed for prog except
>> insofar as they may be needed to fix security issues in the maintenance
>> releases.  Before 3.18 is released, prog and CCSR will be taken out
>> entirely.
>> >
>> > Regards,
>> >
>> > Galen
>> > --
>> > Galen Charlton
>> > Manager of Implementation
>> > Equinox Software, Inc. / The Open Source Experts
>> > email:  gmc at 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
>> >
>> > _______________________________________________
>> > Koha-devel mailing list
>> > Koha-devel at 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/
>>
>>
>> _______________________________________________
>> Koha-devel mailing list
>> Koha-devel at 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/
>>
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/
>



-- 
Joy Nelson
Director of Migrations

ByWater Solutions <http://bywatersolutions.com>
Support and Consulting for Open Source Software
**Office: Fort Worth, TX
Phone/Fax (888)900-8944
What is Koha? <http://bywatersolutions.com/what-is-koha/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131029/c01a6b70/attachment.html>

From kyle.m.hall at gmail.com  Tue Oct 29 19:50:07 2013
From: kyle.m.hall at gmail.com (Kyle Hall)
Date: Tue, 29 Oct 2013 14:50:07 -0400
Subject: [Koha-devel] OPAC theme proposal
In-Reply-To: <CAFpshE-jhVm--x1SffXzYhC=6WYaY8Paj-8mUiCMuG5Zb_av=Q@mail.gmail.com>
References: <CAPLnt66_e5Zw3osow5vH-8zz5Zj62Z1jwPjfzkMEUAmiF8a5SQ@mail.gmail.com>
	<CABZfb=U7fh2b6oQAjjKZ6iZOmAfMD5Gr5A5BXE7w74gXXYc_8A@mail.gmail.com>
	<CABZfb=VkCZLFyBiC+45Hm2-tTxUH_2bwrZdAEapcNiLRNyAP2Q@mail.gmail.com>
	<CAC0K6VELiEoGWn=Ze3H_XW=WMBEKnDAnpLwqQXW7iEmNaNcVXg@mail.gmail.com>
	<CAFpshE-jhVm--x1SffXzYhC=6WYaY8Paj-8mUiCMuG5Zb_av=Q@mail.gmail.com>
Message-ID: <CACpVHfwpXnM=sgdasxG9o3AHnoqurf+ZoF1VAXC5BQzpodNuCQ@mail.gmail.com>

+1

http://www.kylehall.info
ByWater Solutions ( http://bywatersolutions.com )
Meadville Public Library ( http://www.meadvillelibrary.org )
Crawford County Federated Library System ( http://www.ccfls.org )
Mill Run Technology Solutions ( http://millruntech.com )


On Tue, Oct 29, 2013 at 10:18 AM, Joy Nelson <joy at bywatersolutions.com>wrote:

> +1
>
>
> On Mon, Oct 28, 2013 at 8:58 PM, Nicole Engard <nengard at gmail.com> wrote:
>
>> +1
>>
>>
>> On Mon, Oct 28, 2013 at 6:17 PM, Tomas Cohen Arazi <tomascohen at gmail.com>wrote:
>>
>>>
>>> +1
>>>
>>> Six month seems enough for adjusting the css anyway.
>>>
>>> El 28/10/2013 14:32, "Galen Charlton" <gmc at esilibrary.com> escribi?:
>>>
>>> >
>>> > Hi,
>>> >
>>> > Based on the feedback received last week, here is my current proposal
>>> for managing the OPAC themes:
>>> >
>>> > [1] We ship Bootstrap as the default theme for 3.14 for new
>>> installations.
>>> > [2] We announce deprecation of prog and CCSR when 3.14 is released and
>>> issue a recommendation that libraries start switching to Bootstrap.
>>> > [3] At the same time, we announce that prog and CCSR will be removed
>>> in 3.18.  If some organization wishes to maintain either theme after then,
>>> they can do so, but as a separate contrib.  However, if you are inclined to
>>> support either theme after they've been removed ... please think carefully
>>> about the amount of work that would entail.
>>> > [4] The RM will assist in getting OPAC template patches in the
>>> pipeline that were written for prog updated to support Bootstrap as well.
>>> > [5] Starting with the 3.16, new OPAC patches should be targeted for
>>> Bootstrap first.  During the 3.16 cycle, contributors are requested to make
>>> an effort to update the prog theme as well, particularly for new features,
>>> but this is a request, not a requirement.  In other words, this means that
>>> for 3.16, libraries may need to switch to Bootstrap to take full advantage
>>> of new OPAC functionality, but the prog theme will continue to be
>>> functional.
>>> > [6] During the 3.18 cycle, no patches will be pushed for prog except
>>> insofar as they may be needed to fix security issues in the maintenance
>>> releases.  Before 3.18 is released, prog and CCSR will be taken out
>>> entirely.
>>> >
>>> > Regards,
>>> >
>>> > Galen
>>> > --
>>> > Galen Charlton
>>> > Manager of Implementation
>>> > Equinox Software, Inc. / The Open Source Experts
>>> > email:  gmc at 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
>>> >
>>> > _______________________________________________
>>> > Koha-devel mailing list
>>> > Koha-devel at 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/
>>>
>>>
>>> _______________________________________________
>>> Koha-devel mailing list
>>> Koha-devel at 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/
>>>
>>
>>
>> _______________________________________________
>> Koha-devel mailing list
>> Koha-devel at 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/
>>
>
>
>
> --
> Joy Nelson
> Director of Migrations
>
> ByWater Solutions <http://bywatersolutions.com>
> Support and Consulting for Open Source Software
> **Office: Fort Worth, TX
> Phone/Fax (888)900-8944
> What is Koha? <http://bywatersolutions.com/what-is-koha/>
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131029/14ef0225/attachment-0001.html>

From chris.nighswonger at gmail.com  Tue Oct 29 19:53:31 2013
From: chris.nighswonger at gmail.com (Christopher Nighswonger)
Date: Tue, 29 Oct 2013 14:53:31 -0400
Subject: [Koha-devel] OPAC theme proposal
In-Reply-To: <CACpVHfwpXnM=sgdasxG9o3AHnoqurf+ZoF1VAXC5BQzpodNuCQ@mail.gmail.com>
References: <CAPLnt66_e5Zw3osow5vH-8zz5Zj62Z1jwPjfzkMEUAmiF8a5SQ@mail.gmail.com>
	<CABZfb=U7fh2b6oQAjjKZ6iZOmAfMD5Gr5A5BXE7w74gXXYc_8A@mail.gmail.com>
	<CABZfb=VkCZLFyBiC+45Hm2-tTxUH_2bwrZdAEapcNiLRNyAP2Q@mail.gmail.com>
	<CAC0K6VELiEoGWn=Ze3H_XW=WMBEKnDAnpLwqQXW7iEmNaNcVXg@mail.gmail.com>
	<CAFpshE-jhVm--x1SffXzYhC=6WYaY8Paj-8mUiCMuG5Zb_av=Q@mail.gmail.com>
	<CACpVHfwpXnM=sgdasxG9o3AHnoqurf+ZoF1VAXC5BQzpodNuCQ@mail.gmail.com>
Message-ID: <CAA7=B8zc6nrRSD2VLHKgkKze9NY+auYWhHpHgwi1VoK2Xcfd-Q@mail.gmail.com>

+1


On Tue, Oct 29, 2013 at 2:50 PM, Kyle Hall <kyle.m.hall at gmail.com> wrote:

> +1
>
> http://www.kylehall.info
> ByWater Solutions ( http://bywatersolutions.com )
> Meadville Public Library ( http://www.meadvillelibrary.org )
> Crawford County Federated Library System ( http://www.ccfls.org )
> Mill Run Technology Solutions ( http://millruntech.com )
>
>
> On Tue, Oct 29, 2013 at 10:18 AM, Joy Nelson <joy at bywatersolutions.com>wrote:
>
>> +1
>>
>>
>> On Mon, Oct 28, 2013 at 8:58 PM, Nicole Engard <nengard at gmail.com> wrote:
>>
>>> +1
>>>
>>>
>>> On Mon, Oct 28, 2013 at 6:17 PM, Tomas Cohen Arazi <tomascohen at gmail.com
>>> > wrote:
>>>
>>>>
>>>> +1
>>>>
>>>> Six month seems enough for adjusting the css anyway.
>>>>
>>>> El 28/10/2013 14:32, "Galen Charlton" <gmc at esilibrary.com> escribi?:
>>>>
>>>> >
>>>> > Hi,
>>>> >
>>>> > Based on the feedback received last week, here is my current proposal
>>>> for managing the OPAC themes:
>>>> >
>>>> > [1] We ship Bootstrap as the default theme for 3.14 for new
>>>> installations.
>>>> > [2] We announce deprecation of prog and CCSR when 3.14 is released
>>>> and issue a recommendation that libraries start switching to Bootstrap.
>>>> > [3] At the same time, we announce that prog and CCSR will be removed
>>>> in 3.18.  If some organization wishes to maintain either theme after then,
>>>> they can do so, but as a separate contrib.  However, if you are inclined to
>>>> support either theme after they've been removed ... please think carefully
>>>> about the amount of work that would entail.
>>>> > [4] The RM will assist in getting OPAC template patches in the
>>>> pipeline that were written for prog updated to support Bootstrap as well.
>>>> > [5] Starting with the 3.16, new OPAC patches should be targeted for
>>>> Bootstrap first.  During the 3.16 cycle, contributors are requested to make
>>>> an effort to update the prog theme as well, particularly for new features,
>>>> but this is a request, not a requirement.  In other words, this means that
>>>> for 3.16, libraries may need to switch to Bootstrap to take full advantage
>>>> of new OPAC functionality, but the prog theme will continue to be
>>>> functional.
>>>> > [6] During the 3.18 cycle, no patches will be pushed for prog except
>>>> insofar as they may be needed to fix security issues in the maintenance
>>>> releases.  Before 3.18 is released, prog and CCSR will be taken out
>>>> entirely.
>>>> >
>>>> > Regards,
>>>> >
>>>> > Galen
>>>> > --
>>>> > Galen Charlton
>>>> > Manager of Implementation
>>>> > Equinox Software, Inc. / The Open Source Experts
>>>> > email:  gmc at 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
>>>> >
>>>> > _______________________________________________
>>>> > Koha-devel mailing list
>>>> > Koha-devel at 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/
>>>>
>>>>
>>>> _______________________________________________
>>>> Koha-devel mailing list
>>>> Koha-devel at 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/
>>>>
>>>
>>>
>>> _______________________________________________
>>> Koha-devel mailing list
>>> Koha-devel at 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/
>>>
>>
>>
>>
>> --
>> Joy Nelson
>> Director of Migrations
>>
>> ByWater Solutions <http://bywatersolutions.com>
>> Support and Consulting for Open Source Software
>> **Office: Fort Worth, TX
>> Phone/Fax (888)900-8944
>> What is Koha? <http://bywatersolutions.com/what-is-koha/>
>>
>>
>> _______________________________________________
>> Koha-devel mailing list
>> Koha-devel at 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/
>>
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131029/f09337b5/attachment.html>

From liz at catalyst.net.nz  Tue Oct 29 21:33:05 2013
From: liz at catalyst.net.nz (Liz Rea)
Date: Wed, 30 Oct 2013 09:33:05 +1300
Subject: [Koha-devel] OPAC theme proposal
In-Reply-To: <CAA7=B8zc6nrRSD2VLHKgkKze9NY+auYWhHpHgwi1VoK2Xcfd-Q@mail.gmail.com>
References: <CAPLnt66_e5Zw3osow5vH-8zz5Zj62Z1jwPjfzkMEUAmiF8a5SQ@mail.gmail.com>	<CABZfb=U7fh2b6oQAjjKZ6iZOmAfMD5Gr5A5BXE7w74gXXYc_8A@mail.gmail.com>	<CABZfb=VkCZLFyBiC+45Hm2-tTxUH_2bwrZdAEapcNiLRNyAP2Q@mail.gmail.com>	<CAC0K6VELiEoGWn=Ze3H_XW=WMBEKnDAnpLwqQXW7iEmNaNcVXg@mail.gmail.com>	<CAFpshE-jhVm--x1SffXzYhC=6WYaY8Paj-8mUiCMuG5Zb_av=Q@mail.gmail.com>	<CACpVHfwpXnM=sgdasxG9o3AHnoqurf+ZoF1VAXC5BQzpodNuCQ@mail.gmail.com>
	<CAA7=B8zc6nrRSD2VLHKgkKze9NY+auYWhHpHgwi1VoK2Xcfd-Q@mail.gmail.com>
Message-ID: <52701B81.7010603@catalyst.net.nz>

+1 from me as well. Thanks for the coherent proposal, Galen.

Liz
On 30/10/13 07:53, Christopher Nighswonger wrote:
> +1
>
>
> On Tue, Oct 29, 2013 at 2:50 PM, Kyle Hall <kyle.m.hall at gmail.com> wrote:
>
>> +1
>>
>> http://www.kylehall.info
>> ByWater Solutions ( http://bywatersolutions.com )
>> Meadville Public Library ( http://www.meadvillelibrary.org )
>> Crawford County Federated Library System ( http://www.ccfls.org )
>> Mill Run Technology Solutions ( http://millruntech.com )
>>
>>
>> On Tue, Oct 29, 2013 at 10:18 AM, Joy Nelson <joy at bywatersolutions.com>wrote:
>>
>>> +1
>>>
>>>
>>> On Mon, Oct 28, 2013 at 8:58 PM, Nicole Engard <nengard at gmail.com> wrote:
>>>
>>>> +1
>>>>
>>>>
>>>> On Mon, Oct 28, 2013 at 6:17 PM, Tomas Cohen Arazi <tomascohen at gmail.com
>>>>> wrote:
>>>>> +1
>>>>>
>>>>> Six month seems enough for adjusting the css anyway.
>>>>>
>>>>> El 28/10/2013 14:32, "Galen Charlton" <gmc at esilibrary.com> escribi?:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Based on the feedback received last week, here is my current proposal
>>>>> for managing the OPAC themes:
>>>>>> [1] We ship Bootstrap as the default theme for 3.14 for new
>>>>> installations.
>>>>>> [2] We announce deprecation of prog and CCSR when 3.14 is released
>>>>> and issue a recommendation that libraries start switching to Bootstrap.
>>>>>> [3] At the same time, we announce that prog and CCSR will be removed
>>>>> in 3.18.  If some organization wishes to maintain either theme after then,
>>>>> they can do so, but as a separate contrib.  However, if you are inclined to
>>>>> support either theme after they've been removed ... please think carefully
>>>>> about the amount of work that would entail.
>>>>>> [4] The RM will assist in getting OPAC template patches in the
>>>>> pipeline that were written for prog updated to support Bootstrap as well.
>>>>>> [5] Starting with the 3.16, new OPAC patches should be targeted for
>>>>> Bootstrap first.  During the 3.16 cycle, contributors are requested to make
>>>>> an effort to update the prog theme as well, particularly for new features,
>>>>> but this is a request, not a requirement.  In other words, this means that
>>>>> for 3.16, libraries may need to switch to Bootstrap to take full advantage
>>>>> of new OPAC functionality, but the prog theme will continue to be
>>>>> functional.
>>>>>> [6] During the 3.18 cycle, no patches will be pushed for prog except
>>>>> insofar as they may be needed to fix security issues in the maintenance
>>>>> releases.  Before 3.18 is released, prog and CCSR will be taken out
>>>>> entirely.
>>>>>> Regards,
>>>>>>
>>>>>> Galen
>>>>>> --
>>>>>> Galen Charlton
>>>>>> Manager of Implementation
>>>>>> Equinox Software, Inc. / The Open Source Experts
>>>>>> email:  gmc at 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
>>>>>> _______________________________________________
>>>>>> Koha-devel mailing list
>>>>>> Koha-devel at 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/
>>>>>
>>>>> _______________________________________________
>>>>> Koha-devel mailing list
>>>>> Koha-devel at 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/
>>>>>
>>>>
>>>> _______________________________________________
>>>> Koha-devel mailing list
>>>> Koha-devel at 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/
>>>>
>>>
>>>
>>> --
>>> Joy Nelson
>>> Director of Migrations
>>>
>>> ByWater Solutions <http://bywatersolutions.com>
>>> Support and Consulting for Open Source Software
>>> **Office: Fort Worth, TX
>>> Phone/Fax (888)900-8944
>>> What is Koha? <http://bywatersolutions.com/what-is-koha/>
>>>
>>>
>>> _______________________________________________
>>> Koha-devel mailing list
>>> Koha-devel at 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/
>>>
>>
>> _______________________________________________
>> Koha-devel mailing list
>> Koha-devel at 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/
>>
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131030/f9d76a2f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131030/f9d76a2f/attachment-0001.pgp>

From mtj at kohaaloha.com  Wed Oct 30 03:38:01 2013
From: mtj at kohaaloha.com (Mason James)
Date: Wed, 30 Oct 2013 15:38:01 +1300
Subject: [Koha-devel] About cloning from GitHub
In-Reply-To: <526F714B.7020401@biblibre.com>
References: <CAML=htYNTbbWsEh3QcW2ua+E59hZnwrN_aMMbwDEdi4FAGttOw@mail.gmail.com>
	<05BFE94A-5C3F-4FF6-8D41-BA758547ABAB@kohaaloha.com>
	<526F714B.7020401@biblibre.com>
Message-ID: <590FDCCE-D0D7-4CD6-8C0D-3F0E8E0627A2@kohaaloha.com>


On 2013-10-29, at 9:26 PM, Fridolyn SOMERS wrote:

> This repository seems not to be a real mirror.
> Master is up-to-date, but not branches : 3.10.x is 1 year old and 3.12.x does not exist.
> Also, there are no tags.

oups!, thanks for this info Fridolyn

i will fix this


> 
> Le 28/10/2013 19:45, Mason James a ?crit :
>> 
>> On 2013-10-28, at 6:01 PM, Karam Qubsi wrote:
>> 
>>> Hi ,
>>> I tried to clone from
>>> git clone git://git.koha-community.org/koha.git
>>> 
>> 
>>> Is it OK to clone from github ? or it's not Sync ?
>>> 
>> 


From paul.poulain at biblibre.com  Wed Oct 30 08:43:07 2013
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Wed, 30 Oct 2013 08:43:07 +0100
Subject: [Koha-devel] OPAC theme proposal
In-Reply-To: <CABZfb=VkCZLFyBiC+45Hm2-tTxUH_2bwrZdAEapcNiLRNyAP2Q@mail.gmail.com>
References: <CAPLnt66_e5Zw3osow5vH-8zz5Zj62Z1jwPjfzkMEUAmiF8a5SQ@mail.gmail.com>	<CABZfb=U7fh2b6oQAjjKZ6iZOmAfMD5Gr5A5BXE7w74gXXYc_8A@mail.gmail.com>
	<CABZfb=VkCZLFyBiC+45Hm2-tTxUH_2bwrZdAEapcNiLRNyAP2Q@mail.gmail.com>
Message-ID: <5270B88B.3060706@biblibre.com>

Le 28/10/2013 23:17, Tomas Cohen Arazi a ?crit :
> +1
> 
> Six month seems enough for adjusting the css anyway.
+1 for this proposal.
I would also add : if someone can't adjust it's css, the 3.14 will be
maintained for at least 6 months, probably one year, maybe more.
So anyone can stay on 3.14 if needed.



-- 
Paul POULAIN - BibLibre
http://www.biblibre.com
Free & Open Source Softwares for libraries
Koha, Drupal, Piwik, Jasper


From jonathan.druart at biblibre.com  Wed Oct 30 16:59:24 2013
From: jonathan.druart at biblibre.com (Jonathan Druart)
Date: Wed, 30 Oct 2013 16:59:24 +0100
Subject: [Koha-devel] Jenkins status [was Jenkins build is back to
	stable : Koha_master #1475]
In-Reply-To: <CAJzKNY6GNtbUiSpoE6e9KnQNcSmXhSm+TpoAdB70CkSv2OVqww@mail.gmail.com>
References: <CAJzKNY6GNtbUiSpoE6e9KnQNcSmXhSm+TpoAdB70CkSv2OVqww@mail.gmail.com>
Message-ID: <CAJzKNY6xW4ano7Wo8EVtcGtmXfhkuM7fnyVoWx43T7cL8JpAyw@mail.gmail.com>

No answer?
Does that mean I am the only one wondering why jenkins is back to stable?
Or maybe is it because I was not clear enough in my question ?
A big work has been made on unit tests. It seems important to me to
know why our integration server fails when the code passes on my
development instance.

Regards,
Jonathan

2013/10/24 Jonathan Druart <jonathan.druart at biblibre.com>:
> Hi all!
>
> I often receive emails from Jenkins: "master is unstable", "master is
> back to stable".
> Last unstable status was caused by a fail in
> t/db_dependent/Acquisition/Invoices.t (I think).
> Here Jenkins says : "it is stable, see changes". But changes are about
> a tt change.
> I don't know who fixed the failure and how it was fixed. It is
> frustrating not to know :)
> Especially because the tests pass on master with my data!
>
> Do you think it would be possible to put something in place in order
> to follow Jenkins ' moods?
>
> For discussion.
> Regards,
> Jonathan
>
> 2013/10/23  <chris at bigballofwax.co.nz>:
>> See <http://jenkins.koha-community.org/job/Koha_master/1475/changes>
>>

From M.de.Rooy at rijksmuseum.nl  Wed Oct 30 17:06:26 2013
From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy)
Date: Wed, 30 Oct 2013 16:06:26 +0000
Subject: [Koha-devel] Jenkins status [was Jenkins build is back
	to	stable : Koha_master #1475]
In-Reply-To: <CAJzKNY6xW4ano7Wo8EVtcGtmXfhkuM7fnyVoWx43T7cL8JpAyw@mail.gmail.com>
References: <CAJzKNY6GNtbUiSpoE6e9KnQNcSmXhSm+TpoAdB70CkSv2OVqww@mail.gmail.com>,
	<CAJzKNY6xW4ano7Wo8EVtcGtmXfhkuM7fnyVoWx43T7cL8JpAyw@mail.gmail.com>
Message-ID: <809BE39CD64BFD4EB9036172EBCCFA3116499322@S-MAIL-1B.rijksmuseum.intra>

Your question is certainly valid.
There are still too many tests depending on some data to exist.
Finding out why it no longer fails requires some (extensive?) digging into which patches were pushed in the meantime. 
________________________________________
Van: koha-devel-bounces at lists.koha-community.org [koha-devel-bounces at lists.koha-community.org] namens Jonathan Druart [jonathan.druart at biblibre.com]
Verzonden: woensdag 30 oktober 2013 16:59
Aan: koha-devel at lists.koha-community.org
Onderwerp: Re: [Koha-devel] Jenkins status [was Jenkins build is back to        stable : Koha_master #1475]

No answer?
Does that mean I am the only one wondering why jenkins is back to stable?
Or maybe is it because I was not clear enough in my question ?
A big work has been made on unit tests. It seems important to me to
know why our integration server fails when the code passes on my
development instance.

Regards,
Jonathan

2013/10/24 Jonathan Druart <jonathan.druart at biblibre.com>:
> Hi all!
>
> I often receive emails from Jenkins: "master is unstable", "master is
> back to stable".
> Last unstable status was caused by a fail in
> t/db_dependent/Acquisition/Invoices.t (I think).
> Here Jenkins says : "it is stable, see changes". But changes are about
> a tt change.
> I don't know who fixed the failure and how it was fixed. It is
> frustrating not to know :)
> Especially because the tests pass on master with my data!
>
> Do you think it would be possible to put something in place in order
> to follow Jenkins ' moods?
>
> For discussion.
> Regards,
> Jonathan
>
> 2013/10/23  <chris at bigballofwax.co.nz>:
>> See <http://jenkins.koha-community.org/job/Koha_master/1475/changes>
>>
_______________________________________________
Koha-devel mailing list
Koha-devel at 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/

From jonathan.druart at biblibre.com  Wed Oct 30 17:15:40 2013
From: jonathan.druart at biblibre.com (Jonathan Druart)
Date: Wed, 30 Oct 2013 17:15:40 +0100
Subject: [Koha-devel] Jenkins status [was Jenkins build is back to
 stable : Koha_master #1475]
In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA3116499322@S-MAIL-1B.rijksmuseum.intra>
References: <CAJzKNY6GNtbUiSpoE6e9KnQNcSmXhSm+TpoAdB70CkSv2OVqww@mail.gmail.com>
	<CAJzKNY6xW4ano7Wo8EVtcGtmXfhkuM7fnyVoWx43T7cL8JpAyw@mail.gmail.com>
	<809BE39CD64BFD4EB9036172EBCCFA3116499322@S-MAIL-1B.rijksmuseum.intra>
Message-ID: <CAJzKNY64=XM7spO1jR4yxwx-J4vbw1zt=Rf1x3ir7JHKH355Hg@mail.gmail.com>

> Your question is certainly valid.
> There are still too many tests depending on some data to exist.
> Finding out why it no longer fails requires some (extensive?) digging into which patches were pushed in the meantime.

Jenkins is usually back to stable without any patch pushed. So an
intervention is done on the Jenkins DB on adding/updating/removing
data.

From chrisc at catalyst.net.nz  Wed Oct 30 18:49:03 2013
From: chrisc at catalyst.net.nz (Chris Cormack)
Date: Thu, 31 Oct 2013 06:49:03 +1300
Subject: [Koha-devel] Jenkins status [was Jenkins build is back to
 stable : Koha_master #1475]
In-Reply-To: <CAJzKNY64=XM7spO1jR4yxwx-J4vbw1zt=Rf1x3ir7JHKH355Hg@mail.gmail.com>
References: <CAJzKNY6GNtbUiSpoE6e9KnQNcSmXhSm+TpoAdB70CkSv2OVqww@mail.gmail.com>
	<CAJzKNY6xW4ano7Wo8EVtcGtmXfhkuM7fnyVoWx43T7cL8JpAyw@mail.gmail.com>
	<809BE39CD64BFD4EB9036172EBCCFA3116499322@S-MAIL-1B.rijksmuseum.intra>
	<CAJzKNY64=XM7spO1jR4yxwx-J4vbw1zt=Rf1x3ir7JHKH355Hg@mail.gmail.com>
Message-ID: <20131030174903.GW25622@rorohiko.wgtn.cat-it.co.nz>

* Jonathan Druart (jonathan.druart at biblibre.com) wrote:
> > Your question is certainly valid.
> > There are still too many tests depending on some data to exist.
> > Finding out why it no longer fails requires some (extensive?) digging into which patches were pushed in the meantime.
> 
> Jenkins is usually back to stable without any patch pushed. So an
> intervention is done on the Jenkins DB on adding/updating/removing
> data.

Not usually no, often the test is failing due to depending on external
data sources. XISBN.t is the prime example, it can fail because it
can't connect to the external data source.

The current failing test is Serials 
http://jenkins.koha-community.org/job/Koha_master/lastCompletedBuild/testReport/

01:10:42.908 #   Failed test 'test getting history from sub-scription'
01:10:42.909 #   at t/db_dependent/Serials.t line 59.
01:10:42.915 
01:10:42.915 #   Failed test 'Subscription has at least one serial'
01:10:42.916 #   at t/db_dependent/Serials.t line 62.

This one will be to do with data, and changes it started failing
http://jenkins.koha-community.org/job/Koha_master/1482/

When all the serials changes were pushed. 


It fails on my local machine too
Test Summary Report
-------------------
t/db_dependent/Serials.t (Wstat: 768 Tests: 35 Failed: 3)
  Failed tests:  6, 8-9
    Non-zero exit status: 3
    Files=1, Tests=35,  0 wallclock secs ( 0.04 usr  0.00 sys +  0.43
cusr  0.02 csys =  0.49 CPU)
Result: FAIL

Chris
-- 
Chris Cormack
Catalyst IT Ltd.
+64 4 803 2238
PO Box 11-053, Manners St, Wellington 6142, New Zealand

From danielg.koha at gmail.com  Wed Oct 30 19:53:45 2013
From: danielg.koha at gmail.com (Daniel Grobani)
Date: Wed, 30 Oct 2013 11:53:45 -0700
Subject: [Koha-devel] October 2013 Koha Community Newsletter has been
	published
Message-ID: <CAOeKewgSK01WscE1B3hdVKsoxGFbL5MQtKKquvpOgkMki5RNRQ@mail.gmail.com>

Hi,

The October 2013 edition of the Koha Community Newsletter has been
posted to http://koha-community.org/koha-community-newsletter-october-2013/.

Cheers,

Daniel Grobani
Koha Community Newsletter Editor

From gmc at esilibrary.com  Thu Oct 31 04:55:48 2013
From: gmc at esilibrary.com (Galen Charlton)
Date: Wed, 30 Oct 2013 20:55:48 -0700
Subject: [Koha-devel] String freeze for 3.14 starting at the end of the day
	tomorrow
Message-ID: <CAPLnt653eKKCq3hQ=ED6cxbUGAssLDPRrt3kbeWL_WwoaL7M+g@mail.gmail.com>

Hi,

As scheduled, string freeze will commence tomorrow -- specifically, at
23:59 in my time zone (U.S. PDT).  Upon completing merging in the remaining
viable 3.14 candidates tomorrow, I will be cutting the first beta of 3.14
tomorrow.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  gmc at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131030/51c1da58/attachment.html>

From chris at bigballofwax.co.nz  Thu Oct 31 08:42:31 2013
From: chris at bigballofwax.co.nz (Chris Cormack)
Date: Thu, 31 Oct 2013 20:42:31 +1300
Subject: [Koha-devel] Jenkins status [was Jenkins build is back to
 stable : Koha_master #1475]
In-Reply-To: <20131030174903.GW25622@rorohiko.wgtn.cat-it.co.nz>
References: <CAJzKNY6GNtbUiSpoE6e9KnQNcSmXhSm+TpoAdB70CkSv2OVqww@mail.gmail.com>
	<CAJzKNY6xW4ano7Wo8EVtcGtmXfhkuM7fnyVoWx43T7cL8JpAyw@mail.gmail.com>
	<809BE39CD64BFD4EB9036172EBCCFA3116499322@S-MAIL-1B.rijksmuseum.intra>
	<CAJzKNY64=XM7spO1jR4yxwx-J4vbw1zt=Rf1x3ir7JHKH355Hg@mail.gmail.com>
	<20131030174903.GW25622@rorohiko.wgtn.cat-it.co.nz>
Message-ID: <CA+95qVS4pkESuYPcjJfCm6hho_r-41nQmHbP27KvaNnQMrwp8Q@mail.gmail.com>

> -------------------
> t/db_dependent/Serials.t (Wstat: 768 Tests: 35 Failed: 3)
>   Failed tests:  6, 8-9
>     Non-zero exit status: 3
>     Files=1, Tests=35,  0 wallclock secs ( 0.04 usr  0.00 sys +  0.43
> cusr  0.02 csys =  0.49 CPU)
> Result: FAIL
>
This was fixed by

http://jenkins.koha-community.org/job/Koha_master/1487/changes

Chris

From jonathan.druart at biblibre.com  Thu Oct 31 16:29:00 2013
From: jonathan.druart at biblibre.com (Jonathan Druart)
Date: Thu, 31 Oct 2013 16:29:00 +0100
Subject: [Koha-devel] Jenkins status [was Jenkins build is back to
 stable : Koha_master #1475]
In-Reply-To: <20131030174903.GW25622@rorohiko.wgtn.cat-it.co.nz>
References: <CAJzKNY6GNtbUiSpoE6e9KnQNcSmXhSm+TpoAdB70CkSv2OVqww@mail.gmail.com>
	<CAJzKNY6xW4ano7Wo8EVtcGtmXfhkuM7fnyVoWx43T7cL8JpAyw@mail.gmail.com>
	<809BE39CD64BFD4EB9036172EBCCFA3116499322@S-MAIL-1B.rijksmuseum.intra>
	<CAJzKNY64=XM7spO1jR4yxwx-J4vbw1zt=Rf1x3ir7JHKH355Hg@mail.gmail.com>
	<20131030174903.GW25622@rorohiko.wgtn.cat-it.co.nz>
Message-ID: <CAJzKNY6OLk04CtafypVX+zUj-aTmfsL0jRMYEoMLQfbrp2fScA@mail.gmail.com>

Hello,

Thank you for your answer Chris !

So there are 3 kinds of failure causes:
1/ C4::XISBN::get_xisbns fails because the connection to an external
data source cannot be established.
2/ data is not created by the unit tests and does not exist in the sample files.
3/ a test "normally" fails

For 1, is it consistent to mock the connection ?
For 2, I think it could be resolved using the idea from bug 10337:
reset the DB data before launching tests.

It would be great to receive mails from Jenkins saying the master is
unstable only if is a code issue (and not a connection issue or a lack
of data).

Moreover, we have some unit test files which are never launched. So if
a regression is introduced on routines covered by these unit tests, we
are not alerted.
The prove command should be launched with the recursive flag.

Regards,
Jonathan

2013/10/30 Chris Cormack <chrisc at catalyst.net.nz>:
> * Jonathan Druart (jonathan.druart at biblibre.com) wrote:
>> > Your question is certainly valid.
>> > There are still too many tests depending on some data to exist.
>> > Finding out why it no longer fails requires some (extensive?) digging into which patches were pushed in the meantime.
>>
>> Jenkins is usually back to stable without any patch pushed. So an
>> intervention is done on the Jenkins DB on adding/updating/removing
>> data.
>
> Not usually no, often the test is failing due to depending on external
> data sources. XISBN.t is the prime example, it can fail because it
> can't connect to the external data source.
>
> The current failing test is Serials
> http://jenkins.koha-community.org/job/Koha_master/lastCompletedBuild/testReport/
>
> 01:10:42.908 #   Failed test 'test getting history from sub-scription'
> 01:10:42.909 #   at t/db_dependent/Serials.t line 59.
> 01:10:42.915
> 01:10:42.915 #   Failed test 'Subscription has at least one serial'
> 01:10:42.916 #   at t/db_dependent/Serials.t line 62.
>
> This one will be to do with data, and changes it started failing
> http://jenkins.koha-community.org/job/Koha_master/1482/
>
> When all the serials changes were pushed.
>
>
> It fails on my local machine too
> Test Summary Report
> -------------------
> t/db_dependent/Serials.t (Wstat: 768 Tests: 35 Failed: 3)
>   Failed tests:  6, 8-9
>     Non-zero exit status: 3
>     Files=1, Tests=35,  0 wallclock secs ( 0.04 usr  0.00 sys +  0.43
> cusr  0.02 csys =  0.49 CPU)
> Result: FAIL
>
> Chris
> --
> Chris Cormack
> Catalyst IT Ltd.
> +64 4 803 2238
> PO Box 11-053, Manners St, Wellington 6142, New Zealand

From gmc at esilibrary.com  Thu Oct 31 18:07:05 2013
From: gmc at esilibrary.com (Galen Charlton)
Date: Thu, 31 Oct 2013 10:07:05 -0700
Subject: [Koha-devel] OPAC theme proposal
In-Reply-To: <5270B88B.3060706@biblibre.com>
References: <CAPLnt66_e5Zw3osow5vH-8zz5Zj62Z1jwPjfzkMEUAmiF8a5SQ@mail.gmail.com>
	<CABZfb=U7fh2b6oQAjjKZ6iZOmAfMD5Gr5A5BXE7w74gXXYc_8A@mail.gmail.com>
	<CABZfb=VkCZLFyBiC+45Hm2-tTxUH_2bwrZdAEapcNiLRNyAP2Q@mail.gmail.com>
	<5270B88B.3060706@biblibre.com>
Message-ID: <CAPLnt64ioqwsMZub1VwenKN2CPEqY2L0myrXbNwShwvxjB5VGw@mail.gmail.com>

Hi,

On Wed, Oct 30, 2013 at 12:43 AM, Paul Poulain <paul.poulain at biblibre.com>wrote:

> Le 28/10/2013 23:17, Tomas Cohen Arazi a ?crit :
> > +1
> >
> > Six month seems enough for adjusting the css anyway.
> +1 for this proposal.
> I would also add : if someone can't adjust it's css, the 3.14 will be
> maintained for at least 6 months, probably one year, maybe more.
> So anyone can stay on 3.14 if needed.
>

Thanks for the feedback, everybody.  I have now pushed a patch to master
making Bootstrap the default OPAC theme for new installs.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  gmc at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131031/f13a435e/attachment.html>

From gmc at esilibrary.com  Thu Oct 31 18:26:37 2013
From: gmc at esilibrary.com (Galen Charlton)
Date: Thu, 31 Oct 2013 10:26:37 -0700
Subject: [Koha-devel] Jenkins status [was Jenkins build is back to
 stable : Koha_master #1475]
In-Reply-To: <CAJzKNY6OLk04CtafypVX+zUj-aTmfsL0jRMYEoMLQfbrp2fScA@mail.gmail.com>
References: <CAJzKNY6GNtbUiSpoE6e9KnQNcSmXhSm+TpoAdB70CkSv2OVqww@mail.gmail.com>
	<CAJzKNY6xW4ano7Wo8EVtcGtmXfhkuM7fnyVoWx43T7cL8JpAyw@mail.gmail.com>
	<809BE39CD64BFD4EB9036172EBCCFA3116499322@S-MAIL-1B.rijksmuseum.intra>
	<CAJzKNY64=XM7spO1jR4yxwx-J4vbw1zt=Rf1x3ir7JHKH355Hg@mail.gmail.com>
	<20131030174903.GW25622@rorohiko.wgtn.cat-it.co.nz>
	<CAJzKNY6OLk04CtafypVX+zUj-aTmfsL0jRMYEoMLQfbrp2fScA@mail.gmail.com>
Message-ID: <CAPLnt65H2YzsnH1BhRkhkHDQFpD3oQPHreXxqkx=c1cGXav_eA@mail.gmail.com>

Hi,

On Thu, Oct 31, 2013 at 8:29 AM, Jonathan Druart <
jonathan.druart at biblibre.com> wrote:

> So there are 3 kinds of failure causes:
> 1/ C4::XISBN::get_xisbns fails because the connection to an external
> data source cannot be established.
> 2/ data is not created by the unit tests and does not exist in the sample
> files.
> 3/ a test "normally" fails
>
> For 1, is it consistent to mock the connection ?
>

Mocking the connection is an option, but IMO it's better to attempt a real
connection, and have the test skip if the connection cannot be established.


> For 2, I think it could be resolved using the idea from bug 10337:
> reset the DB data before launching tests.
>

I think some tweaking is needed for that proposal.  It's one thing to have
Jenkins reset its database(s) before running a build, but I feel strongly
that we should encourage ordinary developers to feel free to run prove -v
t/db_dependent/whatever.t at any time against their main development
database.  We're pretty close to that being safe now, and once all of the
DB-dependent tests run in a transaction, it will be safe enough for a
developer to run any and all of the tests at will.

That's not to say that there shouldn't be scripts available for a developer
to set up a separate testing database and easily reset it at will, too, but
I don't think they belong as a mandatory test under t/db_dependent.

It would be great to receive mails from Jenkins saying the master is
> unstable only if is a code issue (and not a connection issue or a lack
> of data).
>

Well, there is always going to be the possibility of a problem with the
test system, so it's never going to be perfect.  For example, if nothing
else there will always be the possibility that the

I think it might be better if we give folks the option to subscribe to
emails from Jenkins, not get them automatically if one of their patches
just happens to be in a set that triggered a test failure.

RMs and RMaints need to care about Jenkins test results.  QA team members
should also care.  So should ordinary developers, but that doesn't
necessarily mean that they have to unconditionally get the nags from
Jenkins.


> Moreover, we have some unit test files which are never launched. So if
> a regression is introduced on routines covered by these unit tests, we
> are not alerted.
> The prove command should be launched with the recursive flag.
>

That would be a goal, but because of dependencies, particularly the Solr
stuff, we're not yet at the point where prove -r t/, when run on a Jenkins
build server, will not result in test failures.

If there are specific tests that you've noticed that aren't being run,
please enumerate them and I can adjust the Jenkins config.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  gmc at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131031/221a1133/attachment.html>