On Mon, Feb 4, 2013 at 8:35 PM, Nicole Engard wrote:
>
> On Mon, Feb 4, 2013 at 1:14 PM, Frédéric Demians wrote:
>
>>
>> Isn't Open Library the solution?
>>
>
> Yes, but most libraries aren't picking Open Library cause the images are
> so tini tiny :) So hopefully that is resolved in 3.12 or in a
In security circles, if the reporter feels that the bug is not being
recognized or dealt with adequately by the dedicated project team, then they
have the option (and some responsibility) to report it to the wider
community. But *starting* with public disclosure of a security issue is
correctly re
> > Regarding the simplicity of signing off, I take some issue. It is
> > *severely* non-trivial to test major integration features. Consider SIP2
> > and LDAP, or something like EDI. It can depend not just on accurate test
> > data, but entire servers, network environments, remote accounts gran
>
> > Is it not possible to do one of these two?
>
> I think they are asking for the proper way of modifying the script
> that generates barcodes in koha for NEW items, preserving the
> semantics of the current system they're using.
>
I don't think so, based on:
Post migration we will generate &
On Tue, Nov 2, 2010 at 4:12 PM, Chris Nighswonger <
cnighswon...@foundations.edu> wrote:
> On Tue, Nov 2, 2010 at 2:10 PM, Joe Atzberger wrote:
>
>> Chris, I disagree that the first sign-off on a major vendor's patches
>> should be external. The first sign-off
I agree, neither itemBarcodeInputFilter nor javascript are necessary. Just
make the data loaded in Koha match the printed barcodes.
If you are worried about further generation of barcodes, then you might have
to insert an artificial max barcode value under the scheme you intend to
use, in order t
Chris, I disagree that the first sign-off on a major vendor's patches should
be external. The first sign-off from a major vendor should be *internal* to
their quality control process. This was at one time the standing policy
amongst LibLime and BibLibre for major changes.
I think encouraging abs
You still need something to get messages from the Koha server to your other
mailserver. In all cases, the simplest way to accomplish that is w/ a
mailserver on the Koha box. It can be configured such that it doesn't
connect to any other systems, but only to your other mailserver.
--Joe
2010/10/
For those who didn't read the pasted logs, one link they mentioned is here:
http://dev.mysql.com/doc/refman/5.1/en/forcing-recovery.html
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listi
I wouldn't be surprised if this was related to dynamic allocation on the VM.
Essentially, it can inject a random very large I/O latency to any
operation. It may also change the hardware model used by the VM.
I would recommend looking at InnoDB diagnostics, and possibly starting up
w/ innodb_forc
On linux: ssh-keygen
--joe
On Thu, Sep 2, 2010 at 8:09 AM, Nicole Engard wrote:
> Hi all,
>
> To access the manual people need to generate public ssh keys - I used
> to have this documented somewhere, but can't find it. I'm wondering
> if someone could write up a tutorial for the wiki on how t
Koha can be effectively virtualized for production in VMware, Virtualbox or
xen. It is quite common and helpful.
And yes, you can use the same codebase with different Koha instances. You
will have to do edit your $KOHA_CONF files accordingly. But start with one
instance and get familiar with it
Yeah, the whole point of preferring distro packages is for binaries and
distro-specific configs. Any decent image manipulation components will rely
on binary code for performance. Unfortunately, too many CPAN modules fail
to build XS correctly on a given platform (including debian, historically),
I'm also against translating SQL when templated techniques are feasible.
But if the feature needed is to allow staff users the ability to enter
multiple translations *at runtime* with no systems-level administration,
then the only question is whether to allow Koha to:
1. write to a directory t
If so, this would be a catastrophically bad behavior. Nothing could be
disabled once edited.
On Fri, Jul 2, 2010 at 9:26 AM, Paul Poulain wrote:
> Hi the list,
>
> I have found (and it has not been reported yet AFAIK) that the YesNo
> sysprefs are now store as 'yes' or 'no', no more as '1' or '0
On Mon, Jun 14, 2010 at 11:37 AM, Cab Vinton wrote:
> Have come across references to this a few times recently & am curious
> enough to ask the development community whether the NoSQL movement
> holds any relevance for Koha's future.
>
> According to that font of universal wisdom, Wikipedia, "Typ
NYTprof combined with firebug (or chrome dev tools) can give you the
comprehensive picture. The former atomizes and itemizes the server side
costs. The latter details the client side, including graphs of time spent
downloading vs. rendering, per file.
On Jun 5, 2010 9:38 PM, "Chris Cormack" wr
That seems pretty reasonable. Beneficial patches are accepted from anybody!
>
--joe
>
On Wed, May 19, 2010 at 9:31 AM, Toni wrote:
> Hello,
>
>>
> After looking into the code of the predefined report "Patrons with No
>
>> Checkouts" (borrowers_out.pl), I wonder whether the way it is generated
time item availability info, and that standard still differentiates
between:
- circ status
- checkout/access fee type
- checkout/access fee amount
- hold queue length
- date due
- recall date
- hold pickup date
- other item properties (size, weight, etc)
ILL systems can and
Hey Liz --
>
It sounds like you would be trying to code AutoGraphics logic into Koha.
>
Another user group might prefer the granularity that currently exists, or
use software that requires it. Broadly speaking, we can imagine
"availability" many different ways:
>
- available for checkout
20 matches
Mail list logo
