Good thought, but its already installed. Any other ideas?
ls -al /etc/apache2/*/*env*
-rw-r--r-- 1 root root 58 Aug 1 2015
/etc/apache2/mods-available/env.load
-rw-r--r-- 1 root root 1280 Aug 7 2015
/etc/apache2/mods-available/setenvif.conf
-rw-r--r-- 1 root root 68 Aug 1 2015
/etc/apac
n/installer/data/mysql/atomicupdate/oai_sets.sql:
- [Sat Oct 24 23:52:23 2015] updatedatabase.pl: ERROR 1062 (23000) at
line 35: Duplicate entry 'OAI-PMH:AutoUpdateSets' for key 'PRIMARY'
On Sun, Oct 25, 2015 at 11:05 AM, Doug Kingston wrote:
> While doing a upgrade on o
While doing a upgrade on our test koha instance (based on a copy of
production), I received the following errors.:
- [Sat Oct 24 23:52:23 2015] updatedatabase.pl: C4::Installer::load_sql
returned the following errors while attempting to load
/home/koha/koha-test/intranet/cgi-bin/installe
Mystery solved.
I had the OPAC site in my LastPass password manager with the "auto-login"
option set.
Every time I visited the OPAC site, Lastpass would provide the login
credentials in the POST. Koha acted on those credentials even though we
had marked user logins disabled. This is probably a b
On Wed, Oct 30, 2013 at 5:05 PM, Galen Charlton wrote:
> Hi Elaine,
>
> On Wed, Oct 30, 2013 at 4:31 PM, Elaine Bradtke wrote:
>
>> Here's an example of the imported 008:
>> 130515s2006stka###gr#000#0#eng#d
>>
>
> Just to confirm, for the migrated records, "#" in the 008 represents a
> l
My last install was on 3.10.02 and all was well with the set of Perl
modules had then, which included Text::CSV_XS-0.85. As I prepared to build
3.10.06, I upgraded my Perl modules as some additions were required in any
case. After the cpan upgrades, 'make test' was failing for both my 3.10.02
and
I have a suspicion that the problem may be related to this section of
lib/C4/Koha.pm:
sub getFacets {
my $facets;
if ( C4::Context->preference("marcflavour") eq "UNIMARC" ) {
$facets = [
...
}
else {
$facets = [
{
idx => 'su-to'
While updating the database on our test system, we received the following
errors. I looks like these values are already in the 3.8.7 version of the
database.
-Doug-
Update errors :
- [Sun Dec 2 23:08:15 2012] updatedatabase.pl: DBD::mysql::db do failed:
Duplicate entry 'SuspendHoldsIntran
Patch 8823 has introduce a bug (tracked in
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9149) where
C4/Biblio.pm
calls a non-existent subroutine: GetAuthorizedHeading. This breaks bin/
link_bibs_to_authorities.pl. I have informed the author of the patch.
__
Biblio number is only relevant for bibs. What should be used for
authorities? That is what I was referring to below but the problem may be
common to both objects.
-Doug-
On Sep 3, 2012 9:49 AM, "Jared Camins-Esakov"
wrote:
> Doug,
>
> I would concur that 001 and 003 need to be taken together
I would concur that 001 and 003 need to be taken together to have any
chance of a unique identifier. Our library has our own unique 003
(UkLoVW). For indexing, I suspect a better key to hand to zebra would be
the system control number (035 $a). Are these kept unique by koha?
While I do believe
bib1.att for reference attached.
-Doug-
On 2 September 2012 19:55, Doug Kingston wrote:
> Could something be amiss with /etc/koha/zebradb/authorities/etc/bib1.att?
> Especially given the error:
> [Sun Sep 02 23:38:10 2012] [error] [client 75.149.175.233] ZOOM error 25
> "Spec
10
On 2 September 2012 19:37, Doug Kingston wrote:
> We still get the same errors after running
> link_bibs_to_authorities.plfollowed by
> rebuild_zebra.pl -b -a -r
> The authorities not showing up was caused by duplicate control numbers.
> We have cleared up that problem.
&g
We still get the same errors after running
link_bibs_to_authorities.plfollowed by
rebuild_zebra.pl -b -a -r
The authorities not showing up was caused by duplicate control numbers. We
have cleared up that problem.
-Doug-
On 2 September 2012 18:57, Jared Camins-Esakov
wrote:
> Doug,
>
> More rele
Server information Koha version: 3.08.04.000 OS version ('uname -a'): Linux
library.efdss.org 2.6.32.33-kvm-i386-2028-dirty #5 SMP Mon Nov 28
20:23:39 GMT 2011 i686 GNU/Linux Perl interpreter: /usr/bin/perl Perl
version: 5.010001 Perl @INC: /usr/share/koha/lib
/etc/perl
/usr/local/lib/perl/5.10
relink headings that have previously been linked to
authority records.
On 2 September 2012 17:26, Doug Kingston wrote:
> I reproduced your 500 error and found these in the logfile. ZOOM is a
> zebra lookup error.
> [Sun Sep 02 23:38:10 2012] [error] [client 75.149.175.233] ZOO
I reproduced your 500 error and found these in the logfile. ZOOM is a
zebra lookup error.
[Sun Sep 02 23:38:10 2012] [error] [client 75.149.175.233] ZOOM error 25
"Specified element set name not valid for specified database" (addinfo:
"F") from diag-set 'Bib-1', referer:
http://catalogue-admin.efd
Better yet, we could use 'uniq -d'. It only prints out the duplicate
lines, so the following should suffice:
marcprint | grep "=001" | sort | uniq -d
I agree we should also be able to do something with SQL or SQL/Perl pretty
easily, but this was quick.
-Doug
On 1 September 2012 17:26, Mark Tomp
September 2012 16:11, Doug Kingston wrote:
> So doing some further research, it definitely looks like we have duplicate
> control numbers (001). This is a data entry mistake and it looks like the
> cataloger copied the biblios for similar entries. I have gone back and
> altered the c
nique then it
> will index OK.
> The better solution is to fix the xsl to probably not use the z:id for
> biblios or maybe get it to use the 999$c, but the zebra config scares me.
> It took ages to find the cause so I hope this helps someone.
> Ian
>
> On 01/09/2012 18:11, Doug Kin
On 1 September 2012 09:46, Jared Camins-Esakov
wrote:
> Doug,
>
> So environment variables are not the issue. We are carefully managing
>> those.
>>
>
> Make sure when you are using cron jobs that you set the environment
> variables IN YOUR CRONTAB. Setting environment variables elsewhere is a
>
So environment variables are not the issue. We are carefully managing
those.
I have tried using the new tool checkNonIndexedBiblios.pl (from patch 6566)
and it indeed finds a few recent biblios that are not indexed. Using the
-z option to mark them for indexing followed by a manual run of
rebuil
I can confirm that applying this patch to my 3.8.4 system and rebuilding
the indexes with rebuild_zebra.pl -r -b, and rebuild_zebra.pl -r -a has
resolved our problem.
-Doug-
On 28 August 2012 01:36, Chris Cormack wrote:
> On 28 August 2012 19:49, Ian Bays wrote:
> > We also found that on a rec
We are trying to fix up some duplicate and wrong authority records (note
that Mr Calvertt below has an extra comma after his middle name in the MAIN
ENTRY--PERSONAL NAME, but not in SUBJECT ADDED ENTRY-PERSONAL NAME which is
correct. We want to dump auth 2705 and just keep auth 2706. The
merge_au
We start the zebraqueue daemon from the /etc/init.d/koha-zebraqueue-daemon
script at startup. This is a link to
/usr/share/koha/bin/koha-zebraqueue-ctl.sh.
My hack to keep things up to date is to run
'/usr/share/koha/bin/migration_tools/rebuild_zebra.pl -b' every 2 minutes
from cron.
/etc/cron.d/
It seems to have a default of 25 entries per page displayed. I'd like to
be able to significantly increase that. How can I change the default
results_per_page for this other than editing tools/manage-marc-import.pl?
-Doug-
___
Koha mailing list http:/
Running Koha 3.4.3, it appears that Koha is only using Memcache for
storing session information and certain very static information:
<28 get KOHAgetTranslatedLanguages-list-opac prog
<28 get KOHAgetTranslatedLanguages-scalar-opac prog en
<28 get KOHAgetAllLanguages-scalar-
There would seem to be m
27 matches
Mail list logo
