Re: [Koha-devel] Anybody still using tarballs?

[Galen Charlton via Koha-devel]

Hi,

On Tue, Nov 7, 2023 at 3:22 PM Jonathan Druart via Koha-devel <
koha-devel@lists.koha-community.org> wrote:

> I am suggesting removing the tarball from our release process. I don't
> think anybody is using it anyway.
> It's extra work for RMaints, and it does not seem necessary.
>

I know that there are some Koha libraries running on RedHat-derived
distributions. While such sites could in principle maintain their
installations from Git checkouts, they are a constituency of likey tarball
users.

Regards,

Galen
-- 
Galen Charlton
Implementation and IT Manager
Equinox Open Library Initiative
g...@equinoxoli.org
https://www.equinoxOLI.org
phone: 877-OPEN-ILS (673-6457)
direct: 770-709-5581
<http://evergreen-ils.org>
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : https://www.koha-community.org/
git : https://git.koha-community.org/
bugs : https://bugs.koha-community.org/

Re: [Koha-devel] borrower_message_preference_id reaches limit - quickfix?

[Galen Charlton]

Hi,

On Wed, Jan 4, 2023 at 4:28 AM Magnus Enger  wrote:
> Bug 32556 - borrower_message_preference_id reaches limit
> https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32556
>
> Has anyone else run into this, and found a quickfix that works?
>
> I tried dumping the database, changing the id columns from INT to
> BIGINT, but got a foreign key error when loading the database back in.

I responded in the bug, but it is possible to remove and recreate the
specific foreign key constraint that references
borrower_message_preference_id when changing the type of that column and
its referrer.

Regards,

Galen
--
Galen Charlton
Implementation and IT Manager
Equinox Open Library Initiative
g...@equinoxoli.org
https://www.equinoxOLI.org
phone: 877-OPEN-ILS (673-6457)
direct: 770-709-5581
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : https://www.koha-community.org/
git : https://git.koha-community.org/
bugs : https://bugs.koha-community.org/

Re: [Koha-devel] REST API should not advertise required permissions

[Galen Charlton]

Hi,

On Tue, Jan 3, 2023 at 7:58 PM David Cook  wrote:
> It seems to me that we should just stop at “Authorization failure”. While
it
> might be helpful for a dev to know what the required permissions are,
>  I think it would also be overly helpful for an attacker to know what
> permissions are required too, no?

I don't feel strongly about it, but lean towards including the details for
the sake of anybody trying to use the API. After all, the game is already
up if the attacker is able to grant additional permissions to the service
account.

This may be a stretch, but another advantage of including the details is to
reduce any temptation to assign the superlibrarian permission to a service
account "just to get it working".

Regards,

Galen
--
Galen Charlton
Implementation and IT Manager
Equinox Open Library Initiative
g...@equinoxoli.org
https://www.equinoxOLI.org
phone: 877-OPEN-ILS (673-6457)
direct: 770-709-5581
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : https://www.koha-community.org/
git : https://git.koha-community.org/
bugs : https://bugs.koha-community.org/

Re: [Koha-devel] Fundamental flaw in Koha REST API

[Galen Charlton]

Hi,

On Mon, Dec 5, 2022 at 5:40 PM David Cook  wrote:
> At the moment, it’s not widely used by Koha itself, so I don’t think
> it will be hard to remove from Koha, but any third-party integrations
> would need to refactor to use a different option.

This might not be a huge factor, though of course removing that header
should go through a deprecation procedure.

Specifically, upon skimming the results of a GitHub search of
"x-koha-query", the only uses I found outside of Koha itself were in
plugins published by a couple active community members.

Regards,

Galen
-- 
Galen Charlton
Implementation and IT Manager
Equinox Open Library Initiative
g...@equinoxoli.org
https://www.equinoxOLI.org
phone: 877-OPEN-ILS (673-6457)
direct: 770-709-5581
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : https://www.koha-community.org/
git : https://git.koha-community.org/
bugs : https://bugs.koha-community.org/

Re: [Koha-devel] debian.koha-community.org refusing connections from server

[Galen Charlton]

Hi,

On Tue, May 10, 2022 at 3:12 AM  wrote:

> Who manages the server that hosts debian.koha-community.org? It looks
> like it’s actively refusing connections from one of my Koha servers.
>
>
>
> Err:9 http://debian.koha-community.org/koha 20.11 InRelease
>
>   Could not connect to debian.koha-community.org:80 (67.220.127.145),
> connection timed out
>
>
>
> I was able to connect just fine from a different IP address, and that
> server can contact many other Apt repos.
>

That would be me. Please let me know the IP address of the server that was
getting blocked.

Regards,

Galen
-- 
Galen Charlton
Implementation and IT Manager
Equinox Open Library Initiative
g...@equinoxoli.org
https://www.equinoxOLI.org
phone: 877-OPEN-ILS (673-6457)
direct: 770-709-5581
<http://evergreen-ils.org>
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : https://www.koha-community.org/
git : https://git.koha-community.org/
bugs : https://bugs.koha-community.org/

Re: [Koha-devel] Biblio Auto-Increment location

[Galen Charlton]

Hi Bruce,

On Wed, May 4, 2022 at 4:16 PM Chris Cormack  wrote:
> There's a lot we can code around, cataloguing cats is definitely not one
:)

Is this the (adorable) miscreant in question?
https://twitter.com/augustanalib/status/973622037276012545

Regards,

Galen
--
Galen Charlton
Implementation and IT Manager
Equinox Open Library Initiative
g...@equinoxoli.org
https://www.equinoxOLI.org
phone: 877-OPEN-ILS (673-6457)
direct: 770-709-5581
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : https://www.koha-community.org/
git : https://git.koha-community.org/
bugs : https://bugs.koha-community.org/

Re: [Koha-devel] Thoughts on reloading Koha plugins

[Galen Charlton]

Hi,

On Wed, May 26, 2021 at 1:17 AM  wrote:

> Hmm interesting. I see instructions on setting up Wordpress with FastCGI
> but no comments about any impact that would have on plugins. Maybe they
> just don’t worry about it the same way most Koha folk don’t worry about it
> hehe.
>

As I recall, Zend Opcache has various settings to control if and when it
will recompile the PHP scripts in caches. Depending on what settings you
choose, in a FastCGI environment it can periodically check to see if a
script has been updated and update the cache if need be - or, if you
choose, never revalidate the cache, in which case you'd need to reload or
restart php-fpm after changing code.

Also, WordPress has code that tries to clear opcache. [1, 2]

[1]
https://developer.wordpress.org/reference/functions/wp_opcache_invalidate/
[2] https://core.trac.wordpress.org/ticket/36455

Regards,

Galen
-- 
Galen Charlton
Implementation and IT Manager
Equinox Open Library Initiative
g...@equinoxoli.org
https://www.equinoxOLI.org
phone: 877-OPEN-ILS (673-6457)
direct: 770-709-5581
<http://evergreen-ils.org>
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : https://www.koha-community.org/
git : https://git.koha-community.org/
bugs : https://bugs.koha-community.org/

Re: [Koha-devel] Koha Community Wordpress Accounts person

[Galen Charlton]

Hi,

I'll set up an account and send details to Michael directly.

Regards,

Galen

On Mon, Nov 30, 2020 at 2:02 PM Koha News  wrote:

> Not sure who is managing the Koha Community Wordpress installation but
> we need an account created for Michael Kuhn who is going to be taking on
> the newsletter.
>
> Thank you!
>
> Chad
>
> ___
> Koha-devel mailing list
> Koha-devel@lists.koha-community.org
> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>


-- 
Galen Charlton
Implementation and Services Manager
Equinox Open Library Initiative
phone:  1-877-OPEN-ILS (673-6457)
email:  g...@equinoxinitiative.org
web:  https://equinoxInitiative.org
direct: +1 770-709-5581
cell:   +1 404-984-4366
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Cleaning git project list

[Galen Charlton]

Hi,

On Tue, Sep 8, 2020 at 5:26 AM Jonathan Druart <
jonathan.dru...@bugs.koha-community.org> wrote:
> wip/koha-equinox.git Equinox work in progress     Galen Charlton

I confirm that this can go away.

Regards,

Galen
--
Galen Charlton
Implementation and Services Manager
Equinox Open Library Initiative
phone:  1-877-OPEN-ILS (673-6457)
email:  g...@equinoxinitiative.org
web:  https://equinoxInitiative.org
direct: +1 770-709-5581
cell:   +1 404-984-4366
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] KC apt server, time for an upgrade?

[Galen Charlton]

Hi,

On Thu, Jul 23, 2020 at 1:12 PM Galen Charlton 
wrote:
> Sure. I will proceed with bumping up the VM's Debian version over the
next few days.

It's now running Debian 8; I'll bump it up to 9 over the weekend.

Regards,

Galen
--
Galen Charlton
Implementation and Services Manager
Equinox Open Library Initiative
phone:  1-877-OPEN-ILS (673-6457)
email:  g...@equinoxinitiative.org
web:  https://equinoxInitiative.org
direct: +1 770-709-5581
cell:   +1 404-984-4366
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] KC apt server, time for an upgrade?

[Galen Charlton]

Hi,

On Thu, Jul 23, 2020 at 12:34 AM Mason James  wrote:

> can we make a plan to get the VM upgraded (or the repo moved) to
> debian/ubuntu stable
>

Sure. I will proceed with bumping up the VM's Debian version over the next
few days.

Regards,

Galen
-- 
Galen Charlton
Implementation and Services Manager
Equinox Open Library Initiative
phone:  1-877-OPEN-ILS (673-6457)
email:  g...@equinoxinitiative.org
web:  https://equinoxInitiative.org
direct: +1 770-709-5581
cell:   +1 404-984-4366
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Barcode duplicates is possible

[Galen Charlton]

Hi,

On Wed, Jan 30, 2019 at 11:05 AM Owen Leonard  wrote:
> Is there any form data *shouldn't* trim?

The only cases I can think of where leading or trailing whitespace should
be retained would be certain fixed fields in MARC records and subfields in
the the MARC21 010 field.

Regards,

Galen
--
Galen Charlton
Implementation and Services Manager
Equinox Open Library Initiative
phone:  1-877-OPEN-ILS (673-6457)
email:  g...@equinoxinitiative.org
web:  https://equinoxInitiative.org
direct: +1 770-709-5581
cell:   +1 404-984-4366
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] removing some projects from git.koha-community.org

[Galen Charlton]

Hi,

On Wed, Nov 14, 2018 at 8:48 AM Paul Poulain 
wrote:
> wip/koha-equinox.git Equinox work in progress     Galen Charlton
5 years ago

This one is disused and from Equinox's point of view does not need to be
retained.

Regards,

Galen
--
Galen Charlton
Implementation and Services Manager
Equinox Open Library Initiative
phone:  1-877-OPEN-ILS (673-6457)
email:  g...@equinoxinitiative.org
web:  https://equinoxInitiative.org
direct: +1 770-709-5581
cell:   +1 404-984-4366
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] no acces to debian.koha-community.org

[Galen Charlton]

Hi,

It is now back up.

Regards,

Galen

On Fri, Dec 1, 2017 at 9:37 AM, Galen Charlton
 wrote:
> Hi,
>
> I'm taking a look at this now; the VM appears to have fallen over after a DOS.
>
> Regards,
>
> Galen
>
> On Fri, Dec 1, 2017 at 9:36 AM, Laurent Ducos
>  wrote:
>> always closed, Port 80 seems closed
>>
>> telnet debian.koha-community.org 80
>> Trying 67.220.127.145...
>> 
>> timeout
>> Laurent Ducos
>> Administrateur Systèmes et Réseaux
>> 0974770716
>> 1 décembre 2017 15:28 "Michael Kuhn"  a écrit:
>>> Hi
>>>
>>>>> Since about 1 hour I do not have access to debian.koha-community.org from 
>>>>> our public ip
>>>>> 91.121.55.79
>>>>> Can you give us access again please?
>>>>> since others ip everything is ok
>>>
>>> Right now, http://debian.koha-community.org can be accessed again.
>>>
>>> Best wishes: Michael
>>> --
>>> Geschäftsführer · Diplombibliothekar BBS, Informatiker eidg. Fachausweis
>>> Admin Kuhn GmbH · Pappelstrasse 20 · 4123 Allschwil · Schweiz
>>> T 0041 (0)61 261 55 61 · E m...@adminkuhn.ch · W www.adminkuhn.ch
>>> ___
>>> Koha-devel mailing list
>>> Koha-devel@lists.koha-community.org
>>> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>>> website : http://www.koha-community.org
>>> git : http://git.koha-community.org
>>> bugs : http://bugs.koha-community.org
>> ___
>> Koha-devel mailing list
>> Koha-devel@lists.koha-community.org
>> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>> website : http://www.koha-community.org/
>> git : http://git.koha-community.org/
>> bugs : http://bugs.koha-community.org/
>
>
>
> --
> Galen Charlton
> Infrastructure and Added Services Manager
> Equinox Open Library Initiative
> phone:  1-877-OPEN-ILS (673-6457)
> email:  g...@equinoxinitiative.org
> web:  https://equinoxInitiative.org
> direct: +1 770-709-5581
> cell:   +1 404-984-4366



-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Open Library Initiative
phone:  1-877-OPEN-ILS (673-6457)
email:  g...@equinoxinitiative.org
web:  https://equinoxInitiative.org
direct: +1 770-709-5581
cell:   +1 404-984-4366
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] no acces to debian.koha-community.org

[Galen Charlton]

Hi,

I'm taking a look at this now; the VM appears to have fallen over after a DOS.

Regards,

Galen

On Fri, Dec 1, 2017 at 9:36 AM, Laurent Ducos
 wrote:
> always closed, Port 80 seems closed
>
> telnet debian.koha-community.org 80
> Trying 67.220.127.145...
> 
> timeout
> Laurent Ducos
> Administrateur Systèmes et Réseaux
> 0974770716
> 1 décembre 2017 15:28 "Michael Kuhn"  a écrit:
>> Hi
>>
>>>> Since about 1 hour I do not have access to debian.koha-community.org from 
>>>> our public ip
>>>> 91.121.55.79
>>>> Can you give us access again please?
>>>> since others ip everything is ok
>>
>> Right now, http://debian.koha-community.org can be accessed again.
>>
>> Best wishes: Michael
>> --
>> Geschäftsführer · Diplombibliothekar BBS, Informatiker eidg. Fachausweis
>> Admin Kuhn GmbH · Pappelstrasse 20 · 4123 Allschwil · Schweiz
>> T 0041 (0)61 261 55 61 · E m...@adminkuhn.ch · W www.adminkuhn.ch
>> ___
>> Koha-devel mailing list
>> Koha-devel@lists.koha-community.org
>> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>> website : http://www.koha-community.org
>> git : http://git.koha-community.org
>> bugs : http://bugs.koha-community.org
> ___
> Koha-devel mailing list
> Koha-devel@lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/



-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Open Library Initiative
phone:  1-877-OPEN-ILS (673-6457)
email:  g...@equinoxinitiative.org
web:  https://equinoxInitiative.org
direct: +1 770-709-5581
cell:   +1 404-984-4366
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Gender-neutral pronouns

[Galen Charlton]

Hi,

On Thu, Apr 20, 2017 at 10:59 AM, Paul Poulain
 wrote:
> I'll probably be poorly ranked here, but in my opinion there are more
> important things to fix in Koha... (randomly chosen: clean the wiki from
> severely outdated pages, test one of the 205 patches waiting for sign-off,
> improve documentation, investigate why we have 10 blockers or critical bugs
> open -without a patch-, one of them BZ14731 being >1yr old)

Well, folks remain free to set their personal priorities in how they
choose to contribute to Koha. Trying to be more inclusive by measuring
our words more carefully does not preclude working on bugs or updating
the wiki... and may also result in more potential contributors
deciding to stick around and pitch in.

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Open Library Initiative
phone:  1-877-OPEN-ILS (673-6457)
email:  g...@equinoxinitiative.org
web:  https://equinoxInitiative.org
direct: +1 770-709-5581
cell:   +1 404-984-4366
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] [Koha] Redundant infrastructure for Koha

[Galen Charlton]

Hi,

On Mon, Nov 7, 2016 at 4:36 PM, Michael Hafen  wrote:
> Has anyone tried access Zebra through a network socket instead of the unix
> one?  I was under the impression that that was possible.

It is, and it's as easy as changing the following lines in koha-conf.xml from:

unix:/var/run/koha/SITE/bibliosocket
unix:/var/run/koha/SITE/authoritysocket

to

tcp:HOST_OR_IP:PORT
tcp:HOST_OR_IP:ANOTHER_PORT

Of course, depending on how you arrange things, local tweaks to the
indexer jobs would be required to ensure that all of the copies of the
Zebra databases got updated.

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / Open Your Library
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] SPAM in bugzilla: what do we do ?

[Galen Charlton]

Hi,

On Thu, Sep 8, 2016 at 9:13 AM, Jonathan Druart
 wrote:
> The later:
> 17276, 17242, 17219, 17199, 17071, 17070, etc.

I have disabled the BZ accounts that filed those bugs, none of which
had any activity other than creating the spam.

If this turns out to be more than just a blip, there appears to be at
least one anti-spam extension we could try [1].

[1] https://github.com/mozilla-bteam/bmo/tree/master/extensions

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / Open Your Library
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Frameworks / DB constraints

[Galen Charlton]

Hi,

On Tue, Apr 19, 2016 at 11:16 AM, Tajoli Zeno  wrote:
> I'm agree on solution proposed by Jesse: creating the foreign key with ON
> DELETE SET NULL.

At the moment, biblio.frameworkcode doesn't permit NULL values, and
InnoDB doesn't support ON DELETE SET DEFAULT.  That doesn't mean that
we couldn't do more work so that frameworkcode IS NULL is fully
supported, but it's not *just* a matter of adding the FK.

I'm more in favor of either:

- adding a FK that does ON DELETE RESTRICT. For most databases, this
would require adding a row to biblio_framework whose frameworkcode is
the empty string.
- having the business logic take care of falling back to the default
framework when necessary.

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / Open Your Library
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Packing needs - status to add to bugzilla and the dashboard?

[Galen Charlton]

Hi,

On Wed, Mar 9, 2016 at 7:42 AM, Kyle Hall  wrote:

> Also, are you saying any newly packaged libraries *must* make it in to
> Debian?
>

No, I am not saying this.  I said this: "Furthermore, such packages must
meet Debian's licensing requirements."

We cannot Debian to accept a package, and we obviously have no particular
influence over Debian's release schedule. Consequently, hosting a package
either temporarily or permanently on debian.koha-community.org is a valid
option for us in case of technical disagreement with Debian or because we
want to require a package before it is available on Debian stable.  In the
long run, however, it is better that such hosting be temporary; as it saves
us work to have a dependency be part of Debian.

Why must packages meet the Debian requirements?
>

So that they have a chance of actually getting into Debian — and so that
Koha does not fall into the trap of requiring non-free dependencies for the
sake of developer convenience.

I should point out that this is not a new guideline.  From the wiki [1]:

"The Koha project is not going to redistribute a module just because it's
in CPAN"

At minimum, a CPAN module that is being considered for packaging must meet
the Debian Free Software Guidelines [2]; in my opinion, that is
non-negotiable given Koha's status as a GPL3+ project.  Of course, there
are a variety of technical requirements that a package must meet before it
would get accepted by Debian, but we have more flexibility there: we can
choose to host a package that is DFSG-complaint but is not quite yet ready
for prime-time... if we absolutely need to.


> This seems like it's adding yet another barrier to entry for new Koha
> developers.
>

Are new developers actually the primary source of suggestions that we add
new CPAN dependencies to Koha?

Regardless, there are a variety of competing aims at play here, and I
submit that the convenience of new developers -- or not so new developers
-- does not trump other considerations that include:

* keeping the number of dependencies (and thus, potential vectors for bugs
and security exposures) manageable. Each new dependency adds a maintenance
cost the project; not necessarily large in and of itself, but it adds up.
* ensuring Koha's stability for Debian users
* having some assurance that new dependencies are likely to work; if a CPAN
module is already packaged for Debian, there's at least some signal that
this is the case
* for that matter, easing the situation for folks running RHEL who are
restricted from installing CPAN modules willy-nilly; there are at least a
few such Koha users out there

Now we all need to be Debian package maintainers as well?
>

No. Somebody who wants to add a CPAN dependency that is not yet packaged
for Debian has several avenues to take (assuming that they've
triple-checked that a new dependency is actually necessary):

* they can package it themselves (and bluntly, in the case of paid
development that is conducted by a commercial entity, I do not view that as
an unreasonable expectation that they one way or another arrange to deal
with packaging new dependencies that they propose)
* they can make a request of various other developers in the Koha community
who have experience building packages -- it's not just me who can do it --
 although I note that a request works better than a demand.
* they can make a request of the Debian Perl Group [3], who are, by all
accounts, a pretty helpful bunch
* they can find a Debian Developer to contract with to build the package


> It seems like we're taking away one of the most powerful features of Perl,
> it's extensive library of available modules.
>

CPAN, as with anything else, is subject to Sturgeon's law; using existing
Perl packages helps provide a useful quality filter. As far as Debian is
concerned, there are almost 3,500 CPAN modules that are already packaged
for Jessie.  Does this cover everything? No, of course not; but I submit
that a project that already has over 150 CPAN dependencies should be
cautious about adding new ones.

[1]
https://wiki.koha-community.org/wiki/Building_Debian_Dependencies/Dependency_Guidelines
[2] https://en.wikipedia.org/wiki/Debian_Free_Software_Guidelines
[3] https://pkg-perl.alioth.debian.org/

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / Open Your Library
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Packing needs - status to add to bugzilla and the dashboard?

[Galen Charlton]

Hi,

On Tue, Mar 8, 2016 at 12:50 PM, Brendan Gallagher <
i...@bywatersolutions.com> wrote:

> Do we have a defined role description of responsibility of the Packaging
> Manager?  (I've only read Robin's posts to the mailing list before - is
> that it?)
>

We do now, seeded with my view of the position:

https://wiki.koha-community.org/wiki/Project_roles#Packaging_manager

On a side note, the overall page is new; I'm figuring that it might be a
useful exercise to outline minimum role responsibilities for all of the
named project positions.

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / Open Your Library
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Supported Debian versions

[Galen Charlton]

Hi,

On Tue, Mar 8, 2016 at 4:55 PM, Tomas Cohen Arazi 
wrote:
>
> If we introduced a sitemap generation wrapper script around sitemap.pl to
> make it work the-packages-way (what I worked on this morning), it would be
> great to just patch the apache-shared-opac.conf file, including either the
> configuration for the sitemap files, or an include for an extra file that
> deals with it. As we need generate sitemaps for each instance, we need a
> way to point it to the instance-specific sitemap directory. It would use a
> placeholder for the instance name so it works for already created instances.
> Right now, we need to let the users know how to patch their files.
>
> That's the main reason I asked. I can do it the same way we did for Plack,
> wrapping the include inside the = 2.4.8> condition anyway. Just
> asking.
>

Thanks for the example.  I'm not necessarily attached to the notion of
maintaining Wheezy support to the very end of its LTS period, but I don't
think that this specific case is worth abruptly de-supporting Wheezy
(although yes, Define sure will be handy).

Consequently, unless some other new dependency forces the issue, I suggest
that we consider doing the following:

- announce a deprecation of Wheezy support (or perhaps more precisely,
support for Apache < 2.4) with the release of 3.24
- officially de-support Wheezy in new releases starting with 3.26

In the long run, I'm willing to carve out a new repository slot to keep
3.24 going for Wheezy for as long as there is an RMaint willing to at least
handle security patches.

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / Open Your Library
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Supported Debian versions

[Galen Charlton]

Hi,

On Tue, Mar 8, 2016 at 1:13 PM, Tomas Cohen Arazi 
wrote:

> Will the next release support Debian Wheezy?
>

We'll have to see based on what the net new dependencies end up being.
Wheezy is set to be in LTS from 26th of April 2016 to 31st of May 2018, so
there would be some value in not forcing a mandatory major Debian upgrade
on users in order to use Koha 3.24, but I don't think that need be a firm
commitment on our parts.

At present, of course, you'll need Jessie to get Apache 2.4 and Plack
support; Jessie thus remains the minimum _recommended_ Debian version.

[1] https://wiki.debian.org/LTS/

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / Open Your Library
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Packing needs - status to add to bugzilla and the dashboard?

[Galen Charlton]

Hi,

On Tue, Mar 8, 2016 at 12:30 PM, Chris Cormack 
wrote:
>
> I don't think it's fair to push this all on the package manager. If a dev

introduces new dependencies that need packaging, it should be their
> responsibility to make sure this is done.
>

Indeed. I am willing to build *some* packages (and submit them to Debian),
but that willingness is decidedly not infinite.

The first question that somebody who proposes to add a new dependency
should ask themselves is this: is there a way to accomplish the task at
hand without adding a new dependency?  If not, can the task at hand be
accomplished using packages that are already in Debian stable?  If not,
does the dependency at least have an active third-party ITP (intent to
package) in the Debian bug tracker?

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / Open Your Library
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Proposal - Deal with modules versioning ($VERSION)

[Galen Charlton]

Hi,

On Thu, Mar 3, 2016 at 7:02 AM, Mark Tompsett  wrote:
> (a) removing $VERSION (except from Koha.pm, right?)

Right.

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Proposal - Deal with modules versioning ($VERSION)

[Galen Charlton]

Hi,

On Thu, Mar 3, 2016 at 4:08 AM, Jonathan Druart
 wrote:
> Well, they all can be removed with 2 sed basically.

Agreed, it wouldn't be a big deal to remove them in one fell swoop.

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Proposal - Deal with modules versioning ($VERSION)

[Galen Charlton]

Hi,

On Wed, Mar 2, 2016 at 9:56 AM, Jonathan Druart
 wrote:
> What are your thoughts? Are you more a, b, c, d or ... e?

I'm in favor of option a (remove $VERSION from internal modules) or
option e (drop PERL12 outright, but don't necessarily bother to remove
$VERSION from the existing modules).  I take this position on the
following basis:

- we don't explicitly promise that C4:: and Koha:: provide a _public_ API
- no, really, we don't; if we did, we would have been taking much more
care about keeping function and method signatures stable the past
decade
- any third-party code that nonetheless relies on Perl modules in C4::
and Koha:: should just check $Koha::VERSION
- if we want to provide a public API via a set of Perl modules, we're
of course free to do so, but should then keep questions of API
versioning segregated to a special namespace
- in light of all of the above considerations, any of the other
options requires effort that doesn't solve a particular problem

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] release-tools: get_bugs.pl and the --html switch

[Galen Charlton]

Hi,

On Fri, Feb 12, 2016 at 11:05 AM, Julian Maurice
 wrote:
> I think you should be able to push to release-tools.

I have now synced permissions in Gitolite so that all current RMs and
RMaints have permission to push to the release tools repository
(gitmas...@git.koha-community.org:release-tools).

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Introduce the use of Grunt or Gulp?

[Galen Charlton]

Hi,

On Thu, Feb 11, 2016 at 2:01 PM, Renvoize, Martin
 wrote:
> Am I missing something in the ' need for it to be packaged ' here?  aren't
> they Dev tools, to be used in a development type install during development?
>
> Then used in the build stage for producing packages.

Well, using them in the build stage is exactly the sticking point --
it would be preferable to not be dependent on build tools that aren't
themselves packaged for Debian.  To be clear, however, that isn't an
argument against folks using Grunt or Gulp to assist with front-end
development so long as what's directly needed for packaging and
production installs (such as minification and LESS compilation) can be
accomplished without requiring non-packaged tools (and as I mentioned
before, I'm willing to help with that).

> I'd suggest keeping the resultant files in git for the current build scripts
> to use for production builds for instance, and lean on the qa script to
> ensure they were created using the grunt processing.

I'm not in favor of this as a long-term solution, but I recognize that
continuing to do this (as we already do for the Bootstrap LESS files)
may be a work-around.

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Introduce the use of Grunt or Gulp?

[Galen Charlton]

Hi,

On Wed, Feb 10, 2016 at 9:35 AM, Owen Leonard  wrote:
> After a quick look at Jake I'm concerned that it is not as
> fully-featured or well-documented than Grunt or Gulp.

I agree, although for the specific purpose of compiling LESS,
minifying Javascript (and doing that dynamically for the purpose of a
dev setup), at first blush Jake looks like it might be sufficient.

> The wider
> adoption of Grunt and Gulp mean that there is a more vibrant array of
> plugins for each and discussion on the web to provide help and
> documentation.

Agreed — unfortunately, that has not (yet) translated into there being
Debian packages for them.

That said, there is a work-around that Debian packagers have used for
projects like jQuery: writing a custom build script strictly for use
by packaging and production installations from tarball that requires
only uglifyjs and packaged Node.js modules.  I might be willing to
write such a thing, and it could complement use of Grunt or Gulp for
folks actively contributing to front-end development.

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Introduce the use of Grunt or Gulp?

[Galen Charlton]

Hi,

On Tue, Feb 9, 2016 at 5:57 PM, Owen Leonard  wrote:
> Removing the generated files from git makes sense from a front-end
> developer's point of view, but I wonder if that doesn't create too
> many problems for packaging/installation

As far as *packaging* is concerned... I'd just as soon that no
generated files be retained in Git, and that we rely on the build
mechanism to generate them.

> as well as complicate things
> for developers who don't want to mess with generating those files when
> they're not touching the interface?

The tricky part is ongoing updates, although Jake (and Grunt and Gulp)
do have the ability to set up "watch tasks", meaning that it's
probably possible to set something up so that recompiling/reuglify-ing
can happen automatically.  Of course, some additional developer
documentation would need to be written.

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Introduce the use of Grunt or Gulp?

[Galen Charlton]

Hi,

On Sun, Feb 7, 2016 at 8:53 PM, Owen Leonard  wrote:
> I have some experience with Grunt, and have heard good things about
> Gulp. Has anyone else used either in their non-Koha projects?

Grunt is used by Evergreen's new web staff interface; while I can't
claim to be an expert in it, it gets the job done.

> Adopting them would introduce a little more complexity to the process
> of making client-side changes to Koha, and to be honest I'm not sure
> of the right way to incorporate the tools into our workflow.

>From a packaging point of view... I ended up down a rabbit hole. Grunt
itself is not packaged for Debian due to a long-standing issues with
one of its own devDependencies, JSHint [1]. I don't see any signs that
Gulp is packaged either.

Using Grunt would therefore present a problem: it would require a
build dependency that is not itself packaged for Debian.  I note that
Debian's package of jQuery includes a custom build script to avoid
using Grunt.

Jake [2] *is* packaged for Debian -- would that work for you as an
alternative, Owen?

> If there is interest I'd be happy to submit a patch introducing the
> process to the OPAC as a demonstration.

+1 for doing something, but see above.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673727
[2] https://github.com/jakejs/jake

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Discussion for Bug 14757 - Allow the use of Template Toolkit syntax for slips and notices

[Galen Charlton]

Hi,

On Fri, Feb 5, 2016 at 2:53 PM, Kyle Hall  wrote:
> I think if we are going to go with b, we should have the freedom to not be
> beholden to all the oddities and cruft of the current syntax. For this
> reason I am a fan of b.

+1 to b.

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Spam in IRC

[Galen Charlton]

Hi,

On Fri, Feb 5, 2016 at 2:35 AM, Mirko Tietgen  wrote:
> It would be nice to have somebody with op
> rights for EU mornings.

Following discussion in #koha this morning, I've added Mirko to the
list of folks able to become op.  For reference, the list now stands
at:

1: gmcharlt MASTER
2: rangi MASTER
3: slef MASTER
4: wizzyrea MASTER
5: bag CHANOP
6: cait CHANOP
7: chris_n CHANOP
8: drojf CHANOP
9: jcamins CHANOP
10: magnuse CHANOP

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Discussion for Bug 14757 - Allow the use of Template Toolkit syntax for slips and notices

[Galen Charlton]

Hi,

On Wed, Feb 3, 2016 at 8:56 AM, Kyle Hall  wrote:
> I think Jonathan has an excellent plan of attack, but it does require a
> complete switchover all at once.

Rather than forcing a complete switchover right off the bat, I suggest
adding a flag that specifies whether old-style or TT templates are in
effect for a given notice.  That way, we'll have much more flexibility
to design the new templating mechanism to take full advantage of
Template Toolkit, and folks will have the ability to migrate their
notices definitions on their own schedule.

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Discussion for Bug 14757 - Allow the use of Template Toolkit syntax for slips and notices

[Galen Charlton]

Hi,

On Wed, Feb 3, 2016 at 7:18 AM, Marcel de Rooy  wrote:
> And perhaps harder: How do we
> guarantee that we do not loose the ability for librarians to add
> or edit notices? If you need "an expert" to do so, we went too far..

As a data point, part of Evergreen's infrastructure for generating
certain kinds of notices uses Template::Toolkit templates.  I can't
say whether or not that's a big barrier, but I do know that at least
some librarians have managed to edit their notices without requiring
much assistance.

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] RFC for a really new stuff : sharing data worldwide

[Galen Charlton]

Hi,

On Mon, Feb 1, 2016 at 7:27 AM, Frédéric Demians  wrote:
> Do we really need a Git repo for translation files since the authoring
> of translated strings is managed outside Git in Pootle?

I think there's some value in continuing to have one:

- in the (of course unlikely) event that the Pootle server completely
fails and cannot be restored, such a repository would serve as a
backup of last resort.  Likewise for the (even more unlikely) event
that somebody does major vandalism on a translation, as Pootle itself
does not have version control.
- the repository would enable reproducing a package or tarball, which
in turn would be useful for tracking down the occasional bug that
stems from an issue with one of the PO files.

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Jenkins (we want to move the server)

[Galen Charlton]

Hi,

On Fri, Jan 29, 2016 at 8:39 AM, Laurent Ducos
 wrote:
> 2 : migrate dns , the new IP is 212.47.240.49 galen can you do it? maybe
> Tuesday 2.

I spoke with Chris and he'll do it; just ping him.

> 4 i'ts possible to create a TLS certificat for https transaction ? CN
> jenkins.koha-community.org  ?? -> galen again ???

I can do that.

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] KohaCon16 - Registrations & Call for proposals Open

[Galen Charlton]

Hi,

On Mon, Jan 25, 2016 at 6:04 AM, Γιάννης Κουρμούλης 
wrote:
>
> Developers, technical support staff, librarians are invited to share their
> experience by contributing with a presentation proposal based on their
> knowledge, ideas, best practices and even mistakes! (Please note that all
> presentations will be in English).
>

Will proposals for remote presentations (i.e., via webinar) be considered?

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Hide records on Leader 05 = d in OPAC

[Galen Charlton]

Hi,

On Fri, Jan 15, 2016 at 12:46 AM, David Cook  wrote:
> I like the idea of just deleting records directly, but I think it's
> more complex than it appears at first glance. It's not just an
> issue with OAI-PMH either really. It's an issue any time you
> try to delete a record without providing feedback to an end-user.

I've got a question for you: for the specific project you're coding
for, which ends do you control? The Koha instance, the data provider
publishing via OAI-PMH, or both?

To make a general point: yep, there are definitely edge cases and
error conditions to consider when implementing a mechanism by which a
third party can specify that records should be deleted in a Koha
database. Some of those might be better solved by policy rather than
code; for example, if the OAI-PMH provider in some sense "owns" the
records that Koha ingests from it, does the Koha library need to a
have policy of not adding items to such records?  If so, it might be
appropriate to add an option that specifies that bib deletions are to
forcibly cascade.

Conversely, if it *is* legitimate for the Koha user to add items to
those records, does that mean that the OAI-PMH provider no longer has
"ownership"?

To make another general point: I think it would be better for the
consequences of record deletion to be handled *within the context of
OAI-PMH harvesting* (or more generally, mechanisms to sync records
with an external provider), but *not* to have those consequences spill
over for users who are not doing such harvesting as all.  Your
original proposal to unconditionally hide Leader/05='d' records from
the public catalog would be an example of such spillover.

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Merge borrowers and deletedborrowers tables

[Galen Charlton]

Hi,

On Wed, Jan 13, 2016 at 11:23 AM, Jonathan Druart
 wrote:
> Some of the existing constraints are wrong, some does not exist.
> On the 3 bug reports (see original message), I have submitted patches
> to add/fix the FK constraint, but we will loose data.
> The big advantage is... not to loose these data :)

That is not an unambiguous advantage: one's "losing" patron data is
another's "better protecting patron privacy".  Also, merging the two
tables will impose a cost on every user that has written reports that
query the borrowers table and will be faced with the task of
determining if they need to tack on "AND NOT deleted" clauses to the
queries.

That said, in Evergreen patron records do have a boolean flag that
expresses logical deletion status. That approach has generally worked,
but at the cost of requiring more code to fully delete and/or
anonymize records for patrons who no longer have any relationship with
the library.

Overall, I'm neutral on the design question of using one table or two;
I'm more dubious about the potential for disruption if we make a
change, since we're not starting from scratch here.

I note that the three bugs you've cited are concerned with the
deletion of *staff* user accounts.  A more minimal change might be to
treat staff accounts specially and devise a way to mark them inactive
instead of deleting them.

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Hide records on Leader 05 = d in OPAC

[Galen Charlton]

Hi,

On Sun, Jan 10, 2016 at 8:44 PM, David Cook  wrote:
> We can’t necessarily rely on all Koha instances running this cronjob, nor
> can we rely on the frequency. Shouldn’t we be hiding these records from the
> OPAC as soon as they’re marked as “deleted”?
>
> I’ve opened a bug for this purpose:
> http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15537

I am in mild disfavor of this proposal, particularly as implemented in
current patch. Using a cronjob to delete records where Leader/05 is
set to 'd' is useful when the library has arranged their workflow such
that they *know* that Leader/05 = 'd' is being used consistently to
signify that a record is no longer wanted. However, for a library that
has not hitherto cared about the values in that position,
unconditionally suppressing the display of such records could come as
an unwelcome surprise.

That said, it is also a reasonable choice for a library to want to use
the Leader/05 as suppression criterion.  Consequently, I suggest
adding a configuration option.  For that matter, making it
configurable (say, by allowing the library to specify a set of query
additions for the purpose of filtering records from public display)
could result in a more generally useful mechanism.

> I admit that I have a special interest in this where I might
> be overlaying existing records using a mostly empty skeleton
>  record generated from an OAI-PMH identifier and a OAI-PMH
> deleted status (OAI-PMH doesn’t send metadata for deleted records).
>  I’d match the existing record in Koha using the identifier, and
> then set LDR05 to “d” in accordance with the OAI-PMH deleted
> status. Then, that record would disappear from the OPAC, so that
> end users don’t see this skeleton record.

I do not find this a compelling use case as stated.  If the goal is to
allow harvesting and overlay records from an OAI-PMH provider to also
delete bibs from a Koha database... coding so that the records are
*actually* deleted seems more direct.

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] easykoha update announed but downloads only 1.8 meg or 11 meg? where is whole

[Galen Charlton]

Hi,

On Tue, Dec 29, 2015 at 2:39 PM, Chris Cormack  wrote:
> * couryho...@aol.com (couryho...@aol.com) wrote:
>> easykoha update announced but  downloads only 1.8 meg  or 11  meg? where is
>> whole  thing?  koha  has to be  larger!/  i  got several update messages  
>> from
>> source forge on this  yesterday and today. Help anyone??  Ed Sharpe
>
> First off, what is easykoha? Where was it announced?

Is it this? http://sourceforge.net/projects/vkmkoha/files/?source=navbar

If so, it looks like the ISO file was updated in the past hour and may
be usable now (not that I can vouch for it).

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Update required to link on the Koha community website home page

[Galen Charlton]

Hi,

On Fri, Dec 25, 2015 at 4:12 PM, David Nind  wrote:
> On the https://koha-community.org/ home page the link to "Introducing Koha
> 3.22" should link to https://koha-community.org/koha-3-22-released/ (rather
> than https://koha-community.org/koha-3-22-0-released/ as it does not exist).

Thanks for the report; I have corrected the link.

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Perldoc website

[Galen Charlton]

Hi,

On Tue, Dec 22, 2015 at 8:47 AM, Nicolas Legrand
 wrote:
> I'm a bit puzzled by the web perldoc, some changes are not effective
> on master.

It looks like that a while back an issue with the Git clone used for
generating the perldoc prevented updates from being fetched.  I've
corrected the issue and am regenerating the website now.

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] feature for bugzilla ?

[Galen Charlton]

Hi,

On Fri, Dec 18, 2015 at 4:34 AM, Paul Poulain  wrote:
> I was wondering if there could be an Addon, a feature, un plugin, or
> whatever, that could "obsolete" a comment. An obsoleted comment would be
> collapsed by default. Anyone can obsolete a comment, it's just to
> (hopefully) have a thread easier to read.

As it happens, Bugzilla 5 has a new feature to tag comments:

https://www.bugzilla.org/releases/5.0/release-notes.html#feat_comment_tags
https://wiki.mozilla.org/BMO/comment_tagging

Comment tags can be used to control visibility and whether a comment
is automatically expanded or not.  And as it happens... out-of-the-box
you can use the 'obsolete' tag to specify that a comment should be
un-expanded by default. Too convenient!

See the following bug for an example:

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

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] [Koha] Problem with BarcodeFallbackSearch

[Galen Charlton]

Hi,

On Wed, Dec 9, 2015 at 6:46 PM, Paul A  wrote:
> Enhancements, improvements and new features: a good starting point is the
> user list, (IRC?) and possibly the dev list. If there is consensus, this
> should be filed at ???  (similar to
> bugzilla)

It is hardly unusual for a "bugs" database to be used to record both
reports of defects with the software and requests for enhancements.
The Koha project has done so for years; procedures for doing are
documented in the project bug reporting guidelines [1].

Using Bugzilla for both bugs and enhancements serves the Koha
community by providing a single place where all requests for changes
to the software can be found -- and to consolidate multiple requests
for the same change.  It also gives us a way to readily reclassify
change requests; there are and will be plenty of grey areas where a
given request could reasonably considered either a bug or an
enhancement. Creating a separate database for enhancements, as you
appear to be suggesting, would make such reclassification more
difficult.

The existence of bugs.koha-community.org does not, of course, preclude
somebody from discussing a potential enhancement on the mailing list,
and doing so can be a useful way to gauge interest or find folks
interesting in collaborating in making an enhancement happen.
However, discouraging folks from using the bugs database would be a
disservice to the Koha community; given the number of users who are
interested in changes to Koha, *some* system for organizing requests
is needed. Bugzilla is not perfect, but it is what we have.

[1] http://wiki.koha-community.org/wiki/Bug_Reporting_Guidelines

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Link to the Current Stable Release is broken

[Galen Charlton]

Hi Stefano,

On Tue, Nov 3, 2015 at 4:13 AM, Stefano Bargioni  wrote:
> At page http://koha-community.org/download-koha/, the link to the "Current 
> Stable Release (.tar.gz)" 
> <http://download.koha-community.org/koha-latest.tar.gz> is broken.
> Thx. Stefano

I checked, and it looks like somebody corrected the link earlier today.

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] git commit messages

[Galen Charlton]

Hi,

On Wed, Sep 23, 2015 at 9:13 AM, Galen Charlton  wrote:
> I'm not sure that there's automation for putting the bug number in the
> subject line of the commit, but there's certainly automation (e.g.,
> the script that builds release notes) that depends on the bug number
> being there -- (and consequently, the release notes can answer your
> question about knowing in what versions a bugfix was applied, though I
> grant that additional indexing might be nice).

And to that end, here's a little script I put together just now:

http://git.koha-community.org/gitweb/?p=contrib/global.git;a=blob;f=index-release-notes/extract_bugs_from_koha_release_notes;hb=HEAD

extract_bugs_from_koha_release_notes: grab bug numbers from Koha
release notes

This script extracts bug numbers referenced by Koha release notes and
outputs a two-column list of version numbers and bugs.

It should be run from within a clone of the Koha Git repository; usage is:

  extract_bugs_from_koha_release_notes > bug_index

TODO: this script doesn't currently recognize every way that
  bugs have gotten cited by release notes.

Cheers,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] git commit messages

[Galen Charlton]

Hi,

On Wed, Sep 23, 2015 at 8:42 AM, Barton Chittenden
 wrote:
> 1) Convention (and possibly some koha programming standard) says that the
> bug number be included in the summary line of the commit message. Somewhere
> along the line, I assumed that this was an automated thing, so I left them
> off to avoid duplication :-/ (I'm in the process of fixing those). If we did
> want to automate this, where would we put it in the process?

I'm not sure that there's automation for putting the bug number in the
subject line of the commit, but there's certainly automation (e.g.,
the script that builds release notes) that depends on the bug number
being there -- (and consequently, the release notes can answer your
question about knowing in what versions a bugfix was applied, though I
grant that additional indexing might be nice).

I share Colin's preference for commit messages that describe the
change that the commit makes rather than the bug that the commit fixes
-- even more so when the commit message makes it clear how its effects
are visible to the user, and what, if anything, the user may need to
do about it.

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Cleaning up...

[Galen Charlton]

Hi,

On Fri, Sep 11, 2015 at 1:02 PM, Michael Hafen 
wrote:

> I would suggest the cleanup_database.pl script in the cronjobs directory,
> except I've just looked at it and it doesn't touch the import_items or
> import_biblios tables.
>

Actually, it does, via the --import DAYS switch and cascading deletes.

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] RFC: Reverting MARC batches with deleted records

[Galen Charlton]

Hi,

On Tue, Jun 23, 2015 at 12:39 PM, Kyle Hall  wrote:
> The question becomes, is this the correct thing to do? If a record is
> deleted, shouldn't it stay deleted?

My gut reaction: it should stay deleted, as there was presumably some
other intentional action taken at some point to delete it.

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] OPAC Validation error

[Galen Charlton]

Hi,

On Wed, Jun 10, 2015 at 8:24 AM, Owen Leonard  wrote:
> The last time I checked into it the answer is that you can't avoid the
> validation error. If I recall correctly, somewhere along the line the
> spec diverged from what others were implementing.

I can confirm that your understanding is correct.

> As long as it's providing us needed functionality and not breaking
> browsers, I say we ignore the error.

unAPI is still used by some applications, most notably Zotero.

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Issues with DBIx and nested transactions

[Galen Charlton]

Hi,

On Thu, Jun 4, 2015 at 1:13 PM, Tomas Cohen Arazi  wrote:
> to our (abuse?) of $dbh->{AutoCommit} = 0 on the tests.

Not abuse - one way or another, the DB-dependent tests really ought
not to be make permanent changes to the database.

> Before someone says it: reverting the commits will put us back to the
> previous state, of course. But it will just hide the problem for a while.

Time to revert regardless. :)

However, here's a diff that shows one way to get DBIx::Class and DBI
to stop fighting over who gets to control the transaction:
http://paste.lisp.org/display/149194

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] License question

[Galen Charlton]

Hi,

On Wed, Apr 29, 2015 at 8:36 PM, Mark Tompsett  wrote:
> While looking at bug 5685, I noticed the newer version is only licensed
> under MIT. Is that license compatible with the GPL3 that Koha is?

>From https://www.gnu.org/philosophy/license-list.html#Expat:

"This is a lax, permissive non-copyleft free software license,
compatible with the GNU GPL. It is sometimes ambiguously referred to
as the MIT License."

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] New coding guidelines on adding a syspref (INSERTIGNORE)

[Galen Charlton]

Hi,

On Tue, Apr 7, 2015 at 11:53 AM, Christopher Nighswonger
 wrote:
> A long time ago, when I first opened this bug, I had hoped to code up a sub
> which would handle the check to see if the pref existed or not. The thought
> was to avoid the use of MySQLisms.
>
> I would think that this is a quick-and-easy, have-it-today fix, with the
> ultimate goal to be DB agnostic.

'INSERT IGNORE' is grep-able enough for future munging into a
DB-agnostic solution.

+1 to encouraging use of 'insert ignore' for now.

-1 to rejecting patches on account of it; QAers should instead supply
follow-ups if needed.

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Git repository cleanup

[Galen Charlton]

Hi,

On Fri, Mar 27, 2015 at 11:55 AM, Tomas Cohen Arazi
 wrote:
> We have talked in the past about removing translation files from the git
> repo. For that to happen, we need to have a properly set translations
> repository, and a workflow modification (probably).
>
> Is there any work going on that direction?

Does a translations Git repository require any sort of special setup?
If not, creating the repo itself and giving the TM (and if needed for
the transition, RM & RMaints) push access would be trivial for me to
do.

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] New RESTful API

[Galen Charlton]

Hi,

On Fri, Mar 6, 2015 at 7:41 AM, Julian Maurice 
wrote:

> A proof-of-concept patch was made and is attached to Bug 13799 [2].
>

Are we ready to jump to requiring a minimum of Perl 5.18?  My read of the
Mojolicious FAQ [1] is that 5.18 and 5.20 are well supported at present,
while 5.10 is best effort.  "Best effort" for frameworks does not, however,
inspire great confidence in me.

This is by not necessarily a showstopper -- Debian Jessie will ship with
5.20, Ubuntu Trusty ships 5.18, and so forth -- but if we're not ready to
make the jump in Perl versions, I would suggest finding a different
framework to use.

[1]
http://mojolicio.us/perldoc/Mojolicious/Guides/FAQ#Which-versions-of-Perl-are-supported-by-Mojolicious

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Bugzilla and other sites outage

[Galen Charlton]

Hi,

On Sun, Mar 1, 2015 at 9:54 PM, Chris Cormack  wrote:
> Linode are rebooting all of their xen servers which will mean the VM that
> bugzilla and a bunch of other Koha sites and tools run on will disappear for
> a couple of hours.
>
> It will be rebooted at
> 2015-03-07 6:00:00 PM UTC
>
> They have allocated a 2 hour window, but it should not be down that long.

For similar reasons, the IRC bot huginn will be down during the reboot
of the Linode hosting it:

2015-03-08 9:00:00 PM UTC

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Fwd: Questionaire regarding Patron Privacy and Security

[Galen Charlton]

Hi,

On Wed, Nov 12, 2014 at 3:34 PM, Brendan Gallagher
 wrote:
> Can someone add info about LDAP to that list?  (someone with the correct
> technical terms that is ;) )

I've made an edit to the Etherpad to mention LDAP.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Ambiguous column names

[Galen Charlton]

Hi,

On Wed, Nov 12, 2014 at 10:35 AM, Chris Cormack
 wrote:
> I think we don't need to make columns unique across the whole db just when
> selecting do select borrowers.timestamp as something.
> DBIx::Class helps us with this also

I agree with Chris.  In legacy code, doing a "select *" from a join on
multiple tables is should be discouraged, so using the addition of a
new column to locate cases of these to stamp out is preferable.  The
alternative of using a distinct column name has the problem of making
the writing of more general templates and classes more difficult.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] What purpose do the 003 and 005 tageditor popup anchors serve?

[Galen Charlton]

Hi,

On Mon, Sep 8, 2014 at 9:28 AM, Indranil Das Gupta  wrote:
> The max role I can see for 003 tageditor link is to provide a link to
> set MarcOrgCode syspref but then that is handled elsewhere. Perhaps a
> z39.50 server list alike link to this page -
> http://www.loc.gov/marc/authority/ecadorg.html and its provider links?
>
> For example, 
> http://www.loc.gov/marc/organizations/org-search.php?org_keyword=L2C2+Technologies&submit=Search
> pulls up my data in the LOC Org code db. It could be wrapped into an
> impromptu API (as long as LOC does not change *their* db lookup
> process)
>
> Does something like that even make any sense? I'm just thinking aloud
> here (so I might be talking utter BS :P)

I think providing access to the whole LC organization code list would
be overkill unless you're using a Koha database as part of your
workflow to do contract cataloging for a bunch of libraries.

What might be useful for a consortium would be allowing more than one
value for MarcOrgCode.  In fact, that's already the topic of bug 10132
(MarcOrgCode would be useful on branch level). [1]

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

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] What purpose do the 003 and 005 tageditor popup anchors serve?

[Galen Charlton]

Hi,

On Sun, Sep 7, 2014 at 9:59 PM, Indranil Das Gupta  wrote:
> I noticed that 003 and 005 tageditors do not actually have a popup to
> back them up. That unlike LDR (000), 007, 008 the tags 003 and 005 do
> not call any window.open function and their respective
> Clictag_ functions are blank.
>
> what is the purpose for having these tageditor links around for these two?
>
> curious to know :)

There's no particular reason for these to have tageditor links - as
you surmise, the only action of the plugins is to populate (empty) 003
and 005 fields with default values.

Consequently, the links could be removed, as they do nothing --
although if we do that, perhaps there should be some alternative
visual indication that something special happens if one clicks in
those fields.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] SIP2 AF field sent even if patron password is invalid

[Galen Charlton]

Hi,

On Tue, Jul 29, 2014 at 8:35 AM, Kyle Hall  wrote:
> I have an interesting SIP2 implementation issue. When authenticating through
> SIP2, if a valid patron id is passed in, but an *invalid* password is passed
> in, Koha's SIP2 server send back the AF ( screen message ) field even though
> the credentials are invalid. If a patron owes any fees, the server will send
> back the amount owed in an AF field.

Sadly, it looks like the only provision that the SIP2 specification
makes for dealing with an invalid patron password is to set the CQ
field.  My reading of the spec is that the expected behavior regarding
other fields in the patron status and patron information responses is
undefined when an incorrect password is supplied.

> For instance, Overdrive will display this AF field even with an invalid
> password. Freegal does not ( but it may not display any AF field ). At least
> one SIP2 machine we tested against will also display the AF field when an
> invalid password is submitted.
>
> Is this a Koha issue, or a client side issue? The SIP2 protocol
> specification does not indicate that AF fields should be removed in the
> event of an invalid password. My guess is that some SIP2 server
> implementations may send back "Invalid password" messages which may be
> useful.

Possibly.  In any event, I think we should either not send an AF, or
send one that contains something like "Invalid password" if the patron
password is wrong.

That leaves open the question about what to do with other fields,
particularly in the patron information response.  My feeling is that
we should be conservative: if a patron password is sent via patron
status or patron information requests, and it's wrong, no information
about the patron should be returned.  There may need to be a
configuration option controlling this behavior.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] RFC: /svc/ API

[Galen Charlton]

Hi,

On Tue, Jul 22, 2014 at 5:11 PM, David Cook  wrote:
> +1 to a versioned API. I don't think that I use it for anything at the
> moment, but I'm not 100% sure about all our apps. I think we might have a
> third-party one that uses it.

Also +1 to a versioned API.

> This script should probably also use PUT, but I have no idea if OCLC
> Connexion supports that.

I don't believe it matters as far as Connexion is concerned, as it
only talks to connexion_import_daemon.pl via a raw socket.

> Since there are an indeterminate number of third-party software systems
> using the existing API, I'd recommend versioning and using v2 to handle
> things more RESTfully.

MarcEdit is one program I know that uses the current API to inject
records into a Koha database.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] The schema of DBIx::Class is not up-to-date

[Galen Charlton]

Hi,

On Mon, Jul 7, 2014 at 7:10 AM, Yohann Dufour
 wrote:
> I joined with this email the list of the differences between the DBIx::Class
> schema and the current database schema.

I believe that the difference in the generated schema classes can be
accounted for by the fact that you're using a newer version of
DBIx::Class::Schema::Loader.

When I was RM for 3.16, I was using DBIC::Schema::Loader version
v0.07025.  Yesterday Tomas and I did some checking of classes
generated using v0.07039.  Among other changes, the newer versions now
recognize "set null" as a FK action and default to "restrict" rather
than "cascade" if the action is not explicitly specified.

Those are both good changes, so I recommend that we require at least
version v0.07039 of DBIC::Schema::Loader.  Since that module is /not/
required for production use -- it's only needed for development --
requiring a hire version should not affect packaging signficantly.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Advise on DBIx

[Galen Charlton]

Hi

On Fri, Jul 4, 2014 at 11:16 AM, Tomas Cohen Arazi  wrote:
> it dies because "No such relationship Deletedbiblioitem on Deletedbiblio".
> How shuold we cope with that situation? (I understand introducing a
> relationship would mean a lot of trouble as the tables are intended for
> deleted / not hard-linked data).
>
> Any ideas? Plain SQL?

Briefly, you can declare the relationship relationships in the DBIC
class without there having to be a corresponding FK in the underlying
SQL. That said, if this query is something that would be used
frequently, adding a FK relationship would be fine, or at least an
index.

> P.S. Happy independence day for those that apply :-D

Thanks!

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Extending MARC::Charset::Table ?

[Galen Charlton]

Hi,

On Wed, Jun 4, 2014 at 11:56 AM, Philippe Blouin <
philippe.blo...@inlibro.com> wrote:

> We're using the MARC library for some migration, as usual, but we
> encountered some new issue with some arabic title: the key code 703
>   0x02BF 703 MODIFIER LETTER LEFT HALF RING ʿ   is not part of the Table
> db, which cause the whole subfield to disappear and causing us headaches.
>


What is the source character encoding of the records?  If the records are
already in UTF-8, then it is not necessary to transcode them to MARC8, then
back to UTF8 for loading into Koha.  Adding the following line to whatever
code you're using to pre-process the records might help:

MARC::Charset->assume_unicode(1);

As an alternative, you could adjust change the records to use 0x02bb rather
than 0x02bf.  I'm assuming that the strings in question are transliterated
Arabic following the ALA-LC Arabic romanization.  If so, back in 1999, the
mapping of the "ayn" character was changed from 0x02bf to 0x02bb. [1]

[1] http://www.loc.gov/marc/marbi/2005/2005-05.html

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

[Koha-devel] 3.16.x branched

[Galen Charlton]

Hi,

I've started the public branch for 3.16.x.  I will be pushing patches
to master and 3.16.x through Sunday; Tomás will take responsibility
for master starting on Monday.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Convert circ tables to AJAX - possible for 3.16.1 ?

[Galen Charlton]

Hi,

On Thu, May 22, 2014 at 1:30 AM, Fridolin SOMERS
 wrote:
> This enhancement looks like a little revolution in circulation,
> congratulations :D
>
> But it's big, and depends on Bug 11518, also enhancement.
> It will be not that easy to add in 3.14.x without generating bugs.

I agree.  -1 to backporting this to 3.14.x.

Backporting it to 3.16.x for inclusion to 3.16.1 stretches the rule of
"no major enhancements in maintenance releases" a bit, but does so in
the name of a worthy performance gain and and acknowledgment of the
consideration that there's only a month's span of time between the
release of 3.16.0 and 3.16.1.

Folks should consider bug 11703 impetus for upgrading to 3.16.1.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

[Koha-devel] Reminder - development meeting tomorrow

[Galen Charlton]

Hi,

As a reminder, the next development meeting is scheduled for tomorrow,
21 May 2014, at 15:00 UTC and 22:00 UTC.  The agenda can be found at

http://wiki.koha-community.org/wiki/Development_IRC_meeting,_21_May_2014

Of particular note, I know that Tomás would like to discuss plans for
3.18 during the meeting.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

[Koha-devel] RM transition note

[Galen Charlton]

Hi,

Just so folks know, Tomás and I discussed details of the RM handover
today.  The upshot is that after the release of 3.16.0 this Thursday,
I will go through the passed-QA queue and push patches to master and
3.16.x (as many of them will be wanted for 3.16.1 anyway).  Tomás will
begin pushing to master on Monday.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

[Koha-devel] Koha 3.16 release candidate available

[Galen Charlton]

Hi,

The release candidate for Koha 3.16 is now available for download at:

http://download.koha-community.org/koha-3.16.00-rc.tar.gz

Please test thoroughly.  General release, as a reminder, is scheduled
for this Thursday, 22 May.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Very big patch (over 1000 lines) -- SQL for MARC21

[Galen Charlton]

Hi,

On Tue, May 13, 2014 at 11:08 AM, Zeno Tajoli  wrote:
> What is it the best workflow to insert those SQL into git tree ?
>
> I can create a patch, but it will be very big (more that 1000 lines).

The size is fine.

> I see two option:
> a) I create the patch and I attach it to a bug in bugzilla, dimentions are 
> not a problem

Creating a patch and attaching it to the bug is what I recommend.

>  Someone sign-off/qa it as normal.
> b)I create a gzip with the .sql and I attach it to a bug in bugzilla, 
> sign-off and qa only writting a comment

Please do this only if generating a patch doesn't work for you for
whatever reason.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Removal of the prog and CCSR themes in 3.18

[Galen Charlton]

Hi,

On Mon, May 12, 2014 at 7:55 AM, Galen Charlton  wrote:
> Assuming that we don't change our minds, then as of now, there would
> be no requirement that new patches update the prog theme.

Also, I have opened bug 12233 for the removal of the themes.  Any
concerns about the mechanics of removing the deprecated themes should
probably go there.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

[Koha-devel] Removal of the prog and CCSR themes in 3.18

[Galen Charlton]

Hi,

Just as a reminder, here's a section from the release notes for 3.14.0:

"The 'prog' and 'CCSR' public catalog themes are deprecated as of the
release of Koha 3.14.0.  Existing Koha sites are encouraged to switch
to the Bootstrap theme as soon as convenient.  The 'prog' and 'CCSR'
OPAC themes are slated to be completely removed in the second major
release of Koha after 3.14.0, i.e., in the release currently
contemplated for November 2014."

That release currently contemplated for November 2014 is, of course, 3.18.0.

At this point, I'd like to request positive confirmation that folks
are still happy with that course of action; if we decide to change our
minds, we should do so prior to the release of 3.16.0.

Assuming that we don't change our minds, then as of now, there would
be no requirement that new patches update the prog theme.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

[Koha-devel] Koha 3.16 beta available; string freeze belong

[Galen Charlton]

Hi,

The beta release of Koha 3.16 is available from
http://download.koha-community.org/.  For more details, please see
http://koha-community.org/koha-3-16-beta-released/.

As of now, a string freeze is in effect.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Find the patch!

[Galen Charlton]

Hi,

On Thu, May 1, 2014 at 1:51 AM, Jonathan Druart
 wrote:
> Sometime it is very difficult to find a patch, because you don't have
> enough information on what you are searching for. This tool will allow
> you to find "Which patches modify this file [with which bug status]",
> "Which patches modify the GetBiblio routine", "What is the bigger
> patch modifying this file", etc.
>
> The link: it is hosted by the Koha community :
> http://splitter.koha-community.org/

This is very, very neat.  Thanks for making this!

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] 3.16 release calendar

[Galen Charlton]

Hi,

On Tue, Apr 8, 2014 at 2:58 PM, Galen Charlton  wrote:
> Wednesday, 30 April: beta release -- by the end of the day, I will
> clear the Passed QA queue and roll a beta release.  A soft string
> freeze will start upon release of the beta; at this point, translators
> can be confident that there won't be major string changes.
>
> Monday, 5 May: at the end of the day, a firm string freeze will
> beginning.  I will not call it a hard freeze, as security bugs and
> release blockers will trump string stability, but translators can
> expect that there will be no unnecessary changes.

I'm going to combine these two events.  In other words, I will release
the beta on Monday, and the firm string freeze will start then as
well.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Deprecating the Non-XSLT display on Detail and Search/List Results

[Galen Charlton]

Hi,

On Tue, Apr 29, 2014 at 12:40 AM, Magnus Enger  wrote:
> On 24 April 2014 05:12, David Cook  wrote:
>> What do people think about deprecating the non-XSLT display on detail and
>> search/list results pages?
>
> +1.
>
> I'm not overly fond of XSLT as such, but reducing complexity is good.

I really want to hear from current users on this one.

I've sent out a tweet, but I suggest that somebody who is strongly in
favor of the deprecation also raise the question on the mailing list
-- in particular, whether there are folks who intentionally do not use
the XSLT option. If the consensus is to announce a deprecation, we may
as well do so upon the release of 3.16.0.

Of course, because of bug 10134, somebody who started with 3.12.0 or
later would have had to intentionally turn the XSLT option off.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] March towards 3.16.0 #1

[Galen Charlton]

Hi,

On Wed, Apr 23, 2014 at 5:22 AM, Galen Charlton  wrote:
> If there are things that you believe are close and worthy of leeway,
> please reply to this thread.

The list of candidates for 3.16.0 can be found here:

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

This includes all bugs that have passed QA as of now as well as the
ones for which leeway is being granted.

Of course, patches that fix bugs may make it in to 3.16.0, but at this
point new features and enhancements that are not on this list should
have zero expectation of making it into the release.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Perl 5.18

[Galen Charlton]

Hi,

On Mon, Apr 28, 2014 at 7:43 AM, Tomas Cohen Arazi  wrote:
> The latest Ubuntu LTS release includes Perl 5.18. One of the main noticeable
> consequences of this is that some 5.10 features are now marked as
> experimental, and hence warnings appear everywhere.
>
> One example could be the use of '~~' (C4/Search.pm:536). These warnings can
> be avoided using the following pragma [1]:
>
> no if $] >= 5.018, 'warnings', "experimental::feature_name";

In my view, we should not use the pragma to hide the warning messages
-- we should remove use of the experimental constructs, including the
smartmatch operator.  There have already been a couple recent-ish
patches pushed [1] to remove uses of smartmatch.

This is because, as the link you included in your email states,
features that the Perl developers have marked as experimental are
subject to change, which could lead to surprises as future versions of
Perl get released.

I have opened a new bug [2] for removing the remaining uses of the
smartmatch operator, and I suggest that we add a new coding guideline
to this effect:

=== PERL19: The use of the Perl smartmatch operator is forbidden ===

The Perl smartmatch operator, including ~~ and given/when, has been
[http://perldoc.perl.org/5.18.0/perldelta.html#The-smartmatch-family-of-features-are-now-experimental
marked experimental] as of Perl 5.18.0.   Since the meaning of the
smartmatch operator is subject to change, and since using it will by
default add warnings to the error log, new code should not use it.

[1] Bugs 11468 and 11479
[2] http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12151

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] git-bz update

[Galen Charlton]

Hi,

On Thu, Apr 24, 2014 at 5:30 AM, Owen Leonard  wrote:
>> For those of us who had help installing git-bz in the first place,
>> could you point us to instructions on how to update?
>
> http://wiki.koha-community.org/wiki/Git_bz_configuration

In particular, if your git-bz installation was done per those
instructions, an update would be done by changing to the directory
containing the clone of the git-bz repository, then running "git
pull".

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Deprecating the Non-XSLT display on Detail and Search/List Results

[Galen Charlton]

Hi,

On Wed, Apr 23, 2014 at 8:12 PM, David Cook  wrote:
> What do people think about deprecating the non-XSLT display on detail and
> search/list results pages?

0.  Here follows some thinking aloud:

One of the main advantages of the XSLT display templates is that they
have full access to the entire metadata record, and as a consequence
it's possible to put in complicated display logic without having to
write custom Perl code.  This mattered quite a bit at the time that
XSLT display system was introduced because HTML::Template::Pro lacked
good support for things like filters and template functions. Removing
the non-XSLT templates would also make it possible to remove a fair
amount of code for extracting data from MARC records, as that could be
left to the XSLT templates.

The big downside is that XSLT is not particularly user-friendly,
particularly if you want to make changes that go beyond tweaking a
couple labels.  The verbosity of XSLT's syntax also can get in the way
of developers wanting to make changes.  However, the importance of
that consideration depends on an answer to a question that I, for one,
don't have a good sense of: how many Koha libraries actually make
major changes to their OPAC record displays?

Nowadays, if I were asked to put together a fresh set of OPAC
templates for Koha, I would probably do it via Template Toolkit, but
organized differently: the search results and bib details code would
just pass along metadata (for now MARC::Record) and item objects to
the template, and there would be a site of helper functions available
for grabbing display values.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

[Koha-devel] March towards 3.16.0 #1

[Galen Charlton]

Hi,

I apologize for calling the dev meeting, but not being able to attend
it, but I have other unavoidable responsibilities today.  Here is a
quick update on 3.16.x:

- Feature freeze is still end of Monday, 28 April in the PDT time
zone.  Any patch that reaches passed QA by that point will be
considered for 3.16.0.  As I mentioned before, I'm granting leeway to
the new cataloging editor; I will also grant leeway to multiple
transport type enhancements, as there are a number of separate bug
reports, some of which have not yet gone through QA.

If there are things that you believe are close and worthy of leeway,
please reply to this thread.

- I will not be cutting an alpha today after all, but will still cut a
testing release on 30 April.  I may call it alpha or beta depending on
how stable it feels to me.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

[Koha-devel] git-bz update

[Galen Charlton]

Hi,

A couple days ago the latest security release was applied to Koha's
Bugzilla installation.  The security update included changes to login
handling to protect against CSRF attacks; this happened to break
git-bz's ability to upload patches and modify bug information.

I've pushed a patch that restores git-bz's ability to authenticate to
the 'fishsoup' branch of git://git.koha-community.org/git-bz.  If you
use git-bz, please update now.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] KohaDates filter questions...

[Galen Charlton]

Hi,

On Mon, Mar 31, 2014 at 7:49 AM, Mark Tompsett  wrote:
> Glad to hear that either way works, but shouldn’t we aim for consistency?
> Should we not suggest a standard, even if we don’t enforce it?

-1 to making it a standard.  I have a personal preference for '=>'
over '=', but since TT accepts both forms, and I know of no
user-visible reasons to prefer one over the other, adding it to the
coding guidelines solely for the sake of consistency provides no real
benefit.

I note that with the possible exception of PERL1, none of the current
coding guidelines concern themselves solely with code styling
consistency.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Rename the repos?

[Galen Charlton]

Hi,

On Tue, Apr 15, 2014 at 10:28 AM, Mark Tompsett  wrote:
> Keeping reallyoldstable: -0
> -- I'm kind of on the fence. It would be great to install an older stable
> version, but what is the point of hosting it, when someone could follow the
> instructions on the wiki
> (http://wiki.koha-community.org/wiki/Building_Debian_Packages_-_The_Easy_Way,
> for example) and roll their own earlier distribution from a git
> installation.

By that logic, why should we host an APT repository at all?

The answer, of course, is to make supported versions of Koha easy to
install.  I think we should be leery of directing folks at
instructions on how to roll their own packages unless they are doing
development for Koha or are an entity that is providing their own
support for an officially unsupported version of Koha.

This ties into a broader question of how many versions we want to
support.  My view is that we "officially" support a version, we should
provide packages for it (depending of course, on the availability of
people and tools to build them).

> Renaming by version number: -1
> -- I don't think having to do the modifications gives us added benefits,
> does it?

Well, there's a potentially a rather big benefit: not surprising
somebody who is tracking stable with a major version upgrade,
particularly since Koha falls in the category of usually being the
primary reason why a given server/VM exists

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] A note about the squeeze-dev repo

[Galen Charlton]

Hi,

On Mon, Apr 14, 2014 at 11:45 PM, Robin Sheat  wrote:
> I've just updated the koha in squeeze-dev to the latest master. However
> this won't update automatically, as 3.15.1 was in there previously (to
> force an update for the security update a few months back), and now the
> version is back to 3.15~git...
>
> Prior to the security update, the version was 3.15-1, but due to a more
> strict enforcement of the debian policy in recent versions, we have to
> drop the -1 part.
>
> So, if you are using packages from master (for testing purposes only, of
> course :), you'll want to do:
>
> sudo apt-get install koha-common=3.15~*
>
> to force the "downgrade" to the current version.

Thanks!

I'd like to tack on a semi-related (or possibly not at all related)
question.  Should we consider adopting a different set of code
names/suites for our APT repository?  For example:

testing
stable
oldstable
(maybe) reallyoldstable

or perhaps go by version number (modified as needed to confirm with
any toolchain expectations about the format of the suite name)?

3.16.x
3.14.x
etc.

Doing this would avoid any implications about which particular OS
releases a given package can work with.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

[Koha-devel] Module maintainers

[Galen Charlton]

Hi,

Marcel had set up a page on the wiki for discussion about the role of
module maintainers, which currently can be found at

http://wiki.koha-community.org/wiki/Talk:What_does_a_module_maintainer_do

However, I want to increase the visibility of the discussion that has
been taking place regarding the role of module maintainers, so I'm
starting a mailing list thread.

I encourage folks to start by reading the wiki page, but to give a
summary of the discussion both on the page and during the general IRC
meeting today, thoughts on a variety of potential parts of the MM's
job have been expressed, including:

- whether or not MMs push patches to master vs. preparing branches for
the RM to pull from
- where MMs fit in the QA process
- the extent to which MMs actively work on their modules (as opposed
to more passively dealing with patches that present themselves)
- the degree to which the workflow for MMs should be determined by the
RM's preferences (and what happens when the position of RM changes)

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

[Koha-devel] Roles for 3.18; RMaints

[Galen Charlton]

Hi,

The current list of candidates for project roles can be found at

http://wiki.koha-community.org/wiki/Roles_for_3.18

We have candidates for all major project positions with the exception
of release maintainers for 3.12.x and 3.10.x.

I encourage folks to step up to run for RMaint, particularly for
3.12.x, but we should also discuss what the community support policy
for older releases should be.

For example, we could choose to support the most recent X stable
release branches, or we could decide that we want to support Y years
back, although given our release schedule either approach would work
out to the same outcome depending on how far back we want to go.

We should also consider what "support" means, particularly for the
older branches.  Several things that could be included in a definition
are:

- Having a release maintainer actively pushing bugfixes.  This is a
sine qua non, in my opinion.
- General community willingness to respond to questions and bug
reports with an answer that goes beyond "please upgrade to the latest
stable branch"
- Building release tarballs monthly (or maybe less frequently for
older branches)
- Building Debian packages
- Willingness to do security releases

Related, the next development meeting is scheduled for Wednesday, 23
April 2014, as a two part meeting at 15:00 UTC and 22:00 UTC.  Voting
on the project roles will be on the agenda for that meeting.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

[Koha-devel] 3.16 release calendar

[Galen Charlton]

Hi,

I'm setting the following dates for the next steps in the Koha release
cycle.  Note that date for deadlines should be interpreted to mean
that they finish at 23:59 in my time zone, which is presently
UTC-08:00.

Wednesday, 23 April: alpha release -- I will clear the passed QA queue
and roll a tarball.

Monday, 28 April: feature freeze -- any new feature or enhancement bug
must have reached Passed QA by the end of that day to be considered
for inclusion.  Note that I may grant the new cataloging editor up to
two days of leeway on this deadline.

Wednesday, 30 April: beta release -- by the end of the day, I will
clear the Passed QA queue and roll a beta release.  A soft string
freeze will start upon release of the beta; at this point, translators
can be confident that there won't be major string changes.

Monday, 5 May: at the end of the day, a firm string freeze will
beginning.  I will not call it a hard freeze, as security bugs and
release blockers will trump string stability, but translators can
expect that there will be no unnecessary changes.

Monday, 19 May: I will cut the release candidate

Thursday: 22 May: General release.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Problem on git server

[Galen Charlton]

Hi,

On Mon, Mar 31, 2014 at 2:18 AM, Zeno Tajoli  wrote:
> there are problems on git server ?
> My request of 'git pull' doesn't work.
> I receive:
> fatal: read error: Connection reset by peer

It works for me at the moment.  Please advise if it's still not working for you.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Update database error on Koha install

[Galen Charlton]

Hi,

On Tue, Mar 25, 2014 at 8:38 AM, Scott Kushner
 wrote:
> Does anyone know how to get around this? It seems that I'm stuck in a loop
> with the installer and cannot get out!
>
> Any help would be appreciated.

It looks like some manual SQL would be called for, following the steps
in the relevant database schema update.  Specifically, since it looks
like that the borrowernumber column is already present, probably from
a previous run, you should try:

[1] UPDATE patronimage LEFT JOIN borrowers USING ( cardnumber ) SET
patronimage.borrowernumber = borrowers.borrowernumber;

[2] ALTER TABLE patronimage DROP FOREIGN KEY patronimage_fk1;

It's possible that this one may fail if no such foreign key with that
name exists.  If so, that's fine, you can continue on:

[3] ALTER TABLE patronimage DROP PRIMARY KEY, ADD PRIMARY KEY( borrowernumber );

[4] ALTER TABLE patronimage DROP cardnumber;

[5] ALTER TABLE patronimage ADD FOREIGN KEY ( borrowernumber )
REFERENCES borrowers ( borrowernumber ) ON DELETE CASCADE ON UPDATE
CASCADE;

If you get this far, the final step is to tell Koha that you've
successfully installed that DB revision:

UPDATE systempreferences SET value = '3.1300030' WHERE variable = 'Version';

After that, you should be able to proceed with the rest of the schema upgrade.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Proposed to delete table aqorderdelivery (bug 11928)

[Galen Charlton]

Hi,

On Wed, Mar 12, 2014 at 6:00 AM, Zeno Tajoli  wrote:
> here, http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11928,
> I propose to delete Mysql table aqorderdelivery

+1.  I've signed off on Mark's patch to remove it.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] A volunteer for 3.12.x during April?

[Galen Charlton]

Hi,

On Mon, Mar 10, 2014 at 5:22 PM, Chris Cormack  wrote:
> * Tomas Cohen Arazi (tomasco...@gmail.com) wrote:
>>Hi, I'll be offline during April (trip) and would need someone to
>>volunteer for the 3.12.x RMaint position.
>
> I can take over for April, if that is ok with others.

+1 and thanks, Chris.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Calculating priority for new hold requests

[Galen Charlton]

Hi,

On Mon, Mar 10, 2014 at 10:29 AM, Galen Charlton  wrote:
> The patch for bug 8918 offers the potential start of an improvement
> for this situation by defining a new central routine to calculate the
> priority, although at present CalculatePriority() is used in only one
> place.  However, I'd like to suggest that rather than simply expanding
> the use of CalculatePriority(), that it instead by called by
> AddReserve() and that the $priority parameter of AddReserve() be
> removed.  This would have the effect of pushing each new request to
> the end of the line (with variations for future holds and item-level
> requests).

By the way, there is already a relevant bug open: 11640.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

[Koha-devel] Calculating priority for new hold requests

[Galen Charlton]

Hi,

An issue that's bugged me for a while is the fact that AddReserve()
relies on the caller to set the priority of the request.  That
historically has meant that there are several different places in the
code where the priority is calculated, and the code duplication means
that there's a risk of it getting calculated slightly differently.
Furthermore, there's the potential for a race condition if the patron
or staff member takes a while to actually submit the hold request.

The patch for bug 8918 offers the potential start of an improvement
for this situation by defining a new central routine to calculate the
priority, although at present CalculatePriority() is used in only one
place.  However, I'd like to suggest that rather than simply expanding
the use of CalculatePriority(), that it instead by called by
AddReserve() and that the $priority parameter of AddReserve() be
removed.  This would have the effect of pushing each new request to
the end of the line (with variations for future holds and item-level
requests).

As near as I can tell, all of the places that call AddReserves()
alreay implement this policy (including serials/routing-preview.pl,
although indirectly).  However, I would appreciate a check of that
assumption.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] update22_to_30.pl throwing MySQL syntax error while creating `labels` table

[Galen Charlton]

Hi,

On Fri, Mar 7, 2014 at 7:39 AM, Indranil Das Gupta  wrote:
> While migrating an ancient but very much in production 2.2.5 db to
> 3.14, ran into a small bug in the update script. I worked around it by
> changing 'timestamp(14)` to simply 'timestamp'
>
> http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11908
>
> Do I go ahead and write a patch? Or simply ignore it?

Go ahead and write a patch if you feel inclined -- it would fix a
problem, and anything that makes it easier for folks still running
Koha 2 to upgrade is a good thing.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Re: [Koha-devel] Reminder: General IRC meeting is 5 March 2014 at 19:00 UTC

[Galen Charlton]

Hi,

On Wed, Mar 5, 2014 at 5:32 AM, Owen Leonard  wrote:
> This is a reminder that the next general IRC meeting is 5 March 2014
> at 19:00 UTC (in about 4 hours as of this writing)

The minutes can be found at:

http://meetings.koha-community.org/2014/koha_general_meeting__5_march_2014.2014-03-05-19.05.html

The logs can be found at:

http://meetings.koha-community.org/2014/koha_general_meeting__5_march_2014.2014-03-05-19.05.log.html

I would like to direct folks' attention in particular to our decision
to schedule the next meeting to occur in two parts on 9 April 2014:
once at 15:00 UTC, and again at 21:00 UTC.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/