From liz at catalyst.net.nz  Fri May  1 00:15:43 2015
From: liz at catalyst.net.nz (Liz Rea)
Date: Fri, 01 May 2015 10:15:43 +1200
Subject: [Koha-devel] "News" area is gone
In-Reply-To: <CAArtO+foZrH476xtqKEU6OpuPtGLH0O1ce4_r9rirMpBoQykdw@mail.gmail.com>
References: <CAArtO+foZrH476xtqKEU6OpuPtGLH0O1ce4_r9rirMpBoQykdw@mail.gmail.com>
Message-ID: <5542A98F.9060900@catalyst.net.nz>

Hi Luciana

This issue is caused by a bug in Koha:
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12507

The good news is, it only happens on the last day of the month, and the
news will be back tomorrow. In other good news, the fix for it has
already been pushed into Koha upstream, so this problem won't occur once
you upgrade to an unaffected version (3.16.10, 3.18+).

If you need the contents of the news before tomorrow, you can look at
the news items directly in More -> Tools -> News -> then select the news
item.

Cheers,
Liz



On 01/05/15 01:36, Luciana Coca wrote:
> Hello everyone!
> The "News" area have dissappeared.
> The configuration and preferences are correct. I have deleted and
> created new News, but nothing happend.
> Please, help me.
>
> Thank you all.
> Luciana.
> _______________________________________________
> 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/

-- 
--
Liz Rea
Catalyst.Net Limited
Level 6, Catalyst House, 
150 Willis Street, Wellington.
P.O Box 11053, Manners Street, 
Wellington 6142

GPG: B149 A443 6B01 7386 C2C7 F481 B6c2 A49D 3726 38B7


From robin at catalyst.net.nz  Fri May  1 01:02:56 2015
From: robin at catalyst.net.nz (Robin Sheat)
Date: Fri, 01 May 2015 11:02:56 +1200
Subject: [Koha-devel] Problems with Indexdata idzebra-2.0 build (Zebra
 2.0.59)
In-Reply-To: <CABZfb=V=skYpy8dGEXh9OUfK4T4RcWqija+kHj7A+G2Hfu9t+w@mail.gmail.com>
References: <CABZfb=UzQhrUKMBPGiB_xqnUqvV_j1MGdRR5XwM67V12p=i=Eg@mail.gmail.com>
	<55420A74.40508@abunchofthings.net>
	<CABZfb=V=skYpy8dGEXh9OUfK4T4RcWqija+kHj7A+G2Hfu9t+w@mail.gmail.com>
Message-ID: <1430434976.15471.68.camel@catalyst.net.nz>

Tomas Cohen Arazi schreef op do 30-04-2015 om 10:23 [-0300]:
> It seems (from jenkins output) that search is broken on GRS-1 setups
> on Jessie.
> Which we don't really care as we dropped support for GRS-1 on 3.18.

There is something else wrong with the jessie version, too.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777515

-- 
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: 473 bytes
Desc: This is a digitally signed message part
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20150501/e407a337/attachment.pgp>

From bgkriegel at gmail.com  Fri May  1 16:15:20 2015
From: bgkriegel at gmail.com (Bernardo Gonzalez Kriegel)
Date: Fri, 1 May 2015 11:15:20 -0300
Subject: [Koha-devel] [Koha] Jenkins & the Manual
In-Reply-To: <CAC0K6VGe8QBsfqAJ5USdVGRPK76==K0OXK0cpBb-vi-ebSgGDA@mail.gmail.com>
References: <CAC0K6VGe8QBsfqAJ5USdVGRPK76==K0OXK0cpBb-vi-ebSgGDA@mail.gmail.com>
Message-ID: <CADF4kvQ1NAoTJRfptn_5NObzwGXP3NbSBKis5JhBQiZ9H8LgLQ@mail.gmail.com>

It's strange, I have no problems with the repo,
but Jenkins seems to have.

Fetching upstream changes from git://git.koha-community.org/kohadocs.git
 > git --version # timeout=10
 > git -c core.askpass=true fetch --tags --progress
git://git.koha-community.org/kohadocs.git
+refs/heads/*:refs/remotes/origin/*
ERROR: Timeout after 10 minutesERROR
<http://stacktrace.jenkins-ci.org/search?query=ERROR>: Error cloning
remote repo 'origin'ERROR
<http://stacktrace.jenkins-ci.org/search?query=ERROR>: Error cloning
remote repo 'origin'



-- 
Bernardo Gonzalez Kriegel
bgkriegel at gmail.com

On Thu, Apr 30, 2015 at 7:29 PM, Nicole Engard <nengard at gmail.com> wrote:

> Hi all,
>
> I don't know who manages this so I'm sorry to email everyone, but the
> manual on Jenkins is a big screwy.
>
> http://jenkins.koha-community.org/
>
> The 3.18 branch is missing and the master branch fails all the time
> but it generates the HTML and PDFs a-ok and shows no errors when I
> validate in Oxygen. Eventually the failures stop and it passes - so I
> know nothing is wrong with the manual itself, I wonder if something is
> screwy with the fact that the wrong branches are being checked.
>
> Nicole
> _______________________________________________
> Koha mailing list  http://koha-community.org
> Koha at lists.katipo.co.nz
> https://lists.katipo.co.nz/mailman/listinfo/koha
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20150501/f6d1419f/attachment.html>

From mtompset at hotmail.com  Sat May  2 03:57:01 2015
From: mtompset at hotmail.com (Mark Tompsett)
Date: Fri, 1 May 2015 21:57:01 -0400
Subject: [Koha-devel] prove xt results
Message-ID: <BLU172-DS618CBE430669198E32569C6D40@phx.gbl>

Greetings,

mtompset at debian:~/kohaclone$ prove xt
xt/permissions.t ............ ok
xt/sample_notices.t ......... 1/?
#   Failed test 'No sample notice to add'
#   at xt/sample_notices.t line 82.
# Sample notices to add in de-DE/mandatory/sample_notices.sql: DISCHARGE
# Looks like you failed 1 test of 34.
xt/sample_notices.t ......... Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/34 subtests
xt/single_quotes.t .......... ok
xt/tt_valid.t ............... ok
xt/verify-debian-docbook.t .. ok
xt/yaml_valid.t ............. ok

Test Summary Report
-------------------
xt/sample_notices.t       (Wstat: 256 Tests: 34 Failed: 1)
  Failed test:  9
  Non-zero exit status: 1
Files=6, Tests=117,  3 wallclock secs ( 0.03 usr  0.01 sys +  2.73 cusr  0.00 csys =  2.77 CPU)
Result: FAIL

Given that I don?t know what to add (in terms of language), I thought I?d mention it here so that some loving developer familiar with de-DE might remedy the situation.

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

From bgkriegel at gmail.com  Sat May  2 04:48:34 2015
From: bgkriegel at gmail.com (Bernardo Gonzalez Kriegel)
Date: Fri, 1 May 2015 23:48:34 -0300
Subject: [Koha-devel] prove xt results
In-Reply-To: <BLU172-DS618CBE430669198E32569C6D40@phx.gbl>
References: <BLU172-DS618CBE430669198E32569C6D40@phx.gbl>
Message-ID: <CADF4kvTY-JLskdtqc6wbOi+r1qBT7CLDcgaRihyKCubr28ZXKw@mail.gmail.com>

Good catch Mark!

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

Bernardo

-- 
Bernardo Gonzalez Kriegel
bgkriegel at gmail.com

On Fri, May 1, 2015 at 10:57 PM, Mark Tompsett <mtompset at hotmail.com> wrote:

>   Greetings,
>
> mtompset at debian:~/kohaclone$ prove xt
> xt/permissions.t ............ ok
> xt/sample_notices.t ......... 1/?
> #   Failed test 'No sample notice to add'
> #   at xt/sample_notices.t line 82.
> # Sample notices to add in de-DE/mandatory/sample_notices.sql: DISCHARGE
> # Looks like you failed 1 test of 34.
> xt/sample_notices.t ......... Dubious, test returned 1 (wstat 256, 0x100)
> Failed 1/34 subtests
> xt/single_quotes.t .......... ok
> xt/tt_valid.t ............... ok
> xt/verify-debian-docbook.t .. ok
> xt/yaml_valid.t ............. ok
>
> Test Summary Report
> -------------------
> xt/sample_notices.t       (Wstat: 256 Tests: 34 Failed: 1)
>   Failed test:  9
>   Non-zero exit status: 1
> Files=6, Tests=117,  3 wallclock secs ( 0.03 usr  0.01 sys +  2.73 cusr
> 0.00 csys =  2.77 CPU)
> Result: FAIL
>
> Given that I don?t know what to add (in terms of language), I thought I?d
> mention it here so that some loving developer familiar with de-DE might
> remedy the situation.
>
> GPML,
> Mark Tompsett
>
> _______________________________________________
> 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/20150501/04392fde/attachment.html>

From tomascohen at gmail.com  Mon May  4 04:38:50 2015
From: tomascohen at gmail.com (Tomas Cohen Arazi)
Date: Sun, 3 May 2015 23:38:50 -0300
Subject: [Koha-devel] [Koha] Jenkins & the Manual
In-Reply-To: <CADF4kvQ1NAoTJRfptn_5NObzwGXP3NbSBKis5JhBQiZ9H8LgLQ@mail.gmail.com>
References: <CAC0K6VGe8QBsfqAJ5USdVGRPK76==K0OXK0cpBb-vi-ebSgGDA@mail.gmail.com>
	<CADF4kvQ1NAoTJRfptn_5NObzwGXP3NbSBKis5JhBQiZ9H8LgLQ@mail.gmail.com>
Message-ID: <CABZfb=Ux5oXnjt7BJ+0M2VYMVW=BM70kHm3eQLe75h6zEqEM=w@mail.gmail.com>

Bernardo, the problem is the 10 minutes timeout the jenkins process has.
The solution is to manually clone the first time and assign the right
permissions.

I'll take a look tomorrow, but I think we should make Galen a call as it is
his node.

Regards
El 1/5/2015 11:15 a. m., "Bernardo Gonzalez Kriegel" <bgkriegel at gmail.com>
escribi?:

> It's strange, I have no problems with the repo,
> but Jenkins seems to have.
>
> Fetching upstream changes from git://git.koha-community.org/kohadocs.git
>  > git --version # timeout=10
>  > git -c core.askpass=true fetch --tags --progress git://git.koha-community.org/kohadocs.git +refs/heads/*:refs/remotes/origin/*
> ERROR: Timeout after 10 minutesERROR <http://stacktrace.jenkins-ci.org/search?query=ERROR>: Error cloning remote repo 'origin'ERROR <http://stacktrace.jenkins-ci.org/search?query=ERROR>: Error cloning remote repo 'origin'
>
>
>
> --
> Bernardo Gonzalez Kriegel
> bgkriegel at gmail.com
>
> On Thu, Apr 30, 2015 at 7:29 PM, Nicole Engard <nengard at gmail.com> wrote:
>
>> Hi all,
>>
>> I don't know who manages this so I'm sorry to email everyone, but the
>> manual on Jenkins is a big screwy.
>>
>> http://jenkins.koha-community.org/
>>
>> The 3.18 branch is missing and the master branch fails all the time
>> but it generates the HTML and PDFs a-ok and shows no errors when I
>> validate in Oxygen. Eventually the failures stop and it passes - so I
>> know nothing is wrong with the manual itself, I wonder if something is
>> screwy with the fact that the wrong branches are being checked.
>>
>> Nicole
>> _______________________________________________
>> Koha mailing list  http://koha-community.org
>> Koha at lists.katipo.co.nz
>> https://lists.katipo.co.nz/mailman/listinfo/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/20150503/6699437e/attachment.html>

From dcook at prosentient.com.au  Mon May  4 04:57:03 2015
From: dcook at prosentient.com.au (David Cook)
Date: Mon, 4 May 2015 12:57:03 +1000
Subject: [Koha-devel] Problems with Indexdata idzebra-2.0 build (Zebra
	2.0.59)
In-Reply-To: <1430434976.15471.68.camel@catalyst.net.nz>
References: <CABZfb=UzQhrUKMBPGiB_xqnUqvV_j1MGdRR5XwM67V12p=i=Eg@mail.gmail.com>	<55420A74.40508@abunchofthings.net>	<CABZfb=V=skYpy8dGEXh9OUfK4T4RcWqija+kHj7A+G2Hfu9t+w@mail.gmail.com>
	<1430434976.15471.68.camel@catalyst.net.nz>
Message-ID: <050501d08615$ffb21340$ff1639c0$@prosentient.com.au>

As Robin points out, the 2.0.59 version of Zebra has another problem as well.

When using ICU, words with hyphens aren't tokenized correctly. 

For instance, "Mont-Royal" would be truncated down to "Mont" both at indexing and search time. 

So a query for "Mont-Royal" would indeed return the records for "Mont-Royal", but it would also return the records for "Mont-Liban". 

A query for "Royal" would also return no records for "Mont-Royal" as well. 

Dreadful.

However, IndexData have fixed this problem with Zebra 2.0.60. 

So... that's a thing. At the moment, the easiest most short-term fix to me is to point to IndexData's Debian repositories, but I don't  think that'll be acceptable as a long-term solution. 

We mostly use OpenSuse, and I managed to get them to add Zebra 2.0.60 to their stable repositories, so we're OK for now. 

Now that Jessie has been released, perhaps there's a higher chance of the fix getting into Debian stable as well?

David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St, Ultimo, NSW 2007

> -----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: Friday, 1 May 2015 9:03 AM
> To: koha-devel at lists.koha-community.org
> Subject: Re: [Koha-devel] Problems with Indexdata idzebra-2.0 build (Zebra
> 2.0.59)
> 
> Tomas Cohen Arazi schreef op do 30-04-2015 om 10:23 [-0300]:
> > It seems (from jenkins output) that search is broken on GRS-1 setups
> > on Jessie.
> > Which we don't really care as we dropped support for GRS-1 on 3.18.
> 
> There is something else wrong with the jessie version, too.
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777515
> 
> --
> Robin Sheat
> Catalyst IT Ltd.
> ? +64 4 803 2204
> GPG: 5FA7 4B49 1E4D CAA4 4C38  8505 77F5 B724 F871 3BDF



From indradg at gmail.com  Mon May  4 16:13:18 2015
From: indradg at gmail.com (Indranil Das Gupta)
Date: Mon, 4 May 2015 19:43:18 +0530
Subject: [Koha-devel] About "Free" as variabletype in Local use syspref
	definitions
Message-ID: <CAEm3SZ1SRS+HFVeOT0hvsrDKEzzwh1aGZYm565NmFNTAY-vJ1A@mail.gmail.com>

Hi,

I needed to add a few Local Use sysprefs - SMSSendUsername /
SMSSendPassword - both of which are of 'Free' variabl type0 (the
default type if the Koha Internal fieldset options are not used)

IMHO having the option 'Free' offered as well in the list might be a
good idea. I've filed a bug and posted a trivial patch against
systempreferences.tt at
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14135

Would like some feedback. If the general opinion is it is not
required, I'll close it as 'RESOLVED WONTFIX'

thanks

-- 
Indranil Das Gupta

Phone : +91-98300-20971
Blog    : http://indradg.randomink.org/blog
IRC      : indradg on irc://irc.freenode.net
Twitter : indradg

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-
Please exchange editable Office documents only in ODF Format. No other
format is acceptable. Support Open Standards.

For a free editor supporting ODF, please visit LibreOffice -
http://www.documentfoundation.org

From mtompset at hotmail.com  Tue May  5 01:15:59 2015
From: mtompset at hotmail.com (Mark Tompsett)
Date: Mon, 4 May 2015 19:15:59 -0400
Subject: [Koha-devel] Cleaner tests
Message-ID: <BLU172-DS19CFEF4E59863EB4E1A810C6D20@phx.gbl>

Greetings,

Bugs 14110-14118,14120-14121 make ?prove t? less noisy. Feedback and sign offs appreciated. 

GPML,
Mark Tompsett

P.S. More test cleaning up coming, Tomas. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20150504/f08439da/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wlEmoticon-smile[1].png
Type: image/png
Size: 1046 bytes
Desc: not available
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20150504/f08439da/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wlEmoticon-winkingsmile[1].png
Type: image/png
Size: 1135 bytes
Desc: not available
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20150504/f08439da/attachment-0001.png>

From mirko at abunchofthings.net  Tue May  5 12:17:03 2015
From: mirko at abunchofthings.net (Mirko Tietgen)
Date: Tue, 05 May 2015 11:17:03 +0100
Subject: [Koha-devel] General IRC Meeting 06 May 2015 / Roles for 3.22
Message-ID: <5548989F.9030108@abunchofthings.net>

Dear list,

this is a quick reminder about the Koha Community General IRC
Meeting in about 24 hours, 06 May 2015 10:00 UTC. Get your local
time for the event at
http://www.timeanddate.com/worldclock/fixedtime.html?msg=Koha+IRC+General+Meeting&iso=20150506T10

Among other things, we will decide on the team for the Koha 3.22
release. A list of roles and candidates can be found at
http://wiki.koha-community.org/wiki/Roles_for_3.22

You can find the full agenda of the meeting at
http://wiki.koha-community.org/wiki/General_IRC_meeting_6_May_2015

-- Mirko


--

Mirko Tietgen
mirko at abunchofthings.net
http://koha.abunchofthings.net

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

From ISM at kis.in  Tue May  5 12:37:30 2015
From: ISM at kis.in (KIS ISM)
Date: Tue, 5 May 2015 10:37:30 +0000
Subject: [Koha-devel] Koha 3.18 and Ldap with Active Directory not working
Message-ID: <980d71abc55d42c0b03d3ea494ead2ae@SerEx1.kis.in>

Hi,

I'm having such a hard time to get ldap with AD (on Windows Server 2012 R2) to work - now trying on 3.18.3

Koha login does see whether username/password is correct but exists with error on correct username/password.

Yes, I changed <userid is="cn"></userid>  and <principal_name>%s at kis.in</principal_name> to all the different variations I did find no the net. No success.
Does anyone have any ideas?

Rudy Wuthrich, Kodaikanal International School

This is my ldap part from koha-config.xml

<useldapserver>1</useldapserver><!-- see C4::Auth_with_ldap for extra configs you must add if you want to turn this on -->
<ldapserver id="ldapserver"  listenref="ldapserver">
<hostname>ldaps://serad1.kis.in</hostname>
<base>OU=KISaaaa,OU=KISbbbb,DC=kis,DC=in</base>
<user>CN=ldapuser,DC=kis,DC=in</user>
<pass>password</pass>
<replicate>1</replicate>
<update>1</update>
<auth_by_bind>1</auth_by_bind>
<principal_name>%s at kis.in</principal_name>

<mapping>
<firstname    is="givenname"></firstname>
<surname      is="sn"> </surname>
<address      is="">KIS</address>
<userid       is="cn"></userid>
<password     is=""></password>
<email        is="mail"></email>
<phone        is=""></phone>
</mapping>

Here is what happens:

When I try with wrong username/password

?    You entered an incorrect

With correct username/password
Software error:

LDAP search failed to return object : 0000208D: NameErr: DSID-03100238, problem 2001 (NO_OBJECT), data 0, best match of:

            'OU=KISStaff,DC=kis,DC=in'

 at /usr/share/koha/lib/C4/Auth_with_ldap.pm line 92.

For help, please send mail to the webmaster ([no address given]<mailto:[no%20address%20given]>), giving this error message and the time and date of the error.
And from the opac-error.log
[Tue May 05 15:57:37 2015] [error] [client 172.16.98.24] [Tue May  5 15:57:37 2015] opac-user.pl: LDAP search failed to return object : 0000208D: NameErr: DSID-03100238, problem 2001 (NO_OBJECT), data 0, best match of:, referer: http://172.16.60.73:8000/cgi-bin/koha/opac-user.pl
[Tue May 05 15:57:37 2015] [error] [client 172.16.98.24] [Tue May  5 15:57:37 2015] opac-user.pl: \t'OU=KISStaff,DC=kis,DC=in', referer: http://172.16.60.73:8000/cgi-bin/koha/opac-user.pl
[Tue May 05 15:57:37 2015] [error] [client 172.16.98.24] [Tue May  5 15:57:37 2015] opac-user.pl: , referer: http://172.16.60.73:8000/cgi-bin/koha/opac-user.pl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20150505/6188aae4/attachment.html>

From michael.hafen at washk12.org  Tue May  5 18:31:16 2015
From: michael.hafen at washk12.org (Michael Hafen)
Date: Tue, 5 May 2015 10:31:16 -0600
Subject: [Koha-devel] Koha 3.18 and Ldap with Active Directory not
	working
In-Reply-To: <980d71abc55d42c0b03d3ea494ead2ae@SerEx1.kis.in>
References: <980d71abc55d42c0b03d3ea494ead2ae@SerEx1.kis.in>
Message-ID: <CAAh7Udk7SFf5kEzF5AsnTTTFrUR_JTst=kFGQdLieYMQoJZNsg@mail.gmail.com>

Usually, in AD, the beginning of the principal name is the same as the
sAMAccountName, have you tried that in the mapping for userid?

On Tue, May 5, 2015 at 4:37 AM, KIS ISM <ISM at kis.in> wrote:

>  Hi,
>
>
>
> I?m having such a hard time to get ldap with AD (on Windows Server 2012
> R2) to work ? now trying on 3.18.3
>
>
>
> Koha login does see whether username/password is correct but exists with
> error on correct username/password.
>
>
>
> Yes, I changed <userid is="cn"></userid>  and <principal_name>%s at kis.in</principal_name>
> to all the different variations I did find no the net. No success.
>
> Does anyone have any ideas?
>
>
>
> Rudy Wuthrich, Kodaikanal International School
>
>
>
> This is my ldap part from koha-config.xml
>
>
>
> <useldapserver>1</useldapserver><!-- see C4::Auth_with_ldap for extra
> configs you must add if you want to turn this on -->
>
> <ldapserver id="ldapserver"  listenref="ldapserver">
>
> <hostname>ldaps://serad1.kis.in</hostname>
>
> <base>OU=KISaaaa,OU=KISbbbb,DC=kis,DC=in</base>
>
> <user>CN=ldapuser,DC=kis,DC=in</user>
>
> <pass>password</pass>
>
> <replicate>1</replicate>
>
> <update>1</update>
>
> <auth_by_bind>1</auth_by_bind>
>
> <principal_name>%s at kis.in</principal_name>
>
>
>
> <mapping>
>
> <firstname    is="givenname"></firstname>
>
> <surname      is="sn"> </surname>
>
> <address      is="">KIS</address>
>
> <userid       is="cn"></userid>
>
> <password     is=""></password>
>
> <email        is="mail"></email>
>
> <phone        is=""></phone>
>
> </mapping>
>
>
>
> Here is what happens:
>
>
>
> When I try with wrong username/password
>
> ?    You entered an incorrect
>
>
>
> With correct username/password
> Software error:
>
> LDAP search failed to return object : 0000208D: NameErr: DSID-03100238, problem 2001 (NO_OBJECT), data 0, best match of:
>
>             'OU=KISStaff,DC=kis,DC=in'
>
>  at /usr/share/koha/lib/C4/Auth_with_ldap.pm line 92.
>
> For help, please send mail to the webmaster ([no address given]), giving
> this error message and the time and date of the error.
>
> And from the opac-error.log
>
> [Tue May 05 15:57:37 2015] [error] [client 172.16.98.24] [Tue May  5
> 15:57:37 2015] opac-user.pl: LDAP search failed to return object :
> 0000208D: NameErr: DSID-03100238, problem 2001 (NO_OBJECT), data 0, best
> match of:, referer: http://172.16.60.73:8000/cgi-bin/koha/opac-user.pl
>
> [Tue May 05 15:57:37 2015] [error] [client 172.16.98.24] [Tue May  5
> 15:57:37 2015] opac-user.pl: \t'OU=KISStaff,DC=kis,DC=in', referer:
> http://172.16.60.73:8000/cgi-bin/koha/opac-user.pl
>
> [Tue May 05 15:57:37 2015] [error] [client 172.16.98.24] [Tue May  5
> 15:57:37 2015] opac-user.pl: , referer:
> http://172.16.60.73:8000/cgi-bin/koha/opac-user.pl
>
> _______________________________________________
> 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/
>



-- 
Michael Hafen
Washington County School District Technology Department
Systems Analyst
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20150505/9de6445c/attachment-0001.html>

From tomascohen at gmail.com  Wed May  6 17:54:39 2015
From: tomascohen at gmail.com (Tomas Cohen Arazi)
Date: Wed, 6 May 2015 12:54:39 -0300
Subject: [Koha-devel] Jenkins emails / explanation
Message-ID: <CABZfb=WFvYzLoS8xhtNEzuHfLuX7Uzz4JD=mRG1Eg=b1qkfQ7w@mail.gmail.com>

We might have become used to not receiving Jenkins emails regarding
regressions.
So I decided to send this short explanation of what they are and what are
the expected steps when you receive one.

Jenkins sends emails to authors of patches that got pushed into the branch
being tested, in the event of some tests starting to fail on that push.

The expected behaviour from devs is to check the link provided, and browse
to the 'Test results' section on the left (not sure the wording, mine is in
spanish and didn't figure/look how to change it).

There you'll see the failing tests. It is expected that you check if it is
related to your patches, and in case it is, contact me or the release
maintainer to talk about the problem introduced. This might yield to a
followup on the bug, or a new bug. It will depend on the situation but I
doesn't really matter.

Right now some tests are failing randomly, and is consistent with us
running the tests randomly too :-D (prove -s) It seems to mean that some of
our tests do have side effects that change the scenario for the rest of the
tests.

Anyone interested in taking on this inter-test dependency please let me
know. I don't have the time to do it right now, so close to the release.
But fixing it (either the tests or the hidden bugs) would be great. It
would make our tests and the product as a whole, just better.

Kind regards

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

From mtompset at hotmail.com  Wed May  6 20:37:41 2015
From: mtompset at hotmail.com (Mark Tompsett)
Date: Wed, 6 May 2015 14:37:41 -0400
Subject: [Koha-devel] Jenkins emails / explanation
In-Reply-To: <CABZfb=WFvYzLoS8xhtNEzuHfLuX7Uzz4JD=mRG1Eg=b1qkfQ7w@mail.gmail.com>
References: <CABZfb=WFvYzLoS8xhtNEzuHfLuX7Uzz4JD=mRG1Eg=b1qkfQ7w@mail.gmail.com>
Message-ID: <BLU172-DS14C9785A3522737AD6578C6D00@phx.gbl>

Greetings,
http://jenkins.koha-community.org/job/Koha_Master_D8/39/console
I know that this:
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14103
will at least solve part of the floody emails. Sign off anyone?
GPML,
Mark Tompsett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20150506/49e5c58b/attachment.html>

From kohanews at gmail.com  Wed May  6 20:56:34 2015
From: kohanews at gmail.com (kohanews)
Date: Wed, 06 May 2015 11:56:34 -0700
Subject: [Koha-devel] Koha Community Newsletter: April 2015
Message-ID: <554A63E2.2000105@gmail.com>

Fellow Koha users:

The Koha Community Newsletter for April 2015 is here:
http://koha-community.org/koha-community-newsletter-april-2015/

Many thanks to the folks who submitted articles and news to this month's 
newsletter.

Please feel free to email me with any corrections or suggestions.

Thanks!

Chad Roseburg
Editor, Koha Community Newsletter

From nengard at gmail.com  Thu May  7 01:33:38 2015
From: nengard at gmail.com (Nicole Engard)
Date: Wed, 6 May 2015 18:33:38 -0500
Subject: [Koha-devel] [Koha] Jenkins & the Manual
In-Reply-To: <CABZfb=Ux5oXnjt7BJ+0M2VYMVW=BM70kHm3eQLe75h6zEqEM=w@mail.gmail.com>
References: <CAC0K6VGe8QBsfqAJ5USdVGRPK76==K0OXK0cpBb-vi-ebSgGDA@mail.gmail.com>
	<CADF4kvQ1NAoTJRfptn_5NObzwGXP3NbSBKis5JhBQiZ9H8LgLQ@mail.gmail.com>
	<CABZfb=Ux5oXnjt7BJ+0M2VYMVW=BM70kHm3eQLe75h6zEqEM=w@mail.gmail.com>
Message-ID: <CAC0K6VEimZ72iAF4=br7j8qGjuHbieYqJ8vP5v=J8n0B5JJqCg@mail.gmail.com>

Galen,

Any luck fixing this - now that emails are sending it's rather
annoying to get these emails every time I submit a patch when things
are working - it's making me ignore them all.

Nicole

On Sun, May 3, 2015 at 9:38 PM, Tomas Cohen Arazi <tomascohen at gmail.com> wrote:
> Bernardo, the problem is the 10 minutes timeout the jenkins process has.
> The solution is to manually clone the first time and assign the right
> permissions.
>
> I'll take a look tomorrow, but I think we should make Galen a call as it is
> his node.
>
> Regards
>
> El 1/5/2015 11:15 a. m., "Bernardo Gonzalez Kriegel" <bgkriegel at gmail.com>
> escribi?:
>>
>> It's strange, I have no problems with the repo,
>> but Jenkins seems to have.
>>
>> Fetching upstream changes from git://git.koha-community.org/kohadocs.git
>>  > git --version # timeout=10
>>  > git -c core.askpass=true fetch --tags --progress
>> git://git.koha-community.org/kohadocs.git
>> +refs/heads/*:refs/remotes/origin/*
>> ERROR: Timeout after 10 minutes
>> ERROR: Error cloning remote repo 'origin'
>> ERROR: Error cloning remote repo 'origin'
>>
>>
>>
>> --
>> Bernardo Gonzalez Kriegel
>> bgkriegel at gmail.com
>>
>> On Thu, Apr 30, 2015 at 7:29 PM, Nicole Engard <nengard at gmail.com> wrote:
>>>
>>> Hi all,
>>>
>>> I don't know who manages this so I'm sorry to email everyone, but the
>>> manual on Jenkins is a big screwy.
>>>
>>> http://jenkins.koha-community.org/
>>>
>>> The 3.18 branch is missing and the master branch fails all the time
>>> but it generates the HTML and PDFs a-ok and shows no errors when I
>>> validate in Oxygen. Eventually the failures stop and it passes - so I
>>> know nothing is wrong with the manual itself, I wonder if something is
>>> screwy with the fact that the wrong branches are being checked.
>>>
>>> Nicole
>>> _______________________________________________
>>> Koha mailing list  http://koha-community.org
>>> Koha at lists.katipo.co.nz
>>> https://lists.katipo.co.nz/mailman/listinfo/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/

From bob at calyx.net.au  Thu May  7 04:35:39 2015
From: bob at calyx.net.au (Bob Birchall)
Date: Thu, 07 May 2015 12:35:39 +1000
Subject: [Koha-devel] Learning Tools Interoperability
Message-ID: <554ACF7B.4010701@calyx.net.au>

Hi,
I've been asked if Koha has support for LTI and if not, is it in a road map?
I guess they mean this: 
http://en.wikipedia.org/wiki/Learning_Tools_Interoperability

Its not something I have heard of before.  Any thoughts?
Thank you,
Bob Birchall
Calyx

From mirko at abunchofthings.net  Thu May  7 13:56:59 2015
From: mirko at abunchofthings.net (Mirko Tietgen)
Date: Thu, 07 May 2015 12:56:59 +0100
Subject: [Koha-devel] Learning Tools Interoperability
In-Reply-To: <554ACF7B.4010701@calyx.net.au>
References: <554ACF7B.4010701@calyx.net.au>
Message-ID: <554B530B.5030900@abunchofthings.net>

Hi Bob,

Bob Birchall schrieb am 07.05.2015

> Hi, I've been asked if Koha has support for LTI and if not, is it
> in a road map? I guess they mean this: 
> http://en.wikipedia.org/wiki/Learning_Tools_Interoperability
> 
> Its not something I have heard of before.  Any thoughts?

I came across this a while back when I started using
BigBlueButton.[1] This is more like an overview of things I found
than an opinion on LTI support in Koha.

Basically there are hosts (called ?consumers?) and plugins (called
?tools?) that are supposed to allow easy interoperability. Hosts can
be learning management systems like moodle[2] (often used by german
universities), tools can be a lot of different things. I found a
list here.[3]

There seems to be only a small number of Free Software tools
available (only searched the page for ?open?, did not check all
corresponding websites).

When I did my research, I was thinking of Koha as a host, so I could
have BigBlueButton as a tool in Koha. It's also possible the person
that asked you was thinking of Koha as a tool within a different
host (have the OPAC or some administration within an LMS maybe?).
The latter would probably only work on a per-Koha-module-level.

I did not find the specs the last time and thought it was only
available to members (and lost interest quickly). Seems like that is
not true. I have not had a look at it but I have the link here so
I'll add it.[4] This is the first version, others can be found in
the overview page.[5]

LTI certification for software seems to be bound to membership.
Assuming Koha as a community project would be considered a
non-profit organisation, that is $500 US per year.[6] If i'm not
mistaken, it is possible to implement LTI without certification.

-- Mirko


[1] http://bigbluebutton.org/
[2] https://moodle.org
[3] http://developers.imsglobal.org/catalog.html
[4] http://www.imsglobal.org/lti/blti/bltiv1p0/ltiBLTIimgv1p0.html
[5] http://www.imsglobal.org/lti/index.html
[6] http://www.imsglobal.org/cc/jointhealliance.cfm



-- 

Mirko Tietgen
mirko at abunchofthings.net
http://koha.abunchofthings.net

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

From Giuseppe.Angilella at ct.infn.it  Fri May  8 15:13:03 2015
From: Giuseppe.Angilella at ct.infn.it (Giuseppe Angilella)
Date: Fri, 8 May 2015 15:13:03 +0200 (CEST)
Subject: [Koha-devel] staff member responsible of loan/renewal recorded in
	issues?
Message-ID: <alpine.LFD.2.10.1505081506340.2724@localhost>

Dear Kohaers,

is the information concerning which staff member was responsible of a loan 
or renewal of a given item recorded anywhere in the database? I couldn't 
find it in the "issues" tables.

Assuming it is not, it could be a relevant information to record, in cases 
where several staff members (or even all patrons) have issueing 
privileges.

Many thanks,

Giuseppe.

From veron at veron.ch  Fri May  8 16:34:29 2015
From: veron at veron.ch (=?windows-1252?Q?Marc_V=E9ron?=)
Date: Fri, 08 May 2015 16:34:29 +0200
Subject: [Koha-devel] staff member responsible of loan/renewal recorded
 in issues?
In-Reply-To: <alpine.LFD.2.10.1505081506340.2724@localhost>
References: <alpine.LFD.2.10.1505081506340.2724@localhost>
Message-ID: <554CC975.8070109@veron.ch>

Hi Giuseppe,

Go to:
Home > Tools > Log Viewer

Select "Modules" > Circulation

Regards,

Marc


From indradg at gmail.com  Sat May  9 15:49:15 2015
From: indradg at gmail.com (Indranil Das Gupta)
Date: Sat, 9 May 2015 19:19:15 +0530
Subject: [Koha-devel] I think I just messed up on signing 13673
Message-ID: <CAEm3SZ1Raso+MhAKSpGkjho3jQn6Zj6bbAY-+Depok+6TVWTaA@mail.gmail.com>

first timer mess-ups

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13673#c6

how do I revert this?

thanks!

-- 
Indranil Das Gupta

Phone : +91-98300-20971
Blog    : http://indradg.randomink.org/blog
IRC      : indradg on irc://irc.freenode.net
Twitter : indradg

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-
Please exchange editable Office documents only in ODF Format. No other
format is acceptable. Support Open Standards.

For a free editor supporting ODF, please visit LibreOffice -
http://www.documentfoundation.org

From tomascohen at gmail.com  Sat May  9 16:43:01 2015
From: tomascohen at gmail.com (Tomas Cohen Arazi)
Date: Sat, 9 May 2015 11:43:01 -0300
Subject: [Koha-devel] I think I just messed up on signing 13673
In-Reply-To: <CAEm3SZ1Raso+MhAKSpGkjho3jQn6Zj6bbAY-+Depok+6TVWTaA@mail.gmail.com>
References: <CAEm3SZ1Raso+MhAKSpGkjho3jQn6Zj6bbAY-+Depok+6TVWTaA@mail.gmail.com>
Message-ID: <CABZfb=XkpkaZNG7neAtLF_mDTMJjb=XW3G5y5cpzc59npC2FXw@mail.gmail.com>

On the details of the attachment, obsolete it. It is not big deal so no
worries!
El 9/5/2015 10:49 a. m., "Indranil Das Gupta" <indradg at gmail.com> escribi?:

> first timer mess-ups
>
> http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13673#c6
>
> how do I revert this?
>
> thanks!
>
> --
> Indranil Das Gupta
>
> Phone : +91-98300-20971
> Blog    : http://indradg.randomink.org/blog
> IRC      : indradg on irc://irc.freenode.net
> Twitter : indradg
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-
> Please exchange editable Office documents only in ODF Format. No other
> format is acceptable. Support Open Standards.
>
> For a free editor supporting ODF, please visit LibreOffice -
> http://www.documentfoundation.org
> _______________________________________________
> 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/20150509/824c6b82/attachment.html>

From mtompset at hotmail.com  Sat May  9 23:18:59 2015
From: mtompset at hotmail.com (Mark Tompsett)
Date: Sat, 9 May 2015 17:18:59 -0400
Subject: [Koha-devel] I think I just messed up on signing 13673
In-Reply-To: <CABZfb=XkpkaZNG7neAtLF_mDTMJjb=XW3G5y5cpzc59npC2FXw@mail.gmail.com>
References: <CAEm3SZ1Raso+MhAKSpGkjho3jQn6Zj6bbAY-+Depok+6TVWTaA@mail.gmail.com>
	<CABZfb=XkpkaZNG7neAtLF_mDTMJjb=XW3G5y5cpzc59npC2FXw@mail.gmail.com>
Message-ID: <BLU172-DS16B685C9F782608C47A64BC6DD0@phx.gbl>

Greetings,

All is back to a semblance of order. Patch 1 and 3 still need sign off. 
GPML,
Mark Tompsett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20150509/1f851ee2/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wlEmoticon-smile[1].png
Type: image/png
Size: 1046 bytes
Desc: not available
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20150509/1f851ee2/attachment.png>

From pablo.bianchi at gmail.com  Sun May 10 06:56:34 2015
From: pablo.bianchi at gmail.com (Pablo Bianchi)
Date: Sun, 10 May 2015 01:56:34 -0300
Subject: [Koha-devel] SQL Reports Library v2.0
Message-ID: <CAH2zftFPrdcuu_B6hYs3FM0_L+qVPz41AF4MOXb8ziyj63E08A@mail.gmail.com>

Hi,

I count more than 300 reports on *SQL Reports Library*, is getting a little
bit out of control. Become difficult to:
+ found the needed report,
+ tag them,
+ talk about the report,
+ track easily contributions to each one,
+ link "related" reports, different flavors of the same one,
+ vote them,
+ add easily to Koha,
+ get statistic information,
and much more.

I'm not sure what is the best solution. An ad hoc web development? A friend
suggest me Semanticscuttle <http://semanticscuttle.sourceforge.net/>.
Trying to at least make things more tidy I create: SQL Reports Library in
templates
<http://wiki.koha-community.org/wiki/SQL_Reports_Library_in_templates>
(equivalent
to the usual but using mediawiki templates). This use Template:Report
<http://wiki.koha-community.org/wiki/Template:Report>.

Some things happens (or will happen) with JQuery and SQL libraries: A wiki
page is not a good library/database.

Regards,
Pablo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20150510/ede78de7/attachment.html>

From bob at calyx.net.au  Mon May 11 00:36:38 2015
From: bob at calyx.net.au (Bob Birchall)
Date: Mon, 11 May 2015 08:36:38 +1000
Subject: [Koha-devel] Learning Tools Interoperability
In-Reply-To: <554B530B.5030900@abunchofthings.net>
References: <554ACF7B.4010701@calyx.net.au>
	<554B530B.5030900@abunchofthings.net>
Message-ID: <554FDD76.2070904@calyx.net.au>

On 07/05/15 21:56, Mirko Tietgen wrote:
> Hi Bob,
>
> Bob Birchall schrieb am 07.05.2015
>
>> Hi, I've been asked if Koha has support for LTI and if not, is it
>> in a road map? I guess they mean this:
>> http://en.wikipedia.org/wiki/Learning_Tools_Interoperability
>>
>> Its not something I have heard of before.  Any thoughts?
> I came across this a while back when I started using
> BigBlueButton.[1] This is more like an overview of things I found
> than an opinion on LTI support in Koha.
>
> Basically there are hosts (called ?consumers?) and plugins (called
> ?tools?) that are supposed to allow easy interoperability. Hosts can
> be learning management systems like moodle[2] (often used by german
> universities), tools can be a lot of different things. I found a
> list here.[3]
>
> There seems to be only a small number of Free Software tools
> available (only searched the page for ?open?, did not check all
> corresponding websites).
>
> When I did my research, I was thinking of Koha as a host, so I could
> have BigBlueButton as a tool in Koha. It's also possible the person
> that asked you was thinking of Koha as a tool within a different
> host (have the OPAC or some administration within an LMS maybe?).
> The latter would probably only work on a per-Koha-module-level.
>
> I did not find the specs the last time and thought it was only
> available to members (and lost interest quickly). Seems like that is
> not true. I have not had a look at it but I have the link here so
> I'll add it.[4] This is the first version, others can be found in
> the overview page.[5]
>
> LTI certification for software seems to be bound to membership.
> Assuming Koha as a community project would be considered a
> non-profit organisation, that is $500 US per year.[6] If i'm not
> mistaken, it is possible to implement LTI without certification.
>
> -- Mirko
>
>
> [1] http://bigbluebutton.org/
> [2] https://moodle.org
> [3] http://developers.imsglobal.org/catalog.html
> [4] http://www.imsglobal.org/lti/blti/bltiv1p0/ltiBLTIimgv1p0.html
> [5] http://www.imsglobal.org/lti/index.html
> [6] http://www.imsglobal.org/cc/jointhealliance.cfm
Hi Mirko,
This is great information, thank you.  Its been suggested to me, 
depending on the users' precise needs, that an effective approach might 
be to bolt Koha and Moodle (which has LTI support) together. I'll find 
out more about that.
Thanks and regards,
Bob


From indradg at gmail.com  Mon May 11 02:15:39 2015
From: indradg at gmail.com (Indranil Das Gupta)
Date: Mon, 11 May 2015 05:45:39 +0530
Subject: [Koha-devel] Field width for currency.currency is inadequate
Message-ID: <CAEm3SZ1mSt5S_Nuii8UH8jtJ82D7U3hK4-zUii_mEqCJS9NH-Q@mail.gmail.com>

Hi all,

The database field currency.currency is defined as VARCHAR(10) NOT
NULL. This needs to be increased e.g. set as VARCHAR(255) NOT NULL.

The rationale:

a) While it is possible to accomodate 'US Dollar' in that width, for
many currencies this space is inadequate e.g. 'East Caribbean Dollar',
'Indian Rupee' or 'Tanzanian Shilling'.

b) Further, in the 'New currency' addition form, the maxlength and
size attributes are set as 50, and allows user to enter long names as
examples above. While saving the record, it is truncated to
VARCHAR(10).

I propose the following:

1/ Alter the currency.currency field to VARCHAR(255) NOT NULL from
VARCHAR(10) NOT NULL.

2/ Change the 'maxlength' attribute in the template to 255 (to match
column property)


The bug and the patches are here
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14179

cheers
-idg
-- 
Indranil Das Gupta

Phone : +91-98300-20971
Blog    : http://indradg.randomink.org/blog
IRC      : indradg on irc://irc.freenode.net
Twitter : indradg

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-
Please exchange editable Office documents only in ODF Format. No other
format is acceptable. Support Open Standards.

For a free editor supporting ODF, please visit LibreOffice -
http://www.documentfoundation.org

From mtompset at hotmail.com  Mon May 11 02:49:27 2015
From: mtompset at hotmail.com (Mark Tompsett)
Date: Sun, 10 May 2015 20:49:27 -0400
Subject: [Koha-devel] Field width for currency.currency is inadequate
In-Reply-To: <CAEm3SZ1mSt5S_Nuii8UH8jtJ82D7U3hK4-zUii_mEqCJS9NH-Q@mail.gmail.com>
References: <CAEm3SZ1mSt5S_Nuii8UH8jtJ82D7U3hK4-zUii_mEqCJS9NH-Q@mail.gmail.com>
Message-ID: <BLU172-DS1F6AE86FBCC7AAD8F62F0C6DB0@phx.gbl>

Greetings,

Please see http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14179#c7

GPML,
Mark Tompsett 


From kyle.m.hall at gmail.com  Mon May 11 17:37:06 2015
From: kyle.m.hall at gmail.com (Kyle Hall)
Date: Mon, 11 May 2015 11:37:06 -0400
Subject: [Koha-devel] LAST CALL - RFC for Bug 14048 - Change
 RefundLostItemFeeOnReturn to be branch specific
Message-ID: <CACpVHfxrfxyaxez4W-jKS_weVAnGe=AKrY-R7Fdz0vno82OzCg@mail.gmail.com>

Hey all, I posted this on April 22, and received no feedback. I just wanted
to give everyone a second chance to post any feedback on the development
plan for bug 14048. If you have any comments about it, please let me know!
Otherwise, I'll assume everyone is ok with the development plan, and I can
go ahead with writing this feature.

Thanks!
Kyle

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

Some library systems would like to be able to control the behavior of
RefundLostItemFeeOnReturn

Expected outcome: To make the RefundLostItemFeeOnReturn system preference
branch specific

Plan of Attack:
1) Add new field 'refund_lost_item_fee_on_return' to the 'branches' table
2) Pre-populate this field with the system preference value for
RefundLostItemFeeOnReturn
3) Remove the system preference RefundLostItemFeeOnReturn
4) Replace uses of RefundLostItemFeeOnReturn with a lookup of the value of
branches.refund_lost_item_fee_on_return
5) Use HomeOrHolding to control whether the home branch or the holding
branch of the item is used to determine this.
6) Reveal the setting in the branches editor


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 )
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20150511/689d8a78/attachment.html>

From cgdavis at uintah.utah.gov  Mon May 11 18:04:57 2015
From: cgdavis at uintah.utah.gov (Christopher Davis)
Date: Mon, 11 May 2015 10:04:57 -0600
Subject: [Koha-devel] LAST CALL - RFC for Bug 14048 - Change
 RefundLostItemFeeOnReturn to be branch specific
In-Reply-To: <CACpVHfxrfxyaxez4W-jKS_weVAnGe=AKrY-R7Fdz0vno82OzCg@mail.gmail.com>
References: <CACpVHfxrfxyaxez4W-jKS_weVAnGe=AKrY-R7Fdz0vno82OzCg@mail.gmail.com>
Message-ID: <CACFiFkbxQ9pSDcaJ81ajs5vKDi77xXk7O2Pd7q4bS1AMUe_1rQ@mail.gmail.com>

Kyle,

It looks good to me

Thank you,

Christopher Davis, MLS
Systems & E-Services Librarian
Uintah County Library
cgdavis at uintah.utah.gov
(435) 789-0091 ext.261
uintahlibrary.org
basinlibraries.org
facebook.com/uintahcountylibrary

On Mon, May 11, 2015 at 9:37 AM, Kyle Hall <kyle.m.hall at gmail.com> wrote:

> Hey all, I posted this on April 22, and received no feedback. I just
> wanted to give everyone a second chance to post any feedback on the
> development plan for bug 14048. If you have any comments about it, please
> let me know! Otherwise, I'll assume everyone is ok with the development
> plan, and I can go ahead with writing this feature.
>
> Thanks!
> Kyle
>
> http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14048
>
> Some library systems would like to be able to control the behavior of
> RefundLostItemFeeOnReturn
>
> Expected outcome: To make the RefundLostItemFeeOnReturn system preference
> branch specific
>
> Plan of Attack:
> 1) Add new field 'refund_lost_item_fee_on_return' to the 'branches' table
> 2) Pre-populate this field with the system preference value for
> RefundLostItemFeeOnReturn
> 3) Remove the system preference RefundLostItemFeeOnReturn
> 4) Replace uses of RefundLostItemFeeOnReturn with a lookup of the value of
> branches.refund_lost_item_fee_on_return
> 5) Use HomeOrHolding to control whether the home branch or the holding
> branch of the item is used to determine this.
> 6) Reveal the setting in the branches editor
>
>
> 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 )
>
> _______________________________________________
> 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/20150511/2f6ddce5/attachment.html>

From kyle.m.hall at gmail.com  Tue May 12 12:56:03 2015
From: kyle.m.hall at gmail.com (Kyle Hall)
Date: Tue, 12 May 2015 06:56:03 -0400
Subject: [Koha-devel] LAST CALL - RFC for Bug 14048 - Change
 RefundLostItemFeeOnReturn to be branch specific
In-Reply-To: <CACFiFkbxQ9pSDcaJ81ajs5vKDi77xXk7O2Pd7q4bS1AMUe_1rQ@mail.gmail.com>
References: <CACpVHfxrfxyaxez4W-jKS_weVAnGe=AKrY-R7Fdz0vno82OzCg@mail.gmail.com>
	<CACFiFkbxQ9pSDcaJ81ajs5vKDi77xXk7O2Pd7q4bS1AMUe_1rQ@mail.gmail.com>
Message-ID: <CACpVHfwNec2U0wKFZqG7Xu3LoTc6XWLy+6pfmYTLaxzjncHn0w@mail.gmail.com>

Thanks Christopher!

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 Mon, May 11, 2015 at 12:04 PM, Christopher Davis <cgdavis at uintah.utah.gov
> wrote:

> Kyle,
>
> It looks good to me
>
> Thank you,
>
> Christopher Davis, MLS
> Systems & E-Services Librarian
> Uintah County Library
> cgdavis at uintah.utah.gov
> (435) 789-0091 ext.261
> uintahlibrary.org
> basinlibraries.org
> facebook.com/uintahcountylibrary
>
> On Mon, May 11, 2015 at 9:37 AM, Kyle Hall <kyle.m.hall at gmail.com> wrote:
>
>> Hey all, I posted this on April 22, and received no feedback. I just
>> wanted to give everyone a second chance to post any feedback on the
>> development plan for bug 14048. If you have any comments about it, please
>> let me know! Otherwise, I'll assume everyone is ok with the development
>> plan, and I can go ahead with writing this feature.
>>
>> Thanks!
>> Kyle
>>
>> http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14048
>>
>> Some library systems would like to be able to control the behavior of
>> RefundLostItemFeeOnReturn
>>
>> Expected outcome: To make the RefundLostItemFeeOnReturn system preference
>> branch specific
>>
>> Plan of Attack:
>> 1) Add new field 'refund_lost_item_fee_on_return' to the 'branches' table
>> 2) Pre-populate this field with the system preference value for
>> RefundLostItemFeeOnReturn
>> 3) Remove the system preference RefundLostItemFeeOnReturn
>> 4) Replace uses of RefundLostItemFeeOnReturn with a lookup of the value
>> of branches.refund_lost_item_fee_on_return
>> 5) Use HomeOrHolding to control whether the home branch or the holding
>> branch of the item is used to determine this.
>> 6) Reveal the setting in the branches editor
>>
>>
>> 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 )
>>
>> _______________________________________________
>> 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/20150512/59062e3a/attachment.html>

From M.de.Rooy at rijksmuseum.nl  Thu May 14 16:04:16 2015
From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy)
Date: Thu, 14 May 2015 14:04:16 +0000
Subject: [Koha-devel] Plugin marc21_linking_section.pl
Message-ID: <809BE39CD64BFD4EB9036172EBCCFA315ACCD64F@S-MAIL-1B.rijksmuseum.intra>

Hi all,



Is anyone of you using this plugin?

I can launch it, search for a record.

But if I click the Choose button, nothing happens. (I would expect to get back something into the field that launched the plugin.)



If you use it, please let me know what I am doing wrong :)



See also bug 13437 which makes some changes to various marc21 plugins including this one.



Thanks,



Marcel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20150514/1347a917/attachment.html>

From Katrin.Fischer.83 at web.de  Thu May 14 16:21:06 2015
From: Katrin.Fischer.83 at web.de (Katrin Fischer)
Date: Thu, 14 May 2015 16:21:06 +0200
Subject: [Koha-devel] Plugin marc21_linking_section.pl
In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA315ACCD64F@S-MAIL-1B.rijksmuseum.intra>
References: <809BE39CD64BFD4EB9036172EBCCFA315ACCD64F@S-MAIL-1B.rijksmuseum.intra>
Message-ID: <5554AF52.3070005@web.de>

Hi Marcel,

I tested it a while ago, I wrote up the steps on bugzilla:

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12695#c3

Did you link it to 773$9?

Hope this helps,

Katrin


Am 14.05.2015 um 16:04 schrieb Marcel de Rooy:
> Hi all,
> 
>  
> 
> Is anyone of you using this plugin?
> 
> I can launch it, search for a record.
> 
> But if I click the Choose button, nothing happens. (I would expect to
> get back something into the field that launched the plugin.)
> 
>  
> 
> If you use it, please let me know what I am doing wrong :)
> 
>  
> 
> See also bug 13437 which makes some changes to various marc21 plugins
> including this one.
> 
>  
> 
> Thanks,
> 
>  
> 
> Marcel
> 
> 
> 
> _______________________________________________
> 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 z.tajoli at cineca.it  Thu May 14 16:25:28 2015
From: z.tajoli at cineca.it (Tajoli Zeno)
Date: Thu, 14 May 2015 16:25:28 +0200
Subject: [Koha-devel] Plugin marc21_linking_section.pl
In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA315ACCD64F@S-MAIL-1B.rijksmuseum.intra>
References: <809BE39CD64BFD4EB9036172EBCCFA315ACCD64F@S-MAIL-1B.rijksmuseum.intra>
Message-ID: <5554B058.80504@cineca.it>

Hi,

Il 14/05/2015 16:04, Marcel de Rooy ha scritto:
> Is anyone of you using this plugin?

I use this plugin in Koha 3.12.06 and it works.

> I can launch it, search for a record.
>
> But if I click the Choose button, nothing happens. (I would expect to
> get back something into the field that launched the plugin.)


It insert (into he field that launched the plugin.)
$w -> 001 of searched record
$t -> field 245$a of searched records

> If you use it, please let me know what I am doing wrong :)
>
> See also bug 13437 which makes some changes to various marc21 plugins
> including this one.

I think there is same bug in the code.
Do you test it on 3.18.x or on 3.20-beta ?

Bye
Zeno Tajoli


-- 
Dr. Zeno Tajoli
Servizi Innovativi -- Automazione Biblioteche
z.tajoli at cineca.it
fax +39 02 2135520
CINECA - Sede operativa di Segrate

From tomascohen at gmail.com  Thu May 14 19:58:45 2015
From: tomascohen at gmail.com (Tomas Cohen Arazi)
Date: Thu, 14 May 2015 14:58:45 -0300
Subject: [Koha-devel] Dev meeting to talk about the upcoming release: May
	19th
Message-ID: <CABZfb=VfwQYm+k5ApP+-LBgorEtm91hKB_wGNdPdWnFS_y02XA@mail.gmail.com>

I'd like you to join the next meeting. It will be focused, exclusively, on
Koha 3.20. It will probably be a short meeting, unless something happens
before the meeting that needs broader discussion.

Kind regards

Link:
http://wiki.koha-community.org/wiki/Development_IRC_meeting_19_May_2015



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

From mirko at abunchofthings.net  Thu May 14 20:02:50 2015
From: mirko at abunchofthings.net (Mirko Tietgen)
Date: Thu, 14 May 2015 19:02:50 +0100
Subject: [Koha-devel] Learning Tools Interoperability
In-Reply-To: <554FDD76.2070904@calyx.net.au>
References: <554ACF7B.4010701@calyx.net.au>	<554B530B.5030900@abunchofthings.net>
	<554FDD76.2070904@calyx.net.au>
Message-ID: <5554E34A.9030100@abunchofthings.net>

Hi Bob,

Bob Birchall schrieb am 10.05.2015

> Hi Mirko,
> This is great information, thank you.  Its been suggested to me,
> depending on the users' precise needs, that an effective approach
> might be to bolt Koha and Moodle (which has LTI support) together.
> I'll find out more about that.
> Thanks and regards,
> Bob

I'd be interested to hear more details, please keep me/ the list
updated if there are things you can share.

-- Mirko


-- 

Mirko Tietgen
mirko at abunchofthings.net
http://koha.abunchofthings.net

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

From kohanews at gmail.com  Fri May 15 19:47:05 2015
From: kohanews at gmail.com (kohanews)
Date: Fri, 15 May 2015 10:47:05 -0700
Subject: [Koha-devel] Call for news: May newsletter
Message-ID: <55563119.1000303@gmail.com>

Fellow Koha users ~

I'm collecting news for the May newsletter. Send anything noteworthy to:

k o h a news AT gmail dot com

News criteria:
---------------------------
* News items can be of any length.
* Anything and everything Koha.
* Submit by the 28th.

If you are working on an interesting project or development related to
Koha, please let me know and I'll include it in the development section.

-- 
Chad Roseburg

Editor, Koha Newsletter

From kohanews at gmail.com  Fri May 15 19:48:26 2015
From: kohanews at gmail.com (kohanews)
Date: Fri, 15 May 2015 10:48:26 -0700
Subject: [Koha-devel] Call for development news: May newsletter
Message-ID: <5556316A.5000908@gmail.com>

Koha Development community ~

If you have any bugs or projects you'd like to highlight or promote in 
the May newsletter, please let me know. Maybe it'll attract some 
additional eyes, testers and sign-offs.

k o h a news AT gmail dot com

Thank you!

-- 
Chad Roseburg

Editor, Koha Newsletter

From M.de.Rooy at rijksmuseum.nl  Mon May 18 11:35:19 2015
From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy)
Date: Mon, 18 May 2015 09:35:19 +0000
Subject: [Koha-devel] Plugin marc21_linking_section.pl
In-Reply-To: <5554B058.80504@cineca.it>
References: <809BE39CD64BFD4EB9036172EBCCFA315ACCD64F@S-MAIL-1B.rijksmuseum.intra>
	<5554B058.80504@cineca.it>
Message-ID: <809BE39CD64BFD4EB9036172EBCCFA315ACD6F99@S-MAIL-1B.rijksmuseum.intra>

Thanks Katrin and Zeno.

> I use this plugin in Koha 3.12.06 and it works.
> Do you test it on 3.18.x or on 3.20-beta ?

Yes, it works now on master.


From jonathan.druart at biblibre.com  Mon May 18 11:55:41 2015
From: jonathan.druart at biblibre.com (Jonathan Druart)
Date: Mon, 18 May 2015 10:55:41 +0100
Subject: [Koha-devel] Dev meeting to talk about the upcoming release:
	May 19th
In-Reply-To: <CABZfb=VfwQYm+k5ApP+-LBgorEtm91hKB_wGNdPdWnFS_y02XA@mail.gmail.com>
References: <CABZfb=VfwQYm+k5ApP+-LBgorEtm91hKB_wGNdPdWnFS_y02XA@mail.gmail.com>
Message-ID: <CAJzKNY4ssEYbOCVsxRDBVsbgabnxsscf5Y1oMsrLybKP=QkeZw@mail.gmail.com>

Could you confirm the time please?

"19 May 2015, 15UTC"
But the link on timeandate.com is 21UTC


2015-05-14 18:58 GMT+01:00 Tomas Cohen Arazi <tomascohen at gmail.com>:
> I'd like you to join the next meeting. It will be focused, exclusively, on
> Koha 3.20. It will probably be a short meeting, unless something happens
> before the meeting that needs broader discussion.
>
> Kind regards
>
> Link:
> http://wiki.koha-community.org/wiki/Development_IRC_meeting_19_May_2015
>
>
>
> --
> Tom?s Cohen Arazi
> Prosecretar?a de Inform?tica
> Universidad Nacional de C?rdoba
> ? +54 351 5353750 ext 13168
> GPG: B76C 6E7C 2D80 551A C765  E225 0A27 2EA1 B2F3 C15F
>
> _______________________________________________
> 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 tomascohen at gmail.com  Mon May 18 17:39:42 2015
From: tomascohen at gmail.com (Tomas Cohen Arazi)
Date: Mon, 18 May 2015 12:39:42 -0300
Subject: [Koha-devel] SQL Reports Library v2.0
In-Reply-To: <CAH2zftFPrdcuu_B6hYs3FM0_L+qVPz41AF4MOXb8ziyj63E08A@mail.gmail.com>
References: <CAH2zftFPrdcuu_B6hYs3FM0_L+qVPz41AF4MOXb8ziyj63E08A@mail.gmail.com>
Message-ID: <CABZfb=XdpmeJOZgZ6nRO54b-GrqiZ3rdWw6Hb9Bo+pHfKQvx=Q@mail.gmail.com>

Pablo, I'm interested on making the wiki simpler to browse and maintain. If
you think you can have the time to work on that, just let us know what you
need from our side.

If you come up with something interesting i'm pretty sure we'll embrace it.

Thanks for the effort on making better docs.

On Sun, May 10, 2015 at 1:56 AM, Pablo Bianchi <pablo.bianchi at gmail.com>
wrote:

> Hi,
>
> I count more than 300 reports on *SQL Reports Library*, is getting a
> little bit out of control. Become difficult to:
> + found the needed report,
> + tag them,
> + talk about the report,
> + track easily contributions to each one,
> + link "related" reports, different flavors of the same one,
> + vote them,
> + add easily to Koha,
> + get statistic information,
> and much more.
>
> I'm not sure what is the best solution. An ad hoc web development? A
> friend suggest me Semanticscuttle
> <http://semanticscuttle.sourceforge.net/>.
> Trying to at least make things more tidy I create: SQL Reports Library in
> templates
> <http://wiki.koha-community.org/wiki/SQL_Reports_Library_in_templates> (equivalent
> to the usual but using mediawiki templates). This use Template:Report
> <http://wiki.koha-community.org/wiki/Template:Report>.
>
> Some things happens (or will happen) with JQuery and SQL libraries: A wiki
> page is not a good library/database.
>
> Regards,
> Pablo
>
>
> _______________________________________________
> 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/
>



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

From barton at bywatersolutions.com  Mon May 18 19:05:41 2015
From: barton at bywatersolutions.com (Barton Chittenden)
Date: Mon, 18 May 2015 13:05:41 -0400
Subject: [Koha-devel] SQL Reports Library v2.0
In-Reply-To: <CABZfb=XdpmeJOZgZ6nRO54b-GrqiZ3rdWw6Hb9Bo+pHfKQvx=Q@mail.gmail.com>
References: <CAH2zftFPrdcuu_B6hYs3FM0_L+qVPz41AF4MOXb8ziyj63E08A@mail.gmail.com>
	<CABZfb=XdpmeJOZgZ6nRO54b-GrqiZ3rdWw6Hb9Bo+pHfKQvx=Q@mail.gmail.com>
Message-ID: <CAMSJbVtPrWCCj_MbKNjg3EXDmAez0BseU6-2Vnq1wJ2rF3rEZw@mail.gmail.com>

Pablo,

I'll second Tomas' sentiment -- I refer to the reports library on a regular
basis. I ran across your SQL Reports Library in templates last week, and it
caught my interest. I would be willing to spend some time working on
converting the old SQL Reports Library.

Thanks,

--Barton


On Mon, May 18, 2015 at 11:39 AM, Tomas Cohen Arazi <tomascohen at gmail.com>
wrote:

> Pablo, I'm interested on making the wiki simpler to browse and maintain.
> If you think you can have the time to work on that, just let us know what
> you need from our side.
>
> If you come up with something interesting i'm pretty sure we'll embrace it.
>
> Thanks for the effort on making better docs.
>
> On Sun, May 10, 2015 at 1:56 AM, Pablo Bianchi <pablo.bianchi at gmail.com>
> wrote:
>
>> Hi,
>>
>> I count more than 300 reports on *SQL Reports Library*, is getting a
>> little bit out of control. Become difficult to:
>> + found the needed report,
>> + tag them,
>> + talk about the report,
>> + track easily contributions to each one,
>> + link "related" reports, different flavors of the same one,
>> + vote them,
>> + add easily to Koha,
>> + get statistic information,
>> and much more.
>>
>> I'm not sure what is the best solution. An ad hoc web development? A
>> friend suggest me Semanticscuttle
>> <http://semanticscuttle.sourceforge.net/>.
>> Trying to at least make things more tidy I create: SQL Reports Library
>> in templates
>> <http://wiki.koha-community.org/wiki/SQL_Reports_Library_in_templates> (equivalent
>> to the usual but using mediawiki templates). This use Template:Report
>> <http://wiki.koha-community.org/wiki/Template:Report>.
>>
>> Some things happens (or will happen) with JQuery and SQL libraries: A
>> wiki page is not a good library/database.
>>
>> Regards,
>> Pablo
>>
>>
>> _______________________________________________
>> 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/
>>
>
>
>
> --
> Tom?s Cohen Arazi
> Prosecretar?a de Inform?tica
> Universidad Nacional de C?rdoba
> ? +54 351 5353750 ext 13168
> GPG: B76C 6E7C 2D80 551A C765  E225 0A27 2EA1 B2F3 C15F
>
> _______________________________________________
> 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/20150518/1e6e5e72/attachment.html>

From mtompset at hotmail.com  Mon May 18 19:33:13 2015
From: mtompset at hotmail.com (Mark Tompsett)
Date: Mon, 18 May 2015 13:33:13 -0400
Subject: [Koha-devel] SQL Reports Library v2.0
In-Reply-To: <CAH2zftFPrdcuu_B6hYs3FM0_L+qVPz41AF4MOXb8ziyj63E08A@mail.gmail.com>
References: <CAH2zftFPrdcuu_B6hYs3FM0_L+qVPz41AF4MOXb8ziyj63E08A@mail.gmail.com>
Message-ID: <BLU172-DS16E79383A613F4B417AC57C6C40@phx.gbl>

Greetings,

Obviously others have agreed, because there are bits and pieces elsewhere.
Just search for ?sql reports?
http://wiki.koha-community.org/wiki/SQL_Reports_Holds
http://wiki.koha-community.org/wiki/SQL_Reports_Library
OBSOLETE: http://wiki.koha-community.org/wiki/3.2_SQL_Reports_Library 

The biggest problem is metadata tags for each report so they can be found more easily. I like the template notion put forward.

GPML,
Mark Tompsett

From: Pablo Bianchi 
Sent: Sunday, May 10, 2015 12:56 AM
To: Koha-devel 
Subject: [Koha-devel] SQL Reports Library v2.0

Hi,

I count more than 300 reports on SQL Reports Library, is getting a little bit out of control. Become difficult to:
+ found the needed report,
+ tag them,
+ talk about the report,
+ track easily contributions to each one,
+ link "related" reports, different flavors of the same one,
+ vote them,
+ add easily to Koha,
+ get statistic information,
and much more.

I'm not sure what is the best solution. An ad hoc web development? A friend suggest me Semanticscuttle.
Trying to at least make things more tidy I create: SQL Reports Library in templates (equivalent to the usual but using mediawiki templates). This use Template:Report.

Some things happens (or will happen) with JQuery and SQL libraries: A wiki page is not a good library/database.

Regards,
Pablo



--------------------------------------------------------------------------------
_______________________________________________
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/20150518/94374678/attachment-0001.html>

From indradg at gmail.com  Mon May 18 19:34:32 2015
From: indradg at gmail.com (Indranil Das Gupta)
Date: Mon, 18 May 2015 23:04:32 +0530
Subject: [Koha-devel] [CROSS-POST] does the language sw[itcher really need
 that much screen real estate?
Message-ID: <CAEm3SZ3QYBj1vqB+9LkyjgviVwz4LH9X717tqigGM9dcQ3-vow@mail.gmail.com>

Hi,

The language switcher takes up a lot of space at the bottom. it also
had issues of being not always visible
(http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11057).

Is there a specific design / UX issue (that I may be unaware of) why
it is not implemented as a simple drop down from the masthead toolbar?

thanks :)

-- 
Indranil Das Gupta

Phone : +91-98300-20971
Blog    : http://indradg.randomink.org/blog
IRC      : indradg on irc://irc.freenode.net
Twitter : indradg

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-
Please exchange editable Office documents only in ODF Format. No other
format is acceptable. Support Open Standards.

For a free editor supporting ODF, please visit LibreOffice -
http://www.documentfoundation.org

From tomascohen at gmail.com  Tue May 19 17:12:29 2015
From: tomascohen at gmail.com (Tomas Cohen Arazi)
Date: Tue, 19 May 2015 12:12:29 -0300
Subject: [Koha-devel] Dev meeting to talk about the upcoming release:
	May 19th
In-Reply-To: <CABZfb=VfwQYm+k5ApP+-LBgorEtm91hKB_wGNdPdWnFS_y02XA@mail.gmail.com>
References: <CABZfb=VfwQYm+k5ApP+-LBgorEtm91hKB_wGNdPdWnFS_y02XA@mail.gmail.com>
Message-ID: <CABZfb=X25v9LAHAYDiDjST7aYi6qqzotCGSYb4imYnRx0vvXGQ@mail.gmail.com>

I'm sorry, but I won't make it to the meeting (familly issues).

The meeting could take place without me. The main subject is taking notes
of any problems you might have found on 3.20 so I work on them tomorrow.
Also, get precise information about the status of the dependencies required
for Bug 8007 (Discharge management), because the release will depend on
their availability on the repository. Robin wrote last night on the IRC
that PDF::Writer was ready, but it remains uncertain if we will have
PDF::fromHTML on the repo on time.



On Thu, May 14, 2015 at 2:58 PM, Tomas Cohen Arazi <tomascohen at gmail.com>
wrote:

> I'd like you to join the next meeting. It will be focused, exclusively, on
> Koha 3.20. It will probably be a short meeting, unless something happens
> before the meeting that needs broader discussion.
>
> Kind regards
>
> Link:
> http://wiki.koha-community.org/wiki/Development_IRC_meeting_19_May_2015
>
>
>
> --
> Tom?s Cohen Arazi
> Prosecretar?a de Inform?tica
> Universidad Nacional de C?rdoba
> ? +54 351 5353750 ext 13168
> GPG: B76C 6E7C 2D80 551A C765  E225 0A27 2EA1 B2F3 C15F
>



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

From pablo.bianchi at gmail.com  Tue May 19 20:29:58 2015
From: pablo.bianchi at gmail.com (Pablo Bianchi)
Date: Tue, 19 May 2015 15:29:58 -0300
Subject: [Koha-devel] SQL Reports Library v2.0
In-Reply-To: <CAMSJbVtPrWCCj_MbKNjg3EXDmAez0BseU6-2Vnq1wJ2rF3rEZw@mail.gmail.com>
References: <CAH2zftFPrdcuu_B6hYs3FM0_L+qVPz41AF4MOXb8ziyj63E08A@mail.gmail.com>
	<CABZfb=XdpmeJOZgZ6nRO54b-GrqiZ3rdWw6Hb9Bo+pHfKQvx=Q@mail.gmail.com>
	<CAMSJbVtPrWCCj_MbKNjg3EXDmAez0BseU6-2Vnq1wJ2rF3rEZw@mail.gmail.com>
Message-ID: <CAH2zftExEmesD7Mp+qVynQ0gow-_qbT1J9356KXR1b=TW0vW2g@mail.gmail.com>

I'm very happy this brings enthusiasm!
In first place I think we should convert the big list to the template form
(probably the title will be repeated on template field).
Maybe we need some privileges on mediawiki, I need to study more about it
(mediawiki and their API), but the idea might be not just split the library
on other articles, just *transclude *them, call all the templates with a
giben label. Something like this
<http://en.wikipedia.org/w/api.php?action=query&list=embeddedin&eititle=Template:Infobox>?
An expert on mediawiki API would be great.


2015-05-18 14:05 GMT-03:00 Barton Chittenden <barton at bywatersolutions.com>:

> Pablo,
>
> I'll second Tomas' sentiment -- I refer to the reports library on a
> regular basis. I ran across your SQL Reports Library in templates last
> week, and it caught my interest. I would be willing to spend some time
> working on converting the old SQL Reports Library.
>
> Thanks,
>
> --Barton
>
>
> On Mon, May 18, 2015 at 11:39 AM, Tomas Cohen Arazi <tomascohen at gmail.com>
> wrote:
>
>> Pablo, I'm interested on making the wiki simpler to browse and maintain.
>> If you think you can have the time to work on that, just let us know what
>> you need from our side.
>>
>> If you come up with something interesting i'm pretty sure we'll embrace
>> it.
>>
>> Thanks for the effort on making better docs.
>>
>> On Sun, May 10, 2015 at 1:56 AM, Pablo Bianchi <pablo.bianchi at gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> I count more than 300 reports on *SQL Reports Library*, is getting a
>>> little bit out of control. Become difficult to:
>>> + found the needed report,
>>> + tag them,
>>> + talk about the report,
>>> + track easily contributions to each one,
>>> + link "related" reports, different flavors of the same one,
>>> + vote them,
>>> + add easily to Koha,
>>> + get statistic information,
>>> and much more.
>>>
>>> I'm not sure what is the best solution. An ad hoc web development? A
>>> friend suggest me Semanticscuttle
>>> <http://semanticscuttle.sourceforge.net/>.
>>> Trying to at least make things more tidy I create: SQL Reports Library
>>> in templates
>>> <http://wiki.koha-community.org/wiki/SQL_Reports_Library_in_templates> (equivalent
>>> to the usual but using mediawiki templates). This use Template:Report
>>> <http://wiki.koha-community.org/wiki/Template:Report>.
>>>
>>> Some things happens (or will happen) with JQuery and SQL libraries: A
>>> wiki page is not a good library/database.
>>>
>>> Regards,
>>> Pablo
>>>
>>>
>>> _______________________________________________
>>> 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/
>>>
>>
>>
>>
>> --
>> Tom?s Cohen Arazi
>> Prosecretar?a de Inform?tica
>> Universidad Nacional de C?rdoba
>> ? +54 351 5353750 ext 13168
>> GPG: B76C 6E7C 2D80 551A C765  E225 0A27 2EA1 B2F3 C15F
>>
>> _______________________________________________
>> 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/20150519/b83c62a6/attachment.html>

From tomascohen at gmail.com  Tue May 19 20:34:38 2015
From: tomascohen at gmail.com (Tomas Cohen Arazi)
Date: Tue, 19 May 2015 15:34:38 -0300
Subject: [Koha-devel] SQL Reports Library v2.0
In-Reply-To: <CAH2zftExEmesD7Mp+qVynQ0gow-_qbT1J9356KXR1b=TW0vW2g@mail.gmail.com>
References: <CAH2zftFPrdcuu_B6hYs3FM0_L+qVPz41AF4MOXb8ziyj63E08A@mail.gmail.com>
	<CABZfb=XdpmeJOZgZ6nRO54b-GrqiZ3rdWw6Hb9Bo+pHfKQvx=Q@mail.gmail.com>
	<CAMSJbVtPrWCCj_MbKNjg3EXDmAez0BseU6-2Vnq1wJ2rF3rEZw@mail.gmail.com>
	<CAH2zftExEmesD7Mp+qVynQ0gow-_qbT1J9356KXR1b=TW0vW2g@mail.gmail.com>
Message-ID: <CABZfb=X1dFy0zGTEu0V0A_JnCqHxxqobfben8rB+vqnUPnuoQQ@mail.gmail.com>

As long as it is still simple for the average joe to contribute their
sample query i'm fine.



On Tue, May 19, 2015 at 3:29 PM, Pablo Bianchi <pablo.bianchi at gmail.com>
wrote:

> I'm very happy this brings enthusiasm!
> In first place I think we should convert the big list to the template form
> (probably the title will be repeated on template field).
> Maybe we need some privileges on mediawiki, I need to study more about it
> (mediawiki and their API), but the idea might be not just split the library
> on other articles, just *transclude *them, call all the templates with a
> giben label. Something like this
> <http://en.wikipedia.org/w/api.php?action=query&list=embeddedin&eititle=Template:Infobox>?
> An expert on mediawiki API would be great.
>
>
> 2015-05-18 14:05 GMT-03:00 Barton Chittenden <barton at bywatersolutions.com>
> :
>
> Pablo,
>>
>> I'll second Tomas' sentiment -- I refer to the reports library on a
>> regular basis. I ran across your SQL Reports Library in templates last
>> week, and it caught my interest. I would be willing to spend some time
>> working on converting the old SQL Reports Library.
>>
>> Thanks,
>>
>> --Barton
>>
>>
>> On Mon, May 18, 2015 at 11:39 AM, Tomas Cohen Arazi <tomascohen at gmail.com
>> > wrote:
>>
>>> Pablo, I'm interested on making the wiki simpler to browse and maintain.
>>> If you think you can have the time to work on that, just let us know what
>>> you need from our side.
>>>
>>> If you come up with something interesting i'm pretty sure we'll embrace
>>> it.
>>>
>>> Thanks for the effort on making better docs.
>>>
>>> On Sun, May 10, 2015 at 1:56 AM, Pablo Bianchi <pablo.bianchi at gmail.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> I count more than 300 reports on *SQL Reports Library*, is getting a
>>>> little bit out of control. Become difficult to:
>>>> + found the needed report,
>>>> + tag them,
>>>> + talk about the report,
>>>> + track easily contributions to each one,
>>>> + link "related" reports, different flavors of the same one,
>>>> + vote them,
>>>> + add easily to Koha,
>>>> + get statistic information,
>>>> and much more.
>>>>
>>>> I'm not sure what is the best solution. An ad hoc web development? A
>>>> friend suggest me Semanticscuttle
>>>> <http://semanticscuttle.sourceforge.net/>.
>>>> Trying to at least make things more tidy I create: SQL Reports Library
>>>> in templates
>>>> <http://wiki.koha-community.org/wiki/SQL_Reports_Library_in_templates> (equivalent
>>>> to the usual but using mediawiki templates). This use Template:Report
>>>> <http://wiki.koha-community.org/wiki/Template:Report>.
>>>>
>>>> Some things happens (or will happen) with JQuery and SQL libraries: A
>>>> wiki page is not a good library/database.
>>>>
>>>> Regards,
>>>> Pablo
>>>>
>>>>
>>>> _______________________________________________
>>>> 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/
>>>>
>>>
>>>
>>>
>>> --
>>> Tom?s Cohen Arazi
>>> Prosecretar?a de Inform?tica
>>> Universidad Nacional de C?rdoba
>>> ? +54 351 5353750 ext 13168
>>> GPG: B76C 6E7C 2D80 551A C765  E225 0A27 2EA1 B2F3 C15F
>>>
>>> _______________________________________________
>>> 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/
>>
>
>


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

From robin at catalyst.net.nz  Fri May 22 06:11:27 2015
From: robin at catalyst.net.nz (Robin Sheat)
Date: Fri, 22 May 2015 16:11:27 +1200
Subject: [Koha-devel] Packaging of Koha dependencies
Message-ID: <1432267887.25145.44.camel@catalyst.net.nz>

With my package manager hat on, I want to introduce some general
guidelines for adding dependencies to the Koha project, because some
recent approaches have been problematic and sucked up a lot more time
than they should have.

Apologies in advance for the giant wall of text. It's late afternoon on
a Friday.

First, the easy case:
      * If the dependency you want to add is in wheezy and jessie (being
        aware of versions) already, then that's fine. We try not to
        introduce these within a monthly release unless there's a good
        reason, but for something going into a new major release, that's
        totally OK.

Otherwise:
      * Figure out the minimum version that'll work. Don't just add the
        latest version because that's what you grabbed out of CPAN. If
        it works with a more commonly distributed version then you've
        saved many people a lot of time by declaring that (not just me,
        but anyone trying to use it on other distributions too.) A bit
        more guidance on that here:
        http://mail.librecat.org/pipermail/librecat-dev/2015-May/000380.html
      * If you can reasonably avoid adding a dependency, do it. It's not
        always possible, but some things don't need to be there because
        it saves a few minutes of coding. If it saves you hours, then
        it's probably reasonable to add it.
      * Small, standalone modules will in most cases be easy to deal
        with. Things with many complex dependencies will not. The latter
        may cause backporting the module to be impossible, in which case
        it just won't happen.
      * Point it out to me early, not right before it's going to be
        released. On one hand, I can tell you then if it's going to be
        impossible. On the other, all the testers and QA people will
        have access to the dependency if it's already in the repo when
        it comes time for signing off, making their lives that much
        easier. If I hear that we need a package once it's gone through
        everything (and too often it's QA that points this out to me,
        that's really bad), your patch _will_ be delayed and may miss a
        release.
      * Check the copyright. I'm not going to redistribute a module just
        because it's in CPAN. As far as I can tell, being in CPAN
        doesn't cause a default license to be applied, so if the module
        doesn't have something that says that it can be redistributed,
        the default position is that it is illegal to redistribute it.
      * All modules that I create are submitted into Debian. If they
        don't get into Debian, then they don't get into Koha. Debian is
        pretty strict, so in turn I have to be pretty strict. The reason
        for this is, in part, that it means that the amount of modules I
        have to care about won't (hopefully) just keep getting bigger,
        there's a chance it'll go down too over time.
      * Most modules that are unpackaged have issues that prevent them
        going into debian. These are found by running the "lintian" tool
        over a package. Usually they're quick and easy. Sometimes there
        are a lot of them. If there are a lot of them, I'm going to
        delegate the fixing of them to the people who want this module
        in. I'm happy to coach you through this process and handle the
        basic things, but I don't always have time to spend days
        wrangling your dependency into a good state.
              * I wrote a guide to help you get started here:
                http://wiki.koha-community.org/wiki/Building_Debian_Dependencies
              * If you don't help out with this when necessary, your
                dependency is likely to go to the bottom of my packaging
                queue. If you do, it'll probably be near the top :)
      * To get a feel for something being easy to package, do:
        dh-make-perl --pkg-perl --build --cpan Module::Name
        with the lintian config set up from that wiki page. If you get
        only a few lintian errors (and some you'll see in every case),
        and you get a .deb file out then end, that's a good sign. Even
        better if from there you tidy it up, commit it to alioth, and
        ask me on the relevant bug to have a look over it for you :)
        
There's a fair bit of stuff here, but essentially the purpose boils down
to three points:
     1. my time is limited and some of this is taking away from real
        client work that is needed for Catalyst to be able to sponsor me
        to do this in the first place,
     2. I don't want to be a bottleneck that slows down your work
        getting into Koha, and
     3. the more people that have some experience with this stuff, the
        more people can help things get done.
             1. You can also get your name in lights as a contributor to
                the Debian project this way.

I hope you got this far!

Thanks,
-- 
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: 473 bytes
Desc: This is a digitally signed message part
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20150522/ed63ebb2/attachment.pgp>

From indradg at gmail.com  Sun May 24 14:35:30 2015
From: indradg at gmail.com (Indranil Das Gupta)
Date: Sun, 24 May 2015 18:05:30 +0530
Subject: [Koha-devel] [CROSS-POST] does the language sw[itcher really
 need that much screen real estate?
In-Reply-To: <CAEm3SZ3QYBj1vqB+9LkyjgviVwz4LH9X717tqigGM9dcQ3-vow@mail.gmail.com>
References: <CAEm3SZ3QYBj1vqB+9LkyjgviVwz4LH9X717tqigGM9dcQ3-vow@mail.gmail.com>
Message-ID: <CAEm3SZ2A-WEmpKPk3xrmBnYqt6TF_kTFn5_nCENUfJVAmFOMnw@mail.gmail.com>

Kia ora

On Mon, May 18, 2015 at 11:04 PM, Indranil Das Gupta <indradg at gmail.com> wrote:
> Hi,
>
> The language switcher takes up a lot of space at the bottom. it also
> had issues of being not always visible
> (http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11057).
>
> Is there a specific design / UX issue (that I may be unaware of) why
> it is not implemented as a simple drop down from the masthead toolbar?

There is now a new patch which positions the lang chooser at the
masthead. Users' are being requested to offer their inputs whether:

a) we stick to the way it is currently (at the bottom of the page and
with UX issues unless the patch from 11057 is applied)

(Reference - http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11057)

OR

b) we switch to the new position on the masthead using the patch from 14252?

(Reference - http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14252)

View on 1366x768 pixel resolution -
http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=39369

View on small mobile device resolution -
http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=39434

thanks :-)

-- 
Indranil Das Gupta

Phone : +91-98300-20971
Blog    : http://indradg.randomink.org/blog
IRC      : indradg on irc://irc.freenode.net
Twitter : indradg

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-
Please exchange editable Office documents only in ODF Format. No other
format is acceptable. Support Open Standards.

For a free editor supporting ODF, please visit LibreOffice -
http://www.documentfoundation.org

From irma at calyx.net.au  Sun May 24 17:40:02 2015
From: irma at calyx.net.au (Irma Birchall)
Date: Mon, 25 May 2015 01:40:02 +1000
Subject: [Koha-devel] [CROSS-POST] does the language sw[itcher really
 need that much screen real estate?
In-Reply-To: <CAEm3SZ2A-WEmpKPk3xrmBnYqt6TF_kTFn5_nCENUfJVAmFOMnw@mail.gmail.com>
References: <CAEm3SZ3QYBj1vqB+9LkyjgviVwz4LH9X717tqigGM9dcQ3-vow@mail.gmail.com>
	<CAEm3SZ2A-WEmpKPk3xrmBnYqt6TF_kTFn5_nCENUfJVAmFOMnw@mail.gmail.com>
Message-ID: <CALPHr=jzF_CmYj+RUyK3OAd4DMnTG2hT+rn8ESLycxLovLJ-5Q@mail.gmail.com>

Hi Indranil ++

We vote for b) "we switch to the new position on the masthead using the
patch from 14252"
Nice improvement.

Thank you.


With best regards,
Irma
------------------
Irma Birchall
CEO & Founder : CALYX information essentials
Koha LMS and Omeka implementations and professional services
T: +61 (2) 9437 4848 ~ M: +61 (0) 413 510 717
irma at calyx.net.au ~ www.calyx.net.au ~ http://koha-community.org/
For Koha-oz User Group communications join e-list:
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-oz

On 24 May 2015 at 22:35, Indranil Das Gupta <indradg at gmail.com> wrote:

> Kia ora
>
> On Mon, May 18, 2015 at 11:04 PM, Indranil Das Gupta <indradg at gmail.com>
> wrote:
> > Hi,
> >
> > The language switcher takes up a lot of space at the bottom. it also
> > had issues of being not always visible
> > (http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11057).
> >
> > Is there a specific design / UX issue (that I may be unaware of) why
> > it is not implemented as a simple drop down from the masthead toolbar?
>
> There is now a new patch which positions the lang chooser at the
> masthead. Users' are being requested to offer their inputs whether:
>
> a) we stick to the way it is currently (at the bottom of the page and
> with UX issues unless the patch from 11057 is applied)
>
> (Reference -
> http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11057)
>
> OR
>
> b) we switch to the new position on the masthead using the patch from
> 14252?
>
> (Reference -
> http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14252)
>
> View on 1366x768 pixel resolution -
> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=39369
>
> View on small mobile device resolution -
> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=39434
>
> thanks :-)
>
> --
> Indranil Das Gupta
>
> Phone : +91-98300-20971
> Blog    : http://indradg.randomink.org/blog
> IRC      : indradg on irc://irc.freenode.net
> Twitter : indradg
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-
> Please exchange editable Office documents only in ODF Format. No other
> format is acceptable. Support Open Standards.
>
> For a free editor supporting ODF, please visit LibreOffice -
> http://www.documentfoundation.org
> _______________________________________________
> 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/20150525/164dcc73/attachment.html>

From M.de.Rooy at rijksmuseum.nl  Mon May 25 10:58:52 2015
From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy)
Date: Mon, 25 May 2015 08:58:52 +0000
Subject: [Koha-devel] [CROSS-POST] does the language sw[itcher really
 need that much screen real estate?
In-Reply-To: <CALPHr=jzF_CmYj+RUyK3OAd4DMnTG2hT+rn8ESLycxLovLJ-5Q@mail.gmail.com>
References: <CAEm3SZ3QYBj1vqB+9LkyjgviVwz4LH9X717tqigGM9dcQ3-vow@mail.gmail.com>
	<CAEm3SZ2A-WEmpKPk3xrmBnYqt6TF_kTFn5_nCENUfJVAmFOMnw@mail.gmail.com>,
	<CALPHr=jzF_CmYj+RUyK3OAd4DMnTG2hT+rn8ESLycxLovLJ-5Q@mail.gmail.com>
Message-ID: <809BE39CD64BFD4EB9036172EBCCFA315ACE1CD4@S-MAIL-1B.rijksmuseum.intra>

I like the new position for Languages too.

But it gets kind of crowdy on that top bar (when the user is logged in and has a longer name..)

Imo Languages has more rights to be there than e.g. Search history.

Could we move Search history now to the bar with Advanced Search and Authority Search?

Could we also combine "Welcome, Marcel.."  and Logout ? Only Show the name and provide a dropdown with User options and Logout ?



________________________________
Van: koha-devel-bounces at lists.koha-community.org [koha-devel-bounces at lists.koha-community.org] namens Irma Birchall [irma at calyx.net.au]
Verzonden: zondag 24 mei 2015 17:40
Aan: Indranil Das Gupta
CC: koha-devel at lists.koha-community.org; koha
Onderwerp: Re: [Koha-devel] [CROSS-POST] does the language sw[itcher really need that much screen real estate?

Hi Indranil ++

We vote for b) "we switch to the new position on the masthead using the patch from 14252"
Nice improvement.

Thank you.


With best regards,
Irma
------------------
Irma Birchall
CEO & Founder : CALYX information essentials
Koha LMS and Omeka implementations and professional services
T: +61 (2) 9437 4848<tel:%2B61%20%282%29%209437%204848> ~ M: +61 (0) 413 510 717<tel:%2B61%20%280%29%20413%20510%20717>
irma at calyx.net.au<mailto:irma at calyx.net.au> ~ www.calyx.net.au<http://www.calyx.net.au> ~ http://koha-community.org/
For Koha-oz User Group communications join e-list:
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-oz

On 24 May 2015 at 22:35, Indranil Das Gupta <indradg at gmail.com<mailto:indradg at gmail.com>> wrote:
Kia ora

On Mon, May 18, 2015 at 11:04 PM, Indranil Das Gupta <indradg at gmail.com<mailto:indradg at gmail.com>> wrote:
> Hi,
>
> The language switcher takes up a lot of space at the bottom. it also
> had issues of being not always visible
> (http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11057).
>
> Is there a specific design / UX issue (that I may be unaware of) why
> it is not implemented as a simple drop down from the masthead toolbar?

There is now a new patch which positions the lang chooser at the
masthead. Users' are being requested to offer their inputs whether:

a) we stick to the way it is currently (at the bottom of the page and
with UX issues unless the patch from 11057 is applied)

(Reference - http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11057)

OR

b) we switch to the new position on the masthead using the patch from 14252?

(Reference - http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14252)

View on 1366x768 pixel resolution -
http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=39369

View on small mobile device resolution -
http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=39434

thanks :-)

--
Indranil Das Gupta

Phone : +91-98300-20971<tel:%2B91-98300-20971>
Blog    : http://indradg.randomink.org/blog
IRC      : indradg on irc://irc.freenode.net<http://irc.freenode.net>
Twitter : indradg

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-
Please exchange editable Office documents only in ODF Format. No other
format is acceptable. Support Open Standards.

For a free editor supporting ODF, please visit LibreOffice -
http://www.documentfoundation.org
_______________________________________________
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/

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

From hadzic_ahmed at hotmail.com  Mon May 25 13:56:57 2015
From: hadzic_ahmed at hotmail.com (Ahmed Hadzic)
Date: Mon, 25 May 2015 11:56:57 +0000 (UTC)
Subject: [Koha-devel] How to get CAS based Single Sign On working?
References: <BANLkTim8qfW0ok4ykHtj_dyJ2F8RMQpr3g@mail.gmail.com>
Message-ID: <loom.20150525T135411-27@post.gmane.org>


Hi Kale,

I need to authenticate KOHA with CAS. As I see, you have implemented 
KOHA with CAS and I would be thankful if you could share your 
documentation.

Kind regards



From julian.maurice at biblibre.com  Mon May 25 15:04:24 2015
From: julian.maurice at biblibre.com (Julian Maurice)
Date: Mon, 25 May 2015 15:04:24 +0200
Subject: [Koha-devel] Packaging of Koha dependencies
In-Reply-To: <1432267887.25145.44.camel@catalyst.net.nz>
References: <1432267887.25145.44.camel@catalyst.net.nz>
Message-ID: <55631DD8.2080707@biblibre.com>

Hi Robin,

I have a few questions related to bug 13799 [1].

 > the easy case

a) As the required version of Mojolicious is in jessie, does this mean 
that we don't have to package it for wheezy ? I thought backporting to 
wheezy was still needed since jessie was released just a month ago.

 > If you don't help out...

b) I understand that packaging Swagger2 has fallen to the bottom of your 
queue, and you are requiring help to do it, correct ? If so, I can help, 
just tell me.

Apart from that, I think this mail deserves a page in the wiki.


[1] http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13799

Le 22/05/2015 06:11, Robin Sheat a ?crit :
> With my package manager hat on, I want to introduce some general
> guidelines for adding dependencies to the Koha project, because some
> recent approaches have been problematic and sucked up a lot more time
> than they should have.
>
> Apologies in advance for the giant wall of text. It's late afternoon on
> a Friday.
>
> First, the easy case:
>        * If the dependency you want to add is in wheezy and jessie (being
>          aware of versions) already, then that's fine. We try not to
>          introduce these within a monthly release unless there's a good
>          reason, but for something going into a new major release, that's
>          totally OK.
>
> Otherwise:
>        * Figure out the minimum version that'll work. Don't just add the
>          latest version because that's what you grabbed out of CPAN. If
>          it works with a more commonly distributed version then you've
>          saved many people a lot of time by declaring that (not just me,
>          but anyone trying to use it on other distributions too.) A bit
>          more guidance on that here:
>          http://mail.librecat.org/pipermail/librecat-dev/2015-May/000380.html
>        * If you can reasonably avoid adding a dependency, do it. It's not
>          always possible, but some things don't need to be there because
>          it saves a few minutes of coding. If it saves you hours, then
>          it's probably reasonable to add it.
>        * Small, standalone modules will in most cases be easy to deal
>          with. Things with many complex dependencies will not. The latter
>          may cause backporting the module to be impossible, in which case
>          it just won't happen.
>        * Point it out to me early, not right before it's going to be
>          released. On one hand, I can tell you then if it's going to be
>          impossible. On the other, all the testers and QA people will
>          have access to the dependency if it's already in the repo when
>          it comes time for signing off, making their lives that much
>          easier. If I hear that we need a package once it's gone through
>          everything (and too often it's QA that points this out to me,
>          that's really bad), your patch _will_ be delayed and may miss a
>          release.
>        * Check the copyright. I'm not going to redistribute a module just
>          because it's in CPAN. As far as I can tell, being in CPAN
>          doesn't cause a default license to be applied, so if the module
>          doesn't have something that says that it can be redistributed,
>          the default position is that it is illegal to redistribute it.
>        * All modules that I create are submitted into Debian. If they
>          don't get into Debian, then they don't get into Koha. Debian is
>          pretty strict, so in turn I have to be pretty strict. The reason
>          for this is, in part, that it means that the amount of modules I
>          have to care about won't (hopefully) just keep getting bigger,
>          there's a chance it'll go down too over time.
>        * Most modules that are unpackaged have issues that prevent them
>          going into debian. These are found by running the "lintian" tool
>          over a package. Usually they're quick and easy. Sometimes there
>          are a lot of them. If there are a lot of them, I'm going to
>          delegate the fixing of them to the people who want this module
>          in. I'm happy to coach you through this process and handle the
>          basic things, but I don't always have time to spend days
>          wrangling your dependency into a good state.
>                * I wrote a guide to help you get started here:
>                  http://wiki.koha-community.org/wiki/Building_Debian_Dependencies
>                * If you don't help out with this when necessary, your
>                  dependency is likely to go to the bottom of my packaging
>                  queue. If you do, it'll probably be near the top :)
>        * To get a feel for something being easy to package, do:
>          dh-make-perl --pkg-perl --build --cpan Module::Name
>          with the lintian config set up from that wiki page. If you get
>          only a few lintian errors (and some you'll see in every case),
>          and you get a .deb file out then end, that's a good sign. Even
>          better if from there you tidy it up, commit it to alioth, and
>          ask me on the relevant bug to have a look over it for you :)
>
> There's a fair bit of stuff here, but essentially the purpose boils down
> to three points:
>       1. my time is limited and some of this is taking away from real
>          client work that is needed for Catalyst to be able to sponsor me
>          to do this in the first place,
>       2. I don't want to be a bottleneck that slows down your work
>          getting into Koha, and
>       3. the more people that have some experience with this stuff, the
>          more people can help things get done.
>               1. You can also get your name in lights as a contributor to
>                  the Debian project this way.
>
> I hope you got this far!
>
> Thanks,
>
>
>
> _______________________________________________
> 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/
>


-- 
Julian Maurice <julian.maurice at biblibre.com>
BibLibre

From robin at catalyst.net.nz  Tue May 26 00:44:00 2015
From: robin at catalyst.net.nz (Robin Sheat)
Date: Tue, 26 May 2015 10:44:00 +1200
Subject: [Koha-devel] Packaging of Koha dependencies
In-Reply-To: <55631DD8.2080707@biblibre.com>
References: <1432267887.25145.44.camel@catalyst.net.nz>
	<55631DD8.2080707@biblibre.com>
Message-ID: <1432593840.25145.69.camel@catalyst.net.nz>

Julian Maurice schreef op ma 25-05-2015 om 15:04 [+0200]:
>  > the easy case
> 
> a) As the required version of Mojolicious is in jessie, does this
> mean 
> that we don't have to package it for wheezy ? I thought backporting
> to 
> wheezy was still needed since jessie was released just a month ago.

We will need to package it for wheezy as it's not there.

>  > If you don't help out...
> 
> b) I understand that packaging Swagger2 has fallen to the bottom of
> your 
> queue, and you are requiring help to do it, correct ? If so, I can
> help, 
> just tell me.

No, it just fell to the bottom of my queue because more urgent
pre-release things got in my way, I hope to have a look at it again this
week and think I have solutions to the issues that I had.

> Apart from that, I think this mail deserves a page in the wiki.

Yeah, I plan to do that some time soon.

-- 
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: 473 bytes
Desc: This is a digitally signed message part
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20150526/8d9a9664/attachment.pgp>

From fridolin.somers at biblibre.com  Tue May 26 09:19:51 2015
From: fridolin.somers at biblibre.com (Fridolin SOMERS)
Date: Tue, 26 May 2015 09:19:51 +0200
Subject: [Koha-devel] Packaging of Koha dependencies
In-Reply-To: <1432267887.25145.44.camel@catalyst.net.nz>
References: <1432267887.25145.44.camel@catalyst.net.nz>
Message-ID: <55641E97.1030601@biblibre.com>

Perfect, it's good to know this.
You should copy it to a wiki page I think.
Regards,

Le 22/05/2015 06:11, Robin Sheat a ?crit :
> With my package manager hat on, I want to introduce some general
> guidelines for adding dependencies to the Koha project, because some
> recent approaches have been problematic and sucked up a lot more time
> than they should have.
>
> Apologies in advance for the giant wall of text. It's late afternoon on
> a Friday.
>
> First, the easy case:
>        * If the dependency you want to add is in wheezy and jessie (being
>          aware of versions) already, then that's fine. We try not to
>          introduce these within a monthly release unless there's a good
>          reason, but for something going into a new major release, that's
>          totally OK.
>
> Otherwise:
>        * Figure out the minimum version that'll work. Don't just add the
>          latest version because that's what you grabbed out of CPAN. If
>          it works with a more commonly distributed version then you've
>          saved many people a lot of time by declaring that (not just me,
>          but anyone trying to use it on other distributions too.) A bit
>          more guidance on that here:
>          http://mail.librecat.org/pipermail/librecat-dev/2015-May/000380.html
>        * If you can reasonably avoid adding a dependency, do it. It's not
>          always possible, but some things don't need to be there because
>          it saves a few minutes of coding. If it saves you hours, then
>          it's probably reasonable to add it.
>        * Small, standalone modules will in most cases be easy to deal
>          with. Things with many complex dependencies will not. The latter
>          may cause backporting the module to be impossible, in which case
>          it just won't happen.
>        * Point it out to me early, not right before it's going to be
>          released. On one hand, I can tell you then if it's going to be
>          impossible. On the other, all the testers and QA people will
>          have access to the dependency if it's already in the repo when
>          it comes time for signing off, making their lives that much
>          easier. If I hear that we need a package once it's gone through
>          everything (and too often it's QA that points this out to me,
>          that's really bad), your patch _will_ be delayed and may miss a
>          release.
>        * Check the copyright. I'm not going to redistribute a module just
>          because it's in CPAN. As far as I can tell, being in CPAN
>          doesn't cause a default license to be applied, so if the module
>          doesn't have something that says that it can be redistributed,
>          the default position is that it is illegal to redistribute it.
>        * All modules that I create are submitted into Debian. If they
>          don't get into Debian, then they don't get into Koha. Debian is
>          pretty strict, so in turn I have to be pretty strict. The reason
>          for this is, in part, that it means that the amount of modules I
>          have to care about won't (hopefully) just keep getting bigger,
>          there's a chance it'll go down too over time.
>        * Most modules that are unpackaged have issues that prevent them
>          going into debian. These are found by running the "lintian" tool
>          over a package. Usually they're quick and easy. Sometimes there
>          are a lot of them. If there are a lot of them, I'm going to
>          delegate the fixing of them to the people who want this module
>          in. I'm happy to coach you through this process and handle the
>          basic things, but I don't always have time to spend days
>          wrangling your dependency into a good state.
>                * I wrote a guide to help you get started here:
>                  http://wiki.koha-community.org/wiki/Building_Debian_Dependencies
>                * If you don't help out with this when necessary, your
>                  dependency is likely to go to the bottom of my packaging
>                  queue. If you do, it'll probably be near the top :)
>        * To get a feel for something being easy to package, do:
>          dh-make-perl --pkg-perl --build --cpan Module::Name
>          with the lintian config set up from that wiki page. If you get
>          only a few lintian errors (and some you'll see in every case),
>          and you get a .deb file out then end, that's a good sign. Even
>          better if from there you tidy it up, commit it to alioth, and
>          ask me on the relevant bug to have a look over it for you :)
>
> There's a fair bit of stuff here, but essentially the purpose boils down
> to three points:
>       1. my time is limited and some of this is taking away from real
>          client work that is needed for Catalyst to be able to sponsor me
>          to do this in the first place,
>       2. I don't want to be a bottleneck that slows down your work
>          getting into Koha, and
>       3. the more people that have some experience with this stuff, the
>          more people can help things get done.
>               1. You can also get your name in lights as a contributor to
>                  the Debian project this way.
>
> I hope you got this far!
>
> Thanks,
>
>
>
> _______________________________________________
> 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/
>

-- 
Fridolin SOMERS
Biblibre - P?les support et syst?me
fridolin.somers at biblibre.com

From dptkvs at gmail.com  Wed May 27 08:23:56 2015
From: dptkvs at gmail.com (DP Tripathi)
Date: Wed, 27 May 2015 11:53:56 +0530
Subject: [Koha-devel] Install Koha 3.20 with Single Command at Ubuntu 14.04
	LTS
Message-ID: <CAJJZY-QpEr1rWq3t1soB34M=D4Snxa-jwNJQ=SgEYr2qa4S+OA@mail.gmail.com>

Dear All,

Greetings!

Now, Install Koha 3.20 with one single command at Ubuntu 14.04 LTS

Just follow the instructions.

I assume that you have installed Ubuntu 14.04 LTS in your system and it is
connected with Internet.

Step 1: First download the file at www.librarianguide.co.in/install_koha.sh

Step 2: Wherever you keep the file, just give permission with following
command.

I assume the file is at /home/library

root at nitr/home/library# chmod +x install_koha.sh (press enter)

root at nitr/home/library# ./install_koha.sh (press enter)

It will start installation. Just follow the instruction and provide
necessary inputs.

Step 3: After installation of everything it will open window with nano
editor. Just change the port in Intranet (8000), save (ctrl+x).

Now, it will open Firefox automatically with Koha Web Installer.

User Name: koha_library

Password: Note down the password from
(/etc/koha/sites/library/koha-conf.xml) file.

The password will be at the bottom of file in <config> section.

Enjoy Koha!

Thanks,

DP Tripathi
NIT Rourkela
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20150527/1b2c0699/attachment.html>

From gaetan.boisson at biblibre.com  Wed May 27 11:22:37 2015
From: gaetan.boisson at biblibre.com (Gaetan Boisson)
Date: Wed, 27 May 2015 11:22:37 +0200
Subject: [Koha-devel] Koha and mod perl
Message-ID: <55658CDD.7080906@biblibre.com>

  Hello all,

has anyone set up mod perl on a koha instance? And if so, are there any 
bugs or issues doing this?

It seems we tried it some time ago, and this page says there are issues, 
but doesn't give more details:
http://wiki.koha-community.org/wiki/Koha_Tuning

We have been testing it today and i haven't seen serious issues so far. 
 From the wiki it seems the latest tests were made 4 years ago, so it's 
possible things have changed in Koha and mod_perl.

It's something worth trying at any rate, because the mod perl 
documentation claims "400% to 2000%" performance boosts. It definitely 
feels *much* faster on our test instance right now.

--
Gaetan Boisson
Chef de projet biblioth?caire
BibLibre
06 52 42 51 29
108 avenue Breteuil 13006 Marseille
gaetan.boisson at biblibre.com


From paul.poulain at biblibre.com  Wed May 27 11:32:32 2015
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Wed, 27 May 2015 11:32:32 +0200
Subject: [Koha-devel] Koha and mod perl
In-Reply-To: <55658CDD.7080906@biblibre.com>
References: <55658CDD.7080906@biblibre.com>
Message-ID: <55658F30.7060408@biblibre.com>

Le 27/05/2015 11:22, Gaetan Boisson a ?crit :
>  Hello all,
Hello,
> has anyone set up mod perl on a koha instance? And if so, are there 
> any bugs or issues doing this?
Theory : Plack & mod_perl are using the same kind of idea to embed Perl 
(for Plack it's in specific plackup/starman process, for mod_perl it's 
in Apache itself).

The reason why mod_perl was not working well are probably the same 
reason why Plack was not working well (ie: nested sub & variable scope 
problem). They have been fixed for supporting Plack, it's not a surprise 
to me that they fixed the mod_perl problems.

It also mean that the performance improvement should also be comparable.

Question 1: what could make us face problem with Plack that does not 
appear on mod_perl ?
Question 2: why should we prefer Plack vs mod_perl ? (in the short term 
and/or in the long term)
Question 3: any side effect that we haven't found yet ?
> It seems we tried it some time ago, and this page says there are 
> issues, but doesn't give more details:
> http://wiki.koha-community.org/wiki/Koha_Tuning
>
> We have been testing it today and i haven't seen serious issues so 
> far. From the wiki it seems the latest tests were made 4 years ago, so 
> it's possible things have changed in Koha and mod_perl.
>
> It's something worth trying at any rate, because the mod perl 
> documentation claims "400% to 2000%" performance boosts. It definitely 
> feels *much* faster on our test instance right now.

-- 
Paul Poulain, Associ?-g?rant / co-owner
BibLibre, Services en logiciels libres pour les biblioth?ques
BibLibre, Open Source software and services for libraries


From julian.fiol at biblibre.com  Wed May 27 12:14:03 2015
From: julian.fiol at biblibre.com (Julian FIOL)
Date: Wed, 27 May 2015 12:14:03 +0200
Subject: [Koha-devel] Improving Plack intranet performances (circulation
	module)
Message-ID: <556598EB.6080601@biblibre.com>

Hi everyone,

Using Devel::NYTProf on a Plack config, I noticed that when we checkout 
an item in the circulation page, there is a really long time spent 
creating the database schema.

By adding the import of *Koha::Schema* in the *intranet.psgi* file, we 
can see a significant improvement of the time spent loading the 
circulation page.

Please find here 
<http://www.slideshare.net/JulianFiol/koha-circulation-checkout-improvement> 
(in full screen) the proof of what I'm saying.

I have also added the manipulations to do into the Plack 
<http://wiki.koha-community.org/wiki/Plack#Improving_Plack_performance> 
wiki.

Regards,
Julian FIOL
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20150527/ed062a6d/attachment.html>

From gaetan.boisson at biblibre.com  Wed May 27 12:45:51 2015
From: gaetan.boisson at biblibre.com (Gaetan Boisson)
Date: Wed, 27 May 2015 12:45:51 +0200
Subject: [Koha-devel] search speed
Message-ID: <5565A05F.70809@biblibre.com>

  Hello again all,

looking at speed issues there is one thing that i don't understand, and 
i feel some well versed developpers might have a better idea of what is 
happening.

If you query zebra directly on the server, it's blazingly fast, no 
matter how big your database and how many results you get. (At least the 
difference is negligible, and we still get very low response times.)

But if you do a search in Koha that brings 20 000 results, it's usualy 4 
times faster (maybe more, sorry i don't have precise metrics here) than 
a search that brings up 1 000 000 results.

Is it consistent with your experience?

If it is, what would be the reason for this? My understanding is that 
the search code asks zebra for the first n records to display on the 
first page, and that facets are based on a number of result way below 20 
000 anyway, so the total number of results shouldn't really make a 
difference.

-- 
Gaetan Boisson
Chef de projet biblioth?caire
BibLibre
06 52 42 51 29
108 avenue Breteuil 13006 Marseille
gaetan.boisson at biblibre.com


From jonathan.druart at biblibre.com  Wed May 27 12:56:22 2015
From: jonathan.druart at biblibre.com (Jonathan Druart)
Date: Wed, 27 May 2015 11:56:22 +0100
Subject: [Koha-devel] search speed
In-Reply-To: <5565A05F.70809@biblibre.com>
References: <5565A05F.70809@biblibre.com>
Message-ID: <CAJzKNY4qm5ruZGgYtNRnpR=3D9nUpySnB=4yVG5L=Yqyb+zW1w@mail.gmail.com>

Gaetan,
have a look at the metrics on bug 13665.

2015-05-27 11:45 GMT+01:00 Gaetan Boisson <gaetan.boisson at biblibre.com>:
>  Hello again all,
>
> looking at speed issues there is one thing that i don't understand, and i
> feel some well versed developpers might have a better idea of what is
> happening.
>
> If you query zebra directly on the server, it's blazingly fast, no matter
> how big your database and how many results you get. (At least the difference
> is negligible, and we still get very low response times.)
>
> But if you do a search in Koha that brings 20 000 results, it's usualy 4
> times faster (maybe more, sorry i don't have precise metrics here) than a
> search that brings up 1 000 000 results.
>
> Is it consistent with your experience?
>
> If it is, what would be the reason for this? My understanding is that the
> search code asks zebra for the first n records to display on the first page,
> and that facets are based on a number of result way below 20 000 anyway, so
> the total number of results shouldn't really make a difference.
>
> --
> Gaetan Boisson
> Chef de projet biblioth?caire
> BibLibre
> 06 52 42 51 29
> 108 avenue Breteuil 13006 Marseille
> gaetan.boisson at biblibre.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/

From mtompset at hotmail.com  Wed May 27 13:57:32 2015
From: mtompset at hotmail.com (Mark Tompsett)
Date: Wed, 27 May 2015 07:57:32 -0400
Subject: [Koha-devel] Install Koha 3.20 with Single Command at Ubuntu
	14.04LTS
In-Reply-To: <CAJJZY-QpEr1rWq3t1soB34M=D4Snxa-jwNJQ=SgEYr2qa4S+OA@mail.gmail.com>
References: <CAJJZY-QpEr1rWq3t1soB34M=D4Snxa-jwNJQ=SgEYr2qa4S+OA@mail.gmail.com>
Message-ID: <BLU172-DS5241C77EC3BF6D35A9EC8C6CB0@phx.gbl>

Greetings,

It is always better to follow the instructions on the wiki, as they are always more current (patches take longer to get into master). For example, in your script you have the old MySQL security tweak, but it is commented out. The new tweak: sudo mysql_secure_installation

I do not recommend using a single step install script. This makes it more difficult to help you fix your problems when something goes wrong.

Primary reference: http://wiki.koha-community.org/wiki/Koha_on_Debian
Secondary reference (in the case of Ubuntu): http://wiki.koha-community.org/wiki/Koha_on_ubuntu_-_packages

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

From gaetan.boisson at biblibre.com  Wed May 27 20:29:36 2015
From: gaetan.boisson at biblibre.com (Gaetan Boisson)
Date: Wed, 27 May 2015 20:29:36 +0200
Subject: [Koha-devel] search speed
In-Reply-To: <CAJzKNY4qm5ruZGgYtNRnpR=3D9nUpySnB=4yVG5L=Yqyb+zW1w@mail.gmail.com>
References: <5565A05F.70809@biblibre.com>
	<CAJzKNY4qm5ruZGgYtNRnpR=3D9nUpySnB=4yVG5L=Yqyb+zW1w@mail.gmail.com>
Message-ID: <55660D10.9020600@biblibre.com>

Well as i said, the time is not the same depending on the number of 
results, but in both cases, the number of results is anyway much higher 
than the number of records taken into consideration for facets.

Your investigation indicates that:

In ZOOM->record, the time is spent in
   my $_rec = Net::Z3950::ZOOM::resultset_record($this->_rs(), $which);

Maybe it's worth having a deeper look in this.

Le 27/05/2015 12:56, Jonathan Druart a ?crit :
> Gaetan,
> have a look at the metrics on bug 13665.
>
> 2015-05-27 11:45 GMT+01:00 Gaetan Boisson <gaetan.boisson at biblibre.com>:
>>   Hello again all,
>>
>> looking at speed issues there is one thing that i don't understand, and i
>> feel some well versed developpers might have a better idea of what is
>> happening.
>>
>> If you query zebra directly on the server, it's blazingly fast, no matter
>> how big your database and how many results you get. (At least the difference
>> is negligible, and we still get very low response times.)
>>
>> But if you do a search in Koha that brings 20 000 results, it's usualy 4
>> times faster (maybe more, sorry i don't have precise metrics here) than a
>> search that brings up 1 000 000 results.
>>
>> Is it consistent with your experience?
>>
>> If it is, what would be the reason for this? My understanding is that the
>> search code asks zebra for the first n records to display on the first page,
>> and that facets are based on a number of result way below 20 000 anyway, so
>> the total number of results shouldn't really make a difference.
>>
>> --
>> Gaetan Boisson
>> Chef de projet biblioth?caire
>> BibLibre
>> 06 52 42 51 29
>> 108 avenue Breteuil 13006 Marseille
>> gaetan.boisson at biblibre.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/

-- 
Gaetan Boisson
Chef de projet biblioth?caire
BibLibre
06 52 42 51 29
108 avenue Breteuil 13006 Marseille
gaetan.boisson at biblibre.com


From paul.a at navalmarinearchive.com  Wed May 27 21:02:20 2015
From: paul.a at navalmarinearchive.com (Paul A)
Date: Wed, 27 May 2015 15:02:20 -0400
Subject: [Koha-devel] search speed
In-Reply-To: <55660D10.9020600@biblibre.com>
References: <CAJzKNY4qm5ruZGgYtNRnpR=3D9nUpySnB=4yVG5L=Yqyb+zW1w@mail.gmail.com>
	<5565A05F.70809@biblibre.com>
	<CAJzKNY4qm5ruZGgYtNRnpR=3D9nUpySnB=4yVG5L=Yqyb+zW1w@mail.gmail.com>
Message-ID: <5.2.1.1.2.20150527145630.03e3c988@pop.navalmarinearchive.com>

At 08:29 PM 5/27/2015 +0200, Gaetan Boisson wrote:
>Well as i said, the time is not the same depending on the number of 
>results, but in both cases, the number of results is anyway much higher 
>than the number of records taken into consideration for facets.
>
>Your investigation indicates that:
>
>In ZOOM->record, the time is spent in
>   my $_rec = Net::Z3950::ZOOM::resultset_record($this->_rs(), $which);
>
>Maybe it's worth having a deeper look in this.

I looked into this to some extent in January this year; facets in 3.18 
<http://navalmarinearchive.com/z_koha/search_speed_data.html> appeared to 
be a limiting factor as it "swamped" one CPU core (and NYProf showed this 
to be from ZOOM - see 
<http://navalmarinearchive.com/z_koha/nytprof_318_s/index.html>

Regards -- Paul


>Le 27/05/2015 12:56, Jonathan Druart a ??crit :
>>Gaetan,
>>have a look at the metrics on bug 13665.
>>
>>2015-05-27 11:45 GMT+01:00 Gaetan Boisson <gaetan.boisson at biblibre.com>:
>>>   Hello again all,
>>>
>>>looking at speed issues there is one thing that i don't understand, and i
>>>feel some well versed developpers might have a better idea of what is
>>>happening.
>>>
>>>If you query zebra directly on the server, it's blazingly fast, no matter
>>>how big your database and how many results you get. (At least the difference
>>>is negligible, and we still get very low response times.)
>>>
>>>But if you do a search in Koha that brings 20 000 results, it's usualy 4
>>>times faster (maybe more, sorry i don't have precise metrics here) than a
>>>search that brings up 1 000 000 results.
>>>
>>>Is it consistent with your experience?
>>>
>>>If it is, what would be the reason for this? My understanding is that the
>>>search code asks zebra for the first n records to display on the first page,
>>>and that facets are based on a number of result way below 20 000 anyway, so
>>>the total number of results shouldn't really make a difference.
>>>
>>>--
>>>Gaetan Boisson
>>>Chef de projet biblioth??caire
>>>BibLibre
>>>06 52 42 51 29
>>>108 avenue Breteuil 13006 Marseille
>>>gaetan.boisson at biblibre.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/
>
>--
>Gaetan Boisson
>Chef de projet biblioth??caire
>BibLibre
>06 52 42 51 29
>108 avenue Breteuil 13006 Marseille
>gaetan.boisson at biblibre.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/
>

---
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 robin at catalyst.net.nz  Thu May 28 01:46:54 2015
From: robin at catalyst.net.nz (Robin Sheat)
Date: Thu, 28 May 2015 11:46:54 +1200
Subject: [Koha-devel] Install Koha 3.20 with Single Command at Ubuntu
 14.04 LTS
In-Reply-To: <CAJJZY-QpEr1rWq3t1soB34M=D4Snxa-jwNJQ=SgEYr2qa4S+OA@mail.gmail.com>
References: <CAJJZY-QpEr1rWq3t1soB34M=D4Snxa-jwNJQ=SgEYr2qa4S+OA@mail.gmail.com>
Message-ID: <1432770414.25145.113.camel@catalyst.net.nz>

DP Tripathi schreef op wo 27-05-2015 om 11:53 [+0530]:
> Just follow the instructions.

Some pretty minor issues to start with:

Why does it do this:

sed -e 's/ident//; s/sameuser/trust/' /etc/apache2/ports.conf.dpt > /etc/apache2/ports.conf
then:
sed -e 's/ident//; s/sameuser/trust/' /etc/mysql/my.cnf.dpt > /etc/mysql/my.cnf
then:
sed -e 's/ident//; s/sameuser/trust/' /etc/perl/XML/SAX/ParserDetails.ini.dpt > /etc/perl/XML/SAX/ParserDetails.ini
?

also, rewriting the ParserDetails.ini hasn't been needed for a long
time.

The code does stuff on port 8000, but the messages talk about port 8080.
I think in general 8080 is the more common port to set up secondary
webservices on.

The last echo writes and then immediately opens an editor to the file,
so you wouldn't know what you need to do with it. If it did show the
message, it would ask them to change the port, and then open firefox,
assuming that it hadn't been changed. Also, if they did change it, it
now wouldn't match the "Listen" line added near the top.

This looks like a reasonable quick-start to get a Koha server up,
though. It won't give you nice things like name-based addressing that
you'd probably want in a production server, but they'd be easy enough to
add on after the fact.

-- 
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: 473 bytes
Desc: This is a digitally signed message part
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20150528/9a6c527e/attachment-0001.pgp>

From robin at catalyst.net.nz  Thu May 28 02:01:12 2015
From: robin at catalyst.net.nz (Robin Sheat)
Date: Thu, 28 May 2015 12:01:12 +1200
Subject: [Koha-devel] Improving Plack intranet performances (circulation
 module)
In-Reply-To: <556598EB.6080601@biblibre.com>
References: <556598EB.6080601@biblibre.com>
Message-ID: <1432771272.25145.119.camel@catalyst.net.nz>

Julian FIOL schreef op wo 27-05-2015 om 12:14 [+0200]:
> By adding the import of Koha::Schema in the intranet.psgi file, we can
> see a significant improvement of the time spent loading the
> circulation page.

Somewhere on a giant TODO-unless-someone-does-it-first list I have in my
head is a plan to make packages that use plack instead of CGI. Probably
a package you can install alongside Koha and it converts all the files
to support plack (Debian has a handy thing that lets you redirect files
that'd make this a lot easier - install the package and it's plack,
remove the package and it's back to normal.) 

This is totally the sort of thing that's really good to know as part of
implementing that, so all sorts of things like this that you find,
please wiki-fy :)

Also, Devel::NYTProf is great for this stuff.

-- 
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: 473 bytes
Desc: This is a digitally signed message part
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20150528/bca7f06b/attachment.pgp>

From fridolin.somers at biblibre.com  Thu May 28 09:05:43 2015
From: fridolin.somers at biblibre.com (Fridolin SOMERS)
Date: Thu, 28 May 2015 09:05:43 +0200
Subject: [Koha-devel] Install Koha 3.20 with Single Command at Ubuntu
 14.04 LTS
In-Reply-To: <CAJJZY-QpEr1rWq3t1soB34M=D4Snxa-jwNJQ=SgEYr2qa4S+OA@mail.gmail.com>
References: <CAJJZY-QpEr1rWq3t1soB34M=D4Snxa-jwNJQ=SgEYr2qa4S+OA@mail.gmail.com>
Message-ID: <5566BE47.8090204@biblibre.com>

Hie,

Looks greate.

But why forcing apache MPM Prefork since koha-common has apache2-mpm-itk 
has dependancy ?

PS : installing nano will feed the troll ;)

Le 27/05/2015 08:23, DP Tripathi a ?crit :
> Dear All,
>
> Greetings!
>
> Now, Install Koha 3.20 with one single command at Ubuntu 14.04 LTS
>
> Just follow the instructions.
>
> I assume that you have installed Ubuntu 14.04 LTS in your system and it is
> connected with Internet.
>
> Step 1: First download the file at www.librarianguide.co.in/install_koha.sh
>
> Step 2: Wherever you keep the file, just give permission with following
> command.
>
> I assume the file is at /home/library
>
> root at nitr/home/library# chmod +x install_koha.sh (press enter)
>
> root at nitr/home/library# ./install_koha.sh (press enter)
>
> It will start installation. Just follow the instruction and provide
> necessary inputs.
>
> Step 3: After installation of everything it will open window with nano
> editor. Just change the port in Intranet (8000), save (ctrl+x).
>
> Now, it will open Firefox automatically with Koha Web Installer.
>
> User Name: koha_library
>
> Password: Note down the password from
> (/etc/koha/sites/library/koha-conf.xml) file.
>
> The password will be at the bottom of file in <config> section.
>
> Enjoy Koha!
>
> Thanks,
>
> DP Tripathi
> NIT Rourkela
>
>
>
> _______________________________________________
> 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/
>

-- 
Fridolin SOMERS
Biblibre - P?les support et syst?me
fridolin.somers at biblibre.com

From fridolin.somers at biblibre.com  Thu May 28 09:43:40 2015
From: fridolin.somers at biblibre.com (Fridolin SOMERS)
Date: Thu, 28 May 2015 09:43:40 +0200
Subject: [Koha-devel] search speed
In-Reply-To: <5.2.1.1.2.20150527145630.03e3c988@pop.navalmarinearchive.com>
References: <CAJzKNY4qm5ruZGgYtNRnpR=3D9nUpySnB=4yVG5L=Yqyb+zW1w@mail.gmail.com>	<5565A05F.70809@biblibre.com>	<CAJzKNY4qm5ruZGgYtNRnpR=3D9nUpySnB=4yVG5L=Yqyb+zW1w@mail.gmail.com>
	<5.2.1.1.2.20150527145630.03e3c988@pop.navalmarinearchive.com>
Message-ID: <5566C72C.3010900@biblibre.com>

Could this mean one should not get records from Zebra but directly from 
database ? If getting the id of search results without getting the full 
record is possible.

Le 27/05/2015 21:02, Paul A a ?crit :
> At 08:29 PM 5/27/2015 +0200, Gaetan Boisson wrote:
>> Well as i said, the time is not the same depending on the number of
>> results, but in both cases, the number of results is anyway much
>> higher than the number of records taken into consideration for facets.
>>
>> Your investigation indicates that:
>>
>> In ZOOM->record, the time is spent in
>>   my $_rec = Net::Z3950::ZOOM::resultset_record($this->_rs(), $which);
>>
>> Maybe it's worth having a deeper look in this.
>
> I looked into this to some extent in January this year; facets in 3.18
> <http://navalmarinearchive.com/z_koha/search_speed_data.html> appeared
> to be a limiting factor as it "swamped" one CPU core (and NYProf showed
> this to be from ZOOM - see
> <http://navalmarinearchive.com/z_koha/nytprof_318_s/index.html>
>
> Regards -- Paul
>
>
>> Le 27/05/2015 12:56, Jonathan Druart a ??crit :
>>> Gaetan,
>>> have a look at the metrics on bug 13665.
>>>
>>> 2015-05-27 11:45 GMT+01:00 Gaetan Boisson <gaetan.boisson at biblibre.com>:
>>>>   Hello again all,
>>>>
>>>> looking at speed issues there is one thing that i don't understand,
>>>> and i
>>>> feel some well versed developpers might have a better idea of what is
>>>> happening.
>>>>
>>>> If you query zebra directly on the server, it's blazingly fast, no
>>>> matter
>>>> how big your database and how many results you get. (At least the
>>>> difference
>>>> is negligible, and we still get very low response times.)
>>>>
>>>> But if you do a search in Koha that brings 20 000 results, it's
>>>> usualy 4
>>>> times faster (maybe more, sorry i don't have precise metrics here)
>>>> than a
>>>> search that brings up 1 000 000 results.
>>>>
>>>> Is it consistent with your experience?
>>>>
>>>> If it is, what would be the reason for this? My understanding is
>>>> that the
>>>> search code asks zebra for the first n records to display on the
>>>> first page,
>>>> and that facets are based on a number of result way below 20 000
>>>> anyway, so
>>>> the total number of results shouldn't really make a difference.
>>>>
>>>> --
>>>> Gaetan Boisson
>>>> Chef de projet biblioth??caire
>>>> BibLibre
>>>> 06 52 42 51 29
>>>> 108 avenue Breteuil 13006 Marseille
>>>> gaetan.boisson at biblibre.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/
>>
>> --
>> Gaetan Boisson
>> Chef de projet biblioth??caire
>> BibLibre
>> 06 52 42 51 29
>> 108 avenue Breteuil 13006 Marseille
>> gaetan.boisson at biblibre.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/
>>
>
> ---
> Maritime heritage and history, preservation and conservation,
> research and education through the written word and the arts.
> <http://NavalMarineArchive.com> and <http://UltraMarine.ca>
>
> _______________________________________________
> 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/

-- 
Fridolin SOMERS
Biblibre - P?les support et syst?me
fridolin.somers at biblibre.com

From tomascohen at gmail.com  Thu May 28 12:52:07 2015
From: tomascohen at gmail.com (Tomas Cohen Arazi)
Date: Thu, 28 May 2015 07:52:07 -0300
Subject: [Koha-devel] search speed
In-Reply-To: <5566C72C.3010900@biblibre.com>
References: <5565A05F.70809@biblibre.com>
	<CAJzKNY4qm5ruZGgYtNRnpR=3D9nUpySnB=4yVG5L=Yqyb+zW1w@mail.gmail.com>
	<5.2.1.1.2.20150527145630.03e3c988@pop.navalmarinearchive.com>
	<5566C72C.3010900@biblibre.com>
Message-ID: <CABZfb=UaRGTH5+fMpgL5fCNC9K_TuiCZRjYJkGbUm03ZXwUqXw@mail.gmail.com>

El 28/5/2015 4:43 a. m., "Fridolin SOMERS" <fridolin.somers at biblibre.com>
escribi?:
>
> Could this mean one should not get records from Zebra but directly from
database ? If getting the id of search results without getting the full
record is possible.

It is possible. But we should evaluate the trade-off from preparing the
record for display too. Because for indexing we do lots of stuff to the
record, stuff that should be done on rendering time with such a change.

>
> Le 27/05/2015 21:02, Paul A a ?crit :
>>
>> At 08:29 PM 5/27/2015 +0200, Gaetan Boisson wrote:
>>>
>>> Well as i said, the time is not the same depending on the number of
>>> results, but in both cases, the number of results is anyway much
>>> higher than the number of records taken into consideration for facets.
>>>
>>> Your investigation indicates that:
>>>
>>> In ZOOM->record, the time is spent in
>>>   my $_rec = Net::Z3950::ZOOM::resultset_record($this->_rs(), $which);
>>>
>>> Maybe it's worth having a deeper look in this.
>>
>>
>> I looked into this to some extent in January this year; facets in 3.18
>> <http://navalmarinearchive.com/z_koha/search_speed_data.html> appeared
>> to be a limiting factor as it "swamped" one CPU core (and NYProf showed
>> this to be from ZOOM - see
>> <http://navalmarinearchive.com/z_koha/nytprof_318_s/index.html>
>>
>> Regards -- Paul
>>
>>
>>> Le 27/05/2015 12:56, Jonathan Druart a ??crit :
>>>>
>>>> Gaetan,
>>>> have a look at the metrics on bug 13665.
>>>>
>>>> 2015-05-27 11:45 GMT+01:00 Gaetan Boisson <gaetan.boisson at biblibre.com
>:
>>>>>
>>>>>   Hello again all,
>>>>>
>>>>> looking at speed issues there is one thing that i don't understand,
>>>>> and i
>>>>> feel some well versed developpers might have a better idea of what is
>>>>> happening.
>>>>>
>>>>> If you query zebra directly on the server, it's blazingly fast, no
>>>>> matter
>>>>> how big your database and how many results you get. (At least the
>>>>> difference
>>>>> is negligible, and we still get very low response times.)
>>>>>
>>>>> But if you do a search in Koha that brings 20 000 results, it's
>>>>> usualy 4
>>>>> times faster (maybe more, sorry i don't have precise metrics here)
>>>>> than a
>>>>> search that brings up 1 000 000 results.
>>>>>
>>>>> Is it consistent with your experience?
>>>>>
>>>>> If it is, what would be the reason for this? My understanding is
>>>>> that the
>>>>> search code asks zebra for the first n records to display on the
>>>>> first page,
>>>>> and that facets are based on a number of result way below 20 000
>>>>> anyway, so
>>>>> the total number of results shouldn't really make a difference.
>>>>>
>>>>> --
>>>>> Gaetan Boisson
>>>>> Chef de projet biblioth??caire
>>>>> BibLibre
>>>>> 06 52 42 51 29
>>>>> 108 avenue Breteuil 13006 Marseille
>>>>> gaetan.boisson at biblibre.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/
>>>
>>>
>>> --
>>> Gaetan Boisson
>>> Chef de projet biblioth??caire
>>> BibLibre
>>> 06 52 42 51 29
>>> 108 avenue Breteuil 13006 Marseille
>>> gaetan.boisson at biblibre.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/
>>>
>>
>> ---
>> Maritime heritage and history, preservation and conservation,
>> research and education through the written word and the arts.
>> <http://NavalMarineArchive.com> and <http://UltraMarine.ca>
>>
>> _______________________________________________
>> 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/
>
>
> --
> Fridolin SOMERS
> Biblibre - P?les support et syst?me
> fridolin.somers at biblibre.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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20150528/68964aaf/attachment.html>

From paul.a at navalmarinearchive.com  Thu May 28 15:54:51 2015
From: paul.a at navalmarinearchive.com (Paul A)
Date: Thu, 28 May 2015 09:54:51 -0400
Subject: [Koha-devel] search speed
In-Reply-To: <CABZfb=UaRGTH5+fMpgL5fCNC9K_TuiCZRjYJkGbUm03ZXwUqXw@mail.g
	mail.com>
References: <5566C72C.3010900@biblibre.com> <5565A05F.70809@biblibre.com>
	<CAJzKNY4qm5ruZGgYtNRnpR=3D9nUpySnB=4yVG5L=Yqyb+zW1w@mail.gmail.com>
	<5.2.1.1.2.20150527145630.03e3c988@pop.navalmarinearchive.com>
	<5566C72C.3010900@biblibre.com>
Message-ID: <5.2.1.1.2.20150528094244.02578240@pop.navalmarinearchive.com>

At 07:52 AM 5/28/2015 -0300, Tomas Cohen Arazi wrote:


>El 28/5/2015 4:43 a. m., "Fridolin SOMERS" <fridolin.somers at biblibre.com> 
>escribi??:
> >
> > Could this mean one should not get records from Zebra but directly from 
> database ? If getting the id of search results without getting the full 
> record is possible.
>
>It is possible. But we should evaluate the trade-off from preparing the 
>record for display too. Because for indexing we do lots of stuff to the 
>record, stuff that should be done on rendering time with such a change.

Interesting. The rendering is only on 20 records, while the search is on 
tens or hundreds of thousands of records. It would obviously be a major 
exercise, but the trade-off would be enormous *if* it avoids the overload 
on the single core of the CPU (multi-threading across cores is, from what I 
was able to found out, just an impossible dream.)

Facets are a search enhancement with enormous potential, but when the time 
required increases from a few tenths of a second to 20 seconds+, we felt we 
could not put it into production -- our users tend to want "instant 
gratification."

Best -- Paul


> >
> > Le 27/05/2015 21:02, Paul A a ??crit :
> >>
> >> At 08:29 PM 5/27/2015 +0200, Gaetan Boisson wrote:
> >>>
> >>> Well as i said, the time is not the same depending on the number of
> >>> results, but in both cases, the number of results is anyway much
> >>> higher than the number of records taken into consideration for facets.
> >>>
> >>> Your investigation indicates that:
> >>>
> >>> In ZOOM->record, the time is spent in
> >>> ?  my $_rec = Net::Z3950::ZOOM::resultset_record($this->_rs(), $which);
> >>>
> >>> Maybe it's worth having a deeper look in this.
> >>
> >>
> >> I looked into this to some extent in January this year; facets in 3.18
> >> <http://navalmarinearchive.com/z_koha/search_speed_data.html> appeared
> >> to be a limiting factor as it "swamped" one CPU core (and NYProf showed
> >> this to be from ZOOM - see
> >> <http://navalmarinearchive.com/z_koha/nytprof_318_s/index.html>
> >>
> >> Regards -- Paul
> >>
> >>
> >>> Le 27/05/2015 12:56, Jonathan Druart a ????crit :
> >>>>
> >>>> Gaetan,
> >>>> have a look at the metrics on bug 13665.
> >>>>
> >>>> 2015-05-27 11:45 GMT+01:00 Gaetan Boisson <gaetan.boisson at biblibre.com>:
> >>>>>
> >>>>> ?  Hello again all,
> >>>>>
> >>>>> looking at speed issues there is one thing that i don't understand,
> >>>>> and i
> >>>>> feel some well versed developpers might have a better idea of what is
> >>>>> happening.
> >>>>>
> >>>>> If you query zebra directly on the server, it's blazingly fast, no
> >>>>> matter
> >>>>> how big your database and how many results you get. (At least the
> >>>>> difference
> >>>>> is negligible, and we still get very low response times.)
> >>>>>
> >>>>> But if you do a search in Koha that brings 20 000 results, it's
> >>>>> usualy 4
> >>>>> times faster (maybe more, sorry i don't have precise metrics here)
> >>>>> than a
> >>>>> search that brings up 1 000 000 results.
> >>>>>
> >>>>> Is it consistent with your experience?
> >>>>>
> >>>>> If it is, what would be the reason for this? My understanding is
> >>>>> that the
> >>>>> search code asks zebra for the first n records to display on the
> >>>>> first page,
> >>>>> and that facets are based on a number of result way below 20 000
> >>>>> anyway, so
> >>>>> the total number of results shouldn't really make a difference.
> >>>>>
> >>>>> --
> >>>>> Gaetan Boisson
> >>>>> Chef de projet biblioth????caire
> >>>>> BibLibre
> >>>>> 06 52 42 51 29
> >>>>> 108 avenue Breteuil 13006 Marseille
> >>>>> gaetan.boisson at biblibre.com


From tomascohen at gmail.com  Thu May 28 16:18:22 2015
From: tomascohen at gmail.com (Tomas Cohen Arazi)
Date: Thu, 28 May 2015 11:18:22 -0300
Subject: [Koha-devel] Call for Dev Meeting June 3
Message-ID: <CABZfb=W-3=F67VEy=ESJv85gR=D4qr36UwY_FBf-m5Nt138tvA@mail.gmail.com>

Hi everyone, starting the 3.22 cycle i'd like to keep a 3-week frecquency
for dev meetings.
Lots of big stuff is being worked by different people/teams so having a
regular/deterministic schedule for the meetings might be handy to keep
communicated.

Next meeting will be held next wednestady, with the already used
two-session schema. The agenda will look short at first sight, but we all
know it is not :-D

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

 =Short=

Day: June 3 2015
Time:
 - Part 1: 15:00 UTC
 - Part 1: 22:00 UTC

All comments are welcome.

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

From mtompset at hotmail.com  Thu May 28 16:31:41 2015
From: mtompset at hotmail.com (Mark Tompsett)
Date: Thu, 28 May 2015 10:31:41 -0400
Subject: [Koha-devel] getFrameworkLanguages
Message-ID: <BLU172-DS1582A8F34BB753A4D41A10C6CA0@phx.gbl>

Greetings,

Indranil Das Gupta found this painful to see typo in getFrameworkLanguages: 
'native_descrition'=>$language_set->{language_native_description}.
I told him, tweaking C4/Languages requires writing a test (good rule of 
thumb). So, I wake up, and discover no tests were yet written, and I was 
itching for a sign off. So, I attempt and discover the hole is deeper than 
initially thought. In fact, Indranil Das Gupta pointed out to me that it 
doesn't seem to be used anywhere.

mtompset at debian:~/kohaclone$ git grep getFrameworkLanguages
C4/Languages.pm:        memoize_memcached('getFrameworkLanguages' , 
memcached => C4::Context->memcached);

Part of an export --
C4/Languages.pm:        &getFrameworkLanguages

More exporting --
C4/Languages.pm:    @EXPORT_OK = qw(getFrameworkLanguages 
getTranslatedLanguages getAllLanguages getLanguages get_bidi 
regex_lang_subtags language_get_description accept_language getlanguage);

POD stuff --
C4/Languages.pm:=head2 getFrameworkLanguages

POD stuff example --
C4/Languages.pm: my $languages = getFrameworkLanguages();

Actual function head --
C4/Languages.pm:sub getFrameworkLanguages {


As you can tell I didn't comment on one piece: that memoize_memcached line. 
Is there another thing to trace to figure out if it is used in the memoize 
logic somewhere, or is it safe to remove this function? Feedback 
appreciated.

What bug 14284 becomes is dependent on feedback.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14284

GPML,
Mark Tompsett 


From tomascohen at gmail.com  Thu May 28 16:35:51 2015
From: tomascohen at gmail.com (Tomas Cohen Arazi)
Date: Thu, 28 May 2015 11:35:51 -0300
Subject: [Koha-devel] getFrameworkLanguages
In-Reply-To: <BLU172-DS1582A8F34BB753A4D41A10C6CA0@phx.gbl>
References: <BLU172-DS1582A8F34BB753A4D41A10C6CA0@phx.gbl>
Message-ID: <CABZfb=Wtpc77+AcYQfo6c=1XirtOYph-DHdonPG5vsGt5ryL-A@mail.gmail.com>

We have dead code in lots of places. A cleanup is not a bad idea, but we
should be careful with API changes because someone could be using it. I
didn't spend time on looking at the code. We can add it to the agentda for
the meeting.

2015-05-28 11:31 GMT-03:00 Mark Tompsett <mtompset at hotmail.com>:

> Greetings,
>
> Indranil Das Gupta found this painful to see typo in
> getFrameworkLanguages:
> 'native_descrition'=>$language_set->{language_native_description}.
> I told him, tweaking C4/Languages requires writing a test (good rule of
> thumb). So, I wake up, and discover no tests were yet written, and I was
> itching for a sign off. So, I attempt and discover the hole is deeper than
> initially thought. In fact, Indranil Das Gupta pointed out to me that it
> doesn't seem to be used anywhere.
>
> mtompset at debian:~/kohaclone$ git grep getFrameworkLanguages
> C4/Languages.pm:        memoize_memcached('getFrameworkLanguages' ,
> memcached => C4::Context->memcached);
>
> Part of an export --
> C4/Languages.pm:        &getFrameworkLanguages
>
> More exporting --
> C4/Languages.pm:    @EXPORT_OK = qw(getFrameworkLanguages
> getTranslatedLanguages getAllLanguages getLanguages get_bidi
> regex_lang_subtags language_get_description accept_language getlanguage);
>
> POD stuff --
> C4/Languages.pm:=head2 getFrameworkLanguages
>
> POD stuff example --
> C4/Languages.pm: my $languages = getFrameworkLanguages();
>
> Actual function head --
> C4/Languages.pm:sub getFrameworkLanguages {
>
>
> As you can tell I didn't comment on one piece: that memoize_memcached
> line. Is there another thing to trace to figure out if it is used in the
> memoize logic somewhere, or is it safe to remove this function? Feedback
> appreciated.
>
> What bug 14284 becomes is dependent on feedback.
> http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14284
>
> GPML,
> Mark Tompsett
> _______________________________________________
> 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/
>



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

From mtompset at hotmail.com  Thu May 28 16:46:12 2015
From: mtompset at hotmail.com (Mark Tompsett)
Date: Thu, 28 May 2015 10:46:12 -0400
Subject: [Koha-devel] getFrameworkLanguages
In-Reply-To: <CABZfb=Wtpc77+AcYQfo6c=1XirtOYph-DHdonPG5vsGt5ryL-A@mail.gmail.com>
References: <BLU172-DS1582A8F34BB753A4D41A10C6CA0@phx.gbl>
	<CABZfb=Wtpc77+AcYQfo6c=1XirtOYph-DHdonPG5vsGt5ryL-A@mail.gmail.com>
Message-ID: <BLU172-DS1100199FD04161A8320218C6CA0@phx.gbl>

Greetings,

Shortly after I posted my note, I noticed bug 12017. 
It removes it. I think we may have a duplicate. Sorry, Indranil Das Gupta.

GPML,
Mark Tompsett

From: Tomas Cohen Arazi 
Sent: Thursday, May 28, 2015 10:35 AM
To: Mark Tompsett 
Cc: koha-devel 
Subject: Re: [Koha-devel] getFrameworkLanguages

We have dead code in lots of places. A cleanup is not a bad idea, but we should be careful with API changes because someone could be using it. I didn't spend time on looking at the code. We can add it to the agentda for the meeting.

2015-05-28 11:31 GMT-03:00 Mark Tompsett <mtompset at hotmail.com>:

  Greetings,

  Indranil Das Gupta found this painful to see typo in getFrameworkLanguages: 'native_descrition'=>$language_set->{language_native_description}.
  I told him, tweaking C4/Languages requires writing a test (good rule of thumb). So, I wake up, and discover no tests were yet written, and I was itching for a sign off. So, I attempt and discover the hole is deeper than initially thought. In fact, Indranil Das Gupta pointed out to me that it doesn't seem to be used anywhere.

  mtompset at debian:~/kohaclone$ git grep getFrameworkLanguages
  C4/Languages.pm:        memoize_memcached('getFrameworkLanguages' , memcached => C4::Context->memcached);

  Part of an export --
  C4/Languages.pm:        &getFrameworkLanguages

  More exporting --
  C4/Languages.pm:    @EXPORT_OK = qw(getFrameworkLanguages getTranslatedLanguages getAllLanguages getLanguages get_bidi regex_lang_subtags language_get_description accept_language getlanguage);

  POD stuff --
  C4/Languages.pm:=head2 getFrameworkLanguages

  POD stuff example --
  C4/Languages.pm: my $languages = getFrameworkLanguages();

  Actual function head --
  C4/Languages.pm:sub getFrameworkLanguages {


  As you can tell I didn't comment on one piece: that memoize_memcached line. Is there another thing to trace to figure out if it is used in the memoize logic somewhere, or is it safe to remove this function? Feedback appreciated.

  What bug 14284 becomes is dependent on feedback.
  http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14284

  GPML,
  Mark Tompsett 
  _______________________________________________
  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/





-- 

Tom?s Cohen Arazi
Prosecretar?a de Inform?tica
Universidad Nacional de C?rdoba
? +54 351 5353750 ext 13168
GPG: B76C 6E7C 2D80 551A C765  E225 0A27 2EA1 B2F3 C15F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20150528/f3db8810/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wlEmoticon-smile[1].png
Type: image/png
Size: 1046 bytes
Desc: not available
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20150528/f3db8810/attachment.png>

From julian.fiol at biblibre.com  Thu May 28 16:48:41 2015
From: julian.fiol at biblibre.com (Julian FIOL)
Date: Thu, 28 May 2015 16:48:41 +0200
Subject: [Koha-devel] getFrameworkLanguages
In-Reply-To: <BLU172-DS1582A8F34BB753A4D41A10C6CA0@phx.gbl>
References: <BLU172-DS1582A8F34BB753A4D41A10C6CA0@phx.gbl>
Message-ID: <55672AC9.7010205@biblibre.com>

Hi,

Bernardo Gonzales Kriegel made a lot of work with bug 12017 around this, 
and clean up getFrameworkLanguages and other useless things.

It also move the language_description table out of database, and put it 
in templates.
This is really interesting concerning traduction and performances !

Regards,
Julian FIOL


On 28/05/2015 16:31, Mark Tompsett wrote:
> Greetings,
>
> Indranil Das Gupta found this painful to see typo in 
> getFrameworkLanguages: 
> 'native_descrition'=>$language_set->{language_native_description}.
> I told him, tweaking C4/Languages requires writing a test (good rule 
> of thumb). So, I wake up, and discover no tests were yet written, and 
> I was itching for a sign off. So, I attempt and discover the hole is 
> deeper than initially thought. In fact, Indranil Das Gupta pointed out 
> to me that it doesn't seem to be used anywhere.
>
> mtompset at debian:~/kohaclone$ git grep getFrameworkLanguages
> C4/Languages.pm:        memoize_memcached('getFrameworkLanguages' , 
> memcached => C4::Context->memcached);
>
> Part of an export --
> C4/Languages.pm:        &getFrameworkLanguages
>
> More exporting --
> C4/Languages.pm:    @EXPORT_OK = qw(getFrameworkLanguages 
> getTranslatedLanguages getAllLanguages getLanguages get_bidi 
> regex_lang_subtags language_get_description accept_language getlanguage);
>
> POD stuff --
> C4/Languages.pm:=head2 getFrameworkLanguages
>
> POD stuff example --
> C4/Languages.pm: my $languages = getFrameworkLanguages();
>
> Actual function head --
> C4/Languages.pm:sub getFrameworkLanguages {
>
>
> As you can tell I didn't comment on one piece: that memoize_memcached 
> line. Is there another thing to trace to figure out if it is used in 
> the memoize logic somewhere, or is it safe to remove this function? 
> Feedback appreciated.
>
> What bug 14284 becomes is dependent on feedback.
> http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14284
>
> GPML,
> Mark Tompsett
> _______________________________________________
> 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/20150528/8bea52cb/attachment.html>

From barton at bywatersolutions.com  Thu May 28 17:08:39 2015
From: barton at bywatersolutions.com (Barton Chittenden)
Date: Thu, 28 May 2015 11:08:39 -0400
Subject: [Koha-devel] getFrameworkLanguages
In-Reply-To: <CABZfb=Wtpc77+AcYQfo6c=1XirtOYph-DHdonPG5vsGt5ryL-A@mail.gmail.com>
References: <BLU172-DS1582A8F34BB753A4D41A10C6CA0@phx.gbl>
	<CABZfb=Wtpc77+AcYQfo6c=1XirtOYph-DHdonPG5vsGt5ryL-A@mail.gmail.com>
Message-ID: <CAMSJbVvcwkycR6rqCVg1KhafjVjpm1zzwtdXoyU8XALkJ+-+rw@mail.gmail.com>

I mentioned this in #koha a few weeks ago, but this seems like a perfect
place to bring it up again:

http://devblog.nestoria.com/post/115930183873/tombstones-for-dead-code

Essentially, this is a method for adding executable markers near code that
you want to remove. If you look for the results of the markers, and never
find them, you know that the code has never been called, and is safe to
remove (watch the video for discussion of a few subtle points)

--Barton

On Thu, May 28, 2015 at 10:35 AM, Tomas Cohen Arazi <tomascohen at gmail.com>
wrote:

> We have dead code in lots of places. A cleanup is not a bad idea, but we
> should be careful with API changes because someone could be using it. I
> didn't spend time on looking at the code. We can add it to the agentda for
> the meeting.
>
> 2015-05-28 11:31 GMT-03:00 Mark Tompsett <mtompset at hotmail.com>:
>
> Greetings,
>>
>> Indranil Das Gupta found this painful to see typo in
>> getFrameworkLanguages:
>> 'native_descrition'=>$language_set->{language_native_description}.
>> I told him, tweaking C4/Languages requires writing a test (good rule of
>> thumb). So, I wake up, and discover no tests were yet written, and I was
>> itching for a sign off. So, I attempt and discover the hole is deeper than
>> initially thought. In fact, Indranil Das Gupta pointed out to me that it
>> doesn't seem to be used anywhere.
>>
>> mtompset at debian:~/kohaclone$ git grep getFrameworkLanguages
>> C4/Languages.pm:        memoize_memcached('getFrameworkLanguages' ,
>> memcached => C4::Context->memcached);
>>
>> Part of an export --
>> C4/Languages.pm:        &getFrameworkLanguages
>>
>> More exporting --
>> C4/Languages.pm:    @EXPORT_OK = qw(getFrameworkLanguages
>> getTranslatedLanguages getAllLanguages getLanguages get_bidi
>> regex_lang_subtags language_get_description accept_language getlanguage);
>>
>> POD stuff --
>> C4/Languages.pm:=head2 getFrameworkLanguages
>>
>> POD stuff example --
>> C4/Languages.pm: my $languages = getFrameworkLanguages();
>>
>> Actual function head --
>> C4/Languages.pm:sub getFrameworkLanguages {
>>
>>
>> As you can tell I didn't comment on one piece: that memoize_memcached
>> line. Is there another thing to trace to figure out if it is used in the
>> memoize logic somewhere, or is it safe to remove this function? Feedback
>> appreciated.
>>
>> What bug 14284 becomes is dependent on feedback.
>> http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14284
>>
>> GPML,
>> Mark Tompsett
>> _______________________________________________
>> 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/
>>
>
>
>
> --
> Tom?s Cohen Arazi
> Prosecretar?a de Inform?tica
> Universidad Nacional de C?rdoba
> ? +54 351 5353750 ext 13168
> GPG: B76C 6E7C 2D80 551A C765  E225 0A27 2EA1 B2F3 C15F
>
> _______________________________________________
> 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/20150528/fc703c98/attachment-0001.html>

From fridolin.somers at biblibre.com  Thu May 28 17:21:15 2015
From: fridolin.somers at biblibre.com (Fridolin SOMERS)
Date: Thu, 28 May 2015 17:21:15 +0200
Subject: [Koha-devel] Improving Plack intranet performances (circulation
 module)
In-Reply-To: <556598EB.6080601@biblibre.com>
References: <556598EB.6080601@biblibre.com>
Message-ID: <5567326B.30106@biblibre.com>

Very good news, thanks

Le 27/05/2015 12:14, Julian FIOL a ?crit :
> Hi everyone,
>
> Using Devel::NYTProf on a Plack config, I noticed that when we checkout
> an item in the circulation page, there is a really long time spent
> creating the database schema.
>
> By adding the import of *Koha::Schema* in the *intranet.psgi* file, we
> can see a significant improvement of the time spent loading the
> circulation page.
>
> Please find here
> <http://www.slideshare.net/JulianFiol/koha-circulation-checkout-improvement>
> (in full screen) the proof of what I'm saying.
>
> I have also added the manipulations to do into the Plack
> <http://wiki.koha-community.org/wiki/Plack#Improving_Plack_performance>
> wiki.
>
> Regards,
> Julian FIOL
>
>
>
> _______________________________________________
> 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/
>

-- 
Fridolin SOMERS
Biblibre - P?les support et syst?me
fridolin.somers at biblibre.com

From tomascohen at gmail.com  Thu May 28 17:22:39 2015
From: tomascohen at gmail.com (Tomas Cohen Arazi)
Date: Thu, 28 May 2015 12:22:39 -0300
Subject: [Koha-devel] Improving Plack intranet performances (circulation
	module)
In-Reply-To: <5567326B.30106@biblibre.com>
References: <556598EB.6080601@biblibre.com> <5567326B.30106@biblibre.com>
Message-ID: <CABZfb=VQ=XXfhntpP30kjZ8Kw8POMqfVH_9CtF8i8jdTQkucbQ@mail.gmail.com>

I resumed my work on automating plack usage on packages installs. News
about it soon.

2015-05-28 12:21 GMT-03:00 Fridolin SOMERS <fridolin.somers at biblibre.com>:

> Very good news, thanks
>
> Le 27/05/2015 12:14, Julian FIOL a ?crit :
>
>> Hi everyone,
>>
>> Using Devel::NYTProf on a Plack config, I noticed that when we checkout
>> an item in the circulation page, there is a really long time spent
>> creating the database schema.
>>
>> By adding the import of *Koha::Schema* in the *intranet.psgi* file, we
>> can see a significant improvement of the time spent loading the
>> circulation page.
>>
>> Please find here
>> <
>> http://www.slideshare.net/JulianFiol/koha-circulation-checkout-improvement
>> >
>> (in full screen) the proof of what I'm saying.
>>
>> I have also added the manipulations to do into the Plack
>> <http://wiki.koha-community.org/wiki/Plack#Improving_Plack_performance>
>> wiki.
>>
>> Regards,
>> Julian FIOL
>>
>>
>>
>> _______________________________________________
>> 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/
>>
>>
> --
> Fridolin SOMERS
> Biblibre - P?les support et syst?me
> fridolin.somers at biblibre.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/
>



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

From fridolin.somers at biblibre.com  Thu May 28 17:23:51 2015
From: fridolin.somers at biblibre.com (Fridolin SOMERS)
Date: Thu, 28 May 2015 17:23:51 +0200
Subject: [Koha-devel] search speed
In-Reply-To: <CABZfb=UaRGTH5+fMpgL5fCNC9K_TuiCZRjYJkGbUm03ZXwUqXw@mail.gmail.com>
References: <5565A05F.70809@biblibre.com>	<CAJzKNY4qm5ruZGgYtNRnpR=3D9nUpySnB=4yVG5L=Yqyb+zW1w@mail.gmail.com>	<5.2.1.1.2.20150527145630.03e3c988@pop.navalmarinearchive.com>	<5566C72C.3010900@biblibre.com>
	<CABZfb=UaRGTH5+fMpgL5fCNC9K_TuiCZRjYJkGbUm03ZXwUqXw@mail.gmail.com>
Message-ID: <55673307.1090104@biblibre.com>



Le 28/05/2015 12:52, Tomas Cohen Arazi a ?crit :
> El 28/5/2015 4:43 a. m., "Fridolin SOMERS" <fridolin.somers at biblibre.com>
> escribi?:
>>
>> Could this mean one should not get records from Zebra but directly from
> database ? If getting the id of search results without getting the full
> record is possible.
>
> It is possible. But we should evaluate the trade-off from preparing the
> record for display too. Because for indexing we do lots of stuff to the
> record, stuff that should be done on rendering time with such a change.
What changes ?
For detail page, the record comes from database so it should not be 
different for search results page.

>
>>
>> Le 27/05/2015 21:02, Paul A a ?crit :
>>>
>>> At 08:29 PM 5/27/2015 +0200, Gaetan Boisson wrote:
>>>>
>>>> Well as i said, the time is not the same depending on the number of
>>>> results, but in both cases, the number of results is anyway much
>>>> higher than the number of records taken into consideration for facets.
>>>>
>>>> Your investigation indicates that:
>>>>
>>>> In ZOOM->record, the time is spent in
>>>>    my $_rec = Net::Z3950::ZOOM::resultset_record($this->_rs(), $which);
>>>>
>>>> Maybe it's worth having a deeper look in this.
>>>
>>>
>>> I looked into this to some extent in January this year; facets in 3.18
>>> <http://navalmarinearchive.com/z_koha/search_speed_data.html> appeared
>>> to be a limiting factor as it "swamped" one CPU core (and NYProf showed
>>> this to be from ZOOM - see
>>> <http://navalmarinearchive.com/z_koha/nytprof_318_s/index.html>
>>>
>>> Regards -- Paul
>>>
>>>
>>>> Le 27/05/2015 12:56, Jonathan Druart a ??crit :
>>>>>
>>>>> Gaetan,
>>>>> have a look at the metrics on bug 13665.
>>>>>
>>>>> 2015-05-27 11:45 GMT+01:00 Gaetan Boisson <gaetan.boisson at biblibre.com
>> :
>>>>>>
>>>>>>    Hello again all,
>>>>>>
>>>>>> looking at speed issues there is one thing that i don't understand,
>>>>>> and i
>>>>>> feel some well versed developpers might have a better idea of what is
>>>>>> happening.
>>>>>>
>>>>>> If you query zebra directly on the server, it's blazingly fast, no
>>>>>> matter
>>>>>> how big your database and how many results you get. (At least the
>>>>>> difference
>>>>>> is negligible, and we still get very low response times.)
>>>>>>
>>>>>> But if you do a search in Koha that brings 20 000 results, it's
>>>>>> usualy 4
>>>>>> times faster (maybe more, sorry i don't have precise metrics here)
>>>>>> than a
>>>>>> search that brings up 1 000 000 results.
>>>>>>
>>>>>> Is it consistent with your experience?
>>>>>>
>>>>>> If it is, what would be the reason for this? My understanding is
>>>>>> that the
>>>>>> search code asks zebra for the first n records to display on the
>>>>>> first page,
>>>>>> and that facets are based on a number of result way below 20 000
>>>>>> anyway, so
>>>>>> the total number of results shouldn't really make a difference.
>>>>>>
>>>>>> --
>>>>>> Gaetan Boisson
>>>>>> Chef de projet biblioth??caire
>>>>>> BibLibre
>>>>>> 06 52 42 51 29
>>>>>> 108 avenue Breteuil 13006 Marseille
>>>>>> gaetan.boisson at biblibre.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/
>>>>
>>>>
>>>> --
>>>> Gaetan Boisson
>>>> Chef de projet biblioth??caire
>>>> BibLibre
>>>> 06 52 42 51 29
>>>> 108 avenue Breteuil 13006 Marseille
>>>> gaetan.boisson at biblibre.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/
>>>>
>>>
>>> ---
>>> Maritime heritage and history, preservation and conservation,
>>> research and education through the written word and the arts.
>>> <http://NavalMarineArchive.com> and <http://UltraMarine.ca>
>>>
>>> _______________________________________________
>>> 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/
>>
>>
>> --
>> Fridolin SOMERS
>> Biblibre - P?les support et syst?me
>> fridolin.somers at biblibre.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/
>

-- 
Fridolin SOMERS
Biblibre - P?les support et syst?me
fridolin.somers at biblibre.com

From veron at veron.ch  Thu May 28 19:23:48 2015
From: veron at veron.ch (=?windows-1252?Q?Marc_V=E9ron?=)
Date: Thu, 28 May 2015 19:23:48 +0200
Subject: [Koha-devel] getFrameworkLanguages
In-Reply-To: <CAMSJbVvcwkycR6rqCVg1KhafjVjpm1zzwtdXoyU8XALkJ+-+rw@mail.gmail.com>
References: <BLU172-DS1582A8F34BB753A4D41A10C6CA0@phx.gbl>	<CABZfb=Wtpc77+AcYQfo6c=1XirtOYph-DHdonPG5vsGt5ryL-A@mail.gmail.com>
	<CAMSJbVvcwkycR6rqCVg1KhafjVjpm1zzwtdXoyU8XALkJ+-+rw@mail.gmail.com>
Message-ID: <55674F24.5080408@veron.ch>

That is really a great idea!

--Marc

Am 28.05.2015 um 17:08 schrieb Barton Chittenden:
> I mentioned this in #koha a few weeks ago, but this seems like a perfect
> place to bring it up again:
>
> http://devblog.nestoria.com/post/115930183873/tombstones-for-dead-code
>
> Essentially, this is a method for adding executable markers near code
> that you want to remove. If you look for the results of the markers, and
> never find them, you know that the code has never been called, and is
> safe to remove (watch the video for discussion of a few subtle points)
>
> --Barton
>
> On Thu, May 28, 2015 at 10:35 AM, Tomas Cohen Arazi
> <tomascohen at gmail.com <mailto:tomascohen at gmail.com>> wrote:
>
>     We have dead code in lots of places. A cleanup is not a bad idea,
>     but we should be careful with API changes because someone could be
>     using it. I didn't spend time on looking at the code. We can add it
>     to the agentda for the meeting.
>
(...)

From long_sam.tw at yahoo.com.tw  Fri May 29 04:58:26 2015
From: long_sam.tw at yahoo.com.tw (long_sam.tw)
Date: Fri, 29 May 2015 02:58:26 +0000 (UTC)
Subject: [Koha-devel] search speed
In-Reply-To: <55673307.1090104@biblibre.com>
References: <55673307.1090104@biblibre.com>
Message-ID: <562141696.297352.1432868306818.JavaMail.yahoo@mail.yahoo.com>

Dear Fridolin, 

I see C4/Context.pm dbh no mysql_use_result options, 
We can try it. but it maybe modify koha SQL statement.

http://search.cpan.org/~capttofu/DBD-mysql-4.011/lib/DBD/mysql.pm

This attribute forces the driver to use mysql_use_result rather than mysql_store_result. The former is faster and less memory consuming, but tends to block other processes. (That's why mysql_store_result is the default.)

BR. 
??, 





> Fridolin SOMERS <fridolin.somers at biblibre.com> ? 2015/5/28 (??) 11:24 PM ???
> > 
> 
> Le 28/05/2015 12:52, Tomas Cohen Arazi a ?crit :
>>  El 28/5/2015 4:43 a. m., "Fridolin SOMERS" 
> <fridolin.somers at biblibre.com>
>>  escribi?:
>>> 
>>>  Could this mean one should not get records from Zebra but directly from
>>  database ? If getting the id of search results without getting the full
>>  record is possible.
>> 
>>  It is possible. But we should evaluate the trade-off from preparing the
>>  record for display too. Because for indexing we do lots of stuff to the
>>  record, stuff that should be done on rendering time with such a change.
> What changes ?
> For detail page, the record comes from database so it should not be 
> different for search results page.
> 
>> 
>>> 
>>>  Le 27/05/2015 21:02, Paul A a ?crit :
>>>> 
>>>>  At 08:29 PM 5/27/2015 +0200, Gaetan Boisson wrote:
>>>>> 
>>>>>  Well as i said, the time is not the same depending on the 
> number of
>>>>>  results, but in both cases, the number of results is anyway 
> much
>>>>>  higher than the number of records taken into consideration for 
> facets.
>>>>> 
>>>>>  Your investigation indicates that:
>>>>> 
>>>>>  In ZOOM->record, the time is spent in
>>>>>     my $_rec = 
> Net::Z3950::ZOOM::resultset_record($this->_rs(), $which);
>>>>> 
>>>>>  Maybe it's worth having a deeper look in this.
>>>> 
>>>> 
>>>>  I looked into this to some extent in January this year; facets in 
> 3.18
>>>>  <http://navalmarinearchive.com/z_koha/search_speed_data.html> 
> appeared
>>>>  to be a limiting factor as it "swamped" one CPU core (and 
> NYProf showed
>>>>  this to be from ZOOM - see
>>>> 
> <http://navalmarinearchive.com/z_koha/nytprof_318_s/index.html>
>>>> 
>>>>  Regards -- Paul
>>>> 
>>>> 
>>>>>  Le 27/05/2015 12:56, Jonathan Druart a ??crit :
>>>>>> 
>>>>>>  Gaetan,
>>>>>>  have a look at the metrics on bug 13665.
>>>>>> 
>>>>>>  2015-05-27 11:45 GMT+01:00 Gaetan Boisson 
> <gaetan.boisson at biblibre.com
>>>  :
>>>>>>> 
>>>>>>>     Hello again all,
>>>>>>> 
>>>>>>>  looking at speed issues there is one thing that i 
> don't understand,
>>>>>>>  and i
>>>>>>>  feel some well versed developpers might have a better 
> idea of what is
>>>>>>>  happening.
>>>>>>> 
>>>>>>>  If you query zebra directly on the server, it's 
> blazingly fast, no
>>>>>>>  matter
>>>>>>>  how big your database and how many results you get. (At 
> least the
>>>>>>>  difference
>>>>>>>  is negligible, and we still get very low response 
> times.)
>>>>>>> 
>>>>>>>  But if you do a search in Koha that brings 20 000 
> results, it's
>>>>>>>  usualy 4
>>>>>>>  times faster (maybe more, sorry i don't have 
> precise metrics here)
>>>>>>>  than a
>>>>>>>  search that brings up 1 000 000 results.
>>>>>>> 
>>>>>>>  Is it consistent with your experience?
>>>>>>> 
>>>>>>>  If it is, what would be the reason for this? My 
> understanding is
>>>>>>>  that the
>>>>>>>  search code asks zebra for the first n records to 
> display on the
>>>>>>>  first page,
>>>>>>>  and that facets are based on a number of result way 
> below 20 000
>>>>>>>  anyway, so
>>>>>>>  the total number of results shouldn't really make a 
> difference.
>>>>>>> 
>>>>>>>  --
>>>>>>>  Gaetan Boisson
>>>>>>>  Chef de projet biblioth??caire
>>>>>>>  BibLibre
>>>>>>>  06 52 42 51 29
>>>>>>>  108 avenue Breteuil 13006 Marseille
>>>>>>>  gaetan.boisson at biblibre.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/
>>>>> 
>>>>> 
>>>>>  --
>>>>>  Gaetan Boisson
>>>>>  Chef de projet biblioth??caire
>>>>>  BibLibre
>>>>>  06 52 42 51 29
>>>>>  108 avenue Breteuil 13006 Marseille
>>>>>  gaetan.boisson at biblibre.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/
>>>>> 
>>>> 
>>>>  ---
>>>>  Maritime heritage and history, preservation and conservation,
>>>>  research and education through the written word and the arts.
>>>>  <http://NavalMarineArchive.com> and 
> <http://UltraMarine.ca>
>>>> 
>>>>  _______________________________________________
>>>>  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/
>>> 
>>> 
>>>  --
>>>  Fridolin SOMERS
>>>  Biblibre - P?les support et syst?me
> 
>>>  fridolin.somers at biblibre.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/
>> 
> 
> -- 
> Fridolin SOMERS
> Biblibre - P?les support et syst?me
> fridolin.somers at biblibre.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/
>

From z.tajoli at cineca.it  Fri May 29 09:51:09 2015
From: z.tajoli at cineca.it (Tajoli Zeno)
Date: Fri, 29 May 2015 09:51:09 +0200
Subject: [Koha-devel] Sort by title. Based only on Title or also on
	Title-cover ?
Message-ID: <55681A6D.5040308@cineca.it>

Hi,

reading from 
etc/zebradb/marc_defs/marc21/biblios/biblio-koha-indexdefs.xml I see 
that from 245 $a are crerated two indexes:
Title and Title-cover:

<index_subfields tag="245" subfields="a">
      <target_index>Title-cover:w</target_index>
      <target_index>Title-cover:p</target_index>
      <target_index>Title-cover:s</target_index>
      <target_index>Title:w</target_index>
      <target_index>Title:p</target_index>
      <target_index>Title:s</target_index>
</index_subfields>

Sort by title (A-Z) and (Z-A) in opac are based only on 'Title' Zebra 
index or also on Title-cover ?
It is not clear for me.

Bye
Zeno Tajoli

From tomascohen at gmail.com  Fri May 29 14:30:10 2015
From: tomascohen at gmail.com (Tomas Cohen Arazi)
Date: Fri, 29 May 2015 09:30:10 -0300
Subject: [Koha-devel] Sort by title. Based only on Title or also on
 Title-cover ?
In-Reply-To: <55681A6D.5040308@cineca.it>
References: <55681A6D.5040308@cineca.it>
Message-ID: <CABZfb=U-i66F6O30r6qLeudmSG91iAvNFdc336CqyRF1v7TPYQ@mail.gmail.com>

It is sorting using the 'Title' index. Look at the URL in the OPAC, it
contains sort_by=title_az.

Then look for title_az on C4/Search.pm. You will notice it does:

    $sort_by .= "1=4 <i ";

and then if you look at bib1.att, you will see:

att 4    Title

So that's it.

Hope it helps.

2015-05-29 4:51 GMT-03:00 Tajoli Zeno <z.tajoli at cineca.it>:

> Hi,
>
> reading from
> etc/zebradb/marc_defs/marc21/biblios/biblio-koha-indexdefs.xml I see that
> from 245 $a are crerated two indexes:
> Title and Title-cover:
>
> <index_subfields tag="245" subfields="a">
>      <target_index>Title-cover:w</target_index>
>      <target_index>Title-cover:p</target_index>
>      <target_index>Title-cover:s</target_index>
>      <target_index>Title:w</target_index>
>      <target_index>Title:p</target_index>
>      <target_index>Title:s</target_index>
> </index_subfields>
>
> Sort by title (A-Z) and (Z-A) in opac are based only on 'Title' Zebra
> index or also on Title-cover ?
> It is not clear for me.
>
> Bye
> Zeno Tajoli
> _______________________________________________
> 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/
>



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

From hector.hecaxmmx at gmail.com  Sat May 30 06:02:46 2015
From: hector.hecaxmmx at gmail.com (Hector Castro)
Date: Fri, 29 May 2015 22:02:46 -0600
Subject: [Koha-devel] make test in new installation fails
Message-ID: <CAK1XDrRqGS2AJgSHKAR9DXYykuDvqVR==SUusEzrFa6pjqug0g@mail.gmail.com>

Hi Koha fellows

I was doing a new installation and "make test" FAIL me.
Launchs at the end of the test make: *** [test_dynamic] Error 255 and some
test give me this:
t/NorwegianPatronDB.t ............... strictures.pm extra testing active
but couldn't load all modules. Missing were:

  indirect multidimensional

Extra testing is auto-enabled in checkouts only, so if you're the author
of a strictures using module you need to run:

  cpan indirect multidimensional bareword::filehandles

Someone can tell me if i did something wrong or this is a bug?.

make install worked well.

Regards

-- 
Atte,

Hector Castro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20150529/17e0b055/attachment.html>

From mtompset at hotmail.com  Sat May 30 23:40:53 2015
From: mtompset at hotmail.com (Mark Tompsett)
Date: Sat, 30 May 2015 17:40:53 -0400
Subject: [Koha-devel] Installing from scratch... one more package hosted
	please?
Message-ID: <BLU172-DS21C194A3A997DFF693487AC6C80@phx.gbl>

Greetings,

Backstory:
I felt like trying a base git install from scratch, just to see what the time was like. I torrent downloaded a net install ISO of Debian 8 (Jessie), set it up in VirtualBox, git cloned the Koha source, bit-bz, and qa-test-tools, and ran the install process on the Koha source. I discovered that if you forget to give permissions on the DB, but create the user and password, that the failure of set NAMES ?utf8? is totally not indicative of the real problem. I think there?s a patch idea in there somewhere. Once the Koha was installed, I then attempted to get the qa test tools working. And that led me to installing dh-make-perl just to get libtest-perl-critic-progressive-perl_0.03-1_all.deb installed.

Inquiry:
Can we please host libtest-perl-critic-progressive-perl_0.03-1_all.deb and/or get it somehow pushed up to Debian?

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

From mtj at kohaaloha.com  Sun May 31 04:22:35 2015
From: mtj at kohaaloha.com (Mason James)
Date: Sun, 31 May 2015 14:22:35 +1200
Subject: [Koha-devel] Koha 3.16.11 released
Message-ID: <etPan.556a706c.61df4127.3a51@wasabi>

Hi Folks,?

The Koha release team are proud to announce the release of Koha 3.16.11.?

This is a bugfix/maintenance release?

As always, the best option is to upgrade using the debian packages, at?
debian.koha-community.org,?

Otherwise you can download the tarball at?download.koha-community.org?

Full release notes are here?
http://koha-community.org/koha-3-16-11-released/?


cheers, Mason?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20150531/93add985/attachment.html>