From psm_vu at india.com  Fri Jul  2 08:15:50 2010
From: psm_vu at india.com (Partha Mukhopadhyay)
Date: Fri, 2 Jul 2010 14:15:50 +0800
Subject: [Koha-devel] Graphics::Magick 1.3.5
Message-ID: <20100702061550.51A18CC18B@ws5-11.us4.outblaze.com>


Community-maintained open source software (universe) is enabled in my synaptic package manager.


> ----- Original Message -----
> From: "Michael Hafen" <mdhafen at tech.washk12.org>
> To: "Chris Cormack" <chris at bigballofwax.co.nz>
> Cc: "Partha Mukhopadhyay" <psm_vu at india.com>, koha-devel at lists.koha-community.org
> Subject: Re: [Koha-devel] Graphics::Magick 1.3.5
> Date: Wed, 30 Jun 2010 09:01:11 -0600
> 
> 
> This is in the Universe repository on Ubuntu (Lucid).  If the Universe
> repository isn't enabled you may not be able to install this package
> with it's dependencies through apt.
> 
> On Thu, 2010-07-01 at 01:44 +1200, Chris Cormack wrote:
> > 2010/7/1 Partha Mukhopadhyay <psm_vu at india.com>
> > >
> > > Dear Chris
> > >
> > > I downloaded the package and it goes on this way.........
> > >
> >
> > Why download it? why not simply
> > sudo apt-get install libgraphics-magick-perl
> >
> > What versiion of debian/ubuntu are you running?
> > Chris
> > _______________________________________________
> > Koha-devel mailing list
> > Koha-devel at lists.koha-community.org
> > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> 
> --
> Michael Hafen
> Systems Analyst and Programmer
> Washington County School District
> Utah, USA
> 
> for Koha checkout
> http://development.washk12.org/gitweb/
> or
> git://development.washk12.org/koha

>



Parthasarathi Mukhopadhyay
Department of Library and Information Science
University of Burdwan, Burdwan, West Bengal, India


-- 
_______________________________________________
Search for products and services at: 
http://search.mail.com

From tomascohen at gmail.com  Fri Jul  2 15:16:04 2010
From: tomascohen at gmail.com (Tomas Cohen Arazi)
Date: Fri, 2 Jul 2010 10:16:04 -0300
Subject: [Koha-devel] Graphics::Magick 1.3.5
In-Reply-To: <20100702061550.51A18CC18B@ws5-11.us4.outblaze.com>
References: <20100702061550.51A18CC18B@ws5-11.us4.outblaze.com>
Message-ID: <AANLkTik-kQDooLjT7Lkd2POs9pKLZ4BFLy0xJw3JM0FB@mail.gmail.com>

On Fri, Jul 2, 2010 at 3:15 AM, Partha Mukhopadhyay <psm_vu at india.com> wrote:
>
> Community-maintained open source software (universe) is enabled in my synaptic package manager.


Edit the file /etc/apt/sources.list and make sure you have (at least)
something like this:

deb http://archive.ubuntu.com/ubuntu/ lucid main universe multiverse
deb http://archive.ubuntu.com/ubuntu/ lucid-updates main universe multiverse
deb http://archive.ubuntu.com/ubuntu/ lucid-security main universe multiverse

To+

From tomascohen at gmail.com  Fri Jul  2 15:18:59 2010
From: tomascohen at gmail.com (Tomas Cohen Arazi)
Date: Fri, 2 Jul 2010 10:18:59 -0300
Subject: [Koha-devel] Graphics::Magick 1.3.5
In-Reply-To: <AANLkTik-kQDooLjT7Lkd2POs9pKLZ4BFLy0xJw3JM0FB@mail.gmail.com>
References: <20100702061550.51A18CC18B@ws5-11.us4.outblaze.com> 
	<AANLkTik-kQDooLjT7Lkd2POs9pKLZ4BFLy0xJw3JM0FB@mail.gmail.com>
Message-ID: <AANLkTinoArdJfxc4kizEqTr8RNXS0fkUvlPQptzYjli_@mail.gmail.com>

> On Fri, Jul 2, 2010 at 3:15 AM, Partha Mukhopadhyay <psm_vu at india.com> wrote:
>
> Community-maintained open source software (universe) is enabled in my synaptic package manager.

Those packages are available in universe since karmic (as far as I
know) so you *really* should copy the output of the command:

# lsb_release -a

in your next email.

To+

From paul.poulain at biblibre.com  Fri Jul  2 15:26:56 2010
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Fri, 02 Jul 2010 15:26:56 +0200
Subject: [Koha-devel] preferences.pl problems
Message-ID: <4C2DE920.8020607@biblibre.com>

Hi the list,

I have found (and it has not been reported yet AFAIK) that the YesNo
sysprefs are now store as 'yes' or 'no', no more as '1' or '0'
It means that the user checks "no", 'no' is stored in the syspref, and,
as most of the code contains
> if C4::Context->preference('syspref') { do something }

it's always evaluated as "true".

Is it a problem others have seen or is it me ?

-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08


From ohiocore at gmail.com  Fri Jul  2 15:58:29 2010
From: ohiocore at gmail.com (Joe Atzberger)
Date: Fri, 2 Jul 2010 09:58:29 -0400
Subject: [Koha-devel] preferences.pl problems
In-Reply-To: <4C2DE920.8020607@biblibre.com>
References: <4C2DE920.8020607@biblibre.com>
Message-ID: <AANLkTik0ial7RU6XY328naM8Uzpo-jefAGn0K5LZHZ7J@mail.gmail.com>

If so, this would be a catastrophically bad behavior.  Nothing could be
disabled once edited.

On Fri, Jul 2, 2010 at 9:26 AM, Paul Poulain <paul.poulain at biblibre.com>wrote:

> Hi the list,
>
> I have found (and it has not been reported yet AFAIK) that the YesNo
> sysprefs are now store as 'yes' or 'no', no more as '1' or '0'
> It means that the user checks "no", 'no' is stored in the syspref, and,
> as most of the code contains
> > if C4::Context->preference('syspref') { do something }
>
> it's always evaluated as "true".
>
> Is it a problem others have seen or is it me ?
>
> --
> Paul POULAIN
> http://www.biblibre.com
> Expert en Logiciels Libres pour l'info-doc
> Tel : (33) 4 91 81 35 08
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20100702/39bdb798/attachment.html>

From oleonard at myacpl.org  Fri Jul  2 16:18:23 2010
From: oleonard at myacpl.org (Owen Leonard)
Date: Fri, 2 Jul 2010 10:18:23 -0400
Subject: [Koha-devel] preferences.pl problems
In-Reply-To: <4C2DE920.8020607@biblibre.com>
References: <4C2DE920.8020607@biblibre.com>
Message-ID: <AANLkTimhCA041bS4tLsIXyqiAXEkHyVJR4cdtKbgZLtQ@mail.gmail.com>

On Fri, Jul 2, 2010 at 9:26 AM, Paul Poulain <paul.poulain at biblibre.com> wrote:
>
> I have found (and it has not been reported yet AFAIK) that the YesNo
> sysprefs are now store as 'yes' or 'no', no more as '1' or '0'

I my test system running HEAD I don't see any entries in my
systempreferences table where the value is "yes" or "no."

  -- Owen

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

From gmcharlt at gmail.com  Fri Jul  2 18:57:20 2010
From: gmcharlt at gmail.com (Galen Charlton)
Date: Fri, 2 Jul 2010 12:57:20 -0400
Subject: [Koha-devel] preferences.pl problems
In-Reply-To: <4C2DE920.8020607@biblibre.com>
References: <4C2DE920.8020607@biblibre.com>
Message-ID: <AANLkTimBKcvnfbm4cpN0XwmeidFDnjB8crixOji791g1@mail.gmail.com>

Hi,

On Fri, Jul 2, 2010 at 9:26 AM, Paul Poulain <paul.poulain at biblibre.com> wrote:
> I have found (and it has not been reported yet AFAIK) that the YesNo
> sysprefs are now store as 'yes' or 'no', no more as '1' or '0'
> It means that the user checks "no", 'no' is stored in the syspref, and,
> as most of the code contains
>> if C4::Context->preference('syspref') { do something }
>
> it's always evaluated as "true".
>
> Is it a problem others have seen or is it me ?

I have not seen this in HEAD.  More details, please.

Regards,

Galen
-- 
Galen Charlton
gmcharlt at gmail.com

From fridolyn.somers at gmail.com  Tue Jul  6 16:41:39 2010
From: fridolyn.somers at gmail.com (Fridolyn SOMERS)
Date: Tue, 6 Jul 2010 16:41:39 +0200
Subject: [Koha-devel] Koha-devel Digest, Vol 56, Issue 3
In-Reply-To: <mailman.3.1278151203.10339.koha-devel@lists.koha-community.org>
References: <mailman.3.1278151203.10339.koha-devel@lists.koha-community.org>
Message-ID: <AANLkTikLeaP-z0E_CqNeDDUorakVEH1-QvNy_DBpOXpQ@mail.gmail.com>

We have this problem only when using the translator.
It translates *.pref files replacing yes by "yes", no by "no".
I think that's why yes/no are stored in database instead of 1/0.

Actually whe use "en" version of module/admin/preferences.

------------------------------
>
> Message: 6
> Date: Fri, 2 Jul 2010 12:57:20 -0400
> From: Galen Charlton <gmcharlt at gmail.com>
> Subject: Re: [Koha-devel] preferences.pl problems
> To: Paul Poulain <paul.poulain at biblibre.com>
> Cc: "koha-devel at lists.koha-community.org"
>        <koha-devel at lists.koha-community.org>
> Message-ID:
>        <AANLkTimBKcvnfbm4cpN0XwmeidFDnjB8crixOji791g1 at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hi,
>
> On Fri, Jul 2, 2010 at 9:26 AM, Paul Poulain <paul.poulain at biblibre.com>
> wrote:
> > I have found (and it has not been reported yet AFAIK) that the YesNo
> > sysprefs are now store as 'yes' or 'no', no more as '1' or '0'
> > It means that the user checks "no", 'no' is stored in the syspref, and,
> > as most of the code contains
> >> if C4::Context->preference('syspref') { do something }
> >
> > it's always evaluated as "true".
> >
> > Is it a problem others have seen or is it me ?
>
> I have not seen this in HEAD.  More details, please.
>
> Regards,
>
> Galen
> --
> Galen Charlton
> gmcharlt at gmail.com
>
>
> ------------------------------
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>
> End of Koha-devel Digest, Vol 56, Issue 3
> *****************************************
>



-- 
Fridolyn SOMERS
Information and Communication Technologies engineer
fridolyn.somers at gmail.com
-------------- section suivante --------------
Une pi?ce jointe HTML a ?t? nettoy?e...
URL: </pipermail/koha-devel/attachments/20100706/10e05f55/attachment.htm>

From frederic at tamil.fr  Tue Jul  6 17:52:59 2010
From: frederic at tamil.fr (Frederic Demians)
Date: Tue, 06 Jul 2010 17:52:59 +0200
Subject: [Koha-devel] preferences.pl problems
In-Reply-To: <AANLkTimBKcvnfbm4cpN0XwmeidFDnjB8crixOji791g1@mail.gmail.com>
References: <4C2DE920.8020607@biblibre.com>
	<AANLkTimBKcvnfbm4cpN0XwmeidFDnjB8crixOji791g1@mail.gmail.com>
Message-ID: <4C33515B.3050709@tamil.fr>

I have some boolean sysprefs with yes/no strings in DB on some Koha 
installations, like Paul. But those are old instances that started with 
3.2alpha and prior versions. All those instances having been upgraded to 
HEAD, they  work properly now whatever is the interface language, French 
or English. With the French interface, if you switch on, respectively 
off, a boolean syspref, you get a 1 value, respectively 0, in the DB. I 
suppose that something were wrong during a while with the syspref 
translator.

--
Fr?d?ric

From psm_vu at india.com  Wed Jul  7 14:02:17 2010
From: psm_vu at india.com (Partha Mukhopadhyay)
Date: Wed, 7 Jul 2010 20:02:17 +0800
Subject: [Koha-devel] Graphics::Magick 1.3.5
Message-ID: <20100707120217.9FCB344B6C@ws5-1.us4.outblaze.com>

Dear all

The problem of installing Graphics::Magick 1.3.5 is over. Thanks to Tomas Cohen Arazi and Chris.
Those who are having trouble in installing the said perl module ( a prerequsite for Koha 3.2) the steps are as follows -

1. Update your sources.list (/etc/apt/sources.list) to include following lines at the end of the file;

 deb http://archive.ubuntu.com/ubuntu/ lucid main universe multiverse
 deb http://archive.ubuntu.com/ubuntu/ lucid-updates main universe multiverse
 deb http://archive.ubuntu.com/ubuntu/ lucid-security main universe multiverse

2. Save the file;

3. Come to $ prompt and give following command sudo apt-get update;

4. Now install Graphics::Magick 1.3.5 through issuing following command - 
           sudo apt-get install libgraphics-magick-perl

5.  Say Y to following -

The following extra packages will be installed:
  libgraphicsmagick3 libwmf0.2-7
Suggested packages:
  graphicsmagick-dbg libwmf0.2-7-gtk
The following NEW packages will be installed:
  libgraphics-magick-perl libgraphicsmagick3 libwmf0.2-7
0 upgraded, 3 newly installed, 0 to remove and 89 not upgraded.
Need to get 1,517kB of archives.
After this operation, 4,334kB of additional disk space will be used.
Do you want to continue [Y/n]? Y

Thats all.......


Dr. Parthasarathi Mukhopadhyay
Department of Library and Information Science
University of Burdwan, Burdwan, West Bengal, India


> ----- Original Message -----
> From: "Tomas Cohen Arazi" <tomascohen at gmail.com>
> To: "Partha Mukhopadhyay" <psm_vu at india.com>
> Cc: koha-devel at lists.koha-community.org
> Subject: Re: [Koha-devel] Graphics::Magick 1.3.5
> Date: Fri, 2 Jul 2010 10:16:04 -0300
> 
> 
> On Fri, Jul 2, 2010 at 3:15 AM, Partha Mukhopadhyay <psm_vu at india.com> wrote:
> >
> > Community-maintained open source software (universe) is enabled 
> > in my synaptic package manager.
> 
> 
> Edit the file /etc/apt/sources.list and make sure you have (at least)
> something like this:
> 
> deb http://archive.ubuntu.com/ubuntu/ lucid main universe multiverse
> deb http://archive.ubuntu.com/ubuntu/ lucid-updates main universe multiverse
> deb http://archive.ubuntu.com/ubuntu/ lucid-security main universe multiverse
> 
> To+

>




-- 
_______________________________________________
Search for products and services at: 
http://search.mail.com

From psm_vu at india.com  Wed Jul  7 14:31:54 2010
From: psm_vu at india.com (Partha Mukhopadhyay)
Date: Wed, 7 Jul 2010 20:31:54 +0800
Subject: [Koha-devel] PDF::API2::Simple
Message-ID: <20100707123154.63B4C7C437@ws5-10.us4.outblaze.com>


I tried CPAN to install PDF::API2::Simple (a prerequisite for Koha 3.2) and when failed tried to download and install manually. Every time it is reporting the same problem ----

--------------------------------------------------------------------------------------------------------------------------
psm at libra25:~/Desktop/koha_sw/PDF-API2-Simple-1.1.4$ perl Makefile.PL 
Can't locate inc/Module/Install.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.10.1 /usr/local/share/perl/5.10.1 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl .) at Makefile.PL line 1.
BEGIN failed--compilation aborted at Makefile.PL line 1.
---------------------------------------------------------------------------------------------------

I'm upgrading from Koha 3.06 to 3.2 on Ubuntu 10.04


Parthasarathi Mukhopadhyay
Department of Library and Information Science
University of Burdwan, Burdwan, West Bengal, India


-- 
_______________________________________________
Search for products and services at: 
http://search.mail.com

From colin.campbell at ptfs-europe.com  Wed Jul  7 14:49:51 2010
From: colin.campbell at ptfs-europe.com (Colin Campbell)
Date: Wed, 07 Jul 2010 13:49:51 +0100
Subject: [Koha-devel] PDF::API2::Simple
In-Reply-To: <20100707123154.63B4C7C437@ws5-10.us4.outblaze.com>
References: <20100707123154.63B4C7C437@ws5-10.us4.outblaze.com>
Message-ID: <4C3477EF.2020408@ptfs-europe.com>

On 07/07/10 13:31, Partha Mukhopadhyay wrote:
> 
> I tried CPAN to install PDF::API2::Simple (a prerequisite for Koha 3.2) and when failed tried to download and install manually. Every time it is reporting the same problem ----
> 
> --------------------------------------------------------------------------------------------------------------------------
> psm at libra25:~/Desktop/koha_sw/PDF-API2-Simple-1.1.4$ perl Makefile.PL 
> Can't locate inc/Module/Install.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.10.1 /usr/local/share/perl/5.10.1 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl .) at Makefile.PL line 1.
> BEGIN failed--compilation aborted at Makefile.PL line 1.
> ---------------------------------------------------------------------------------------------------

Install Module::Install from CPAN then install PDF::API2

Colin

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

http://www.ptfs-europe.com

From psm_vu at india.com  Wed Jul  7 15:22:03 2010
From: psm_vu at india.com (Partha Mukhopadhyay)
Date: Wed, 7 Jul 2010 21:22:03 +0800
Subject: [Koha-devel] PDF::API2::Simple
Message-ID: <20100707132203.CF6FDCC18B@ws5-11.us4.outblaze.com>

Dear Colin

Many thanks. It worked!!!

My question

   Is the line ( Can't locate inc/Module/Install.pm) in the output tell us to install Module::Install?

 Thanks and regards

Parthasarathi Mukhopadhyay
Department of Library and Information Science
University of Burdwan, Burdwan, West Bengal, India




> ----- Original Message -----
> From: "Colin Campbell" <colin.campbell at ptfs-europe.com>
> To: koha-devel at lists.koha-community.org
> Subject: Re: [Koha-devel] PDF::API2::Simple
> Date: Wed, 07 Jul 2010 13:49:51 +0100
> 
> 
> On 07/07/10 13:31, Partha Mukhopadhyay wrote:
> >
> > I tried CPAN to install PDF::API2::Simple (a prerequisite for 
> > Koha 3.2) and when failed tried to download and install manually. 
> > Every time it is reporting the same problem ----
> >
> > --------------------------------------------------------------------------------------------------------------------------
> > psm at libra25:~/Desktop/koha_sw/PDF-API2-Simple-1.1.4$ perl 
> > Makefile.PL Can't locate inc/Module/Install.pm in @INC (@INC 
> > contains: /etc/perl /usr/local/lib/perl/5.10.1 
> > /usr/local/share/perl/5.10.1 /usr/lib/perl5 /usr/share/perl5 
> > /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl 
> > .) at Makefile.PL line 1.
> > BEGIN failed--compilation aborted at Makefile.PL line 1.
> > ---------------------------------------------------------------------------------------------------
> 
> Install Module::Install from CPAN then install PDF::API2
> 
> Colin
> 
> --
> Colin Campbell
> Chief Software Engineer,
> PTFS Europe Limited
> Content Management and Library Solutions
> +44 (0) 208 366 1295 (phone)
> +44 (0) 7759 633626  (mobile)
> colin.campbell at ptfs-europe.com
> skype: colin_campbell2
> 
> http://www.ptfs-europe.com
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel

>






-- 
_______________________________________________
Search for products and services at: 
http://search.mail.com

From colin.campbell at ptfs-europe.com  Wed Jul  7 15:41:49 2010
From: colin.campbell at ptfs-europe.com (Colin Campbell)
Date: Wed, 07 Jul 2010 14:41:49 +0100
Subject: [Koha-devel] PDF::API2::Simple
In-Reply-To: <20100707132203.CF6FDCC18B@ws5-11.us4.outblaze.com>
References: <20100707132203.CF6FDCC18B@ws5-11.us4.outblaze.com>
Message-ID: <4C34841D.8080105@ptfs-europe.com>

On 07/07/10 14:22, Partha Mukhopadhyay wrote:
> Dear Colin
> 
> Many thanks. It worked!!!
> 
> My question
> 
>    Is the line ( Can't locate inc/Module/Install.pm) in the output tell us to install Module::Install?
Yes.
Strictly speaking it is saying I can't locate module_X in the
directories you've told me to search for modules in. (within perl you
can see that list in the @INC global variable) so you may see it if
you've done some thing to change your @INC or deleted the directory.
More commonly, in installing it means 'some thing has a use ModuleY;'
and I can't find module Y.

Cheers
Colin

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

http://www.ptfs-europe.com

From gmcharlt at gmail.com  Wed Jul  7 18:02:40 2010
From: gmcharlt at gmail.com (Galen Charlton)
Date: Wed, 7 Jul 2010 12:02:40 -0400
Subject: [Koha-devel] IRC meeting - today, 7 July 2010 at 19:00 UTC+0
Message-ID: <AANLkTikNeUwn96Ks7RlhnGORCVEa_GDhz5mcE_-P0HWZ@mail.gmail.com>

Hi,

Please pardon the tardy reminder.  The next general IRC meeting is
scheduled for 19:00 UTC+0, i.e., three hours from now.  Please connect
to #koha on irc.katipo.co.nz to participate, or use the following
Mibbit link:

http://widget.mibbit.com/?settings=1392bed8b563d8534da6aec9288199ef&server=irc.katipo.co.nz&channel=%23koha

The agenda for the meeting is at:

http://wiki.koha-community.org/wiki/General_IRC_Meeting,_7_July_2010

Currently, it stands as:

   1. Update on Roadmap to 3.2.
   2. Update on Roadmap to 3.0.
   3. Update on Roadmap to 3.4.
   4. Follow-up on actions from General IRC Meeting, 2 June 2010.
   5. Agree times of next meetings.

Regards,

Galen
-- 
Galen Charlton
gmcharlt at gmail.com

From lrea at nekls.org  Wed Jul  7 19:18:13 2010
From: lrea at nekls.org (Liz Rea)
Date: Wed, 7 Jul 2010 12:18:13 -0500
Subject: [Koha-devel] [Koha] Another terminology survey: Debarred,
	restricted, etc.
In-Reply-To: <AANLkTinNcJMcP2IuQSLYCBggzSuS-gIKYc_nHDXUx-GT@mail.gmail.com>
References: <AANLkTimnl6yX3R7gbQI8F4Kn_554Bjdzcli54LhfFG2A@mail.gmail.com> 
	<AANLkTim6u3H95EWjw866s_fK6XuhdmxXBniDXIpSucP1@mail.gmail.com> 
	<4C348B93.8010605@ptfs-europe.com>
	<AANLkTik4S7L_syt0zDYo7F2pA8gla3BdRRScHZ2CYpx2@mail.gmail.com> 
	<AANLkTiklXpDVqOntU41w72JQQUuFC8Zy49ZS8Pta87RK@mail.gmail.com> 
	<2910AFCF-9C45-456D-BA15-99FE78ADE9CC@esilibrary.com>
	<AANLkTikHXuQUFECZ_bqk5Tml9AtT3s17pRnPHcI90HtI@mail.gmail.com> 
	<AANLkTinNcJMcP2IuQSLYCBggzSuS-gIKYc_nHDXUx-GT@mail.gmail.com>
Message-ID: <AANLkTimF-5XrPvCorKKe6jg7ERIqOSz22p85VPeVUc3i@mail.gmail.com>

 Discussion with staff at NEKLS results in a

 +1 for "Suspended"

 Liz Rea
 NEKLS
>
> 2010/7/7 Kyle Hall <kyle.m.hall at gmail.com>:
>> Also a vote for 'suspended'.
>>
>> Kyle
>>
>> http://www.kylehall.info
>> Mill Run Technology Solutions ( http://millruntech.com )
>> Crawford County Federated Library System ( http://www.ccfls.org )
>> Meadville Public Library ( http://www.meadvillelibrary.org )
>>
>>
>>
>> On Wed, Jul 7, 2010 at 10:41 AM, Galen Charlton <gmc at esilibrary.com> wrote:
>>>
>>> Hi,
>>>
>>> On Jul 7, 2010, at 10:37 AM, Owen Leonard wrote:
>>> >> I agree with Colin here. Suspended would probably be more accurate.
>>> >
>>> > Okay, several votes for "suspended" already. I like this one too in
>>> > that it would work well in the staff client and OPAC both.
>>>
>>> +1 "suspended"
>>>
>>> Regards,
>>>
>>> Galen
>>> --
>>> Galen Charlton
>>> VP, Data Services
>>> Equinox Software, Inc. / Your Library's Guide to Open Source
>>> email: ?gmc at esilibrary.com
>>> direct: +1 352-215-7548
>>> skype: ?gmcharlt
>>> web: ? ?http://www.esilibrary.com/
>>>
>>> _______________________________________________
>>> Koha mailing list
>>> Koha at lists.katipo.co.nz
>>> http://lists.katipo.co.nz/mailman/listinfo/koha
>>
>>
>> _______________________________________________
>> Koha mailing list
>> Koha at lists.katipo.co.nz
>> http://lists.katipo.co.nz/mailman/listinfo/koha
>>
>>
>

From nengard at gmail.com  Thu Jul  8 00:32:17 2010
From: nengard at gmail.com (Nicole Engard)
Date: Wed, 7 Jul 2010 18:32:17 -0400
Subject: [Koha-devel] Opac Privacy
Message-ID: <AANLkTinLZ4_YU2mlnYxBGXh4DfaWSTF1O14XGlkdFIJv@mail.gmail.com>

Hi all,

I asked Chris how to handle this bug:
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3881 since
we're very close to release and he said up the severity - the only
thing above what it was set at is blocker - which means we have one
more blocker to address in some way before 3.2 is released.

Thanks
Nicole

From tajoli at cilea.it  Thu Jul  8 12:34:35 2010
From: tajoli at cilea.it (Zeno Tajoli)
Date: Thu, 08 Jul 2010 12:34:35 +0200
Subject: [Koha-devel] No more problem on marc21_field_007.tmpl
Message-ID: <20100708103436.B013946DF2@eliot.biblibre.com>

Hi to all

In the yesterday chat I said:

"Also marc21_field_007.tmpl has problem on translation"
http://stats.workbuffer.org/irclog/koha/2010-07-07#i_467995

a bug similar of http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4472

Today I retry to see the bug.

But after an update of OS [I'm now on Debian 5, I was on Debian 3] 
and git pull of branch 3.0.x
the bug ins not more present.

So I don't fill a bug in bugzilla.
I thnik the problem was in the OS.

Bye

Zeno Tajoli
CILEA - Segrate (MI)
tajoliAT_SPAM_no_prendiATcilea.it
(Indirizzo mascherato anti-spam; sostituisci quanto tra AT con @)


From M.de.Rooy at rijksmuseum.nl  Thu Jul  8 14:21:50 2010
From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy)
Date: Thu, 8 Jul 2010 12:21:50 +0000
Subject: [Koha-devel] QueryWeightFields in Koha 3.2
Message-ID: <32857065C79E3F4E8FDFBB0CAC6897F707392C@S-MAIL-1B.rijksmuseum.intra>

Hi all,

While testing Koha 3.01.00.142 (master in dev mode) with Zebra/MARC21, I notice that searching words without indexes all have 0 hits, when I have disabled QueryWeightFields.
Does anyone of you already know this bug?
I did not find a report in Bugzilla (only opposite behavior in Unimarc).

If I use an index in the search expression like kw=vermeer then the results are correct.

Note that Koha adds kw, wrdlist: to the search expression when I did not pass any index. The kw,wrdlist stuff apparently is passed to Zebra/YAZ and results in no hits.

Regards,

Marcel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20100708/c12d586d/attachment.htm>

From fridolyn.somers at gmail.com  Fri Jul  9 12:18:29 2010
From: fridolyn.somers at gmail.com (Fridolyn SOMERS)
Date: Fri, 9 Jul 2010 12:18:29 +0200
Subject: [Koha-devel] Biblionumber field auto fill
Message-ID: <AANLkTilPu_kdQxC2fbtOgjRoNK6IVRkERyNIoVR1YU_W@mail.gmail.com>

Hie,

I had a problem with a biblio framework where field corresponding to
biblionumber was visible (090$9) :
In this case, editing a record and saving it made a record with 2 fields
090.

It comes from the fact that this field is always added by
Biblio->TransformHtmlToMarc(), meaning it shouldn't be visible.
It does work when this field is hidden in framework.

I also noticed that this field is set again by
Biblio->_koha_marc_update_bib_ids().

Is it a bug ?

-- 
Fridolyn SOMERS
Information and Communication Technologies engineer
fridolyn.somers at gmail.com
-------------- section suivante --------------
Une pi?ce jointe HTML a ?t? nettoy?e...
URL: </pipermail/koha-devel/attachments/20100709/ff686cbc/attachment.htm>

From fridolyn.somers at gmail.com  Fri Jul  9 12:23:33 2010
From: fridolyn.somers at gmail.com (Fridolyn SOMERS)
Date: Fri, 9 Jul 2010 12:23:33 +0200
Subject: [Koha-devel] ISBN search
Message-ID: <AANLkTimmnqmeDnJyF1c1UDo2TbwDruly3p6SR9EMkGuR@mail.gmail.com>

Hie,

I noticed that when performing a search on ISBN index, search is made on any
index.
The query that appears on result page is "nb: test", but the query performed
by Zebra server is : "@attrset Bib-1 test".
It should be : "@attrset Bib-1 @att 1=7 test"

It comes from C4/Search.pm :
When index 'nb' detected, the flag $indexes_set is set to 1.
That means that index mus't be added to query.

Is is a normal behaviour ?

-- 
Fridolyn SOMERS
Information and Communication Technologies engineer
fridolyn.somers at gmail.com
-------------- section suivante --------------
Une pi?ce jointe HTML a ?t? nettoy?e...
URL: </pipermail/koha-devel/attachments/20100709/7c9deb77/attachment.htm>

From fridolyn.somers at gmail.com  Fri Jul  9 12:37:05 2010
From: fridolyn.somers at gmail.com (Fridolyn SOMERS)
Date: Fri, 9 Jul 2010 12:37:05 +0200
Subject: [Koha-devel] QueryWeightFields in Koha 3.2
Message-ID: <AANLkTimeoonuDOd8Y6auh4aAohHS1jJxNwe_0Whrzwjr@mail.gmail.com>

Hie,

Are you sure about "wrdlist", isn't it "wrdl" instead ?
Look for it in zebradb/ccl.properties.

Could you post the zebra server query : "@attrset Bib-1 @att ..." ?

Regards.

-- 
Fridolyn SOMERS
Information and Communication Technologies engineer
fridolyn.somers at gmail.com

Hi all,
>
> While testing Koha 3.01.00.142 (master in dev mode) with Zebra/MARC21, I
> notice that searching words without indexes all have 0 hits, when I have
> disabled QueryWeightFields.
> Does anyone of you already know this bug?
> I did not find a report in Bugzilla (only opposite behavior in Unimarc).
>
> If I use an index in the search expression like kw=vermeer then the results
> are correct.
>
> Note that Koha adds kw, wrdlist: to the search expression when I did not
> pass any index. The kw,wrdlist stuff apparently is passed to Zebra/YAZ and
> results in no hits.
>
> Regards,
>
> Marcel
-------------- section suivante --------------
Une pi?ce jointe HTML a ?t? nettoy?e...
URL: </pipermail/koha-devel/attachments/20100709/130b79bd/attachment.htm>

From cnighswonger at foundations.edu  Mon Jul 12 02:53:30 2010
From: cnighswonger at foundations.edu (Chris Nighswonger)
Date: Sun, 11 Jul 2010 20:53:30 -0400
Subject: [Koha-devel] Moving system preference serialization into the
	database
In-Reply-To: <AANLkTimzsY4hk6lZNWXIZLW8nOGhM_0VTdjgpR8KqvPD@mail.gmail.com>
References: <AANLkTimzsY4hk6lZNWXIZLW8nOGhM_0VTdjgpR8KqvPD@mail.gmail.com>
Message-ID: <AANLkTim-TboIBctnCt5jFXOZznepqgFOEUHfEWEdp9i8@mail.gmail.com>

While doing some beginning work on a local syspref editor to fit in
with the new system preference interface, I have run into the file
permission "problem" of writing to files inside Koha's template
directory structure. This is due to the fact that the system
preferences are serialized in yaml format and stored in *.pref files
within the template directory structure. While the problem of writing
to files is one which needs to be addressed, it is not one that we
have time to address before the 3.2 stable release.

As regards the system preference issue in particular, the problem may
be better resolved by moving the serialization into a table in the
database. As it stands presently, part of the system preference data
is kept in the database in the systempreferences table while the other
part is kept in the *.pref files. Moving the serialization into the
database will have the benefits of keeping the data in one location as
well as overcoming the file writing issues.

So, are there any serious objections to making this change?

Kind Regards,
Chris

From chrisc at catalyst.net.nz  Mon Jul 12 04:31:34 2010
From: chrisc at catalyst.net.nz (Chris Cormack)
Date: Mon, 12 Jul 2010 14:31:34 +1200
Subject: [Koha-devel] Moving system preference serialization into the
 database
In-Reply-To: <AANLkTim-TboIBctnCt5jFXOZznepqgFOEUHfEWEdp9i8@mail.gmail.com>
References: <AANLkTimzsY4hk6lZNWXIZLW8nOGhM_0VTdjgpR8KqvPD@mail.gmail.com>
	<AANLkTim-TboIBctnCt5jFXOZznepqgFOEUHfEWEdp9i8@mail.gmail.com>
Message-ID: <20100712023134.GI9685@rorohiko>

* Chris Nighswonger (cnighswonger at foundations.edu) wrote:
> While doing some beginning work on a local syspref editor to fit in
> with the new system preference interface, I have run into the file
> permission "problem" of writing to files inside Koha's template
> directory structure. This is due to the fact that the system
> preferences are serialized in yaml format and stored in *.pref files
> within the template directory structure. While the problem of writing
> to files is one which needs to be addressed, it is not one that we
> have time to address before the 3.2 stable release.
> 
> As regards the system preference issue in particular, the problem may
> be better resolved by moving the serialization into a table in the
> database. As it stands presently, part of the system preference data
> is kept in the database in the systempreferences table while the other
> part is kept in the *.pref files. Moving the serialization into the
> database will have the benefits of keeping the data in one location as
> well as overcoming the file writing issues.
> 
> So, are there any serious objections to making this change?
> 
Hi Chris

Assuming this leaves the system preferences translatable, as they are
now, then I have no objections.

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

From cnighswonger at foundations.edu  Mon Jul 12 04:46:04 2010
From: cnighswonger at foundations.edu (Chris Nighswonger)
Date: Sun, 11 Jul 2010 22:46:04 -0400
Subject: [Koha-devel] Moving system preference serialization into the
	database
In-Reply-To: <AANLkTim-TboIBctnCt5jFXOZznepqgFOEUHfEWEdp9i8@mail.gmail.com>
References: <AANLkTimzsY4hk6lZNWXIZLW8nOGhM_0VTdjgpR8KqvPD@mail.gmail.com> 
	<AANLkTim-TboIBctnCt5jFXOZznepqgFOEUHfEWEdp9i8@mail.gmail.com>
Message-ID: <AANLkTikkab9lWXuHROfnIBqfcFUQ7nKsDBR248zgmq2_@mail.gmail.com>

On Sun, Jul 11, 2010 at 8:53 PM, Chris Nighswonger
<cnighswonger at foundations.edu> wrote:
> While doing some beginning work on a local syspref editor to fit in
> with the new system preference interface

BTW, this piece of hackary can be seen here for anyone who's interested:

http://git.koha-community.org/gitweb/?p=wip/koha-fbc.git;a=shortlog;h=refs/heads/local_sysprefs

<standard-disclaimer>
    As this is a wip, it is subject to break your system badly or even
worse... you have been warned.
</standard-disclaimer>

From frederic at tamil.fr  Mon Jul 12 09:24:04 2010
From: frederic at tamil.fr (Frederic Demians)
Date: Mon, 12 Jul 2010 09:24:04 +0200
Subject: [Koha-devel] Moving system preference serialization into the
 database
In-Reply-To: <AANLkTim-TboIBctnCt5jFXOZznepqgFOEUHfEWEdp9i8@mail.gmail.com>
References: <AANLkTimzsY4hk6lZNWXIZLW8nOGhM_0VTdjgpR8KqvPD@mail.gmail.com>
	<AANLkTim-TboIBctnCt5jFXOZznepqgFOEUHfEWEdp9i8@mail.gmail.com>
Message-ID: <4C3AC314.9050308@tamil.fr>


> As regards the system preference issue in particular, the problem may
> be better resolved by moving the serialization into a table in the
> database. As it stands presently, part of the system preference data
> is kept in the database in the systempreferences table while the other
> part is kept in the *.pref files. Moving the serialization into the
> database will have the benefits of keeping the data in one location as
> well as overcoming the file writing issues.

Isn't it too late? To be translatable you need not to forget to 
serialize syspref templates per language, and then:

    * modify syspref editor to get YAML data from DB rather than from
      .pref files, per language
    * modify translation process (LangInstaller.pm) to extract text from
      DB and and write into DB

It would be very useful to have a complete API to manage sysprefs and 
allowing to add, modify, update sysprefs, integrated with updatabase.pl 
process.

Now when we add a new syspref, we have to:

   1. Add some text into a .pref file (history in git)
   2. Add an INSERT statement to syspref table into kohastructure.sql
   3. Modify various default values per language located in
      installer/data/mysql/<lang>/.../default-syspref.sql
   4. Update DB number kohaversion.pl and add in updatabase.pl an INSERT
      statement.

Any sysprefs modification should aim at simplification. There is room 
for simplification:

    * Clearly distinguish syspref values from a koha instance (stored in
      DB) and syspref templates (.pref file/db)
    * Put default values per language directly in .pref file (or DB but
      how will you track modifications by developers, we have git now)
    * Delete all perl language default values located in
      installer/data/mysql...
    * Delete deprecated fields in syspreferences table: options,
      explanation, type. And modify accordingly all .sql files.


-- 
Fr?d?ric DEMIANS

From M.de.Rooy at rijksmuseum.nl  Mon Jul 12 09:42:39 2010
From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy)
Date: Mon, 12 Jul 2010 07:42:39 +0000
Subject: [Koha-devel] ISBN search
In-Reply-To: <AANLkTimmnqmeDnJyF1c1UDo2TbwDruly3p6SR9EMkGuR@mail.gmail.com>
References: <AANLkTimmnqmeDnJyF1c1UDo2TbwDruly3p6SR9EMkGuR@mail.gmail.com>
Message-ID: <32857065C79E3F4E8FDFBB0CAC6897F70290D81C@S-MAIL-1A.rijksmuseum.intra>

Searching with nb: <isbn> works correctly.
Zebra log: 09:31:32-12/07 zebrasrv(8) [request] Search biblios OK 1 1 1+0 RPN @attrset Bib-1 @attr 1=7 9789080490468

Searching with ISBN in the search bar works too:
Log says: 09:33:18-12/07 zebrasrv(9) [request] Search biblios OK 1 1 1+0 RPN @attrset Bib-1 @attr 1=7 @attr 4=6 9789080490468

These results come from Koha 3.00.06.009

Van: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] Namens Fridolyn SOMERS
Verzonden: vrijdag 9 juli 2010 12:24
Aan: koha-devel at lists.koha-community.org
Onderwerp: [Koha-devel] ISBN search

Hie,

I noticed that when performing a search on ISBN index, search is made on any index.
The query that appears on result page is "nb: test", but the query performed by Zebra server is : "@attrset Bib-1 test".
It should be : "@attrset Bib-1 @att 1=7 test"

It comes from C4/Search.pm :
When index 'nb' detected, the flag $indexes_set is set to 1.
That means that index mus't be added to query.

Is is a normal behaviour ?

--
Fridolyn SOMERS
Information and Communication Technologies engineer
fridolyn.somers at gmail.com<mailto:fridolyn.somers at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20100712/d1ab3d03/attachment.htm>

From M.de.Rooy at rijksmuseum.nl  Mon Jul 12 09:55:00 2010
From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy)
Date: Mon, 12 Jul 2010 07:55:00 +0000
Subject: [Koha-devel] QueryWeightFields in Koha 3.2
In-Reply-To: <AANLkTimeoonuDOd8Y6auh4aAohHS1jJxNwe_0Whrzwjr@mail.gmail.com>
References: <AANLkTimeoonuDOd8Y6auh4aAohHS1jJxNwe_0Whrzwjr@mail.gmail.com>
Message-ID: <32857065C79E3F4E8FDFBB0CAC6897F70290D837@S-MAIL-1A.rijksmuseum.intra>

Yes, I meant wrdl. Sorry for the confusion..
Searching with yaz-client works fine.

Van: Fridolyn SOMERS [mailto:fridolyn.somers at gmail.com]
Verzonden: vrijdag 9 juli 2010 12:37
Aan: koha-devel at lists.koha-community.org
CC: Marcel de Rooy
Onderwerp: QueryWeightFields in Koha 3.2

Hie,

Are you sure about "wrdlist", isn't it "wrdl" instead ?
Look for it in zebradb/ccl.properties.

Could you post the zebra server query : "@attrset Bib-1 @att ..." ?

Regards.

--
Fridolyn SOMERS
Information and Communication Technologies engineer
fridolyn.somers at gmail.com<mailto:fridolyn.somers at gmail.com>
Hi all,

While testing Koha 3.01.00.142 (master in dev mode) with Zebra/MARC21, I notice that searching words without indexes all have 0 hits, when I have disabled QueryWeightFields.
Does anyone of you already know this bug?
I did not find a report in Bugzilla (only opposite behavior in Unimarc).

If I use an index in the search expression like kw=vermeer then the results are correct.

Note that Koha adds kw, wrdlist: to the search expression when I did not pass any index. The kw,wrdlist stuff apparently is passed to Zebra/YAZ and results in no hits.

Regards,

Marcel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20100712/b78f5acc/attachment-0001.htm>

From fridolyn.somers at gmail.com  Mon Jul 12 12:00:24 2010
From: fridolyn.somers at gmail.com (Fridolyn SOMERS)
Date: Mon, 12 Jul 2010 12:00:24 +0200
Subject: [Koha-devel] QueryWeightFields in Koha 3.2
In-Reply-To: <32857065C79E3F4E8FDFBB0CAC6897F70290D837@S-MAIL-1A.rijksmuseum.intra>
References: <AANLkTimeoonuDOd8Y6auh4aAohHS1jJxNwe_0Whrzwjr@mail.gmail.com> 
	<32857065C79E3F4E8FDFBB0CAC6897F70290D837@S-MAIL-1A.rijksmuseum.intra>
Message-ID: <AANLkTinOvBEY9zAvSVUfY8xpVoqA87hOrCJAhwtY5VHR@mail.gmail.com>

Could you post the zebra server query : "@attrset Bib-1 @att ..." ?

On Mon, Jul 12, 2010 at 9:55 AM, Marcel de Rooy <M.de.Rooy at rijksmuseum.nl>wrote:

>  Yes, I meant wrdl. Sorry for the confusion..
>
> Searching with yaz-client works fine.
>
>
>
> *Van:* Fridolyn SOMERS [mailto:fridolyn.somers at gmail.com]
> *Verzonden:* vrijdag 9 juli 2010 12:37
> *Aan:* koha-devel at lists.koha-community.org
> *CC:* Marcel de Rooy
> *Onderwerp:* QueryWeightFields in Koha 3.2
>
>
>
> Hie,
>
> Are you sure about "wrdlist", isn't it "wrdl" instead ?
> Look for it in zebradb/ccl.properties.
>
> Could you post the zebra server query : "@attrset Bib-1 @att ..." ?
>
> Regards.
>
> --
> Fridolyn SOMERS
> Information and Communication Technologies engineer
> fridolyn.somers at gmail.com
>
> Hi all,
>
> While testing Koha 3.01.00.142 (master in dev mode) with Zebra/MARC21, I
> notice that searching words without indexes all have 0 hits, when I have
> disabled QueryWeightFields.
> Does anyone of you already know this bug?
> I did not find a report in Bugzilla (only opposite behavior in Unimarc).
>
> If I use an index in the search expression like kw=vermeer then the results
> are correct.
>
> Note that Koha adds kw, wrdlist: to the search expression when I did not
> pass any index. The kw,wrdlist stuff apparently is passed to Zebra/YAZ and
> results in no hits.
>
> Regards,
>
> Marcel
>



-- 
Fridolyn SOMERS
Information and Communication Technologies engineer
+33(0)6.86.63.77.68
fridolyn.somers at gmail.com
-------------- section suivante --------------
Une pi?ce jointe HTML a ?t? nettoy?e...
URL: </pipermail/koha-devel/attachments/20100712/a2029a4d/attachment.htm>

From fridolyn.somers at gmail.com  Mon Jul 12 13:37:02 2010
From: fridolyn.somers at gmail.com (Fridolyn SOMERS)
Date: Mon, 12 Jul 2010 13:37:02 +0200
Subject: [Koha-devel] QueryWeightFields in Koha 3.2
In-Reply-To: <32857065C79E3F4E8FDFBB0CAC6897F70290D872@S-MAIL-1A.rijksmuseum.intra>
References: <AANLkTimeoonuDOd8Y6auh4aAohHS1jJxNwe_0Whrzwjr@mail.gmail.com> 
	<32857065C79E3F4E8FDFBB0CAC6897F70290D837@S-MAIL-1A.rijksmuseum.intra> 
	<AANLkTinOvBEY9zAvSVUfY8xpVoqA87hOrCJAhwtY5VHR@mail.gmail.com> 
	<32857065C79E3F4E8FDFBB0CAC6897F70290D872@S-MAIL-1A.rijksmuseum.intra>
Message-ID: <AANLkTilHUQXeyjvnJ2a9NsDNp7fJZRq_a6RSsYWREScg@mail.gmail.com>

Is "kw" present in ccl.properties ?
trie direct ccl by editing url  :

.../opac-search.pl?q=ccl=kw,wrld=rembrandt

Does it work ?

On Mon, Jul 12, 2010 at 12:13 PM, Marcel de Rooy
<M.de.Rooy at rijksmuseum.nl>wrote:

>  12:08:43-12/07 zebrasrv(38) [request] Search biblios OK 0 1 1+0 RPN
> @attrset Bib-1 @and @and kw wrdl: rembrandt
>
>
>
> *Van:* Fridolyn SOMERS [mailto:fridolyn.somers at gmail.com]
> *Verzonden:* maandag 12 juli 2010 12:00
> *Aan:* Marcel de Rooy
> *CC:* koha-devel at lists.koha-community.org
> *Onderwerp:* Re: QueryWeightFields in Koha 3.2
>
>
>
> Could you post the zebra server query : "@attrset Bib-1 @att ..." ?
>
> On Mon, Jul 12, 2010 at 9:55 AM, Marcel de Rooy <M.de.Rooy at rijksmuseum.nl>
> wrote:
>
> Yes, I meant wrdl. Sorry for the confusion..
>
> Searching with yaz-client works fine.
>
>
>
> *Van:* Fridolyn SOMERS [mailto:fridolyn.somers at gmail.com]
> *Verzonden:* vrijdag 9 juli 2010 12:37
> *Aan:* koha-devel at lists.koha-community.org
> *CC:* Marcel de Rooy
> *Onderwerp:* QueryWeightFields in Koha 3.2
>
>
>
> Hie,
>
> Are you sure about "wrdlist", isn't it "wrdl" instead ?
> Look for it in zebradb/ccl.properties.
>
> Could you post the zebra server query : "@attrset Bib-1 @att ..." ?
>
> Regards.
>
> --
> Fridolyn SOMERS
> Information and Communication Technologies engineer
> fridolyn.somers at gmail.com
>
> Hi all,
>
> While testing Koha 3.01.00.142 (master in dev mode) with Zebra/MARC21, I
> notice that searching words without indexes all have 0 hits, when I have
> disabled QueryWeightFields.
> Does anyone of you already know this bug?
> I did not find a report in Bugzilla (only opposite behavior in Unimarc).
>
> If I use an index in the search expression like kw=vermeer then the results
> are correct.
>
> Note that Koha adds kw, wrdlist: to the search expression when I did not
> pass any index. The kw,wrdlist stuff apparently is passed to Zebra/YAZ and
> results in no hits.
>
> Regards,
>
> Marcel
>
>
>
>
> --
> Fridolyn SOMERS
> Information and Communication Technologies engineer
> +33(0)6.86.63.77.68
> fridolyn.somers at gmail.com
>



-- 
Fridolyn SOMERS
Information and Communication Technologies engineer
+33(0)6.86.63.77.68
fridolyn.somers at gmail.com
-------------- section suivante --------------
Une pi?ce jointe HTML a ?t? nettoy?e...
URL: </pipermail/koha-devel/attachments/20100712/4d016049/attachment.htm>

From laurenthdl at alinto.com  Mon Jul 12 13:59:41 2010
From: laurenthdl at alinto.com (LAURENT Henri-Damien)
Date: Mon, 12 Jul 2010 13:59:41 +0200
Subject: [Koha-devel] QueryWeightFields in Koha 3.2
In-Reply-To: <32857065C79E3F4E8FDFBB0CAC6897F70290D837@S-MAIL-1A.rijksmuseum.intra>
References: <AANLkTimeoonuDOd8Y6auh4aAohHS1jJxNwe_0Whrzwjr@mail.gmail.com>
	<32857065C79E3F4E8FDFBB0CAC6897F70290D837@S-MAIL-1A.rijksmuseum.intra>
Message-ID: <4C3B03AD.2040502@alinto.com>

Hi,
as much as i can see that.
I think you are having the kind of troubles I describe there
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4074

That is, with the patch pushed as it stands to filter indexes in
C4/Search.pm
a) it misses to use all the indexes
b) it fail as soon as you donot provide any indexes and you have not set
all the Query*.

You could try and revert patch eb6b10f8c91cfd06fe4a5e981c1d28e31271bc56
and tell us if it helps.

Hopes that helps.
-- 
Henri-Damien LAURENT

Le 12/07/2010 09:55, Marcel de Rooy a ?crit :
> Yes, I meant wrdl. Sorry for the confusion..
> 
> Searching with yaz-client works fine.
> 
>  
> 
> *Van:* Fridolyn SOMERS [mailto:fridolyn.somers at gmail.com]
> *Verzonden:* vrijdag 9 juli 2010 12:37
> *Aan:* koha-devel at lists.koha-community.org
> *CC:* Marcel de Rooy
> *Onderwerp:* QueryWeightFields in Koha 3.2
> 
>  
> 
> Hie,
> 
> Are you sure about "wrdlist", isn't it "wrdl" instead ?
> Look for it in zebradb/ccl.properties.
> 
> Could you post the zebra server query : "@attrset Bib-1 @att ..." ?
> 
> Regards.
> 
> -- 
> Fridolyn SOMERS
> Information and Communication Technologies engineer
> fridolyn.somers at gmail.com <mailto:fridolyn.somers at gmail.com>
> 
> Hi all,
> 
> While testing Koha 3.01.00.142 (master in dev mode) with Zebra/MARC21, I
> notice that searching words without indexes all have 0 hits, when I have
> disabled QueryWeightFields.
> Does anyone of you already know this bug?
> I did not find a report in Bugzilla (only opposite behavior in Unimarc).
> 
> If I use an index in the search expression like kw=vermeer then the
> results are correct.
> 
> Note that Koha adds kw, wrdlist: to the search expression when I did not
> pass any index. The kw,wrdlist stuff apparently is passed to Zebra/YAZ
> and results in no hits.
> 
> Regards,
> 
> Marcel
> 
> 
> 
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel


From cnighswonger at foundations.edu  Mon Jul 12 15:51:31 2010
From: cnighswonger at foundations.edu (Chris Nighswonger)
Date: Mon, 12 Jul 2010 09:51:31 -0400
Subject: [Koha-devel] Moving system preference serialization into the
	database
In-Reply-To: <4C3AC314.9050308@tamil.fr>
References: <AANLkTimzsY4hk6lZNWXIZLW8nOGhM_0VTdjgpR8KqvPD@mail.gmail.com> 
	<AANLkTim-TboIBctnCt5jFXOZznepqgFOEUHfEWEdp9i8@mail.gmail.com> 
	<4C3AC314.9050308@tamil.fr>
Message-ID: <AANLkTilRyd2rwokEBxC2yhcsA8sEiuSu0RVQszpYdYZo@mail.gmail.com>

On Mon, Jul 12, 2010 at 3:24 AM, Frederic Demians <frederic at tamil.fr> wrote:
>
>> As regards the system preference issue in particular, the problem may
>> be better resolved by moving the serialization into a table in the
>> database. As it stands presently, part of the system preference data
>> is kept in the database in the systempreferences table while the other
>> part is kept in the *.pref files. Moving the serialization into the
>> database will have the benefits of keeping the data in one location as
>> well as overcoming the file writing issues.
>
> Isn't it too late?

I'll defer to Galen on that point.

To be translatable you need not to forget to serialize
> syspref templates per language, and then:
>
> ? * modify syspref editor to get YAML data from DB rather than from
> ? ? .pref files, per language
> ? * modify translation process (LangInstaller.pm) to extract text from
> ? ? DB and and write into DB

Actually, the present yaml would simply go into a *.sql file under
mandatory sysprefs. This would ensure their installation during the
initial run of the web installer.

As for translation: The current yaml files should be translated
already. This change would only necessitate a one-time move of those
files into the previously mentioned *.sql files and their appropriate
directories.

Translation into presently un-translated languages would then follow
the already established procedures for translating the mandatory, etc.
sql files.

>
> It would be very useful to have a complete API to manage sysprefs and
> allowing to add, modify, update sysprefs, integrated with updatabase.pl
> process.
>
> Now when we add a new syspref, we have to:
>
> ?1. Add some text into a .pref file (history in git)
> ?2. Add an INSERT statement to syspref table into kohastructure.sql
> ?3. Modify various default values per language located in
> ? ? installer/data/mysql/<lang>/.../default-syspref.sql
> ?4. Update DB number kohaversion.pl and add in updatabase.pl an INSERT
> ? ? statement.
>
> Any sysprefs modification should aim at simplification. There is room for
> simplification:
>
> ? * Clearly distinguish syspref values from a koha instance (stored in
> ? ? DB) and syspref templates (.pref file/db)
> ? * Put default values per language directly in .pref file (or DB but
> ? ? how will you track modifications by developers, we have git now)
> ? * Delete all perl language default values located in
> ? ? installer/data/mysql...
> ? * Delete deprecated fields in syspreferences table: options,
> ? ? explanation, type. And modify accordingly all .sql files.
>

This process is not aimed at fixing the syspref system for ease of use
by developers... sorry, there is definitely not time for that before
the 3.2 release. It is simply aimed at restoring a feature which is
present in 3.0.x which many users depend on, but is not presently in
3.2.x.

Having said that: this work could certainly form the basis of a
solution to those problems encountered by developers when adding
sysprefs to areas other than the 'local-use' tab.

Kind Regards,
Chris

From fridolyn.somers at gmail.com  Mon Jul 12 15:53:25 2010
From: fridolyn.somers at gmail.com (Fridolyn SOMERS)
Date: Mon, 12 Jul 2010 15:53:25 +0200
Subject: [Koha-devel] ISBN search
In-Reply-To: <32857065C79E3F4E8FDFBB0CAC6897F70290D81C@S-MAIL-1A.rijksmuseum.intra>
References: <AANLkTimmnqmeDnJyF1c1UDo2TbwDruly3p6SR9EMkGuR@mail.gmail.com> 
	<32857065C79E3F4E8FDFBB0CAC6897F70290D81C@S-MAIL-1A.rijksmuseum.intra>
Message-ID: <AANLkTikzXuRH6IrD-ILnpDsNY6RSwwNwupSLcxH8ueYE@mail.gmail.com>

Ok, thanks.

I known the problem now.

In tag *3.00.06*, in Search.pm, lines with "$indexes_set++" are in comment.
They are not in comment in revision *3.2 alpha 2* and neither in HEAD.

I can't find when is has been set in comment.

Still, I think it is a bug.

On Mon, Jul 12, 2010 at 9:42 AM, Marcel de Rooy <M.de.Rooy at rijksmuseum.nl>wrote:

>  Searching with nb: <isbn> works correctly.
>
> Zebra log: 09:31:32-12/07 zebrasrv(8) [request] Search biblios OK 1 1 1+0
> RPN @attrset Bib-1 @attr 1=7 9789080490468
>
>
>
> Searching with ISBN in the search bar works too:
>
> Log says: 09:33:18-12/07 zebrasrv(9) [request] Search biblios OK 1 1 1+0
> RPN @attrset Bib-1 @attr 1=7 @attr 4=6 9789080490468
>
>
>
> These results come from Koha 3.00.06.009
>
>
>
> *Van:* koha-devel-bounces at lists.koha-community.org [mailto:
> koha-devel-bounces at lists.koha-community.org] *Namens *Fridolyn SOMERS
> *Verzonden:* vrijdag 9 juli 2010 12:24
> *Aan:* koha-devel at lists.koha-community.org
> *Onderwerp:* [Koha-devel] ISBN search
>
>
>
> Hie,
>
> I noticed that when performing a search on ISBN index, search is made on
> any index.
> The query that appears on result page is "nb: test", but the query
> performed by Zebra server is : "@attrset Bib-1 test".
> It should be : "@attrset Bib-1 @att 1=7 test"
>
> It comes from C4/Search.pm :
> When index 'nb' detected, the flag $indexes_set is set to 1.
> That means that index mus't be added to query.
>
> Is is a normal behaviour ?
>
> --
> Fridolyn SOMERS
> Information and Communication Technologies engineer
> fridolyn.somers at gmail.com
>



-- 
Fridolyn SOMERS
Information and Communication Technologies engineer
+33(0)6.86.63.77.68
fridolyn.somers at gmail.com
-------------- section suivante --------------
Une pi?ce jointe HTML a ?t? nettoy?e...
URL: </pipermail/koha-devel/attachments/20100712/66e341fe/attachment-0001.htm>

From fridolyn.somers at gmail.com  Mon Jul 12 16:19:24 2010
From: fridolyn.somers at gmail.com (Fridolyn SOMERS)
Date: Mon, 12 Jul 2010 16:19:24 +0200
Subject: [Koha-devel] ISBN search
In-Reply-To: <AANLkTikzXuRH6IrD-ILnpDsNY6RSwwNwupSLcxH8ueYE@mail.gmail.com>
References: <AANLkTimmnqmeDnJyF1c1UDo2TbwDruly3p6SR9EMkGuR@mail.gmail.com> 
	<32857065C79E3F4E8FDFBB0CAC6897F70290D81C@S-MAIL-1A.rijksmuseum.intra> 
	<AANLkTikzXuRH6IrD-ILnpDsNY6RSwwNwupSLcxH8ueYE@mail.gmail.com>
Message-ID: <AANLkTimp22e6CwQLfo6OlIZhDyZygv0j3A2hlJWEAsQd@mail.gmail.com>

In tag 3.00.06, lines have been set to comment in commit :

http://git.koha.org/cgi-bin/gitweb.cgi?p=Koha;a=commit;h=8d29c78cbb2ed89057865528771e4683bc734201

But there are no explanations.

Is tag 3.00.06 on master ?

On Mon, Jul 12, 2010 at 3:53 PM, Fridolyn SOMERS
<fridolyn.somers at gmail.com>wrote:

> Ok, thanks.
>
> I known the problem now.
>
> In tag *3.00.06*, in Search.pm, lines with "$indexes_set++" are in
> comment.
> They are not in comment in revision *3.2 alpha 2* and neither in HEAD.
>
> I can't find when is has been set in comment.
>
> Still, I think it is a bug.
>
>
> On Mon, Jul 12, 2010 at 9:42 AM, Marcel de Rooy <M.de.Rooy at rijksmuseum.nl>wrote:
>
>>  Searching with nb: <isbn> works correctly.
>>
>> Zebra log: 09:31:32-12/07 zebrasrv(8) [request] Search biblios OK 1 1 1+0
>> RPN @attrset Bib-1 @attr 1=7 9789080490468
>>
>>
>>
>> Searching with ISBN in the search bar works too:
>>
>> Log says: 09:33:18-12/07 zebrasrv(9) [request] Search biblios OK 1 1 1+0
>> RPN @attrset Bib-1 @attr 1=7 @attr 4=6 9789080490468
>>
>>
>>
>> These results come from Koha 3.00.06.009
>>
>>
>>
>> *Van:* koha-devel-bounces at lists.koha-community.org [mailto:
>> koha-devel-bounces at lists.koha-community.org] *Namens *Fridolyn SOMERS
>> *Verzonden:* vrijdag 9 juli 2010 12:24
>> *Aan:* koha-devel at lists.koha-community.org
>> *Onderwerp:* [Koha-devel] ISBN search
>>
>>
>>
>> Hie,
>>
>> I noticed that when performing a search on ISBN index, search is made on
>> any index.
>> The query that appears on result page is "nb: test", but the query
>> performed by Zebra server is : "@attrset Bib-1 test".
>> It should be : "@attrset Bib-1 @att 1=7 test"
>>
>> It comes from C4/Search.pm :
>> When index 'nb' detected, the flag $indexes_set is set to 1.
>> That means that index mus't be added to query.
>>
>> Is is a normal behaviour ?
>>
>> --
>> Fridolyn SOMERS
>> Information and Communication Technologies engineer
>> fridolyn.somers at gmail.com
>>
>
>
>
> --
> Fridolyn SOMERS
> Information and Communication Technologies engineer
> +33(0)6.86.63.77.68
> fridolyn.somers at gmail.com
>



-- 
Fridolyn SOMERS
Information and Communication Technologies engineer
+33(0)6.86.63.77.68
fridolyn.somers at gmail.com
-------------- section suivante --------------
Une pi?ce jointe HTML a ?t? nettoy?e...
URL: </pipermail/koha-devel/attachments/20100712/ee1570ef/attachment.htm>

From fridolyn.somers at gmail.com  Mon Jul 12 16:44:58 2010
From: fridolyn.somers at gmail.com (Fridolyn SOMERS)
Date: Mon, 12 Jul 2010 16:44:58 +0200
Subject: [Koha-devel] ISBN search
In-Reply-To: <AANLkTimp22e6CwQLfo6OlIZhDyZygv0j3A2hlJWEAsQd@mail.gmail.com>
References: <AANLkTimmnqmeDnJyF1c1UDo2TbwDruly3p6SR9EMkGuR@mail.gmail.com> 
	<32857065C79E3F4E8FDFBB0CAC6897F70290D81C@S-MAIL-1A.rijksmuseum.intra> 
	<AANLkTikzXuRH6IrD-ILnpDsNY6RSwwNwupSLcxH8ueYE@mail.gmail.com> 
	<AANLkTimp22e6CwQLfo6OlIZhDyZygv0j3A2hlJWEAsQd@mail.gmail.com>
Message-ID: <AANLkTimsuhINGT9wgJk-UTV9hcop-DayIiYYPf7Kw5-0@mail.gmail.com>

3.00.6 is on 3.0.X branch.

On Mon, Jul 12, 2010 at 4:19 PM, Fridolyn SOMERS
<fridolyn.somers at gmail.com>wrote:

> In tag 3.00.06, lines have been set to comment in commit :
>
>
> http://git.koha.org/cgi-bin/gitweb.cgi?p=Koha;a=commit;h=8d29c78cbb2ed89057865528771e4683bc734201
>
> But there are no explanations.
>
> Is tag 3.00.06 on master ?
>
>
> On Mon, Jul 12, 2010 at 3:53 PM, Fridolyn SOMERS <
> fridolyn.somers at gmail.com> wrote:
>
>> Ok, thanks.
>>
>> I known the problem now.
>>
>> In tag *3.00.06*, in Search.pm, lines with "$indexes_set++" are in
>> comment.
>> They are not in comment in revision *3.2 alpha 2* and neither in HEAD.
>>
>> I can't find when is has been set in comment.
>>
>> Still, I think it is a bug.
>>
>>
>> On Mon, Jul 12, 2010 at 9:42 AM, Marcel de Rooy <M.de.Rooy at rijksmuseum.nl
>> > wrote:
>>
>>>  Searching with nb: <isbn> works correctly.
>>>
>>> Zebra log: 09:31:32-12/07 zebrasrv(8) [request] Search biblios OK 1 1 1+0
>>> RPN @attrset Bib-1 @attr 1=7 9789080490468
>>>
>>>
>>>
>>> Searching with ISBN in the search bar works too:
>>>
>>> Log says: 09:33:18-12/07 zebrasrv(9) [request] Search biblios OK 1 1 1+0
>>> RPN @attrset Bib-1 @attr 1=7 @attr 4=6 9789080490468
>>>
>>>
>>>
>>> These results come from Koha 3.00.06.009
>>>
>>>
>>>
>>> *Van:* koha-devel-bounces at lists.koha-community.org [mailto:
>>> koha-devel-bounces at lists.koha-community.org] *Namens *Fridolyn SOMERS
>>> *Verzonden:* vrijdag 9 juli 2010 12:24
>>> *Aan:* koha-devel at lists.koha-community.org
>>> *Onderwerp:* [Koha-devel] ISBN search
>>>
>>>
>>>
>>> Hie,
>>>
>>> I noticed that when performing a search on ISBN index, search is made on
>>> any index.
>>> The query that appears on result page is "nb: test", but the query
>>> performed by Zebra server is : "@attrset Bib-1 test".
>>> It should be : "@attrset Bib-1 @att 1=7 test"
>>>
>>> It comes from C4/Search.pm :
>>> When index 'nb' detected, the flag $indexes_set is set to 1.
>>> That means that index mus't be added to query.
>>>
>>> Is is a normal behaviour ?
>>>
>>> --
>>> Fridolyn SOMERS
>>> Information and Communication Technologies engineer
>>> fridolyn.somers at gmail.com
>>>
>>
>>
>>
>> --
>> Fridolyn SOMERS
>> Information and Communication Technologies engineer
>> +33(0)6.86.63.77.68
>> fridolyn.somers at gmail.com
>>
>
>
>
> --
> Fridolyn SOMERS
> Information and Communication Technologies engineer
> +33(0)6.86.63.77.68
> fridolyn.somers at gmail.com
>



-- 
Fridolyn SOMERS
Information and Communication Technologies engineer
+33(0)6.86.63.77.68
fridolyn.somers at gmail.com
-------------- section suivante --------------
Une pi?ce jointe HTML a ?t? nettoy?e...
URL: </pipermail/koha-devel/attachments/20100712/1adbf21c/attachment.htm>

From pianohacker at gmail.com  Mon Jul 12 19:10:59 2010
From: pianohacker at gmail.com (Jesse)
Date: Mon, 12 Jul 2010 11:10:59 -0600
Subject: [Koha-devel] Moving system preference serialization into the
	database
In-Reply-To: <AANLkTilRyd2rwokEBxC2yhcsA8sEiuSu0RVQszpYdYZo@mail.gmail.com>
References: <AANLkTimzsY4hk6lZNWXIZLW8nOGhM_0VTdjgpR8KqvPD@mail.gmail.com>
	<AANLkTim-TboIBctnCt5jFXOZznepqgFOEUHfEWEdp9i8@mail.gmail.com>
	<4C3AC314.9050308@tamil.fr>
	<AANLkTilRyd2rwokEBxC2yhcsA8sEiuSu0RVQszpYdYZo@mail.gmail.com>
Message-ID: <AANLkTikWn7YTZ64Caai65s9ln248MxT3zjdw-M31YpfW@mail.gmail.com>

2010/7/12 Chris Nighswonger <cnighswonger at foundations.edu>

> On Mon, Jul 12, 2010 at 3:24 AM, Frederic Demians <frederic at tamil.fr>
> wrote:
> >
> >> As regards the system preference issue in particular, the problem may
> >> be better resolved by moving the serialization into a table in the
> >> database. As it stands presently, part of the system preference data
> >> is kept in the database in the systempreferences table while the other
> >> part is kept in the *.pref files. Moving the serialization into the
> >> database will have the benefits of keeping the data in one location as
> >> well as overcoming the file writing issues.
> >
> > Isn't it too late?
>
> I'll defer to Galen on that point.
>
> To be translatable you need not to forget to serialize
> > syspref templates per language, and then:
> >
> >   * modify syspref editor to get YAML data from DB rather than from
> >     .pref files, per language
> >   * modify translation process (LangInstaller.pm) to extract text from
> >     DB and and write into DB
>
> Actually, the present yaml would simply go into a *.sql file under
> mandatory sysprefs. This would ensure their installation during the
> initial run of the web installer.
>
> As for translation: The current yaml files should be translated
> already. This change would only necessitate a one-time move of those
> files into the previously mentioned *.sql files and their appropriate
> directories.
>
> Translation into presently un-translated languages would then follow
> the already established procedures for translating the mandatory, etc.
> sql files.
>
> >
> > It would be very useful to have a complete API to manage sysprefs and
> > allowing to add, modify, update sysprefs, integrated with updatabase.pl
> > process.
> >
> > Now when we add a new syspref, we have to:
> >
> >  1. Add some text into a .pref file (history in git)
> >  2. Add an INSERT statement to syspref table into kohastructure.sql
> >  3. Modify various default values per language located in
> >     installer/data/mysql/<lang>/.../default-syspref.sql
> >  4. Update DB number kohaversion.pl and add in updatabase.pl an INSERT
> >     statement.
> >
> > Any sysprefs modification should aim at simplification. There is room for
> > simplification:
> >
> >   * Clearly distinguish syspref values from a koha instance (stored in
> >     DB) and syspref templates (.pref file/db)
> >   * Put default values per language directly in .pref file (or DB but
> >     how will you track modifications by developers, we have git now)
> >   * Delete all perl language default values located in
> >     installer/data/mysql...
> >   * Delete deprecated fields in syspreferences table: options,
> >     explanation, type. And modify accordingly all .sql files.
> >
>
> This process is not aimed at fixing the syspref system for ease of use
> by developers... sorry, there is definitely not time for that before
> the 3.2 release. It is simply aimed at restoring a feature which is
> present in 3.0.x which many users depend on, but is not presently in
> 3.2.x.
>
> Having said that: this work could certainly form the basis of a
> solution to those problems encountered by developers when adding
> sysprefs to areas other than the 'local-use' tab.
>
> Kind Regards,
> Chris
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>

There were two important reasons for moving the system preference
descriptions out of the database.

The first was translation. Translating strings in the SQL files is
significantly different than the rest of the translator's workflow (from
what I can tell), and requires several skills that Pootle does not. The
easiest way to tell this is to look at how many languages have translated
interfaces, and how few have translated system preferences. Besides the main
targets, en-US and fr-FR, there are only four others that had a translated
sysprefs.sql, thanks to the work of Katrin and others. Not many are going to
waltz into the Koha project with both good translation skills and enough
bravery to translate the SQL. Localizing system preference defaults
per-language makes sense, definitely. With the current file-based system,
this is separated from translation, and is a much less daunting task than
having to translate and localize an SQL file at the same time.

Aside from that issue, keeping the two separate was also a very intentional
separation of concerns. Aside from the previously-mentioned translation
problems, putting interface-related strings in the database is bad practice,
IMO. Any practical concerns are important, but I think the current system
has this on its side. Today's nitpicky theoretical problems are tomorrow's
intractable real-life bugs (fines system, anyone?).

Under the old system, fixing any issues with the system preference display
required a database update, no matter how trivial they were. This made
little to no sense, considering that these were entirely interface issues.
Again, you could create a system to keep the data files and DB in sync
without this, but this would be at best confusing and at worse fragile.

Leaving the files where they are makes it clearer that they are intended to
be interface-related data, like the XSLT, and translated as such.

My vote for solving the local-use preferences system is to leave the current
system as it is, but add a database column or some way of easily
distinguishing local-use from non-local-use prefs in the DB (making the
explanation column NULL for non-local-use would work, though would require a
time-consuming database update). This would make building a local-use tab
fairly easy.

Once we do that, we can drop the options column entirely, as I doubt most
local-use users will care enough to set it. Theoretically, we could even
drop the type column, though that might be useful in the future to help deal
with more complex types of system preferences (automatically turning date
sysprefs into C4::Dates objects, for example).

Wow, that turned out longer than expected. Anyway, hope I made sense.

Sincerely,
-- 
Jesse Weaver
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20100712/e6f9e3a4/attachment-0001.htm>

From Katrin.Fischer at bsz-bw.de  Mon Jul 12 19:52:58 2010
From: Katrin.Fischer at bsz-bw.de (Fischer, Katrin)
Date: Mon, 12 Jul 2010 19:52:58 +0200
Subject: [Koha-devel] Moving system preference serialization into
	thedatabase
References: <AANLkTimzsY4hk6lZNWXIZLW8nOGhM_0VTdjgpR8KqvPD@mail.gmail.com><AANLkTim-TboIBctnCt5jFXOZznepqgFOEUHfEWEdp9i8@mail.gmail.com><4C3AC314.9050308@tamil.fr><AANLkTilRyd2rwokEBxC2yhcsA8sEiuSu0RVQszpYdYZo@mail.gmail.com>
	<AANLkTikWn7YTZ64Caai65s9ln248MxT3zjdw-M31YpfW@mail.gmail.com>
Message-ID: <028B1A54D03E7B4482CDCA4EC8F06BFD042B5F@Bodensee.bsz-bw.de>

Jesse++

Translation of SQL files is a bigger project and too difficult for most people starting with Koha.

The current system of translating SQL files is error-prone and should be replaced by better methods. It's too easy to forget one file when adding new permissions or system preferences. Changes to the table structure get not reflected in sample files etc.

In my opionion the current system for translation of system preferences is a great improvement.

Katrin


-----Original Message-----
From: koha-devel-bounces at lists.koha-community.org on behalf of Jesse
Sent: Mon 12.07.2010 19:10
To: Chris Nighswonger
Cc: koha-devel at lists.koha-community.org
Subject: Re: [Koha-devel] Moving system preference serialization into thedatabase
 
2010/7/12 Chris Nighswonger <cnighswonger at foundations.edu>

> On Mon, Jul 12, 2010 at 3:24 AM, Frederic Demians <frederic at tamil.fr>
> wrote:
> >
> >> As regards the system preference issue in particular, the problem may
> >> be better resolved by moving the serialization into a table in the
> >> database. As it stands presently, part of the system preference data
> >> is kept in the database in the systempreferences table while the other
> >> part is kept in the *.pref files. Moving the serialization into the
> >> database will have the benefits of keeping the data in one location as
> >> well as overcoming the file writing issues.
> >
> > Isn't it too late?
>
> I'll defer to Galen on that point.
>
> To be translatable you need not to forget to serialize
> > syspref templates per language, and then:
> >
> >   * modify syspref editor to get YAML data from DB rather than from
> >     .pref files, per language
> >   * modify translation process (LangInstaller.pm) to extract text from
> >     DB and and write into DB
>
> Actually, the present yaml would simply go into a *.sql file under
> mandatory sysprefs. This would ensure their installation during the
> initial run of the web installer.
>
> As for translation: The current yaml files should be translated
> already. This change would only necessitate a one-time move of those
> files into the previously mentioned *.sql files and their appropriate
> directories.
>
> Translation into presently un-translated languages would then follow
> the already established procedures for translating the mandatory, etc.
> sql files.
>
> >
> > It would be very useful to have a complete API to manage sysprefs and
> > allowing to add, modify, update sysprefs, integrated with updatabase.pl
> > process.
> >
> > Now when we add a new syspref, we have to:
> >
> >  1. Add some text into a .pref file (history in git)
> >  2. Add an INSERT statement to syspref table into kohastructure.sql
> >  3. Modify various default values per language located in
> >     installer/data/mysql/<lang>/.../default-syspref.sql
> >  4. Update DB number kohaversion.pl and add in updatabase.pl an INSERT
> >     statement.
> >
> > Any sysprefs modification should aim at simplification. There is room for
> > simplification:
> >
> >   * Clearly distinguish syspref values from a koha instance (stored in
> >     DB) and syspref templates (.pref file/db)
> >   * Put default values per language directly in .pref file (or DB but
> >     how will you track modifications by developers, we have git now)
> >   * Delete all perl language default values located in
> >     installer/data/mysql...
> >   * Delete deprecated fields in syspreferences table: options,
> >     explanation, type. And modify accordingly all .sql files.
> >
>
> This process is not aimed at fixing the syspref system for ease of use
> by developers... sorry, there is definitely not time for that before
> the 3.2 release. It is simply aimed at restoring a feature which is
> present in 3.0.x which many users depend on, but is not presently in
> 3.2.x.
>
> Having said that: this work could certainly form the basis of a
> solution to those problems encountered by developers when adding
> sysprefs to areas other than the 'local-use' tab.
>
> Kind Regards,
> Chris
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>

There were two important reasons for moving the system preference
descriptions out of the database.

The first was translation. Translating strings in the SQL files is
significantly different than the rest of the translator's workflow (from
what I can tell), and requires several skills that Pootle does not. The
easiest way to tell this is to look at how many languages have translated
interfaces, and how few have translated system preferences. Besides the main
targets, en-US and fr-FR, there are only four others that had a translated
sysprefs.sql, thanks to the work of Katrin and others. Not many are going to
waltz into the Koha project with both good translation skills and enough
bravery to translate the SQL. Localizing system preference defaults
per-language makes sense, definitely. With the current file-based system,
this is separated from translation, and is a much less daunting task than
having to translate and localize an SQL file at the same time.

Aside from that issue, keeping the two separate was also a very intentional
separation of concerns. Aside from the previously-mentioned translation
problems, putting interface-related strings in the database is bad practice,
IMO. Any practical concerns are important, but I think the current system
has this on its side. Today's nitpicky theoretical problems are tomorrow's
intractable real-life bugs (fines system, anyone?).

Under the old system, fixing any issues with the system preference display
required a database update, no matter how trivial they were. This made
little to no sense, considering that these were entirely interface issues.
Again, you could create a system to keep the data files and DB in sync
without this, but this would be at best confusing and at worse fragile.

Leaving the files where they are makes it clearer that they are intended to
be interface-related data, like the XSLT, and translated as such.

My vote for solving the local-use preferences system is to leave the current
system as it is, but add a database column or some way of easily
distinguishing local-use from non-local-use prefs in the DB (making the
explanation column NULL for non-local-use would work, though would require a
time-consuming database update). This would make building a local-use tab
fairly easy.

Once we do that, we can drop the options column entirely, as I doubt most
local-use users will care enough to set it. Theoretically, we could even
drop the type column, though that might be useful in the future to help deal
with more complex types of system preferences (automatically turning date
sysprefs into C4::Dates objects, for example).

Wow, that turned out longer than expected. Anyway, hope I made sense.

Sincerely,
-- 
Jesse Weaver

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20100712/971c7f21/attachment.htm>

From frederic at tamil.fr  Mon Jul 12 20:07:40 2010
From: frederic at tamil.fr (Frederic Demians)
Date: Mon, 12 Jul 2010 20:07:40 +0200
Subject: [Koha-devel] Moving system preference serialization into the
 database
In-Reply-To: <AANLkTikWn7YTZ64Caai65s9ln248MxT3zjdw-M31YpfW@mail.gmail.com>
References: <AANLkTimzsY4hk6lZNWXIZLW8nOGhM_0VTdjgpR8KqvPD@mail.gmail.com>	<AANLkTim-TboIBctnCt5jFXOZznepqgFOEUHfEWEdp9i8@mail.gmail.com>	<4C3AC314.9050308@tamil.fr>	<AANLkTilRyd2rwokEBxC2yhcsA8sEiuSu0RVQszpYdYZo@mail.gmail.com>
	<AANLkTikWn7YTZ64Caai65s9ln248MxT3zjdw-M31YpfW@mail.gmail.com>
Message-ID: <4C3B59EC.2060908@tamil.fr>


> Leaving the files where they are makes it clearer that they are 
> intended to be interface-related data, like the XSLT, and translated 
> as such.

Yes, even if it's not so simple, for XSL files and for .pref files, 
because they were designed at first with no specific consideration for 
localization. See various bugs related to this.

> My vote for solving the local-use preferences system is to leave the 
> current system as it is, but add a database column or some way of 
> easily distinguishing local-use from non-local-use prefs in the DB 
> (making the explanation column NULL for non-local-use would work, 
> though would require a time-consuming database update). This would 
> make building a local-use tab fairly easy.

As I understand it, the main issue is with blocker bug 3756. It could be 
solved without adding a new syspref table column. You get from all the 
.pref files a list of 'official' sysprefs and you compare it to defined 
sysprefs in DB: the difference are the local sysprefs.

--
Fr?d?ric



From cnighswonger at foundations.edu  Mon Jul 12 20:16:16 2010
From: cnighswonger at foundations.edu (Chris Nighswonger)
Date: Mon, 12 Jul 2010 14:16:16 -0400
Subject: [Koha-devel] Moving system preference serialization into the
	database
In-Reply-To: <AANLkTikWn7YTZ64Caai65s9ln248MxT3zjdw-M31YpfW@mail.gmail.com>
References: <AANLkTimzsY4hk6lZNWXIZLW8nOGhM_0VTdjgpR8KqvPD@mail.gmail.com> 
	<AANLkTim-TboIBctnCt5jFXOZznepqgFOEUHfEWEdp9i8@mail.gmail.com> 
	<4C3AC314.9050308@tamil.fr>
	<AANLkTilRyd2rwokEBxC2yhcsA8sEiuSu0RVQszpYdYZo@mail.gmail.com> 
	<AANLkTikWn7YTZ64Caai65s9ln248MxT3zjdw-M31YpfW@mail.gmail.com>
Message-ID: <AANLkTikTomtDdx1QiN6_ckjv738AWZIG71MX271Rd8J-@mail.gmail.com>

On Mon, Jul 12, 2010 at 1:10 PM, Jesse <pianohacker at gmail.com> wrote:
>
>
> There were two important reasons for moving the system preference
> descriptions out of the database.
>
> The first was translation. Translating strings in the SQL files is
> significantly different than the rest of the translator's workflow (from
> what I can tell), and requires several skills that Pootle does not. The
> easiest way to tell this is to look at how many languages have translated
> interfaces, and how few have translated system preferences. Besides the main
> targets, en-US and fr-FR, there are only four others that had a translated
> sysprefs.sql, thanks to the work of Katrin and others. Not many are going to
> waltz into the Koha project with both good translation skills and enough
> bravery to translate the SQL. Localizing system preference defaults
> per-language makes sense, definitely. With the current file-based system,
> this is separated from translation, and is a much less daunting task than
> having to translate and localize an SQL file at the same time.
>

Based on this and Katrin's subsequent reply, I certainly will not
argue this point.

> Aside from that issue, keeping the two separate was also a very intentional
> separation of concerns. Aside from the previously-mentioned translation
> problems, putting interface-related strings in the database is bad practice,
> IMO. Any practical concerns are important, but I think the current system
> has this on its side. Today's nitpicky theoretical problems are tomorrow's
> intractable real-life bugs (fines system, anyone?).
>
> Under the old system, fixing any issues with the system preference display
> required a database update, no matter how trivial they were. This made
> little to no sense, considering that these were entirely interface issues.
> Again, you could create a system to keep the data files and DB in sync
> without this, but this would be at best confusing and at worse fragile.
>
> Leaving the files where they are makes it clearer that they are intended to
> be interface-related data, like the XSLT, and translated as such.
>

I am not utterly opposed to leaving the system as it is if that is the
prevailing opinion. As for the fix for the current and future problem
however....

> My vote for solving the local-use preferences system is to leave the current
> system as it is, but add a database column or some way of easily
> distinguishing local-use from non-local-use prefs in the DB (making the
> explanation column NULL for non-local-use would work, though would require a
> time-consuming database update). This would make building a local-use tab
> fairly easy.
>
> Once we do that, we can drop the options column entirely, as I doubt most
> local-use users will care enough to set it. Theoretically, we could even
> drop the type column, though that might be useful in the future to help deal
> with more complex types of system preferences (automatically turning date
> sysprefs into C4::Dates objects, for example).
>

Unless no code depends on the type column, I think we should leave it
alone for the moment. In the long haul, the table could certainly be
cleaned up.

The singular problem with local-use sysprefs in the system as it
presently stands is the matter of setting the file permissions on the
*.pref files. In order for those files to be written from within Koha,
the apache user must have write permissions to those files.

This is, in theory, a very simple fix. Just fixup Makefile.PL and
company to modify the permissions accordingly. It is, in practice, a
small nightmare for anyone who is not intimately acquainted with the
how's, why's, and wherefore's of this group of scripts.

So we need a volunteer... anyone? (Well, this job of writing to files
from within Koha will have to be done sooner or later, but maybe later
is better.) ;-)

A syspref editor working with the syspref system currently in place is
really a trivial thing to create. I see no reason to handle local-use
prefs any differently than other prefs. Doing so would only complicate
things imho. The code I have written so far already serializes new
prefs, writes them to the local-use.pref file, and adds the proper
data to the systempreferences table. It is in the rough, but clearly
demonstrates the possibility of having a working pref editor in the
3.2 release.

Given the relative ease with which a permanent solution maybe had, I'd
hate to see us resort to a hack to fix bug 3756.

Plus, any solution which stores local-use prefs in the db and does not
serialize them makes for yet more work when a permanent solution is
implemented. Not to mention all of the inherent risks of
updatedatabase.pl munging data as it reorganizes it.

Kind Regards,
Chris

From ohiocore at gmail.com  Mon Jul 12 20:37:19 2010
From: ohiocore at gmail.com (Joe Atzberger)
Date: Mon, 12 Jul 2010 14:37:19 -0400
Subject: [Koha-devel] Moving system preference serialization into the
	database
In-Reply-To: <4C3B59EC.2060908@tamil.fr>
References: <AANLkTimzsY4hk6lZNWXIZLW8nOGhM_0VTdjgpR8KqvPD@mail.gmail.com>
	<AANLkTim-TboIBctnCt5jFXOZznepqgFOEUHfEWEdp9i8@mail.gmail.com>
	<4C3AC314.9050308@tamil.fr>
	<AANLkTilRyd2rwokEBxC2yhcsA8sEiuSu0RVQszpYdYZo@mail.gmail.com>
	<AANLkTikWn7YTZ64Caai65s9ln248MxT3zjdw-M31YpfW@mail.gmail.com>
	<4C3B59EC.2060908@tamil.fr>
Message-ID: <AANLkTinWCPrmq0dB8umk1HGtP4vyKJuQyguf3JpyL-Dz@mail.gmail.com>

I'm also against translating SQL when templated techniques are feasible.
 But if the feature needed is to allow staff users the ability to enter
multiple translations *at runtime* with no systems-level administration,
then the only question is whether to allow Koha to:

   1. write to a directory that it later uses for data, or
   2. put more stuff in the database.


The former case would also change the security profile of Koha
significantly.  Allowing your application to write to template directories
is bad practice.  Among other things, if you happen to be running your Koha
installations off of git repos (as I know several vendors do), then having
new uncommitted changes in the repo will *block* git pull/rebase for
updates.  I regard it as inadvisable.

The latter is also undesirable, but only because we are talking about trying
to translate SQL, and for the reasons Frederic points out having to do with
translation.  Therefore the fix is to do something like allowing to Koha to
ingest values from a template file at install and runtime.  Read the
template (doesn't have to be H:T:P, as long as we can get PO files from it),
parse it to whatever, match against keys in the syspref table and update
description.

I should say that I am unconcerned with translation of descriptions for
purely local use variables if the user can control the description field in
the DB.  They can write the description in as many languages as they need.
 For standard sysprefs that need to be translated, I would still want to
route everything through http://translate.koha-community.org/ .  This might
mean a longer turnaround to get the result onto a production system, but it
certainly would lead to better satisfaction with Koha for other users of the
same language.

--joe

On Mon, Jul 12, 2010 at 2:07 PM, Frederic Demians <frederic at tamil.fr> wrote:

>
>  Leaving the files where they are makes it clearer that they are intended
>> to be interface-related data, like the XSLT, and translated as such.
>>
>
> Yes, even if it's not so simple, for XSL files and for .pref files, because
> they were designed at first with no specific consideration for localization.
> See various bugs related to this.
>
>
>  My vote for solving the local-use preferences system is to leave the
>> current system as it is, but add a database column or some way of easily
>> distinguishing local-use from non-local-use prefs in the DB (making the
>> explanation column NULL for non-local-use would work, though would require a
>> time-consuming database update). This would make building a local-use tab
>> fairly easy.
>>
>
> As I understand it, the main issue is with blocker bug 3756. It could be
> solved without adding a new syspref table column. You get from all the .pref
> files a list of 'official' sysprefs and you compare it to defined sysprefs
> in DB: the difference are the local sysprefs.
>
> --
> Fr?d?ric
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20100712/82be68fe/attachment-0001.htm>

From frederic at tamil.fr  Mon Jul 12 20:43:22 2010
From: frederic at tamil.fr (Frederic Demians)
Date: Mon, 12 Jul 2010 20:43:22 +0200
Subject: [Koha-devel] Moving system preference serialization into the
 database
In-Reply-To: <AANLkTikTomtDdx1QiN6_ckjv738AWZIG71MX271Rd8J-@mail.gmail.com>
References: <AANLkTimzsY4hk6lZNWXIZLW8nOGhM_0VTdjgpR8KqvPD@mail.gmail.com>
	<AANLkTim-TboIBctnCt5jFXOZznepqgFOEUHfEWEdp9i8@mail.gmail.com>
	<4C3AC314.9050308@tamil.fr>
	<AANLkTilRyd2rwokEBxC2yhcsA8sEiuSu0RVQszpYdYZo@mail.gmail.com>
	<AANLkTikWn7YTZ64Caai65s9ln248MxT3zjdw-M31YpfW@mail.gmail.com>
	<AANLkTikTomtDdx1QiN6_ckjv738AWZIG71MX271Rd8J-@mail.gmail.com>
Message-ID: <4C3B624A.7060306@tamil.fr>


> A syspref editor working with the syspref system currently in place is
> really a trivial thing to create. I see no reason to handle local-use
> prefs any differently than other prefs.

I see several reasons to handle differently Koha official sysprefs and 
local sysprefs:

    * They don't need the complete editor, with typed values, combo list
      and so on.
    * People who add local sysprefs know what they are doing. They are
      not end-users but integrators or developers.
    * It isn't necessary for local sysprefs to be translatable. So for
      them being stored exclusively in DB with no .pref template isn't a
      problem.

--
Fr?d?ric

From frederic at tamil.fr  Mon Jul 12 20:46:22 2010
From: frederic at tamil.fr (Frederic Demians)
Date: Mon, 12 Jul 2010 20:46:22 +0200
Subject: [Koha-devel] Moving system preference serialization into the
 database
In-Reply-To: <AANLkTinWCPrmq0dB8umk1HGtP4vyKJuQyguf3JpyL-Dz@mail.gmail.com>
References: <AANLkTimzsY4hk6lZNWXIZLW8nOGhM_0VTdjgpR8KqvPD@mail.gmail.com>	<AANLkTim-TboIBctnCt5jFXOZznepqgFOEUHfEWEdp9i8@mail.gmail.com>	<4C3AC314.9050308@tamil.fr>	<AANLkTilRyd2rwokEBxC2yhcsA8sEiuSu0RVQszpYdYZo@mail.gmail.com>	<AANLkTikWn7YTZ64Caai65s9ln248MxT3zjdw-M31YpfW@mail.gmail.com>	<4C3B59EC.2060908@tamil.fr>
	<AANLkTinWCPrmq0dB8umk1HGtP4vyKJuQyguf3JpyL-Dz@mail.gmail.com>
Message-ID: <4C3B62FE.9010106@tamil.fr>

>
> The former case would also change the security profile of Koha 
> significantly.  Allowing your application to write to template 
> directories is bad practice.  Among other things, if you happen to be 
> running your Koha installations off of git repos (as I know several 
> vendors do), then having new uncommitted changes in the repo will 
> *block* git pull/rebase for updates.  I regard it as inadvisable. 


+1

> The latter is also undesirable, but only because we are talking about 
> trying to translate SQL, and for the reasons Frederic points out 
> having to do with translation.  Therefore the fix is to do something 
> like allowing to Koha to ingest values from a template file at install 
> and runtime.  Read the template (doesn't have to be H:T:P, as long as 
> we can get PO files from it), parse it to whatever, match against keys 
> in the syspref table and update description. 

That's how it works now with .pref being specifically tokenized to 
extract text to be translated which are written into a .po file.
-- 
Fr?d?ric

From cnighswonger at foundations.edu  Mon Jul 12 22:04:41 2010
From: cnighswonger at foundations.edu (Chris Nighswonger)
Date: Mon, 12 Jul 2010 16:04:41 -0400
Subject: [Koha-devel] Moving system preference serialization into the
	database
In-Reply-To: <4C3B62FE.9010106@tamil.fr>
References: <AANLkTimzsY4hk6lZNWXIZLW8nOGhM_0VTdjgpR8KqvPD@mail.gmail.com> 
	<AANLkTim-TboIBctnCt5jFXOZznepqgFOEUHfEWEdp9i8@mail.gmail.com> 
	<4C3AC314.9050308@tamil.fr>
	<AANLkTilRyd2rwokEBxC2yhcsA8sEiuSu0RVQszpYdYZo@mail.gmail.com> 
	<AANLkTikWn7YTZ64Caai65s9ln248MxT3zjdw-M31YpfW@mail.gmail.com> 
	<4C3B59EC.2060908@tamil.fr>
	<AANLkTinWCPrmq0dB8umk1HGtP4vyKJuQyguf3JpyL-Dz@mail.gmail.com> 
	<4C3B62FE.9010106@tamil.fr>
Message-ID: <AANLkTil--WcQvD5z2gAalmTE-jcVZWyXg9bMI_f-Ub6H@mail.gmail.com>

Ok. Here is a quick fix which seems to be what everyone is headed
toward. Please abuse it a bit and see if it meets the present
criteria.

http://git.koha-community.org/gitweb/?p=wip/koha-fbc.git;a=commit;h=5b23a615018e049b1e11dbc10b131ecb30dfc6ab

On Mon, Jul 12, 2010 at 2:46 PM, Frederic Demians <frederic at tamil.fr> wrote:
>>
>> The former case would also change the security profile of Koha
>> significantly. ?Allowing your application to write to template directories
>> is bad practice. ?Among other things, if you happen to be running your Koha
>> installations off of git repos (as I know several vendors do), then having
>> new uncommitted changes in the repo will *block* git pull/rebase for
>> updates. ?I regard it as inadvisable.
>
>
> +1
>
>> The latter is also undesirable, but only because we are talking about
>> trying to translate SQL, and for the reasons Frederic points out having to
>> do with translation. ?Therefore the fix is to do something like allowing to
>> Koha to ingest values from a template file at install and runtime. ?Read the
>> template (doesn't have to be H:T:P, as long as we can get PO files from it),
>> parse it to whatever, match against keys in the syspref table and update
>> description.
>
> That's how it works now with .pref being specifically tokenized to extract
> text to be translated which are written into a .po file.
> --
> Fr?d?ric
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel

From frederic at tamil.fr  Mon Jul 12 23:28:38 2010
From: frederic at tamil.fr (Frederic Demians)
Date: Mon, 12 Jul 2010 23:28:38 +0200
Subject: [Koha-devel] Moving system preference serialization into the
 database
In-Reply-To: <AANLkTil--WcQvD5z2gAalmTE-jcVZWyXg9bMI_f-Ub6H@mail.gmail.com>
References: <AANLkTimzsY4hk6lZNWXIZLW8nOGhM_0VTdjgpR8KqvPD@mail.gmail.com>
	<AANLkTim-TboIBctnCt5jFXOZznepqgFOEUHfEWEdp9i8@mail.gmail.com>
	<4C3AC314.9050308@tamil.fr>
	<AANLkTilRyd2rwokEBxC2yhcsA8sEiuSu0RVQszpYdYZo@mail.gmail.com>
	<AANLkTikWn7YTZ64Caai65s9ln248MxT3zjdw-M31YpfW@mail.gmail.com>
	<4C3B59EC.2060908@tamil.fr>
	<AANLkTinWCPrmq0dB8umk1HGtP4vyKJuQyguf3JpyL-Dz@mail.gmail.com>
	<4C3B62FE.9010106@tamil.fr>
	<AANLkTil--WcQvD5z2gAalmTE-jcVZWyXg9bMI_f-Ub6H@mail.gmail.com>
Message-ID: <4C3B8906.5020208@tamil.fr>


> Ok. Here is a quick fix which seems to be what everyone is headed 
> toward. Please abuse it a bit and see if it meets the present criteria.

I try it. It works. But the way you identify local syspref is not the 
good one, as I understand it. You have in systemprefernces.pl (that you 
reactivate) a hash of 'official' sysprefs. Then you select all syspref 
defined in DB which are no in this hash. But it means that if tomorrow I 
had a new preference in a .pref file I also will have to add it in 
systempreferences.pl file otherwise it will appear as local.

--
Fr?d?ric


From cnighswonger at foundations.edu  Tue Jul 13 00:21:28 2010
From: cnighswonger at foundations.edu (Chris Nighswonger)
Date: Mon, 12 Jul 2010 18:21:28 -0400
Subject: [Koha-devel] Moving system preference serialization into the
	database
In-Reply-To: <4C3B8906.5020208@tamil.fr>
References: <AANLkTimzsY4hk6lZNWXIZLW8nOGhM_0VTdjgpR8KqvPD@mail.gmail.com> 
	<AANLkTim-TboIBctnCt5jFXOZznepqgFOEUHfEWEdp9i8@mail.gmail.com> 
	<4C3AC314.9050308@tamil.fr>
	<AANLkTilRyd2rwokEBxC2yhcsA8sEiuSu0RVQszpYdYZo@mail.gmail.com> 
	<AANLkTikWn7YTZ64Caai65s9ln248MxT3zjdw-M31YpfW@mail.gmail.com> 
	<4C3B59EC.2060908@tamil.fr>
	<AANLkTinWCPrmq0dB8umk1HGtP4vyKJuQyguf3JpyL-Dz@mail.gmail.com> 
	<4C3B62FE.9010106@tamil.fr>
	<AANLkTil--WcQvD5z2gAalmTE-jcVZWyXg9bMI_f-Ub6H@mail.gmail.com> 
	<4C3B8906.5020208@tamil.fr>
Message-ID: <AANLkTimJaDeDSGVNNwNOBxL4ahi64xOitQR1WFwhzhbN@mail.gmail.com>

On Mon, Jul 12, 2010 at 5:28 PM, Frederic Demians <frederic at tamil.fr> wrote:
>
>> Ok. Here is a quick fix which seems to be what everyone is headed toward.
>> Please abuse it a bit and see if it meets the present criteria.
>
> I try it. It works.

Thanks.

But the way you identify local syspref is not the good
> one, as I understand it. You have in systemprefernces.pl (that you
> reactivate) a hash of 'official' sysprefs. Then you select all syspref
> defined in DB which are no in this hash. But it means that if tomorrow I had
> a new preference in a .pref file I also will have to add it in
> systempreferences.pl file otherwise it will appear as local.

I think this is an unfortunate side-effect of the "quick and dirty"
part of this fix. Perhaps it might be good to open a bug against 3.4
to do at least some major cleanup of this code. There is a lot of it
which should be removed.

Kind Regards,
Chris

From frederic at tamil.fr  Tue Jul 13 07:45:37 2010
From: frederic at tamil.fr (Frederic Demians)
Date: Tue, 13 Jul 2010 07:45:37 +0200
Subject: [Koha-devel] Moving system preference serialization into the
 database
In-Reply-To: <AANLkTimJaDeDSGVNNwNOBxL4ahi64xOitQR1WFwhzhbN@mail.gmail.com>
References: <AANLkTimzsY4hk6lZNWXIZLW8nOGhM_0VTdjgpR8KqvPD@mail.gmail.com>
	<AANLkTim-TboIBctnCt5jFXOZznepqgFOEUHfEWEdp9i8@mail.gmail.com>
	<4C3AC314.9050308@tamil.fr>
	<AANLkTilRyd2rwokEBxC2yhcsA8sEiuSu0RVQszpYdYZo@mail.gmail.com>
	<AANLkTikWn7YTZ64Caai65s9ln248MxT3zjdw-M31YpfW@mail.gmail.com>
	<4C3B59EC.2060908@tamil.fr>
	<AANLkTinWCPrmq0dB8umk1HGtP4vyKJuQyguf3JpyL-Dz@mail.gmail.com>
	<4C3B62FE.9010106@tamil.fr>
	<AANLkTil--WcQvD5z2gAalmTE-jcVZWyXg9bMI_f-Ub6H@mail.gmail.com>
	<4C3B8906.5020208@tamil.fr>
	<AANLkTimJaDeDSGVNNwNOBxL4ahi64xOitQR1WFwhzhbN@mail.gmail.com>
Message-ID: <4C3BFD81.3000307@tamil.fr>


> I think this is an unfortunate side-effect of the "quick and dirty" 
> part of this fix. Perhaps it might be good to open a bug against 3.4 
> to do at least some major cleanup of this code. There is a lot of it 
> which should be removed

If your patch, as 'squashed' by Chris C., is committed, I will add 
quickly to the old syspref editor the ability to display syspref which 
are exactly the difference between DB and .pref files sysprefs.

Thanks again for the good work.

I agree that sysprefs design should be discussed further for 3.4: code 
cleanup and improvement asked by some (sysprefs per branch for example).

--
Fr?d?ric


From tajoli at cilea.it  Tue Jul 13 15:55:18 2010
From: tajoli at cilea.it (Zeno Tajoli)
Date: Tue, 13 Jul 2010 15:55:18 +0200
Subject: [Koha-devel] To define default 9xx fields for Unimarc setup in all
	languages
Message-ID: <20100713135544.1593146DF2@eliot.biblibre.com>

Hi to all

I sent this mail to different Koha-mailing list because the topic is 
quite wide.
If you are also on koha-dev list, replaty to this list.
Instead replay on koha general list.

I send the mail also to koha-france because many user of Unimarc are French.
But I don't know French, please replay to koha general list or to koha-dev.

Today the complete Unimarc setups are the English and French,
As I know Italian,  Ukrain, Russian and Poland setups are direct translation of
English or Frence setup

But on local fields English and French are not compatible.
Many 9xx fields need to be the same in different languages because the indexes
definitions in the file etc/zebradb/marc_defs/unimarc/biblios/record.abs
are based on specific 9xx values.
And the file record.abs is only one for all Unimarc setup

So my proposal, for 3.2 and also [if possible ] for 3.0.x

We re-write English setup in 9xx fields and we use it
a minimun and a standard that ALL unimarc setups need to follow.
It means that we need same change also to French setup.

I want to discuss with everyone about this topic.
I will write all the patch to fix the situation.

So my proposal:

Fields:

001        Local number -> biblio.biblionumber
090$a      Local number -> biblioitems.biblioitemnumber
099$c      date of creation -> biblio.datecreated
099$d      Date/time last modified -> biblio.timestamp

995$0   Withdrawn status -> items.wthdrawn
995$2	  Lost status -> items.itemlost
995$3   Use restrictions -> items.restricted
995$5   Date acquired -> items.dateaccessioned
995$6   Copy number ->  items.copynumber
995$7   URI -> items.uri
995$8   Koha collection -> items.ccode
995$9   Internal item number -> items.itemnumber
995$a   Homebranch (free text) ->items.homebranch
995$b   Homebranch (coded)
995$d   Holding branch (free text) -> items.holdingbranch
995$d   Holding branch (coded)
995$e   Shelving location-> items.location
995$f    Barcode -> items.barcode
995$j    Inventory number -> items.stocknumber [only 3.2]
995$k   Call number -> items.itemcallnumber,
995$l    Numbering (volume or other part) -> items.materials
995$m  Date of loan or deposit -> items.datelastborrowed
995$n   Expiration of loan date -> items.onloan
995$o   Circulation type (not for loan) -> items.notforloan
995$r    Type of item and material -> items.itype
995$v    Serial Enumeration / chronology -> items.enumchron [only serials]
995$u    Copy note -> items.itemnotes

942$0   Koha issues (borrowed), all copies -> biblioitems.totalissues
942$2   Source of classification or shelving scheme -> biblioitems.cn_source
942$6   Koha normalized classification for sorting -> biblioitems.cn_sort
942$c   Koha [default] item type -> biblioitems.itemtype
942$s   Serial record flag -> biblio.serial



1)Fields 001 and 090$a, BIB Identifier in two places
As French setup, to ahve a correct Unimarc we need BIB id in two places:
001 -> biblio.biblionumber
090 $9 -> biblioitems.biblioitemnumber
biblio.biblionumber and biblioitems.biblioitemnumber must be numerir,
we need to stress this fact in data conversions



2)Field 995 as item field with those subfields:
This proposal is full compatible with French Unimarc
setup and it has also the items subfields that are mandatory for circulation,
  inventory, acquisitions and serials.


3)Field 942 as biblio/item field.
This field is new for all unimarc setup, in english unimarc setup
  there is 990 but 990 is similar, not identical.
I select 942 instead of 990 because 990 is present in French setup 
with a specific meaning.
I ask to French people to accept to put biblioitems.totalissues in 
942$0, it is the base of the
popularity index. Now the base of popularity index is in 995$s.


This proposal is only a minimum, if you think there are others 9xx 
fields/subfields
that MUST be present in every setup, please replay.

If you want to discuss it, please replay.

Bye to all

Zeno Tajoli

Zeno Tajoli
CILEA - Segrate (MI)
tajoliAT_SPAM_no_prendiATcilea.it
(Indirizzo mascherato anti-spam; sostituisci quanto tra AT con @)


From kohadevel at agogme.com  Tue Jul 13 17:55:11 2010
From: kohadevel at agogme.com (Thomas Dukleth)
Date: Tue, 13 Jul 2010 15:55:11 -0000 (UTC)
Subject: [Koha-devel] #koha IRC meeting today about voting on software
	license
Message-ID: <b26e8c29620f166d92db06c276f770b7.squirrel@wmail.agogme.com>

Please remember that the #koha IRC meeting about voting on whether to
upgrade the copyright license for Koha 3.4 will beheld today on the #koha
IRC channel, 13 July 2010 at 19:00 UTC+0.

Time Converter:
http://tinyurl.com/2eaohr4

Agenda:
http://wiki.koha-community.org/wiki/License_Upgrade_Vote_IRC_Meeting,_13_July_2010


Thomas Dukleth
Agogme
109 E 9th Street, 3D
New York, NY  10003
USA
http://www.agogme.com
+1 212-674-3783





From gmcharlt at gmail.com  Tue Jul 13 19:32:15 2010
From: gmcharlt at gmail.com (Galen Charlton)
Date: Tue, 13 Jul 2010 13:32:15 -0400
Subject: [Koha-devel] Moving system preference serialization into the
	database
In-Reply-To: <4C3BFD81.3000307@tamil.fr>
References: <AANLkTimzsY4hk6lZNWXIZLW8nOGhM_0VTdjgpR8KqvPD@mail.gmail.com>
	<AANLkTim-TboIBctnCt5jFXOZznepqgFOEUHfEWEdp9i8@mail.gmail.com>
	<4C3AC314.9050308@tamil.fr>
	<AANLkTilRyd2rwokEBxC2yhcsA8sEiuSu0RVQszpYdYZo@mail.gmail.com>
	<AANLkTikWn7YTZ64Caai65s9ln248MxT3zjdw-M31YpfW@mail.gmail.com>
	<4C3B59EC.2060908@tamil.fr>
	<AANLkTinWCPrmq0dB8umk1HGtP4vyKJuQyguf3JpyL-Dz@mail.gmail.com>
	<4C3B62FE.9010106@tamil.fr>
	<AANLkTil--WcQvD5z2gAalmTE-jcVZWyXg9bMI_f-Ub6H@mail.gmail.com>
	<4C3B8906.5020208@tamil.fr>
	<AANLkTimJaDeDSGVNNwNOBxL4ahi64xOitQR1WFwhzhbN@mail.gmail.com>
	<4C3BFD81.3000307@tamil.fr>
Message-ID: <AANLkTinNJnG6rJSk9WxISTFWVUkE3lLBPuZbOSrN3YMq@mail.gmail.com>

Hi,

On Tue, Jul 13, 2010 at 1:45 AM, Frederic Demians <frederic at tamil.fr> wrote:
> If your patch, as 'squashed' by Chris C., is committed, I will add quickly
> to the old syspref editor the ability to display syspref which are exactly
> the difference between DB and .pref files sysprefs.

Please go ahead and patch against Chris' patch to add this.

Regards,

Galen
-- 
Galen Charlton
gmcharlt at gmail.com

From nengard at gmail.com  Thu Jul 15 14:25:35 2010
From: nengard at gmail.com (Nicole Engard)
Date: Thu, 15 Jul 2010 08:25:35 -0400
Subject: [Koha-devel] Official Koha Newsletter : Volume 1, Issue 7: July 2010
Message-ID: <AANLkTiloGZR1mXq5TGjaGiQrYnZBqXwKh_Y3JdlkxksR@mail.gmail.com>

Read this newsletter online with live links:
http://koha-community.org/koha-newsletter-volume-1issue-7-july-2010/


Official Koha Newsletter (ISSN 2153-8328)
Volume 1, Issue 7: July 2010
Table of Contents

    * Tips & Tricks
          o Search in Koha
          o Amazon Content Not Appearing?
    * Koha in Libraries
          o Koha Users Forum launched in Nigeria
          o Archive & Access Project
    * Koha Events
          o Second Koha Open Day in London
          o KohaCon 2010 Program Available


Tips & Tricks


Search in Koha
by Marilen Aretius Corciovei

For people used to web searches and database oriented application Koha
way of dealing with searches (since v.3) might seem a bit alien. This
is a small set of notes related to some not very obvious questions
which I had to answer in order to do some configurations which seemed
trivial at the beginning. I am not saying this is wrong or
ineffective, just different and different means time to learn. I?m
writing this to help you reduce this time. [Read Part 1 & Part 2.]


Amazon Content Not Working?
by Nicole C. Engard

Question: Why is Amazon?s enhanced content not appearing?

Answer: Amazon uses your server time in its API requests and so if
your system time is off you will not be able to use Amazon content.
Update your server time and make sure all of your Amazon preferences
are turned on, this should solve the problem.


Koha in Libraries


Koha Users Forum launched in Nigeria
by Olugbenga Adara

Projektlink Konsult Limited, the premier Koha support company in
Nigeria hosted the first ever Koha Users Forum at its premises in
Ibadan, Nigeria on Monday June 21, 2010. The event, which had 22
participants from 12 different institutions using Koha in Nigeria,
featured tutorials, tips and tricks and discussions on challenges and
solutions to problems encountered by the participants while running
Koha. More details are available here.


Archive & Access Project
by Savitra Sirohi

The Archive and Access project aims to set up a consortium of archives
and libraries in India with the purpose of catalog sharing and
eventual sharing of full text digitized resources. The project is
supported by the Jamsetji Tata Trust and housed at the Centre or the
Study of Culture and Society, Bangalore.

This will be a union catalog, powered by Koha, of historical
collections of libraries and archives from different parts of the
India. This is an ongoing process, with the regular introduction of
new institutions to the catalog.

The project wishes to solicit contributions from libraries,
organizations, historians and other scholars for this catalog. Those
interested in participating can contact project members at:
publicarchivesindia at gmail.com and more information can be found on the
official page.


Koha Events


Second Koha Open Day in London
by Andrea Chandler

The Kings Fund and CAMLIS are pleased to announce that we will be
holding another free open day for people interested in finding more
about implementing or switching to Koha. All Koha users are also
welcome.

The event will be held in the afternoon of Friday 10th of September at
CAMLIS, from 2pm-5pm. At the moment we don?t have a strict schedule
but we hope to include some short presentations with discussion,
followed by hands-on experience in small groups at
the library computers. There will be some time for existing Koha users
to chat with each other. If any user is interested in giving a 10
minute presentation or demonstration of some aspect of Koha, please
contact one of us.

Places for this event are limited so please book early by contacting
Matthew Hale at the King?s Fund: m.hale at kingsfund.org.uk. If there is
sufficient interest we will repeat it at a later date, so do register
your interest even if you can?t necessarily make this day.


KohaCon 2010 Program Available
by Nicole C. Engard

As we get closer to the next annual KohaCon (this year in NZ ? where
it all started) it?s time to check out the program for the event! We
are still gathering speaker bios and program description updates, but
the preliminary program is available on the conference site.





Newsletter edited by Nicole C. Engard, Koha Documentation Manager.
Please send future story ideas to me.

From colin.campbell at ptfs-europe.com  Thu Jul 15 15:27:37 2010
From: colin.campbell at ptfs-europe.com (Colin Campbell)
Date: Thu, 15 Jul 2010 14:27:37 +0100
Subject: [Koha-devel] Image/Graphics Magick confusion
Message-ID: <4C3F0CC9.3040807@ptfs-europe.com>

Hi,
  just noticed that the debian package lists and scripts in install-misc
install
libimage-magick-perl but the koha dependency is for Graphics::Magick
(libgraphics-magick-perl). Willing to generate a patch for that but
wondered if there are any advantages in using Graphics Magick rather
than Image Magick (as imagemagick has the advantage that the perl module
can be installed from CPAN )

Colin

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

http://www.ptfs-europe.com

From cnighswonger at foundations.edu  Thu Jul 15 15:53:28 2010
From: cnighswonger at foundations.edu (Chris Nighswonger)
Date: Thu, 15 Jul 2010 09:53:28 -0400
Subject: [Koha-devel] Image/Graphics Magick confusion
In-Reply-To: <4C3F0CC9.3040807@ptfs-europe.com>
References: <4C3F0CC9.3040807@ptfs-europe.com>
Message-ID: <AANLkTinsvZXKirDDiBTReCQpuuUItuwJJiiqL8urcWyv@mail.gmail.com>

On Thu, Jul 15, 2010 at 9:27 AM, Colin Campbell
<colin.campbell at ptfs-europe.com> wrote:
< snip >
> wondered if there are any advantages in using Graphics Magick rather
> than Image Magick (as imagemagick has the advantage that the perl module
> can be installed from CPAN )

Only that with Graphics Magick you get both binaries and perl module
in one shot. With Image Magick you'll have to cpan the perl module and
then get the binaries via some other mechanism depending on your *nix
flavor.

Otherwise there is probably no advantage to what we are doing with it.

Kind Regards,
Chris

From colin.campbell at ptfs-europe.com  Thu Jul 15 16:57:33 2010
From: colin.campbell at ptfs-europe.com (Colin Campbell)
Date: Thu, 15 Jul 2010 15:57:33 +0100
Subject: [Koha-devel] Image/Graphics Magick confusion
In-Reply-To: <AANLkTinsvZXKirDDiBTReCQpuuUItuwJJiiqL8urcWyv@mail.gmail.com>
References: <4C3F0CC9.3040807@ptfs-europe.com>
	<AANLkTinsvZXKirDDiBTReCQpuuUItuwJJiiqL8urcWyv@mail.gmail.com>
Message-ID: <4C3F21DD.5040706@ptfs-europe.com>

On 15/07/10 14:53, Chris Nighswonger wrote:
> On Thu, Jul 15, 2010 at 9:27 AM, Colin Campbell
> <colin.campbell at ptfs-europe.com> wrote:
> < snip >
>> wondered if there are any advantages in using Graphics Magick rather
>> than Image Magick (as imagemagick has the advantage that the perl module
>> can be installed from CPAN )
> 
> Only that with Graphics Magick you get both binaries and perl module
> in one shot. With Image Magick you'll have to cpan the perl module and
> then get the binaries via some other mechanism depending on your *nix
> flavor.
> 
> Otherwise there is probably no advantage to what we are doing with it.
Thanks Chris,
  actually not being able to manage the module via cpan is causing me
extra work in something I'm trying to do, (and in non debian platforms)
as ever the mileage varys
Colin


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

http://www.ptfs-europe.com

From ohiocore at gmail.com  Thu Jul 15 17:03:12 2010
From: ohiocore at gmail.com (Joe Atzberger)
Date: Thu, 15 Jul 2010 11:03:12 -0400
Subject: [Koha-devel] Image/Graphics Magick confusion
In-Reply-To: <AANLkTinsvZXKirDDiBTReCQpuuUItuwJJiiqL8urcWyv@mail.gmail.com>
References: <4C3F0CC9.3040807@ptfs-europe.com>
	<AANLkTinsvZXKirDDiBTReCQpuuUItuwJJiiqL8urcWyv@mail.gmail.com>
Message-ID: <AANLkTimNWA4xveAht-QEGSAl4jpaYsVxgi8_kMQi4mmw@mail.gmail.com>

Yeah, the whole point of preferring distro packages is for binaries and
distro-specific configs.  Any decent image manipulation components will rely
on binary code for performance.  Unfortunately, too many CPAN modules fail
to build XS correctly on a given platform (including debian, historically),
hence the distro package approach.

What kind of complication are you seeing?

--joe

On Thu, Jul 15, 2010 at 9:53 AM, Chris Nighswonger <
cnighswonger at foundations.edu> wrote:

> On Thu, Jul 15, 2010 at 9:27 AM, Colin Campbell
> <colin.campbell at ptfs-europe.com> wrote:
> < snip >
> > wondered if there are any advantages in using Graphics Magick rather
> > than Image Magick (as imagemagick has the advantage that the perl module
> > can be installed from CPAN )
>
> Only that with Graphics Magick you get both binaries and perl module
> in one shot. With Image Magick you'll have to cpan the perl module and
> then get the binaries via some other mechanism depending on your *nix
> flavor.
>
> Otherwise there is probably no advantage to what we are doing with it.
>
> Kind Regards,
> Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20100715/b0ffe39c/attachment.htm>

From colin.campbell at ptfs-europe.com  Thu Jul 15 17:41:06 2010
From: colin.campbell at ptfs-europe.com (Colin Campbell)
Date: Thu, 15 Jul 2010 16:41:06 +0100
Subject: [Koha-devel] Image/Graphics Magick confusion
In-Reply-To: <AANLkTimNWA4xveAht-QEGSAl4jpaYsVxgi8_kMQi4mmw@mail.gmail.com>
References: <4C3F0CC9.3040807@ptfs-europe.com>	<AANLkTinsvZXKirDDiBTReCQpuuUItuwJJiiqL8urcWyv@mail.gmail.com>
	<AANLkTimNWA4xveAht-QEGSAl4jpaYsVxgi8_kMQi4mmw@mail.gmail.com>
Message-ID: <4C3F2C12.4020400@ptfs-europe.com>

On 15/07/10 16:03, Joe Atzberger wrote:
> Yeah, the whole point of preferring distro packages is for binaries and
> distro-specific configs.  Any decent image manipulation components will rely
> on binary code for performance.  Unfortunately, too many CPAN modules fail
> to build XS correctly on a given platform (including debian, historically),
> hence the distro package approach.
> 
> What kind of complication are you seeing?
Its just an extra hoop to jump through. Especially of you are using
testing perl environments or stuff like local:lib its easier if you can
just bundle your cpan requirements, not have to rebuild one module
separately. Mind you having had "fun" with Image::Magick's more fluid
api in the past I can see why Graphics::Magick came about.

Colin

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

http://www.ptfs-europe.com

From paul.poulain at biblibre.com  Thu Jul 15 23:10:54 2010
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Thu, 15 Jul 2010 23:10:54 +0200
Subject: [Koha-devel] rebuild_zebra and a limit at 700 000 biblios
Message-ID: <4C3F795E.4060008@biblibre.com>

Hello,

We have a database of 726k biblios and 1.2M items.
When we rebuild_zebra, everything is OK on the export.
Then, the rebuild_zebra seems OK as well, except that only 702k biblios
are indexed.
We don't have any error, everything seems OK.

Does anyone have seen this problem ?

Logs :
exporting biblio
====================
Records exported: 726210
<snip>
06:43:19-08/07 zebraidx(314) [log] Records: 700000 i/u/d 700000/0/0
06:43:29-08/07 zebraidx(314) [log] Records: 701000 i/u/d 701000/0/0
06:43:38-08/07 zebraidx(314) [log] Records: 702000 i/u/d 702000/0/0
07:42:38-08/07 zebraidx(314) [log] Merge 0% <snip>
07:00:52-08/07 zebraidx(314) [log] Merge 95.4% completed; 48 seconds
remaining
07:01:02-08/07 zebraidx(314) [log] Merge 96.4% completed; 37 seconds
remaining
07:01:12-08/07 zebraidx(314) [log] Merge 97.4% completed; 26 seconds
remaining
07:01:22-08/07 zebraidx(314) [log] Merge 98.7% completed; 13 seconds
remaining
07:01:32-08/07 zebraidx(314) [log] Merge 99.9% completed; 0 seconds
remaining
07:01:38-08/07 zebraidx(314) [log] Iterations: isam/dict 301420236/21553295
07:01:38-08/07 zebraidx(314) [log] Dict: inserts/updates/deletions:
21553295/0/0
07:01:42-08/07 zebraidx(314) [log] Records: 702954 i/u/d 702954/0/0
07:01:42-08/07 zebraidx(314) [log] zebra_stop: 20557.86 6312.50 1447.43

Search works on every biblio, except ones after 702955.


-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08


From chris at bigballofwax.co.nz  Thu Jul 15 23:21:51 2010
From: chris at bigballofwax.co.nz (Chris Cormack)
Date: Fri, 16 Jul 2010 09:21:51 +1200
Subject: [Koha-devel] rebuild_zebra and a limit at 700 000 biblios
In-Reply-To: <4C3F795E.4060008@biblibre.com>
References: <4C3F795E.4060008@biblibre.com>
Message-ID: <AANLkTikHjYYRqKSH-VpiF42emmem-RYdpgSbN047hp5M@mail.gmail.com>

On 16 July 2010 09:10, Paul Poulain <paul.poulain at biblibre.com> wrote:
> Hello,
>
> We have a database of 726k biblios and 1.2M items.
> When we rebuild_zebra, everything is OK on the export.
> Then, the rebuild_zebra seems OK as well, except that only 702k biblios
> are indexed.
> We don't have any error, everything seems OK.
>
> Does anyone have seen this problem ?
>
It definitely exports all of them? Have you tried it with -d and -k to
keep the files then check it exported 726k?

Chris

From skushner at mtpl.org  Thu Jul 15 23:21:36 2010
From: skushner at mtpl.org (Scott Kushner)
Date: Thu, 15 Jul 2010 17:21:36 -0400
Subject: [Koha-devel] rebuild_zebra and a limit at 700 000 biblios
References: <4C3F795E.4060008@biblibre.com>
Message-ID: <3F5DBA7C1433624D870AF4F965358FD660E48D@exchange.mplmain.mtpl.org>

Paul, 

I think you have to increase memory in biblios.cfg buffer to.

# Lock File Area
lockDir: /root/koha-dev/var/lock/zebradb/biblios
perm.anonymous:ar
perm.root:rw
passwd: /root/koha-dev/etc/zebradb/etc/passwd
register: /root/koha-dev/var/lib/zebradb/biblios/register:8G
shadow: /root/koha-dev/var/lib/zebradb/biblios/shadow:8G

# Temp File area for result sets
setTmpDir: /root/koha-dev/var/lib/zebradb/biblios/tmp

# Temp File area for index program
keyTmpDir: /root/koha-dev/var/lib/zebradb/biblios/key

# Approx. Memory usage during indexing
memMax: 150M
rank:rank-1
truncmax: 1000000000


Scott Kushner
Information Technologies
Middletown Public Library
-----Original Message-----
From: koha-devel-bounces at lists.koha-community.org
[mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Paul
Poulain
Sent: Thursday, July 15, 2010 5:11 PM
To: koha-devel at lists.koha-community.org
Subject: [Koha-devel] rebuild_zebra and a limit at 700 000 biblios

Hello,

We have a database of 726k biblios and 1.2M items.
When we rebuild_zebra, everything is OK on the export.
Then, the rebuild_zebra seems OK as well, except that only 702k biblios
are indexed.
We don't have any error, everything seems OK.

Does anyone have seen this problem ?

Logs :
exporting biblio
====================
Records exported: 726210
<snip>
06:43:19-08/07 zebraidx(314) [log] Records: 700000 i/u/d 700000/0/0
06:43:29-08/07 zebraidx(314) [log] Records: 701000 i/u/d 701000/0/0
06:43:38-08/07 zebraidx(314) [log] Records: 702000 i/u/d 702000/0/0
07:42:38-08/07 zebraidx(314) [log] Merge 0% <snip>
07:00:52-08/07 zebraidx(314) [log] Merge 95.4% completed; 48 seconds
remaining
07:01:02-08/07 zebraidx(314) [log] Merge 96.4% completed; 37 seconds
remaining
07:01:12-08/07 zebraidx(314) [log] Merge 97.4% completed; 26 seconds
remaining
07:01:22-08/07 zebraidx(314) [log] Merge 98.7% completed; 13 seconds
remaining
07:01:32-08/07 zebraidx(314) [log] Merge 99.9% completed; 0 seconds
remaining
07:01:38-08/07 zebraidx(314) [log] Iterations: isam/dict
301420236/21553295
07:01:38-08/07 zebraidx(314) [log] Dict: inserts/updates/deletions:
21553295/0/0
07:01:42-08/07 zebraidx(314) [log] Records: 702954 i/u/d 702954/0/0
07:01:42-08/07 zebraidx(314) [log] zebra_stop: 20557.86 6312.50 1447.43

Search works on every biblio, except ones after 702955.


-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08

_______________________________________________
Koha-devel mailing list
Koha-devel at lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel


From paul.poulain at biblibre.com  Thu Jul 15 23:28:51 2010
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Thu, 15 Jul 2010 23:28:51 +0200
Subject: [Koha-devel] Fwd: RE: rebuild_zebra and a limit at 700 000 biblios
Message-ID: <4C3F7D93.5040802@biblibre.com>

Scott,

I already have :
register: /home/koha/var/lib/zebradb/biblios/register:40G
shadow: /home/koha/var/lib/zebradb/biblios/shadow:40G

or I'm looking at the wrong file...
double check ...
unless i'm blind (or really too tired), I have 40G, so that should be
enough :\

-------- Message original --------
Sujet: 	RE: [Koha-devel] rebuild_zebra and a limit at 700 000 biblios
Date : 	Thu, 15 Jul 2010 17:17:16 -0400
De : 	Scott Kushner <skushner at mtpl.org>
Pour : 	Paul Poulain <paul.poulain at biblibre.com>



Paul, 
I think you have to increase your memory buffer in biblios.cfg to 8G or
more. I had that problem. 

# Lock File Area
lockDir: /root/koha-dev/var/lock/zebradb/biblios
perm.anonymous:ar
perm.root:rw
passwd: /root/koha-dev/etc/zebradb/etc/passwd
register: /root/koha-dev/var/lib/zebradb/biblios/register:8G
shadow: /root/koha-dev/var/lib/zebradb/biblios/shadow:8G

# Temp File area for result sets
setTmpDir: /root/koha-dev/var/lib/zebradb/biblios/tmp

# Temp File area for index program
keyTmpDir: /root/koha-dev/var/lib/zebradb/biblios/key

# Approx. Memory usage during indexing
memMax: 150M
rank:rank-1
truncmax: 1000000000


Scott Kushner
Information Technologies
Middletown Public Library

-----Original Message-----
From: koha-devel-bounces at lists.koha-community.org
[mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Paul
Poulain
Sent: Thursday, July 15, 2010 5:11 PM
To: koha-devel at lists.koha-community.org
Subject: [Koha-devel] rebuild_zebra and a limit at 700 000 biblios

Hello,

We have a database of 726k biblios and 1.2M items.
When we rebuild_zebra, everything is OK on the export.
Then, the rebuild_zebra seems OK as well, except that only 702k biblios
are indexed.
We don't have any error, everything seems OK.

Does anyone have seen this problem ?

Logs :
exporting biblio
====================
Records exported: 726210
<snip>
06:43:19-08/07 zebraidx(314) [log] Records: 700000 i/u/d 700000/0/0
06:43:29-08/07 zebraidx(314) [log] Records: 701000 i/u/d 701000/0/0
06:43:38-08/07 zebraidx(314) [log] Records: 702000 i/u/d 702000/0/0
07:42:38-08/07 zebraidx(314) [log] Merge 0% <snip>
07:00:52-08/07 zebraidx(314) [log] Merge 95.4% completed; 48 seconds
remaining
07:01:02-08/07 zebraidx(314) [log] Merge 96.4% completed; 37 seconds
remaining
07:01:12-08/07 zebraidx(314) [log] Merge 97.4% completed; 26 seconds
remaining
07:01:22-08/07 zebraidx(314) [log] Merge 98.7% completed; 13 seconds
remaining
07:01:32-08/07 zebraidx(314) [log] Merge 99.9% completed; 0 seconds
remaining
07:01:38-08/07 zebraidx(314) [log] Iterations: isam/dict
301420236/21553295
07:01:38-08/07 zebraidx(314) [log] Dict: inserts/updates/deletions:
21553295/0/0
07:01:42-08/07 zebraidx(314) [log] Records: 702954 i/u/d 702954/0/0
07:01:42-08/07 zebraidx(314) [log] zebra_stop: 20557.86 6312.50 1447.43

Search works on every biblio, except ones after 702955.


-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08

_______________________________________________
Koha-devel mailing list
Koha-devel at lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel



-------------- section suivante --------------
Une pi?ce jointe HTML a ?t? nettoy?e...
URL: </pipermail/koha-devel/attachments/20100715/31ee670c/attachment.htm>

From ian.walls at bywatersolutions.com  Thu Jul 15 23:33:59 2010
From: ian.walls at bywatersolutions.com (Ian Walls)
Date: Thu, 15 Jul 2010 17:33:59 -0400
Subject: [Koha-devel] Fwd: RE: rebuild_zebra and a limit at 700 000
	biblios
In-Reply-To: <4C3F7D93.5040802@biblibre.com>
References: <4C3F7D93.5040802@biblibre.com>
Message-ID: <AANLkTin7lOo7bLggqTOWscsFoua7se6hzruwn5RXflAn@mail.gmail.com>

Paul,


I find that around 70,000 biblios starts to push th 4GB limit, so 700,000
may start to push the 40GB limit, but from what you've pasted, you're not in
that situation (there'd be a warn).

Do you have enough hard drive space total for the exported files, register
and shadow?  Maybe it's that you can't export all the files?  This is a shot
in the dark, really.


-Ian

2010/7/15 Paul Poulain <paul.poulain at biblibre.com>

>  Scott,
>
> I already have :
> register: /home/koha/var/lib/zebradb/biblios/register:40G
> shadow: /home/koha/var/lib/zebradb/biblios/shadow:40G
>
> or I'm looking at the wrong file...
> double check ...
> unless i'm blind (or really too tired), I have 40G, so that should be
> enough :\
>
> -------- Message original --------  Sujet: RE: [Koha-devel] rebuild_zebra
> and a limit at 700 000 biblios  Date : Thu, 15 Jul 2010 17:17:16 -0400  De :
> Scott Kushner <skushner at mtpl.org> <skushner at mtpl.org>  Pour : Paul Poulain
> <paul.poulain at biblibre.com> <paul.poulain at biblibre.com>
>
> Paul,
> I think you have to increase your memory buffer in biblios.cfg to 8G or
> more. I had that problem.
>
> # Lock File Area
> lockDir: /root/koha-dev/var/lock/zebradb/biblios
> perm.anonymous:ar
> perm.root:rw
> passwd: /root/koha-dev/etc/zebradb/etc/passwd
> register: /root/koha-dev/var/lib/zebradb/biblios/register:8G
> shadow: /root/koha-dev/var/lib/zebradb/biblios/shadow:8G
>
> # Temp File area for result sets
> setTmpDir: /root/koha-dev/var/lib/zebradb/biblios/tmp
>
> # Temp File area for index program
> keyTmpDir: /root/koha-dev/var/lib/zebradb/biblios/key
>
> # Approx. Memory usage during indexing
> memMax: 150M
> rank:rank-1
> truncmax: 1000000000
>
>
> Scott Kushner
> Information Technologies
> Middletown Public Library
>
> -----Original Message-----
> From: koha-devel-bounces at lists.koha-community.org
>
> [mailto:koha-devel-bounces at lists.koha-community.org <koha-devel-bounces at lists.koha-community.org>] On Behalf Of Paul
> Poulain
> Sent: Thursday, July 15, 2010 5:11 PM
> To: koha-devel at lists.koha-community.org
> Subject: [Koha-devel] rebuild_zebra and a limit at 700 000 biblios
>
> Hello,
>
> We have a database of 726k biblios and 1.2M items.
> When we rebuild_zebra, everything is OK on the export.
> Then, the rebuild_zebra seems OK as well, except that only 702k biblios
> are indexed.
> We don't have any error, everything seems OK.
>
> Does anyone have seen this problem ?
>
> Logs :
> exporting biblio
> ====================
> Records exported: 726210
> <snip>
> 06:43:19-08/07 zebraidx(314) [log] Records: 700000 i/u/d 700000/0/0
> 06:43:29-08/07 zebraidx(314) [log] Records: 701000 i/u/d 701000/0/0
> 06:43:38-08/07 zebraidx(314) [log] Records: 702000 i/u/d 702000/0/0
> 07:42:38-08/07 zebraidx(314) [log] Merge 0% <snip>
> 07:00:52-08/07 zebraidx(314) [log] Merge 95.4% completed; 48 seconds
> remaining
> 07:01:02-08/07 zebraidx(314) [log] Merge 96.4% completed; 37 seconds
> remaining
> 07:01:12-08/07 zebraidx(314) [log] Merge 97.4% completed; 26 seconds
> remaining
> 07:01:22-08/07 zebraidx(314) [log] Merge 98.7% completed; 13 seconds
> remaining
> 07:01:32-08/07 zebraidx(314) [log] Merge 99.9% completed; 0 seconds
> remaining
> 07:01:38-08/07 zebraidx(314) [log] Iterations: isam/dict
> 301420236/21553295
> 07:01:38-08/07 zebraidx(314) [log] Dict: inserts/updates/deletions:
> 21553295/0/0
> 07:01:42-08/07 zebraidx(314) [log] Records: 702954 i/u/d 702954/0/0
> 07:01:42-08/07 zebraidx(314) [log] zebra_stop: 20557.86 6312.50 1447.43
>
> Search works on every biblio, except ones after 702955.
>
>
> --
> Paul POULAINhttp://www.biblibre.com
> Expert en Logiciels Libres pour l'info-doc
> Tel : (33) 4 91 81 35 08
>
> _______________________________________________
> Koha-devel mailing listKoha-devel at lists.koha-community.orghttp://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>



-- 
Ian Walls
Lead Development Specialist
ByWater Solutions
Phone # (888) 900-8944
http://bywatersolutions.com
ian.walls at bywatersolutions.com
Twitter: @sekjal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20100715/e5bda2d1/attachment-0001.htm>

From cnighswonger at foundations.edu  Thu Jul 15 23:36:07 2010
From: cnighswonger at foundations.edu (Chris Nighswonger)
Date: Thu, 15 Jul 2010 17:36:07 -0400
Subject: [Koha-devel] Fwd: RE: rebuild_zebra and a limit at 700 000
	biblios
In-Reply-To: <AANLkTin7lOo7bLggqTOWscsFoua7se6hzruwn5RXflAn@mail.gmail.com>
References: <4C3F7D93.5040802@biblibre.com>
	<AANLkTin7lOo7bLggqTOWscsFoua7se6hzruwn5RXflAn@mail.gmail.com>
Message-ID: <AANLkTikcEFowd2ZqMkPwt6QBDA1Hqlc0m9BxkIIK91o_@mail.gmail.com>

2010/7/15 Ian Walls <ian.walls at bywatersolutions.com>

> Paul,
>
>
> I find that around 70,000 biblios starts to push th 4GB limit, so 700,000
> may start to push the 40GB limit, but from what you've pasted, you're not in
> that situation (there'd be a warn).
>
>
FWIW, Zebra claims to be able to handle 100GB of record data.

http://www.indexdata.com/zebra/doc/features.html#features-scalability
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20100715/fef92248/attachment.htm>

From cfouts at ptfs.com  Thu Jul 15 23:57:01 2010
From: cfouts at ptfs.com (Fouts, Clay)
Date: Thu, 15 Jul 2010 14:57:01 -0700
Subject: [Koha-devel] Fwd: RE: rebuild_zebra and a limit at 700 000
	biblios
In-Reply-To: <AANLkTin7lOo7bLggqTOWscsFoua7se6hzruwn5RXflAn@mail.gmail.com>
References: <4C3F7D93.5040802@biblibre.com>
	<AANLkTin7lOo7bLggqTOWscsFoua7se6hzruwn5RXflAn@mail.gmail.com>
Message-ID: <AANLkTimzR3jhDz3u4uRMTH9zzeCLMAvsWOIPqWNSs-Ni@mail.gmail.com>

The zebraidx program would fail loudly with a descriptive error if you
exceeded either the configured allocation or available disk space. Some
thing else is going on here.

I would first confirm that all the expected records are actually in the
export file.

Clay


2010/7/15 Ian Walls <ian.walls at bywatersolutions.com>

> Paul,
>
>
> I find that around 70,000 biblios starts to push th 4GB limit, so 700,000
> may start to push the 40GB limit, but from what you've pasted, you're not in
> that situation (there'd be a warn).
>
> Do you have enough hard drive space total for the exported files, register
> and shadow?  Maybe it's that you can't export all the files?  This is a shot
> in the dark, really.
>
>
> -Ian
>
> 2010/7/15 Paul Poulain <paul.poulain at biblibre.com>
>
>  Scott,
>>
>> I already have :
>> register: /home/koha/var/lib/zebradb/biblios/register:40G
>> shadow: /home/koha/var/lib/zebradb/biblios/shadow:40G
>>
>> or I'm looking at the wrong file...
>> double check ...
>> unless i'm blind (or really too tired), I have 40G, so that should be
>> enough :\
>>
>> -------- Message original --------  Sujet: RE: [Koha-devel] rebuild_zebra
>> and a limit at 700 000 biblios  Date : Thu, 15 Jul 2010 17:17:16 -0400  De :
>> Scott Kushner <skushner at mtpl.org> <skushner at mtpl.org>  Pour : Paul
>> Poulain <paul.poulain at biblibre.com> <paul.poulain at biblibre.com>
>>
>> Paul,
>> I think you have to increase your memory buffer in biblios.cfg to 8G or
>> more. I had that problem.
>>
>> # Lock File Area
>> lockDir: /root/koha-dev/var/lock/zebradb/biblios
>> perm.anonymous:ar
>> perm.root:rw
>> passwd: /root/koha-dev/etc/zebradb/etc/passwd
>> register: /root/koha-dev/var/lib/zebradb/biblios/register:8G
>> shadow: /root/koha-dev/var/lib/zebradb/biblios/shadow:8G
>>
>> # Temp File area for result sets
>> setTmpDir: /root/koha-dev/var/lib/zebradb/biblios/tmp
>>
>> # Temp File area for index program
>> keyTmpDir: /root/koha-dev/var/lib/zebradb/biblios/key
>>
>> # Approx. Memory usage during indexing
>> memMax: 150M
>> rank:rank-1
>> truncmax: 1000000000
>>
>>
>> Scott Kushner
>> Information Technologies
>> Middletown Public Library
>>
>> -----Original Message-----
>> From: koha-devel-bounces at lists.koha-community.org
>>
>> [mailto:koha-devel-bounces at lists.koha-community.org <koha-devel-bounces at lists.koha-community.org>] On Behalf Of Paul
>> Poulain
>> Sent: Thursday, July 15, 2010 5:11 PM
>> To: koha-devel at lists.koha-community.org
>> Subject: [Koha-devel] rebuild_zebra and a limit at 700 000 biblios
>>
>> Hello,
>>
>> We have a database of 726k biblios and 1.2M items.
>> When we rebuild_zebra, everything is OK on the export.
>> Then, the rebuild_zebra seems OK as well, except that only 702k biblios
>> are indexed.
>> We don't have any error, everything seems OK.
>>
>> Does anyone have seen this problem ?
>>
>> Logs :
>> exporting biblio
>> ====================
>> Records exported: 726210
>> <snip>
>> 06:43:19-08/07 zebraidx(314) [log] Records: 700000 i/u/d 700000/0/0
>> 06:43:29-08/07 zebraidx(314) [log] Records: 701000 i/u/d 701000/0/0
>> 06:43:38-08/07 zebraidx(314) [log] Records: 702000 i/u/d 702000/0/0
>> 07:42:38-08/07 zebraidx(314) [log] Merge 0% <snip>
>> 07:00:52-08/07 zebraidx(314) [log] Merge 95.4% completed; 48 seconds
>> remaining
>> 07:01:02-08/07 zebraidx(314) [log] Merge 96.4% completed; 37 seconds
>> remaining
>> 07:01:12-08/07 zebraidx(314) [log] Merge 97.4% completed; 26 seconds
>> remaining
>> 07:01:22-08/07 zebraidx(314) [log] Merge 98.7% completed; 13 seconds
>> remaining
>> 07:01:32-08/07 zebraidx(314) [log] Merge 99.9% completed; 0 seconds
>> remaining
>> 07:01:38-08/07 zebraidx(314) [log] Iterations: isam/dict
>> 301420236/21553295
>> 07:01:38-08/07 zebraidx(314) [log] Dict: inserts/updates/deletions:
>> 21553295/0/0
>> 07:01:42-08/07 zebraidx(314) [log] Records: 702954 i/u/d 702954/0/0
>> 07:01:42-08/07 zebraidx(314) [log] zebra_stop: 20557.86 6312.50 1447.43
>>
>> Search works on every biblio, except ones after 702955.
>>
>>
>> --
>> Paul POULAINhttp://www.biblibre.com
>> Expert en Logiciels Libres pour l'info-doc
>> Tel : (33) 4 91 81 35 08
>>
>> _______________________________________________
>> Koha-devel mailing listKoha-devel at lists.koha-community.orghttp://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>>
>>
>> _______________________________________________
>> Koha-devel mailing list
>> Koha-devel at lists.koha-community.org
>> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>>
>
>
>
> --
> Ian Walls
> Lead Development Specialist
> ByWater Solutions
> Phone # (888) 900-8944
> http://bywatersolutions.com
> ian.walls at bywatersolutions.com
> Twitter: @sekjal
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20100715/60c981da/attachment.htm>

From fridolyn.somers at gmail.com  Fri Jul 16 09:04:37 2010
From: fridolyn.somers at gmail.com (Fridolyn SOMERS)
Date: Fri, 16 Jul 2010 09:04:37 +0200
Subject: [Koha-devel] Fwd: RE: rebuild_zebra and a limit at 700 000
	biblios
In-Reply-To: <AANLkTimzR3jhDz3u4uRMTH9zzeCLMAvsWOIPqWNSs-Ni@mail.gmail.com>
References: <4C3F7D93.5040802@biblibre.com>
	<AANLkTin7lOo7bLggqTOWscsFoua7se6hzruwn5RXflAn@mail.gmail.com> 
	<AANLkTimzR3jhDz3u4uRMTH9zzeCLMAvsWOIPqWNSs-Ni@mail.gmail.com>
Message-ID: <AANLkTil5LdtFUlHai2aBBTm5wzxYnSSOfVnX4EmJRWvP@mail.gmail.com>

I have a 300 000 biblios and it works fine with 16G.

I propose a trick to count exported bibios from the database :

   1. Use -x in rebuild_zebra.pl to export in xml
   2. Use -k to keep exported file
   3. Run rebuild_zebra.pl
   4. Go into export folder : /tmp/XXX/biblio
   5. Run this command : cat exported_records | grep "<datafield
   tag=\"090\"" | wc -l

Assuming koha biblionumber is stored in field 090.

Good luck.

2010/7/15 Fouts, Clay <cfouts at ptfs.com>

> The zebraidx program would fail loudly with a descriptive error if you
> exceeded either the configured allocation or available disk space. Some
> thing else is going on here.
>
> I would first confirm that all the expected records are actually in the
> export file.
>
> Clay
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>



-- 
Fridolyn SOMERS
Information and Communication Technologies engineer
+33(0)6.86.63.77.68
fridolyn.somers at gmail.com
-------------- section suivante --------------
Une pi?ce jointe HTML a ?t? nettoy?e...
URL: </pipermail/koha-devel/attachments/20100716/fbf68d96/attachment.htm>

From robin at catalyst.net.nz  Mon Jul 19 07:17:58 2010
From: robin at catalyst.net.nz (Robin Sheat)
Date: Mon, 19 Jul 2010 17:17:58 +1200
Subject: [Koha-devel] New Debian packages and new Debian packages maintainer.
Message-ID: <1279516678.11711.51.camel@zarathud>

Hi folks,

I've taken over maintenance of the Debian Koha packages, and just did my
first upload to them. These packages track the git master branch, and
I'll be updating them every so often, hopefully about once a week or so.
Perhaps more if I get the whole process into one script.

Anyway, if you've been using these packages, Debian will probably start
complaining that the signature has changed. The key that I'm using has
the details:

pub   1024D/A99CEB6D 2004-09-26 [vervaldatum: 2012-09-21]
      Vingerafdruk van de Sleutel = 5957 6D23 8B16 EFAB FEF8  7175 14D3
6485 A99C EB6D
uid                  Robin Sheat <robin at kallisti.net.nz>
uid                  Robin Sheat <robin at ufies.org>
uid                  Robin Sheat (work) <robin at catalyst.net.nz>
uid                  Robin Sheat <robin.sheat at member.fsf.org>
sub   2048g/DF7647FD 2004-09-26 [vervaldatum: 2012-09-21]

To tell Debian it's OK to use, run:

wget -O- http://debian.koha-community.org/koha/gpg.asc | sudo apt-key
add -

(all on one line.)

Don't forget to file bugs if you discover any issues with the packages,
I'm slowly learning how this whole packaging process works.

-- 
Robin Sheat
Catalyst IT Ltd.
? +64 4 803 2204
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Dit berichtdeel is digitaal ondertekend
URL: </pipermail/koha-devel/attachments/20100719/e66e6f89/attachment.pgp>

From nengard at gmail.com  Mon Jul 19 14:56:34 2010
From: nengard at gmail.com (Nicole Engard)
Date: Mon, 19 Jul 2010 08:56:34 -0400
Subject: [Koha-devel] system preference question (anonymous preferences)
In-Reply-To: <d35b50d40912230641m2650f2cfk873adcd6ec4e65be@mail.gmail.com>
References: <d35b50d40912230449l55917589yfc6ff62668c0e110@mail.gmail.com> 
	<4B321F57.5080602@biblibre.com>
	<d35b50d40912230603w35a95b5aia51414b7a92637b8@mail.gmail.com> 
	<d35b50d40912230641m2650f2cfk873adcd6ec4e65be@mail.gmail.com>
Message-ID: <AANLkTilssTmMj0ljVf4toMGfPaH53CCLtgb9Ia6brjXp@mail.gmail.com>

I'm bumping this discussion up because  AnonSuggestions  used to take
a patron ID number, and now it says 'allow' or 'don't allow' has
anyone tested to see if this works the way it says it should?

On Wed, Dec 23, 2009 at 10:41 AM, Nicole Engard <nengard at gmail.com> wrote:
> Further information.
>
> There is a preference 'suggestion' that can be turned on or off to
> allow or not allow purchase suggestions in the OPAC. ?In addition
> there is AnonSuggestion to make those suggestions (if they are
> allowed) anonymous - leaving set to zero disables - but entering a
> userID enables.
>
> AnonymousPatron is then the ID of a patron you want to display in the
> reading history instead of the real patron.
>
> Unfortunately these are 2 different things and should be handled as
> such in the code.
>
> Nicole
>
> On Wed, Dec 23, 2009 at 9:03 AM, Nicole Engard <nengard at gmail.com> wrote:
>> I agree - lots of preferences - but just because i want my reading
>> history anonyimized I may want to gather names for purchase
>> suggestions - which is why I say we need 2.
>>
>> Nicole
>>
>> On Wed, Dec 23, 2009 at 8:47 AM, Paul Poulain <paul.poulain at biblibre.com> wrote:
>>> Nicole Engard a ?crit :
>>>> There are 2 system preferences in my most recent version of HEAD:
>>>>
>>>> ?- AnonSuggestions -- Set to anonymous borrowernumber to enable
>>>> Anonymous suggestions
>>>>
>>>> ?- AnonymousPatron -- Set the identifier (borrowernumber) of the
>>>> 'Mister anonymous' patron. Used for Suggestion and reading history
>>>> privacy
>>>>
>>>> Does this mean that AnonSuggestions is not used? ?I personally think
>>>> we need both and that Anon should be for suggestions and
>>>> AnonymousPatron for reading history.
>>>>
>>>> Can someone please clarify these for me?
>>>>
>>> iirc, I added the AnonymousPatron, and used it for suggestions as well
>>> (in my patch for reading history opt-in). I think we don't need 2
>>> different sysprefs (we already have too many !)
>>>
>>> HTH
>>>
>>> --
>>> Paul POULAIN
>>> http://www.biblibre.com
>>> Expert en Logiciels Libres pour l'info-doc
>>> Tel : (33) 4 91 81 35 08
>>>
>>> _______________________________________________
>>> Koha-devel mailing list
>>> Koha-devel at lists.koha.org
>>> http://lists.koha.org/mailman/listinfo/koha-devel
>>>
>>
>

From oleonard at myacpl.org  Mon Jul 19 15:10:21 2010
From: oleonard at myacpl.org (Owen Leonard)
Date: Mon, 19 Jul 2010 09:10:21 -0400
Subject: [Koha-devel] system preference question (anonymous preferences)
In-Reply-To: <AANLkTilssTmMj0ljVf4toMGfPaH53CCLtgb9Ia6brjXp@mail.gmail.com>
References: <d35b50d40912230449l55917589yfc6ff62668c0e110@mail.gmail.com>
	<4B321F57.5080602@biblibre.com>
	<d35b50d40912230603w35a95b5aia51414b7a92637b8@mail.gmail.com>
	<d35b50d40912230641m2650f2cfk873adcd6ec4e65be@mail.gmail.com>
	<AANLkTilssTmMj0ljVf4toMGfPaH53CCLtgb9Ia6brjXp@mail.gmail.com>
Message-ID: <AANLkTim-LLmcKFOBVsjGEVQmynLSioaVaecMx1gvBdv6@mail.gmail.com>

> I'm bumping this discussion up because ?AnonSuggestions ?used to take
> a patron ID number, and now it says 'allow' or 'don't allow' has
> anyone tested to see if this works the way it says it should?

Seems to work. With AnonSuggestions set to "allow" I can navigate to
/cgi-bin/koha/opac-suggestions.pl without a login prompt. With it set
to "don't allow" I'm asked to log in.

  -- Owen


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

From nengard at gmail.com  Mon Jul 19 15:31:33 2010
From: nengard at gmail.com (Nicole Engard)
Date: Mon, 19 Jul 2010 09:31:33 -0400
Subject: [Koha-devel] system preference question (anonymous preferences)
In-Reply-To: <AANLkTim-LLmcKFOBVsjGEVQmynLSioaVaecMx1gvBdv6@mail.gmail.com>
References: <d35b50d40912230449l55917589yfc6ff62668c0e110@mail.gmail.com> 
	<4B321F57.5080602@biblibre.com>
	<d35b50d40912230603w35a95b5aia51414b7a92637b8@mail.gmail.com> 
	<d35b50d40912230641m2650f2cfk873adcd6ec4e65be@mail.gmail.com> 
	<AANLkTilssTmMj0ljVf4toMGfPaH53CCLtgb9Ia6brjXp@mail.gmail.com> 
	<AANLkTim-LLmcKFOBVsjGEVQmynLSioaVaecMx1gvBdv6@mail.gmail.com>
Message-ID: <AANLkTinmxggMq4ZTetffQNJqiZ1J-9FGF0Sw83Ss7zjZ@mail.gmail.com>

Okey Dokey - good to know.

On Mon, Jul 19, 2010 at 9:10 AM, Owen Leonard <oleonard at myacpl.org> wrote:
>> I'm bumping this discussion up because ?AnonSuggestions ?used to take
>> a patron ID number, and now it says 'allow' or 'don't allow' has
>> anyone tested to see if this works the way it says it should?
>
> Seems to work. With AnonSuggestions set to "allow" I can navigate to
> /cgi-bin/koha/opac-suggestions.pl without a login prompt. With it set
> to "don't allow" I'm asked to log in.
>
> ?-- Owen
>
>
> --
> Web Developer
> Athens County Public Libraries
> http://www.myacpl.org
>

From colin.campbell at ptfs-europe.com  Tue Jul 20 13:46:26 2010
From: colin.campbell at ptfs-europe.com (Colin Campbell)
Date: Tue, 20 Jul 2010 12:46:26 +0100
Subject: [Koha-devel] git bisect
Message-ID: <4C458C92.8060500@ptfs-europe.com>

A handy introduction to using git bisect to track down bugs:
> http://www.effectiveperlprogramming.com/blog/date/2010/07


C.

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

http://www.ptfs-europe.com

From magnus at enger.priv.no  Thu Jul 22 13:43:45 2010
From: magnus at enger.priv.no (Magnus Enger)
Date: Thu, 22 Jul 2010 13:43:45 +0200
Subject: [Koha-devel] Default MARC dialect
In-Reply-To: <AANLkTikOzK_BZfuxGcRV8ikaEtNng9ly_j5R04RQ43rW@mail.gmail.com>
References: <AANLkTikOzK_BZfuxGcRV8ikaEtNng9ly_j5R04RQ43rW@mail.gmail.com>
Message-ID: <AANLkTil9_u5zwphtOv7iyEnwjIeSHSh0x6ka09cToZb3@mail.gmail.com>

Hi all!

During my quest to add support for NORMARC (the Norwegian dialect of
MARC) to Koha, I have come across several places[1] where UNIMARC is
treated as the default if MARC21 is not specified. Here is an example
from the subroutine GetMarcNotes in C4/Biblio.pm:

1268 ? ? if ( $marcflavour eq "MARC21" ) {
1269 ? ? ? ? $scope = '5..';
1270 ? ? } else { ? ?# assume unimarc if not marc21
1271 ? ? ? ? $scope = '3..';
1272 ? ? }

When $marcflavour is "NORMARC" this fails, because NORMARC is more
similar to MARC21 than to UNIMARC. I can think of two solutions to
this:

1. Add NORMARC to the conditional:

if ( $marcflavour eq "MARC21" ||?$marcflavour eq "NORMARC" ) {
? ?$scope = '5..';
} else { ? ?# assume unimarc if not marc21
? ?$scope = '3..';
}

2. Reverse the logic:

if ( $marcflavour eq "UNIMARC" ) {
? ?$scope = '3..';
} else { ? ?# assume marc21 if not unimarc
? ?$scope = '5..';
}

I would prefer the second solution, because

- in all the places I have found this situation it would be resolved
by this solution, because NORMARC is so similar to MARC21
- as far as I know there are more MARC dialects that resemble MARC21
than there are dialects that resemble UNIMARC, so this solution would
perhaps make it easier to add more dialects in the future

If anyone has a completely different solution or pro/con arguments
they would like to add I'm all ears!

Regards,
Magnus Enger
libriotech.no

PS. Just for the record: I'm no fan of NORMARC and would prefer if
Norwegian libraries started using MARC21, but for Koha to be accepted
in Norway it needs to support NORMARC...

Notes:
[1] http://wiki.github.com/MagnusEnger/KohaNor/existing-files

From jwagner at ptfs.com  Thu Jul 22 13:47:56 2010
From: jwagner at ptfs.com (Jane Wagner)
Date: Thu, 22 Jul 2010 07:47:56 -0400
Subject: [Koha-devel] Default MARC dialect
In-Reply-To: <AANLkTil9_u5zwphtOv7iyEnwjIeSHSh0x6ka09cToZb3@mail.gmail.com>
References: <AANLkTikOzK_BZfuxGcRV8ikaEtNng9ly_j5R04RQ43rW@mail.gmail.com> 
	<AANLkTil9_u5zwphtOv7iyEnwjIeSHSh0x6ka09cToZb3@mail.gmail.com>
Message-ID: <c8132c943bcbd5a025baa1593fa57683@mail.gmail.com>

Wouldn't a better solution be to build in a check for the syspref
marcflavour, then act accordingly?  I'm assuming you're adding NORMARC to
that as an option.  That might be more flexible in the long run, as others
add other MARC variants.

Jane Wagner
Library Systems Analyst
PTFS Inc.
Content Management and Library Solutions
6400 Goldsboro Road, Suite 200
Bethesda, MD  20817
(301) 654-8088 x 151
jwagner at ptfs.com

-----Original Message-----
From: koha-devel-bounces at lists.koha-community.org
[mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Magnus
Enger
Sent: Thursday, July 22, 2010 7:44 AM
To: koha-devel at lists.koha-community.org
Subject: [Koha-devel] Default MARC dialect

Hi all!

During my quest to add support for NORMARC (the Norwegian dialect of
MARC) to Koha, I have come across several places[1] where UNIMARC is
treated as the default if MARC21 is not specified. Here is an example
from the subroutine GetMarcNotes in C4/Biblio.pm:

1268 ? ? if ( $marcflavour eq "MARC21" ) {
1269 ? ? ? ? $scope = '5..';
1270 ? ? } else { ? ?# assume unimarc if not marc21
1271 ? ? ? ? $scope = '3..';
1272 ? ? }

When $marcflavour is "NORMARC" this fails, because NORMARC is more
similar to MARC21 than to UNIMARC. I can think of two solutions to
this:

1. Add NORMARC to the conditional:

if ( $marcflavour eq "MARC21" ||?$marcflavour eq "NORMARC" ) {
? ?$scope = '5..';
} else { ? ?# assume unimarc if not marc21
? ?$scope = '3..';
}

2. Reverse the logic:

if ( $marcflavour eq "UNIMARC" ) {
? ?$scope = '3..';
} else { ? ?# assume marc21 if not unimarc
? ?$scope = '5..';
}

I would prefer the second solution, because

- in all the places I have found this situation it would be resolved
by this solution, because NORMARC is so similar to MARC21
- as far as I know there are more MARC dialects that resemble MARC21
than there are dialects that resemble UNIMARC, so this solution would
perhaps make it easier to add more dialects in the future

If anyone has a completely different solution or pro/con arguments
they would like to add I'm all ears!

Regards,
Magnus Enger
libriotech.no

PS. Just for the record: I'm no fan of NORMARC and would prefer if
Norwegian libraries started using MARC21, but for Koha to be accepted
in Norway it needs to support NORMARC...

Notes:
[1] http://wiki.github.com/MagnusEnger/KohaNor/existing-files
_______________________________________________
Koha-devel mailing list
Koha-devel at lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel

From jwagner at ptfs.com  Thu Jul 22 13:49:00 2010
From: jwagner at ptfs.com (Jane Wagner)
Date: Thu, 22 Jul 2010 07:49:00 -0400
Subject: [Koha-devel] Default MARC dialect
In-Reply-To: <c8132c943bcbd5a025baa1593fa57683@mail.gmail.com>
References: <AANLkTikOzK_BZfuxGcRV8ikaEtNng9ly_j5R04RQ43rW@mail.gmail.com> 	
	<AANLkTil9_u5zwphtOv7iyEnwjIeSHSh0x6ka09cToZb3@mail.gmail.com> 
	<c8132c943bcbd5a025baa1593fa57683@mail.gmail.com>
Message-ID: <7d623596a6f8432cd8d4f4a93cd7b106@mail.gmail.com>

Ooops, sorry, read too fast -- you're already checking marcflavor.  It's
too early in the morning....



Jane Wagner
Library Systems Analyst
PTFS Inc.
Content Management and Library Solutions
6400 Goldsboro Road, Suite 200
Bethesda, MD  20817
(301) 654-8088 x 151
jwagner at ptfs.com


-----Original Message-----
From: Jane Wagner [mailto:jwagner at ptfs.com]
Sent: Thursday, July 22, 2010 7:48 AM
To: Magnus Enger; koha-devel at lists.koha-community.org
Subject: RE: [Koha-devel] Default MARC dialect

Wouldn't a better solution be to build in a check for the syspref
marcflavour, then act accordingly?  I'm assuming you're adding NORMARC to
that as an option.  That might be more flexible in the long run, as others
add other MARC variants.

Jane Wagner
Library Systems Analyst
PTFS Inc.
Content Management and Library Solutions
6400 Goldsboro Road, Suite 200
Bethesda, MD  20817
(301) 654-8088 x 151
jwagner at ptfs.com

-----Original Message-----
From: koha-devel-bounces at lists.koha-community.org
[mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Magnus
Enger
Sent: Thursday, July 22, 2010 7:44 AM
To: koha-devel at lists.koha-community.org
Subject: [Koha-devel] Default MARC dialect

Hi all!

During my quest to add support for NORMARC (the Norwegian dialect of
MARC) to Koha, I have come across several places[1] where UNIMARC is
treated as the default if MARC21 is not specified. Here is an example
from the subroutine GetMarcNotes in C4/Biblio.pm:

1268 ? ? if ( $marcflavour eq "MARC21" ) {
1269 ? ? ? ? $scope = '5..';
1270 ? ? } else { ? ?# assume unimarc if not marc21
1271 ? ? ? ? $scope = '3..';
1272 ? ? }

When $marcflavour is "NORMARC" this fails, because NORMARC is more
similar to MARC21 than to UNIMARC. I can think of two solutions to
this:

1. Add NORMARC to the conditional:

if ( $marcflavour eq "MARC21" ||?$marcflavour eq "NORMARC" ) {
? ?$scope = '5..';
} else { ? ?# assume unimarc if not marc21
? ?$scope = '3..';
}

2. Reverse the logic:

if ( $marcflavour eq "UNIMARC" ) {
? ?$scope = '3..';
} else { ? ?# assume marc21 if not unimarc
? ?$scope = '5..';
}

I would prefer the second solution, because

- in all the places I have found this situation it would be resolved
by this solution, because NORMARC is so similar to MARC21
- as far as I know there are more MARC dialects that resemble MARC21
than there are dialects that resemble UNIMARC, so this solution would
perhaps make it easier to add more dialects in the future

If anyone has a completely different solution or pro/con arguments
they would like to add I'm all ears!

Regards,
Magnus Enger
libriotech.no

PS. Just for the record: I'm no fan of NORMARC and would prefer if
Norwegian libraries started using MARC21, but for Koha to be accepted
in Norway it needs to support NORMARC...

Notes:
[1] http://wiki.github.com/MagnusEnger/KohaNor/existing-files
_______________________________________________
Koha-devel mailing list
Koha-devel at lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel

From paul.poulain at biblibre.com  Thu Jul 22 14:07:23 2010
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Thu, 22 Jul 2010 14:07:23 +0200
Subject: [Koha-devel] Default MARC dialect
In-Reply-To: <AANLkTil9_u5zwphtOv7iyEnwjIeSHSh0x6ka09cToZb3@mail.gmail.com>
References: <AANLkTikOzK_BZfuxGcRV8ikaEtNng9ly_j5R04RQ43rW@mail.gmail.com>
	<AANLkTil9_u5zwphtOv7iyEnwjIeSHSh0x6ka09cToZb3@mail.gmail.com>
Message-ID: <4C48347B.2080303@biblibre.com>

Le 22/07/2010 13:43, Magnus Enger a ?crit :
> Hi all!
>
> 2. Reverse the logic:
>
> if ( $marcflavour eq "UNIMARC" ) {
>    $scope = '3..';
> } else {    # assume marc21 if not unimarc
>    $scope = '5..';
> }
>
> I would prefer the second solution
>   
++, it's definetly the way to go.

-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08


From paul.poulain at biblibre.com  Sat Jul 24 07:14:46 2010
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Sat, 24 Jul 2010 07:14:46 +0200
Subject: [Koha-devel] Release Manager : how long (open question)
Message-ID: <4C4A76C6.60506@biblibre.com>

Hi koha-devel,

Chris announced that he planned to release a version every 6 months. I'm
for a "time based" release management, that's the same thing.

Chris has been elected as RM for Koha 3.4 but what will happend in "6
months" when 3.4 is released ? Will we elect a new RM immediatly for
3.6, that will be RM only for 6 months as well.
I don't think it would be a good idea to change the RM every 6 months...
So, shouldn't the RM be elected for a duration instead of for a version
? it's an open question, so let's start the thread about that...

Some ideas :
- 2 years or 3 major releases, the 1st that happend
- 2 years
- 1 year, that can be continued once (ie : after 1 year : vote to
confirm the RM. If not confirmed, then, new elections)
- unlimited duration, confirmed every year
- ...

-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08


From chris at bigballofwax.co.nz  Sat Jul 24 09:56:10 2010
From: chris at bigballofwax.co.nz (Chris Cormack)
Date: Sat, 24 Jul 2010 19:56:10 +1200
Subject: [Koha-devel] Release Manager : how long (open question)
In-Reply-To: <4C4A76C6.60506@biblibre.com>
References: <4C4A76C6.60506@biblibre.com>
Message-ID: <AANLkTikSrKZD2zRTXasP4o+uraCreZCoNiG8cwaQcU4U@mail.gmail.com>

On 24 July 2010 17:14, Paul Poulain <paul.poulain at biblibre.com> wrote:
> Hi koha-devel,
>
> Chris announced that he planned to release a version every 6 months. I'm
> for a "time based" release management, that's the same thing.

More like I plan to release 3.4 around 6 months after starting it.
Rather than planning to release a version every 6 months ;)
>
> Chris has been elected as RM for Koha 3.4 but what will happend in "6
> months" when 3.4 is released ? Will we elect a new RM immediatly for
> 3.6, that will be RM only for 6 months as well.
> I don't think it would be a good idea to change the RM every 6 months...
> So, shouldn't the RM be elected for a duration instead of for a version
> ? it's an open question, so let's start the thread about that...
>
> Some ideas :
> - 2 years or 3 major releases, the 1st that happend
> - 2 years
> - 1 year, that can be continued once (ie : after 1 year : vote to
> confirm the RM. If not confirmed, then, new elections)
> - unlimited duration, confirmed every year
> - ...
A lot of that of course depends on what the RM wants, in my past
experience it isn't a very fun job and takes a lot of time. I'm sure
the others who have served as release managers/maintainers would
agree. I'm not sure I'd be up for doing 2 releases in a row, and I
actually think it might be good to change the release manager often. I
think working on making the transition easy and making the RM's duties
less onerous is the way to go and then shift the duties around each 6
months would be good.

I'm very happy to see Owen's blog post about how he works with
branches, http://www.myacpl.org/koha/?p=558, if people work like this
the RM duties become less difficult.

Chris

From jrafaelantonio at gmail.com  Mon Jul 26 00:32:55 2010
From: jrafaelantonio at gmail.com (Rafael Antonio)
Date: Sun, 25 Jul 2010 23:32:55 +0100
Subject: [Koha-devel] To define default 9xx fields for Unimarc setup in
	all languages
In-Reply-To: <20100713135544.1593146DF2@eliot.biblibre.com>
References: <20100713135544.1593146DF2@eliot.biblibre.com>
Message-ID: <AANLkTinn=nXm45sYLu=cJ=u0pFU2NKXkS9KRVP9Lztdk@mail.gmail.com>

Zeno,

I fully agree with your comments. We have followed these tags for Portuguese
setup but I strongly recommend to have compatible local fields regarding
their impact on PERL scripts.
Regards,

Rafael Antonio

On Tue, Jul 13, 2010 at 2:55 PM, Zeno Tajoli <tajoli at cilea.it> wrote:

> Hi to all
>
> I sent this mail to different Koha-mailing list because the topic is quite
> wide.
> If you are also on koha-dev list, replaty to this list.
> Instead replay on koha general list.
>
> I send the mail also to koha-france because many user of Unimarc are
> French.
> But I don't know French, please replay to koha general list or to koha-dev.
>
> Today the complete Unimarc setups are the English and French,
> As I know Italian,  Ukrain, Russian and Poland setups are direct
> translation of
> English or Frence setup
>
> But on local fields English and French are not compatible.
> Many 9xx fields need to be the same in different languages because the
> indexes
> definitions in the file etc/zebradb/marc_defs/unimarc/biblios/record.abs
> are based on specific 9xx values.
> And the file record.abs is only one for all Unimarc setup
>
> So my proposal, for 3.2 and also [if possible ] for 3.0.x
>
> We re-write English setup in 9xx fields and we use it
> a minimun and a standard that ALL unimarc setups need to follow.
> It means that we need same change also to French setup.
>
> I want to discuss with everyone about this topic.
> I will write all the patch to fix the situation.
>
> So my proposal:
>
> Fields:
>
> 001        Local number -> biblio.biblionumber
> 090$a      Local number -> biblioitems.biblioitemnumber
> 099$c      date of creation -> biblio.datecreated
> 099$d      Date/time last modified -> biblio.timestamp
>
> 995$0   Withdrawn status -> items.wthdrawn
> 995$2     Lost status -> items.itemlost
> 995$3   Use restrictions -> items.restricted
> 995$5   Date acquired -> items.dateaccessioned
> 995$6   Copy number ->  items.copynumber
> 995$7   URI -> items.uri
> 995$8   Koha collection -> items.ccode
> 995$9   Internal item number -> items.itemnumber
> 995$a   Homebranch (free text) ->items.homebranch
> 995$b   Homebranch (coded)
> 995$d   Holding branch (free text) -> items.holdingbranch
> 995$d   Holding branch (coded)
> 995$e   Shelving location-> items.location
> 995$f    Barcode -> items.barcode
> 995$j    Inventory number -> items.stocknumber [only 3.2]
> 995$k   Call number -> items.itemcallnumber,
> 995$l    Numbering (volume or other part) -> items.materials
> 995$m  Date of loan or deposit -> items.datelastborrowed
> 995$n   Expiration of loan date -> items.onloan
> 995$o   Circulation type (not for loan) -> items.notforloan
> 995$r    Type of item and material -> items.itype
> 995$v    Serial Enumeration / chronology -> items.enumchron [only serials]
> 995$u    Copy note -> items.itemnotes
>
> 942$0   Koha issues (borrowed), all copies -> biblioitems.totalissues
> 942$2   Source of classification or shelving scheme ->
> biblioitems.cn_source
> 942$6   Koha normalized classification for sorting -> biblioitems.cn_sort
> 942$c   Koha [default] item type -> biblioitems.itemtype
> 942$s   Serial record flag -> biblio.serial
>
>
>
> 1)Fields 001 and 090$a, BIB Identifier in two places
> As French setup, to ahve a correct Unimarc we need BIB id in two places:
> 001 -> biblio.biblionumber
> 090 $9 -> biblioitems.biblioitemnumber
> biblio.biblionumber and biblioitems.biblioitemnumber must be numerir,
> we need to stress this fact in data conversions
>
>
>
> 2)Field 995 as item field with those subfields:
> This proposal is full compatible with French Unimarc
> setup and it has also the items subfields that are mandatory for
> circulation,
>  inventory, acquisitions and serials.
>
>
> 3)Field 942 as biblio/item field.
> This field is new for all unimarc setup, in english unimarc setup
>  there is 990 but 990 is similar, not identical.
> I select 942 instead of 990 because 990 is present in French setup with a
> specific meaning.
> I ask to French people to accept to put biblioitems.totalissues in 942$0,
> it is the base of the
> popularity index. Now the base of popularity index is in 995$s.
>
>
> This proposal is only a minimum, if you think there are others 9xx
> fields/subfields
> that MUST be present in every setup, please replay.
>
> If you want to discuss it, please replay.
>
> Bye to all
>
> Zeno Tajoli
>
> Zeno Tajoli
> CILEA - Segrate (MI)
> tajoliAT_SPAM_no_prendiATcilea.it
> (Indirizzo mascherato anti-spam; sostituisci quanto tra AT con @)
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20100725/bc86cdc2/attachment.htm>

From nengard at gmail.com  Mon Jul 26 19:09:27 2010
From: nengard at gmail.com (Nicole Engard)
Date: Mon, 26 Jul 2010 13:09:27 -0400
Subject: [Koha-devel] Deprecated System Preferences
Message-ID: <AANLkTinh6U9Z4wOwzO99XBUH=aUX-GOe81KAkEf+KHhA@mail.gmail.com>

Hello all,

There is a discussion going on on this bug report:
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3756
regarding deprecated preferences and the fact that they still show in
Koha.  I want to submit a patch (as is suggested) to remove these
preferences, but I need confirmation that they are in fact deprecated.
 Below is the list of preferences can you all chip in and tell me
which are really deprecated so that I don't delete something
important?  Some of these I think we do need but never made it to the
new sys prefs interface ... others I remember reading were deprecated.

acquisitions
AnonymousPatron
AutoEmailPrimaryAddress
BakerTaylorPassword
BranchTransferLimitsType
defaultSortOrder
FrameworksLoaded
holdCancelLength
ILS-DI:AuthorizedIPs
kohaspsuggest
libraryAddress
marc
MIME
OAI-PMH:Set
OAI-PMH:Subset
OpacCloud
OPACdefaultSortOrder
OPACDisplayExtendedSubInfo
OPACNoResultsFound
OPACRerunSearch
OPACSubscriptionDisplay
OrderPdfTemplate
pdfformat
PINESISBN
printcirculationslips
RandomizeHoldsQueueWeight
sortbynonfiling
SyndeticsCoverImageSize
TemplateEncoding
Version
z3950AuthorAuthFields



Thanks a ton,
Nicole C. Engard

From pianohacker at gmail.com  Mon Jul 26 20:26:23 2010
From: pianohacker at gmail.com (Jesse)
Date: Mon, 26 Jul 2010 12:26:23 -0600
Subject: [Koha-devel] Deprecated System Preferences
In-Reply-To: <AANLkTinh6U9Z4wOwzO99XBUH=aUX-GOe81KAkEf+KHhA@mail.gmail.com>
References: <AANLkTinh6U9Z4wOwzO99XBUH=aUX-GOe81KAkEf+KHhA@mail.gmail.com>
Message-ID: <AANLkTimphZinKEzi6QogkZh1iBb9LOAZmmdha5cMC2nP@mail.gmail.com>

I recognize a fair number of these from the sysprefs rewrite. I
checked the source and omitted them, and left a comment in the source.
Anything mentioned as deprecated or broken in the comments at the top
of the .pref files is confirmed not to do anything as of a few months
ago.

2010/7/26, Nicole Engard <nengard at gmail.com>:
> Hello all,
>
> There is a discussion going on on this bug report:
> http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3756
> regarding deprecated preferences and the fact that they still show in
> Koha.  I want to submit a patch (as is suggested) to remove these
> preferences, but I need confirmation that they are in fact deprecated.
>  Below is the list of preferences can you all chip in and tell me
> which are really deprecated so that I don't delete something
> important?  Some of these I think we do need but never made it to the
> new sys prefs interface ... others I remember reading were deprecated.
>
> acquisitions
> AnonymousPatron
> AutoEmailPrimaryAddress
> BakerTaylorPassword
> BranchTransferLimitsType
> defaultSortOrder
> FrameworksLoaded
> holdCancelLength
> ILS-DI:AuthorizedIPs
> kohaspsuggest
> libraryAddress
> marc
> MIME
> OAI-PMH:Set
> OAI-PMH:Subset
> OpacCloud
> OPACdefaultSortOrder
> OPACDisplayExtendedSubInfo
> OPACNoResultsFound
> OPACRerunSearch
> OPACSubscriptionDisplay
> OrderPdfTemplate
> pdfformat
> PINESISBN
> printcirculationslips
> RandomizeHoldsQueueWeight
> sortbynonfiling
> SyndeticsCoverImageSize
> TemplateEncoding
> Version
> z3950AuthorAuthFields
>
>
>
> Thanks a ton,
> Nicole C. Engard
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>


-- 
Jesse Weaver

From robin at catalyst.net.nz  Tue Jul 27 00:59:08 2010
From: robin at catalyst.net.nz (Robin Sheat)
Date: Tue, 27 Jul 2010 10:59:08 +1200
Subject: [Koha-devel] Building Debian packages
Message-ID: <1280185148.11711.88.camel@zarathud>

As I mentioned a little while back, I've started maintaining the Koha
Debian packages. It occurred to me that some of you may want to make
your own for internal use or whatever, so I've put the process I use to
make them up on the wiki:

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

It'll need a fair bit of adaptation, as currently it's pretty customised
to my configuration, and deployment of the debian.koha-community.org
packages, but all the important steps are there.

-- 
Robin Sheat
Catalyst IT Ltd.
? +64 4 803 2204
GPG: 5957 6D23 8B16 EFAB FEF8  7175 14D3 6485 A99C EB6D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Dit berichtdeel is digitaal ondertekend
URL: </pipermail/koha-devel/attachments/20100727/56d9d45c/attachment.pgp>

From tajoli at cilea.it  Tue Jul 27 10:46:43 2010
From: tajoli at cilea.it (Zeno Tajoli)
Date: Tue, 27 Jul 2010 10:46:43 +0200
Subject: [Koha-devel] Deprecated System Preferences
In-Reply-To: <AANLkTinh6U9Z4wOwzO99XBUH=aUX-GOe81KAkEf+KHhA@mail.gmail.c
 om>
References: <AANLkTinh6U9Z4wOwzO99XBUH=aUX-GOe81KAkEf+KHhA@mail.gmail.com>
Message-ID: <20100727084644.45A2347167@eliot.biblibre.com>

At 19.09 26/07/2010, Nicole Engard wrote:
>Hello all,
>
>There is a discussion going on on this bug report:
>http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3756
>regarding deprecated preferences and the fact that they still show in
>Koha.  I want to submit a patch (as is suggested) to remove these
>preferences, but I need confirmation that they are in fact deprecated.
>  Below is the list of preferences

>Version [section "Admin"]
This preference is used in C4/Installer.pm an C4/Context.pm
It record the exact version of Koha. We need it to update Koha between
different version. Is not deprecated, as I know.
I don'r know it useful to not show it.

>z3950AuthorAuthFields [section "Cataloguing"]
It is used in cataloguing/addbiblio.pl and in acqui/neworderempty.pl.
Those scripts use the system preferences in two subroutines called 
"MARCfindbreeding".

Is a list of marc tags about authors. This list is different in 
Unimarc and in Marc21.
I think  we need to keep it.

Bye

Zeno Tajoli
CILEA - Segrate (MI)
tajoliAT_SPAM_no_prendiATcilea.it
(Indirizzo mascherato anti-spam; sostituisci quanto tra AT con @)


From ian.walls at bywatersolutions.com  Tue Jul 27 14:01:02 2010
From: ian.walls at bywatersolutions.com (Ian Walls)
Date: Tue, 27 Jul 2010 08:01:02 -0400
Subject: [Koha-devel] Deprecated System Preferences
In-Reply-To: <AANLkTinh6U9Z4wOwzO99XBUH=aUX-GOe81KAkEf+KHhA@mail.gmail.com>
References: <AANLkTinh6U9Z4wOwzO99XBUH=aUX-GOe81KAkEf+KHhA@mail.gmail.com>
Message-ID: <AANLkTi=_4G2-8oR3-SSvVAE_z3_bMdXLtf4RYYf6kze1@mail.gmail.com>

>
>
> OPACNoResultsFound
>
> If this is not in use, it should be, or something like it.  I know lots of
libraries who'd like to have a little more control over what is displayed
when no results are found in the OPAC (like links to ILL, suggestions, their
reference department, other places to search, etc.)



> RandomizeHoldsQueueWeight
>

This is used by misc/cronjobs/holds/build_holds_queue.pl and nowhere else,
same as StaticHoldsQueueWeight.  We should probably hang on to both of these
until a top-down rebuild of the Holds system can be planned and assessed.

Version needs to be kept in the database somewhere for upgrade purposes, but
it should be read-only in the staff interface, perhaps in the About section,
where the Koha version (for code) is kept.  It'd be nice to be able to
quickly compare the two numbers to make sure they're in sync.  It's possible
for the database to get ahead of the codebase, which can create all kinds of
unpredictable craziness.

Cheers,


-Ian

-- 
Ian Walls
Lead Development Specialist
ByWater Solutions
Phone # (888) 900-8944
http://bywatersolutions.com
ian.walls at bywatersolutions.com
Twitter: @sekjal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20100727/69535c89/attachment.htm>

From nengard at gmail.com  Tue Jul 27 14:06:53 2010
From: nengard at gmail.com (Nicole Engard)
Date: Tue, 27 Jul 2010 08:06:53 -0400
Subject: [Koha-devel] Deprecated System Preferences
In-Reply-To: <4c4e9cf4.e690d80a.18a5.ffffd1e4SMTPIN_ADDED@mx.google.com>
References: <AANLkTinh6U9Z4wOwzO99XBUH=aUX-GOe81KAkEf+KHhA@mail.gmail.com> 
	<4c4e9cf4.e690d80a.18a5.ffffd1e4SMTPIN_ADDED@mx.google.com>
Message-ID: <AANLkTinc5_FSaii-PuL3yg_K0pxRz_=omrkAryuPS1HF@mail.gmail.com>

On Tue, Jul 27, 2010 at 4:46 AM, Zeno Tajoli <tajoli at cilea.it> wrote:
>> Version [section "Admin"]
>
> This preference is used in C4/Installer.pm an C4/Context.pm
> It record the exact version of Koha. We need it to update Koha between
> different version. Is not deprecated, as I know.
> I don'r know it useful to not show it.

This one (if it must show) makes sense to show on Local Use or Admin.

Nicole

From asquared21 at gmail.com  Wed Jul 28 22:44:58 2010
From: asquared21 at gmail.com (Alex Jurgensen)
Date: Wed, 28 Jul 2010 13:44:58 -0700
Subject: [Koha-devel] Is There A Way To Request Data Via Another Web App
Message-ID: <ADA3000F-AB01-4647-A843-B1BCE35C19DA@gmail.com>

Hi All,

I am a new developer.

I have a web application that requires to be able to query Koha for a list of books that are checked out to a particular user,.

Is this exposed via an interface, or is reading it dirrectly from the database my best bet?

If reading the data that I need dirrectly from the database is the best solution, is there documentation that describes the layout of the databases?

Any help is greatly appreciated.

Hopefully I can contribute here.

Regards,
Alex,



From chris at bigballofwax.co.nz  Wed Jul 28 22:54:49 2010
From: chris at bigballofwax.co.nz (Chris Cormack)
Date: Thu, 29 Jul 2010 08:54:49 +1200
Subject: [Koha-devel] Is There A Way To Request Data Via Another Web App
In-Reply-To: <ADA3000F-AB01-4647-A843-B1BCE35C19DA@gmail.com>
References: <ADA3000F-AB01-4647-A843-B1BCE35C19DA@gmail.com>
Message-ID: <AANLkTik_-ZXqVbkHzixcASmRqY82w_HT6ypjLQ7vOuFO@mail.gmail.com>

On 29 July 2010 08:44, Alex Jurgensen <asquared21 at gmail.com> wrote:
> Hi All,
>
> I am a new developer.
>
> I have a web application that requires to be able to query Koha for a list of books that are checked out to a particular user,.
>
> Is this exposed via an interface, or is reading it dirrectly from the database my best bet?
>
> If reading the data that I need dirrectly from the database is the best solution, is there documentation that describes the layout of the databases?
>
> Any help is greatly appreciated.
>
>
Hi Alex

Look at the ilsdi.pl script in the opac
http://yourwebserver/cgi-bin/koha/opac/ilsdi.pl
That screen will give you some instructions how to use it.

Chris

From robin at catalyst.net.nz  Thu Jul 29 01:24:52 2010
From: robin at catalyst.net.nz (Robin Sheat)
Date: Thu, 29 Jul 2010 11:24:52 +1200
Subject: [Koha-devel] Building Debian packages
In-Reply-To: <AANLkTimu6Cv5bX4UrdBQSNBg0s_cpvQ61fg6rbDR2YvO@mail.gmail.com>
References: <1280185148.11711.88.camel@zarathud>
	<AANLkTimu6Cv5bX4UrdBQSNBg0s_cpvQ61fg6rbDR2YvO@mail.gmail.com>
Message-ID: <1280359492.11711.168.camel@zarathud>

Op woensdag 28-07-2010 om 10:17 uur [tijdzone -0300], schreef Tiago
Murakami:
> I install beta version of koha 3.2 in a Debian Squeeze as described in
> "Koha 3.2 on Debian Squeeze" -
> http://wiki.koha-community.org/wiki/Debian , but zebra don?t work. I
> tried on Ubuntu Lucid, as a described in Koha on Lucid using Koha
> packages and don?t work too.
> 
> Its necessary any other configuration for zebra? 

Which package did you install? 'koha' contains a standard configuration
and is useful to get a single instance up and running quickly, and
'koha-common' (which contains all the code and support scripts) allows a
more complex setup, at the expense of not giving you one up front.

If you use the 'koha' package, you'll need to set up the zebra-related
cron jobs and launch scripts yourself, as the site that it gives you
isn't hooked into the Koha site management system that koha-common on
its own uses.

My recommendation at the moment would be to just install koha-common,
and use the koha-create script to generate a single instance. What I
might do in the future when I get time is make the 'koha' package
install its default site in such a way that it gets managed by the
koha-common tools. This would mean that the koha-rebuild-zebra cron job
and such like magically happen.

In fact, I've created a bug:
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5071
so that this doesn't fall off my radar. I've also edited the wiki page
at http://wiki.koha-community.org/wiki/Koha_3.2_on_Debian_Squeeze to
hopefully clarify this.

-- 
Robin Sheat
Catalyst IT Ltd.
? +64 4 803 2204
GPG: 5957 6D23 8B16 EFAB FEF8  7175 14D3 6485 A99C EB6D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Dit berichtdeel is digitaal ondertekend
URL: </pipermail/koha-devel/attachments/20100729/4a9c6869/attachment.pgp>

From fridolyn.somers at gmail.com  Fri Jul 30 13:26:24 2010
From: fridolyn.somers at gmail.com (Fridolyn SOMERS)
Date: Fri, 30 Jul 2010 13:26:24 +0200
Subject: [Koha-devel] Is There A Way To Request Data Via Another Web App
In-Reply-To: <AANLkTik_-ZXqVbkHzixcASmRqY82w_HT6ypjLQ7vOuFO@mail.gmail.com>
References: <ADA3000F-AB01-4647-A843-B1BCE35C19DA@gmail.com> 
	<AANLkTik_-ZXqVbkHzixcASmRqY82w_HT6ypjLQ7vOuFO@mail.gmail.com>
Message-ID: <AANLkTinKTigruZhvf-j-gyCOURiVe=vRxjvh-N2Gs-U7@mail.gmail.com>

You may use C4/*.pm libraries to avoid recreating SQL queries.

On Wed, Jul 28, 2010 at 10:54 PM, Chris Cormack <chris at bigballofwax.co.nz>wrote:

> On 29 July 2010 08:44, Alex Jurgensen <asquared21 at gmail.com> wrote:
> > Hi All,
> >
> > I am a new developer.
> >
> > I have a web application that requires to be able to query Koha for a
> list of books that are checked out to a particular user,.
> >
> > Is this exposed via an interface, or is reading it dirrectly from the
> database my best bet?
> >
> > If reading the data that I need dirrectly from the database is the best
> solution, is there documentation that describes the layout of the databases?
> >
> > Any help is greatly appreciated.
> >
> >
> Hi Alex
>
> Look at the ilsdi.pl script in the opac
> http://yourwebserver/cgi-bin/koha/opac/ilsdi.pl
> That screen will give you some instructions how to use it.
>
> Chris
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>



-- 
Fridolyn SOMERS
Information and Communication Technologies engineer
+33(0)6.86.63.77.68
fridolyn.somers at gmail.com
-------------- section suivante --------------
Une pi?ce jointe HTML a ?t? nettoy?e...
URL: </pipermail/koha-devel/attachments/20100730/24a70676/attachment.htm>

From nengard at gmail.com  Fri Jul 30 13:40:02 2010
From: nengard at gmail.com (Nicole Engard)
Date: Fri, 30 Jul 2010 07:40:02 -0400
Subject: [Koha-devel] August Koha Newsletter: Call for Articles
Message-ID: <AANLkTim99HG3k4QmMn5cO9ey1CQvufYcJ+hmGqnXY4ft@mail.gmail.com>

It's that time again, the next newsletter will be published in 15
days.  I need any and all announcements/tips/tricks/news/koha events
sent to me by the 12th of August if I'm to get the newsletter out on
time.  Articles should be short and if you have a lot to say then send
along a link to the full article.  Remember you don't have to write a
whole lot, just a short 2 liner is A-OK!

Thanks in advance,
Nicole C. Engard