From oleonard at myacpl.org Wed Aug 1 17:13:00 2012 From: oleonard at myacpl.org (Owen Leonard) Date: Wed, 1 Aug 2012 11:13:00 -0400 Subject: [Koha-devel] Cautionary warnings in longoverdue.pl Message-ID: misc/longoverdue.pl contains this warning; WARNING: This script is known to be faulty. It is NOT recommended to use multiple --lost options. See http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2883 The bug in question has been closed ("RESOLVED - WORKSFORME"). Can we now remove that warning from the script? What about these FIXMEs? Are they still valid, and should that affect the help text? # FIXME: We need three pieces of data to operate: # ~ lower bound (number of days), # ~ upper bound (number of days), # ~ new lost value. # Right now we get only two, causing the endrange hack. This is a design-level failure. # FIXME: do checks on --lost ranges to make sure they are exclusive. # FIXME: do checks on --lost ranges to make sure the authorized values exist. # FIXME: do checks on --lost ranges to make sure don't go past endrange. # FIXME: convert to using pod2usage # FIXME: allow --help or -h -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org From paul.poulain at biblibre.com Wed Aug 1 17:17:22 2012 From: paul.poulain at biblibre.com (Paul Poulain) Date: Wed, 01 Aug 2012 17:17:22 +0200 Subject: [Koha-devel] Sanbox n.2 and bug 8357 In-Reply-To: References: Message-ID: <50194882.5040203@biblibre.com> Le 31/07/2012 10:47, tajoli at cilea.it a ?crit : > Hi to all, > > Yesterday I have tested bug 8357 with the Biblibre sanbox n.2. > I also use the second form in the web page http://pro.test2.biblibre.com/cgi-bin/koha/sandbox.pl > to sign-off the patch. > > I wait 12 hours but the sign-off is not done. > > Is there any problem ? The problem is fixed. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From paul.poulain at biblibre.com Thu Aug 2 10:46:47 2012 From: paul.poulain at biblibre.com (Paul Poulain) Date: Thu, 02 Aug 2012 10:46:47 +0200 Subject: [Koha-devel] About Release process In-Reply-To: <028B1A54D03E7B4482CDCA4EC8F06BFD016267C1@Bodensee.bsz-bw.de> References: <4FFE90A3.1010900@biblibre.com> <5006E431.3010507@biblibre.com> <809BE39CD64BFD4EB9036172EBCCFA310DFD1AF1@S-MAIL-1B.rijksmuseum.intra> <028B1A54D03E7B4482CDCA4EC8F06BFD016267C1@Bodensee.bsz-bw.de> Message-ID: <501A3E77.7050207@biblibre.com> Le 19/07/2012 11:12, Fischer, Katrin a ?crit : > Hi all, Hi all, > Who will be testing and who will be fixing bugs? I think the problem > will only get moved a bit in time, but it will still be there. Both > branches will diverge quickly as soon as patches are only pushed to one > of them. Then we will start to need different patches for bug fixes, > patches will not apply, testers will have to test on each branch > separately etc. I've been unclear. What we plan to do with Jared is pushing patches on master, and also pushing bugfixes/non-core enhancements to 3.10 branch. That's the workflow we already have for the stable release. The idea is to branch 3.10 soon to ensure the best possible stability. We will encourage developers to test things against master, we (the RMs) will take care of deciding if something is to push against master only or against master and 3.10 I think we can say this workflow is tried for 3.10, we will decide after the release if it is adopted for the next releases. I'll announce the updated timing in my next RM newsletter (that i'll publish tomorrow, before leaving for vacation) * today => sept 22 => development process * sept 22 => feature freeze, no more large or core enhancements pushed, whatever the date of submission of the patch. 3.10 version is branched in git. * oct 22 => string freeze, no more string changes * nov 22 => Koha 3.10.0 is released > I am also not persuaded moving the release date is a good idea, because > we switched to time based releases for having reliable release dates and > being able to plan. I also fear by moving it to November, we will move > it right into the "end of year madness". Also we will maybe have the > same problem again with a RM from a different country/continent. So if > we decide to move the dates, please let us stick to those forever. In French we have an expression that is "you must choose your poison my friend". It means there is no "good" option, you just must choose the less annoying one. Moving by 1 month is the best option I can see. Could the release of a 3.10.0RC1 -or 3.9.99 the numbering doesn't matter-, on Oct 22th please you ? That's an option I could deal with. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From chris at bigballofwax.co.nz Thu Aug 2 10:55:20 2012 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Thu, 2 Aug 2012 20:55:20 +1200 Subject: [Koha-devel] About Release process In-Reply-To: <501A3E77.7050207@biblibre.com> References: <4FFE90A3.1010900@biblibre.com> <5006E431.3010507@biblibre.com> <809BE39CD64BFD4EB9036172EBCCFA310DFD1AF1@S-MAIL-1B.rijksmuseum.intra> <028B1A54D03E7B4482CDCA4EC8F06BFD016267C1@Bodensee.bsz-bw.de> <501A3E77.7050207@biblibre.com> Message-ID: On 2 August 2012 20:46, Paul Poulain wrote: > Le 19/07/2012 11:12, Fischer, Katrin a ?crit : >> Hi all, > Hi all, > Moving by 1 month is the best option I can see. > Could the release of a 3.10.0RC1 -or 3.9.99 the numbering doesn't > matter-, on Oct 22th please you ? That's an option I could deal with. > So the question is, do we now have a 7th month cycle? Or is it just this once? Is the next release a 5 month one, or are we back to 6? Chris From cnighswonger at foundations.edu Thu Aug 2 15:48:49 2012 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Thu, 2 Aug 2012 09:48:49 -0400 Subject: [Koha-devel] About Release process In-Reply-To: References: <4FFE90A3.1010900@biblibre.com> <5006E431.3010507@biblibre.com> <809BE39CD64BFD4EB9036172EBCCFA310DFD1AF1@S-MAIL-1B.rijksmuseum.intra> <028B1A54D03E7B4482CDCA4EC8F06BFD016267C1@Bodensee.bsz-bw.de> <501A3E77.7050207@biblibre.com> Message-ID: On Thu, Aug 2, 2012 at 4:55 AM, Chris Cormack wrote: > On 2 August 2012 20:46, Paul Poulain wrote: >> Le 19/07/2012 11:12, Fischer, Katrin a ?crit : >>> Hi all, >> Hi all, > >> Moving by 1 month is the best option I can see. >> Could the release of a 3.10.0RC1 -or 3.9.99 the numbering doesn't >> matter-, on Oct 22th please you ? That's an option I could deal with. >> > So the question is, do we now have a 7th month cycle? Or is it just this once? > Is the next release a 5 month one, or are we back to 6? I have some experience in date-shifting from my time as Rmaint, FWIW. When I found I had to push a release date, I generally tried to do one of two things depending on the date: 1. If I was less than halfway to the next release date, i released and the released again on the next scheduled date. 2. If I was over halfway to the next release date, I skipped a release. This is probably *not* the exact fix for major releases, but.... In light of this, I would suggested that we slide this release date forward if needed and retain the next release date as scheduled. This track probably causes the least disruption to those who have planned their upgrade schedule around the major release schedule. Kind Regards, Chris From paul.poulain at biblibre.com Fri Aug 3 17:59:38 2012 From: paul.poulain at biblibre.com (Paul Poulain) Date: Fri, 03 Aug 2012 17:59:38 +0200 Subject: [Koha-devel] About Release process In-Reply-To: References: <4FFE90A3.1010900@biblibre.com> <5006E431.3010507@biblibre.com> <809BE39CD64BFD4EB9036172EBCCFA310DFD1AF1@S-MAIL-1B.rijksmuseum.intra> <028B1A54D03E7B4482CDCA4EC8F06BFD016267C1@Bodensee.bsz-bw.de> <501A3E77.7050207@biblibre.com> Message-ID: <501BF56A.5030101@biblibre.com> Le 02/08/2012 10:55, Chris Cormack a ?crit : Hi Chris & al, >> Moving by 1 month is the best option I can see. >> Could the release of a 3.10.0RC1 -or 3.9.99 the numbering doesn't >> matter-, on Oct 22th please you ? That's an option I could deal with. >> > So the question is, do we now have a 7th month cycle? Or is it just this once? > Is the next release a 5 month one, or are we back to 6? We stick to a 6 months release: * oct 22th = RC1, nov 22th = .0 release * apr 22th = RC1, may 22th = .0 release -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From paul.poulain at biblibre.com Fri Aug 3 18:30:20 2012 From: paul.poulain at biblibre.com (Paul Poulain) Date: Fri, 03 Aug 2012 18:30:20 +0200 Subject: [Koha-devel] Koha Release Manager newsletter published Message-ID: <501BFC9C.3040609@biblibre.com> Hello, I just published my monthly newsletter on koha-community.org website : http://koha-community.org/koha-release-manager-newsletter-9-2012-07/ And now, I leave for 3 weeks of vacation. See you on Aug, 26th ! -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From ashokmishra119 at gmail.com Sat Aug 4 08:34:16 2012 From: ashokmishra119 at gmail.com (Ashok Mishra) Date: Sat, 4 Aug 2012 12:04:16 +0530 Subject: [Koha-devel] koha reservoir problem Message-ID: sir please help me my system err is *No results found* Biblios in reservoir None My koha information given below Koha version: 3.08.01.002 OS version ('uname -a'): Linux bcp-library 3.2.0-26-generic-pae #41-Ubuntu SMP Thu Jun 14 16:45:14 UTC 2012 i686 i686 i386 GNU/Linux Perl interpreter: /usr/bin/perl Perl version: 5.014002 Perl @INC: /usr/share/koha/lib /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl . MySQL version: mysql Ver 14.14 Distrib 5.5.24, for debian-linux-gnu (i686) using readline 6.2 Apache version: Server version: Apache/2.2.22 (Ubuntu) Zebra version: Zebra 2.0.44 (C) 1994-2010, Index Data ApS Zebra is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. SHA1 ID: 419ad759807269fdfa379799a051ed3a551c6541 Using ICU -- Ashok Mishra *Librarian* Bansal College of Pharmacy, Bhopal -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at bigballofwax.co.nz Sat Aug 4 10:33:47 2012 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Sat, 4 Aug 2012 20:33:47 +1200 Subject: [Koha-devel] Koha Release Manager newsletter published In-Reply-To: <501BFC9C.3040609@biblibre.com> References: <501BFC9C.3040609@biblibre.com> Message-ID: On 4 August 2012 04:30, Paul Poulain wrote: > Hello, > > I just published my monthly newsletter on koha-community.org website : > http://koha-community.org/koha-release-manager-newsletter-9-2012-07/ > > And now, I leave for 3 weeks of vacation. See you on Aug, 26th ! > -- While 3.10.0 is being delayed for a month, due to the vacation. I still plan to release 3.8.4 on time (August 22). To this end, patches that pass QA and are bug fixes I will be applying on 3.8.x. So I would (as always) appreciate any work the QA team does, and any work the rest of community does signing off. Chris From paul.poulain at free.fr Fri Aug 3 18:24:43 2012 From: paul.poulain at free.fr (Paul Poulain) Date: Fri, 03 Aug 2012 18:24:43 +0200 Subject: [Koha-devel] Koha Release Manager newsletter published Message-ID: <501BFB4B.8050303@free.fr> Hello, I just published my monthly newsletter on koha-community.org website : http://koha-community.org/koha-release-manager-newsletter-9-2012-07/ And now, I leave for 3 weeks of vacation. See you on Aug, 26th ! -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From karamqubsi at gmail.com Mon Aug 6 11:03:05 2012 From: karamqubsi at gmail.com (Karam Qubsi) Date: Mon, 6 Aug 2012 12:03:05 +0300 Subject: [Koha-devel] arabic Language for koha3.8 In-Reply-To: <1337723808811-5713443.post@n5.nabble.com> References: <1337723808811-5713443.post@n5.nabble.com> Message-ID: Hi kouider What do you mean ? the Arabic is 100% complete ( staff , opac and pref ! ) http://translate.koha-community.org/ar/38/ On Wed, May 23, 2012 at 12:56 AM, kouider bounama wrote: > arabic (68%, OPAC 100%) > > > -- > View this message in context: > http://koha.1045719.n5.nabble.com/Koha-3-8-1-released-tp5713183p5713443.html > Sent from the Koha-devel mailing list archive at Nabble.com. > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -- Karam Qubsi Koha Arab Translating Team http://koha.wikibrary.org/ Wikibrary for Arab Librarians http://wikibrary.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From karamqubsi at gmail.com Mon Aug 6 13:33:00 2012 From: karamqubsi at gmail.com (Karam Qubsi) Date: Mon, 6 Aug 2012 14:33:00 +0300 Subject: [Koha-devel] arabic Language for koha3.8 In-Reply-To: References: <1337723808811-5713443.post@n5.nabble.com> Message-ID: Sorry I didn't notice that your mail sent On Wed, May 23, 2012 but I received it today On Mon, Aug 6, 2012 at 12:03 PM, Karam Qubsi wrote: > Hi kouider > What do you mean ? > the Arabic is 100% complete ( staff , opac and pref ! ) > http://translate.koha-community.org/ar/38/ > > > On Wed, May 23, 2012 at 12:56 AM, kouider bounama wrote: > >> arabic (68%, OPAC 100%) >> >> >> -- >> View this message in context: >> http://koha.1045719.n5.nabble.com/Koha-3-8-1-released-tp5713183p5713443.html >> Sent from the Koha-devel mailing list archive at Nabble.com. >> _______________________________________________ >> Koha-devel mailing list >> Koha-devel at lists.koha-community.org >> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >> website : http://www.koha-community.org/ >> git : http://git.koha-community.org/ >> bugs : http://bugs.koha-community.org/ >> > > > > -- > Karam Qubsi > Koha Arab Translating Team > http://koha.wikibrary.org/ > Wikibrary for Arab Librarians > http://wikibrary.org > > -- Karam Qubsi Koha Arab Translating Team http://koha.wikibrary.org/ Wikibrary for Arab Librarians http://wikibrary.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From julian.maurice at biblibre.com Tue Aug 7 14:44:05 2012 From: julian.maurice at biblibre.com (Julian Maurice) Date: Tue, 07 Aug 2012 14:44:05 +0200 Subject: [Koha-devel] [Koha] Koha 3.8.0 Released In-Reply-To: References: <500D3320.7000001@biblibre.com> Message-ID: <50210D95.4000807@biblibre.com> Le 23/07/2012 13:24, Hugo Agud a ?crit : > thanks a lot for the info!!! > > 2012/7/23 Paul Poulain > > > Le 23/07/2012 12:40, Hugo Agud a ?crit : > > Hi Chris > > > > > I have seen again where I saw it.. the chance of sharing > patterns... it was > > not a official community new it was a presentation in Kohacon11 > > The bug and the patch is here : > http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7688 > > it's signed off, so hopefully, it should be in 3.10 > Note that the patch is signed off by one person, but this is a huge patch. Huge patches often requires multiple signoffs before being integrated. In all cases, multiple signoffs often speed up the integration process, so you are very welcome to help here :-) -- Julian Maurice BibLibre From magnus at enger.priv.no Wed Aug 8 12:30:03 2012 From: magnus at enger.priv.no (Magnus Enger) Date: Wed, 8 Aug 2012 12:30:03 +0200 Subject: [Koha-devel] Short notice: Global Bug Squashing Day 2012-08-10 Message-ID: Dear Community! The bug wranglers are a bit rusty, but we would like to suggest a GBSD for Friday 2012-08-10 (yup, that's *this* Friday)! All the usual activities of signing off patches etc are encouraged: http://wiki.koha-community.org/wiki/2012-08-10_Global_bug_squashing_day Remember that even one signoff will now make your name show up on the super cool dashboard Chris C has created: http://dashboard.koha-community.org/ ... as well as in future relase notes! Best regards, Magnus Enger From paul.a at aandc.org Wed Aug 8 17:19:40 2012 From: paul.a at aandc.org (Paul) Date: Wed, 08 Aug 2012 11:19:40 -0400 Subject: [Koha-devel] 3.8.3 dependencies Message-ID: <5.2.1.1.2.20120808105248.03cae2b0@stormy.ca> Looking at Koha 3.8.3 on my "desktop" (64-bit Ubuntu 12.04 server plus Gnome 2.3 utilities, graphics etc) Final unmet dependencies are: Graphics::Magick 0 * 1.3.05 No Net::Z3950::ZOOM 0 * 1.16 Yes XML::LibXSLT 0 * 1.59 Yes The last two are problematic. As far as I can see after a fair amount of trying (CPAN, Debian and Ubuntu repositories) they both, via yaz, are dependant on libyaz-dev which in turn allows libxml2-dev. The most promising source appears to be libyaz4-dev_4.2.18-1build1_i386.deb -- but this fails miserably (despite "force install" and apt-get -f) as the 64-bit system refuses these particular i386 packages, ultimately with: (Reading database ... 176579 files and directories currently installed.) Unpacking libxml2-dev:i386 (from .../libxml2-dev_2.7.8.dfsg-5.1ubuntu4.1_i386.deb) ... dpkg: error processing /var/cache/apt/archives/libxml2-dev_2.7.8.dfsg-5.1ubuntu4.1_i386.deb (--unpack): './usr/bin/xml2-config' is different from the same file on the system dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) Processing triggers for man-db ... Errors were encountered while processing: /var/cache/apt/archives/libxml2-dev_2.7.8.dfsg-5.1ubuntu4.1_i386.deb E: Sub-process /usr/bin/dpkg returned an error code (1) Does any one have pointers to a 64 bit package for Net::Z3950::ZOOM and XML::LibXSLT (or another workaround)? Also, while Graphics::Magick might not be "required", can anyone tell me what if any functionality might be impacted? Just for the record, all dependencies installed without problems on our production server (64-bit, but Ubuntu 11.10 and Koha 3.6.1) and on my sandbox (12.04, 3.6.7) but it is an older 32-bit machine. Many thanks and best regards, Paul From tomascohen at gmail.com Wed Aug 8 17:34:03 2012 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Wed, 8 Aug 2012 12:34:03 -0300 Subject: [Koha-devel] 3.8.3 dependencies In-Reply-To: <5.2.1.1.2.20120808105248.03cae2b0@stormy.ca> References: <5.2.1.1.2.20120808105248.03cae2b0@stormy.ca> Message-ID: On Wed, Aug 8, 2012 at 12:19 PM, Paul wrote: > Looking at Koha 3.8.3 on my "desktop" (64-bit Ubuntu 12.04 server plus Gnome > 2.3 utilities, graphics etc) > > Final unmet dependencies are: > > Graphics::Magick 0 * 1.3.05 No > Net::Z3950::ZOOM 0 * 1.16 Yes > XML::LibXSLT 0 * 1.59 Yes > > The last two are problematic. As far as I can see after a fair amount of > trying (CPAN, Debian and Ubuntu repositories) they both, via yaz, are > dependant on libyaz-dev which in turn allows libxml2-dev. The most > promising source appears to be libyaz4-dev_4.2.18-1build1_i386.deb -- but > this fails miserably (despite "force install" and apt-get -f) as the 64-bit > system refuses these particular i386 packages, ultimately with: Just $ apt-get install libyaz4 libyaz4-dev > Does any one have pointers to a 64 bit package for Net::Z3950::ZOOM and > XML::LibXSLT (or another workaround)? and: $ apt-get install libnet-z3950-zoom-perl libxml-libxslt-perl libgraphics-magick-perl Regards To+ From mtompset at hotmail.com Wed Aug 8 18:07:26 2012 From: mtompset at hotmail.com (Mark Tompsett) Date: Thu, 9 Aug 2012 00:07:26 +0800 Subject: [Koha-devel] 3.8.3 dependencies In-Reply-To: <5.2.1.1.2.20120808105248.03cae2b0@stormy.ca> References: <5.2.1.1.2.20120808105248.03cae2b0@stormy.ca> Message-ID: Greetings, Someone correct me if I am wrong, but given that Ubuntu is a Debian-based system, it should not break things if you add the debian.koha-community.org repository and try grabbing what you need from there. http://wiki.koha-community.org/wiki/Koha_3.8_on_Debian_Squeeze This gives the line you need to add into an /etc/apt/sources.list.d/koha.list file Make sure to get the key too! The command is in the "Everyone" part just below the repository options. Update the libraries available listing: $ sudo apt-get update Then try to apt-get them. Hopefully by pointing to the koha-community.org repository this will solve your problems. I don't know if this will or not, as I have yet to do a 64-bit install, but it can't hurt to try. :) 3.6.X and 3.8.X have different dependencies, and some don't exist nicely in the purely default Ubuntu world. Just my thoughts. No guarantees. Regards, Mark Tompsett From robin at catalyst.net.nz Wed Aug 8 18:22:21 2012 From: robin at catalyst.net.nz (Robin Sheat) Date: Wed, 08 Aug 2012 18:22:21 +0200 Subject: [Koha-devel] 3.8.3 dependencies In-Reply-To: References: <5.2.1.1.2.20120808105248.03cae2b0@stormy.ca> Message-ID: <5022923D.1020209@catalyst.net.nz> Op 08-08-12 18:07, Mark Tompsett schreef: > Someone correct me if I am wrong, but given that Ubuntu is a > Debian-based system, it should not break things if you add the > debian.koha-community.org repository and try grabbing what you need from > there. You are correct. I run pretty much everything as 64-bit and haven't noticed any dependency issues. All the stuff in debian.k-c.org is platform agnostic. -- Robin Sheat Catalyst IT Ltd. ? +64 4 803 2204 GPG: 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D From mdhafen at tech.washk12.org Wed Aug 8 18:30:03 2012 From: mdhafen at tech.washk12.org (Mike Hafen) Date: Wed, 8 Aug 2012 10:30:03 -0600 Subject: [Koha-devel] 3.8.3 dependencies In-Reply-To: References: <5.2.1.1.2.20120808105248.03cae2b0@stormy.ca> Message-ID: Some have suggested the debian.k-c.org repo, which is good. I'm running Ubuntu 12.04 Desktop 64-bit, and my package list includes good versions of the three perl modules you've listed. Looks like they come from the Universe repo. On Wed, Aug 8, 2012 at 9:34 AM, Tomas Cohen Arazi wrote: > On Wed, Aug 8, 2012 at 12:19 PM, Paul wrote: > > Looking at Koha 3.8.3 on my "desktop" (64-bit Ubuntu 12.04 server plus > Gnome > > 2.3 utilities, graphics etc) > > > > Final unmet dependencies are: > > > > Graphics::Magick 0 * 1.3.05 No > > Net::Z3950::ZOOM 0 * 1.16 Yes > > XML::LibXSLT 0 * 1.59 Yes > > > > The last two are problematic. As far as I can see after a fair amount of > > trying (CPAN, Debian and Ubuntu repositories) they both, via yaz, are > > dependant on libyaz-dev which in turn allows libxml2-dev. The most > > promising source appears to be libyaz4-dev_4.2.18-1build1_i386.deb -- but > > this fails miserably (despite "force install" and apt-get -f) as the > 64-bit > > system refuses these particular i386 packages, ultimately with: > > Just > $ apt-get install libyaz4 libyaz4-dev > > > Does any one have pointers to a 64 bit package for Net::Z3950::ZOOM and > > XML::LibXSLT (or another workaround)? > > and: > $ apt-get install libnet-z3950-zoom-perl libxml-libxslt-perl > libgraphics-magick-perl > > Regards > To+ > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.m.hall at gmail.com Wed Aug 8 21:35:48 2012 From: kyle.m.hall at gmail.com (Kyle Hall) Date: Wed, 8 Aug 2012 15:35:48 -0400 Subject: [Koha-devel] Serials Work RFC - Storing Enumeration Data Message-ID: Hello All, I'm working with a library that is having problems running reports based on serials enumeration data, and I was hoping to get some feedback on an idea I have. Right now, we store the enumeration format in subscription.numberingmethod ( e.g. "Vol {X}, No {Y}, Issue {Z}" ). When the serial is received, the X, Y and Z are replaced with real values and this is stored in serials.serialseq and items.enumchron, I'm wondering if it would be better to store this data in separate columns instead. 1. Add columns x_description, y_description, and z_description to the table subscription. In the above example these would contain 'Vol', 'No', and 'Issue' respectively. 2. Add columns x_data, y_data and z_data to the table issues. So for "Vol 5, No 2, Issue 7", these columns would be 5, 2 and 7 respectively. 3. Retrospectively parse subscription.numberingmethod into x_description, y_description, and z_description 4. Retrospectively parse serials.serialseq into x_data, y_data and z_data At this point, we could get rid of serials.serialseq, or we could keep it alongside this new data. I would lean toward keeping it as we cannot guarantee step 4 will work right, as a librarian can modify serials.serialseq by hand when receiving the item. The question is: is this a good idea, or a stupid idea? Please let me know either way! Thanks, Kyle http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) Mill Run Technology Solutions ( http://millruntech.com ) From paul.a at aandc.org Wed Aug 8 22:09:22 2012 From: paul.a at aandc.org (Paul) Date: Wed, 08 Aug 2012 16:09:22 -0400 Subject: [Koha-devel] 3.8.3 dependencies In-Reply-To: References: <5.2.1.1.2.20120808105248.03cae2b0@stormy.ca> <5.2.1.1.2.20120808105248.03cae2b0@stormy.ca> Message-ID: <5.2.1.1.2.20120808160034.03356350@localhost> At 12:34 PM 8/8/2012 -0300, Tomas Cohen Arazi wrote: >On Wed, Aug 8, 2012 at 12:19 PM, Paul wrote: > > Looking at Koha 3.8.3 on my "desktop" (64-bit Ubuntu 12.04 server plus > Gnome > > 2.3 utilities, graphics etc) > > > > Final unmet dependencies are: > > > > Graphics::Magick 0 * 1.3.05 No > > Net::Z3950::ZOOM 0 * 1.16 Yes > > XML::LibXSLT 0 * 1.59 Yes > > > > The last two are problematic. As far as I can see after a fair amount of > > trying (CPAN, Debian and Ubuntu repositories) they both, via yaz, are > > dependant on libyaz-dev which in turn allows libxml2-dev. The most > > promising source appears to be libyaz4-dev_4.2.18-1build1_i386.deb -- but > > this fails miserably (despite "force install" and apt-get -f) as the 64-bit > > system refuses these particular i386 packages, ultimately with: >Just >$ apt-get install libyaz4 libyaz4-dev > > Does any one have pointers to a 64 bit package for Net::Z3950::ZOOM and > > XML::LibXSLT (or another workaround)? >and: >$ apt-get install libnet-z3950-zoom-perl libxml-libxslt-perl >libgraphics-magick-perl Thank you Tomas (and Robin, Mike and Mark), koha_perl_deps.pl -m -u is now giving no missing dependencies. However: WARNING: on the 64-bit Ubuntu 12.04, do not attempt an apt-get install of libyaz4-dev_4.2.18-1build1_i386.deb - I ended up with a bunch of files fragments to purge, found with sudo dpkg --configure -a Strangely, libgraphics-magick-perl did not fully install (it's also got some i386 bits that 64-bit Ubuntu 12.04 won't digest) but it does get far enough to (apparently) meet Koha 3.8.3 dependencies. I'll try and get full notes written up later and look into the koha-communities repository (off to a meeting now ...) Again, thanks to all, Paul --- Maritime heritage and history, preservation and conservation, research and education through the written word and the arts. and From robin at catalyst.net.nz Wed Aug 8 22:23:03 2012 From: robin at catalyst.net.nz (Robin Sheat) Date: Wed, 08 Aug 2012 22:23:03 +0200 Subject: [Koha-devel] 3.8.3 dependencies In-Reply-To: <5.2.1.1.2.20120808160034.03356350@localhost> References: <5.2.1.1.2.20120808105248.03cae2b0@stormy.ca> <5.2.1.1.2.20120808105248.03cae2b0@stormy.ca> <5.2.1.1.2.20120808160034.03356350@localhost> Message-ID: <5022CAA7.5020300@catalyst.net.nz> Op 08-08-12 22:09, Paul schreef: > > WARNING: on the 64-bit Ubuntu 12.04, do not attempt an apt-get install > of libyaz4-dev_4.2.18-1build1_i386.deb - I ended up with a bunch of > files fragments to purge, found with sudo dpkg --configure -a > > Strangely, libgraphics-magick-perl did not fully install (it's also got > some i386 bits that 64-bit Ubuntu 12.04 won't digest) but it does get > far enough to (apparently) meet Koha 3.8.3 dependencies. You shouldn't be touching i386 packages on a 64-bit machine unless you really know what you're doing. libgraphics-magick-perl should be pure 64 bit. Better, don't install .deb files of things that are in your apt repo anyway. -- Robin Sheat Catalyst IT Ltd. ? +64 4 803 2204 GPG: 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D From tomascohen at gmail.com Wed Aug 8 22:42:23 2012 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Wed, 8 Aug 2012 17:42:23 -0300 Subject: [Koha-devel] 3.8.3 dependencies In-Reply-To: <5022CAA7.5020300@catalyst.net.nz> References: <5.2.1.1.2.20120808105248.03cae2b0@stormy.ca> <5.2.1.1.2.20120808160034.03356350@localhost> <5022CAA7.5020300@catalyst.net.nz> Message-ID: Robin, On Wed, Aug 8, 2012 at 5:23 PM, Robin Sheat wrote: > Op 08-08-12 22:09, Paul schreef: >> >> WARNING: on the 64-bit Ubuntu 12.04, do not attempt an apt-get install >> of libyaz4-dev_4.2.18-1build1_i386.deb - I ended up with a bunch of >> files fragments to purge, found with sudo dpkg --configure -a >> >> Strangely, libgraphics-magick-perl did not fully install (it's also got >> some i386 bits that 64-bit Ubuntu 12.04 won't digest) but it does get >> far enough to (apparently) meet Koha 3.8.3 dependencies. > > You shouldn't be touching i386 packages on a 64-bit machine unless you > really know what you're doing. libgraphics-magick-perl should be pure 64 > bit. Better, don't install .deb files of things that are in your apt > repo anyway. I found the ubuntu.packages to cause that behaviour on 64bit setups. I also found that fixing the libyaz (and some libmysqlXX-dev) versions fixed it. I didn't talk about it as Mark was revisiting those packages files for several ubuntu releases and the side effect was that it got fixed. Mark and I talked about that fixes on IRC. I don't know if it has been pushed into master (and 3.8.x) right now but I recommend using koha_perl_deps.pl and searching for the right packages until the fixed files get pushed. Paul: try $ dpkg -l | grep 386 and you will get a list of the remaining i386 packages installed. They will look like libqtgui4:i386 Regards To+ From mtompset at hotmail.com Thu Aug 9 06:03:35 2012 From: mtompset at hotmail.com (Mark Tompsett) Date: Thu, 9 Aug 2012 12:03:35 +0800 Subject: [Koha-devel] 3.8.3 dependencies In-Reply-To: References: <5.2.1.1.2.20120808105248.03cae2b0@stormy.ca><5.2.1.1.2.20120808160034.03356350@localhost><5022CAA7.5020300@catalyst.net.nz> Message-ID: Greetings, This is where my little check_deps.sh script comes in. With Robin's help, we got the debian.koha-community.org repository apt-file'able. With Jared's help, we were able to download default sources.list files for Ubuntu 10.04, Ubuntu 12.04, Debian 6.0.X, and Debian 7.0.X, and he got a working version into some repo somewhere (I can't remember off the top of my head). Jared did tweak the sources.list files to include the debian.koha-community.org repository, because Template::Plugin::HtmlToText (I think that's the name) does not exist in the default Ubuntu repositories (at least for Ubuntu 12.04 under 32-bit). My little check_deps.sh script can then ensure that future releases of ANY version of Koha (assuming PerlDependencies.pm is up to date and correct, because that is what koha_perl_deps.pl uses) has the appropriate things added into the {OS}.{version}.packages (not really packages, but a list of packages needed to be installed, so don't get confused) file(s) so that the dselect section of the Wiki page's instructions (http://wiki.koha-community.org/wiki/Koha_on_Ubuntu#Ubuntu_Packages_from_List) will just work for a tarball or git install. This script was used in the preparation of 3.6.7 just before release. Thanks to Jared for letting me squeak it in. I'm hoping to tweak it a little further, as Bug 8485 (it has been signed off, but not pushed) has made some of the logic in the script not necessary. GPML, Mark Tompsett From julian.maurice at biblibre.com Thu Aug 9 09:41:26 2012 From: julian.maurice at biblibre.com (Julian Maurice) Date: Thu, 09 Aug 2012 09:41:26 +0200 Subject: [Koha-devel] Serials Work RFC - Storing Enumeration Data In-Reply-To: References: Message-ID: <502369A6.4040009@biblibre.com> Le 08/08/2012 21:35, Kyle Hall a ?crit : > Hello All, > I'm working with a library that is having problems running reports > based on serials enumeration data, and I was hoping to get some > feedback on an idea I have. > > Right now, we store the enumeration format in > subscription.numberingmethod ( e.g. "Vol {X}, No {Y}, Issue {Z}" ). > When the serial is received, the X, Y and Z are replaced with real > values and this is stored in serials.serialseq and items.enumchron, > I'm wondering if it would be better to store this data in separate > columns instead. > > 1. Add columns x_description, y_description, and z_description to the > table subscription. In the above example these would contain 'Vol', > 'No', and 'Issue' respectively. > 2. Add columns x_data, y_data and z_data to the table issues. So for > "Vol 5, No 2, Issue 7", these columns would be 5, 2 and 7 > respectively. > 3. Retrospectively parse subscription.numberingmethod into > x_description, y_description, and z_description > 4. Retrospectively parse serials.serialseq into x_data, y_data and z_data > > At this point, we could get rid of serials.serialseq, or we could keep > it alongside this new data. I would lean toward keeping it as we > cannot guarantee step 4 will work right, as a librarian can modify > serials.serialseq by hand when receiving the item. > > The question is: is this a good idea, or a stupid idea? > > Please let me know either way! > > Thanks, > Kyle > I think it's a good idea generally to store 'basic' informations that could generate other informations, instead of storing only one generated data that we can only use for displaying purposes. But before starting working at this, please take a look at Bug 7688 (if you haven't yet). It allow to store numbering pattern in database instead of having them hard-coded. In particular, description of X, Y and Z are stored (so 1st point is already done ;)) -- Julian Maurice BibLibre From nengard at gmail.com Thu Aug 9 12:51:17 2012 From: nengard at gmail.com (Nicole Engard) Date: Thu, 9 Aug 2012 06:51:17 -0400 Subject: [Koha-devel] Serials Work RFC - Storing Enumeration Data In-Reply-To: <502369A6.4040009@biblibre.com> References: <502369A6.4040009@biblibre.com> Message-ID: I would say that items.enumeration should still have the formatted version, but I like the idea of splitting in the serials table. Nicole Sent from my Nexus 7 tablet. Please excuse brevity and typos. On Aug 9, 2012 3:41 AM, "Julian Maurice" wrote: > Le 08/08/2012 21:35, Kyle Hall a ?crit : > >> Hello All, >> I'm working with a library that is having problems running reports >> based on serials enumeration data, and I was hoping to get some >> feedback on an idea I have. >> >> Right now, we store the enumeration format in >> subscription.numberingmethod ( e.g. "Vol {X}, No {Y}, Issue {Z}" ). >> When the serial is received, the X, Y and Z are replaced with real >> values and this is stored in serials.serialseq and items.enumchron, >> I'm wondering if it would be better to store this data in separate >> columns instead. >> >> 1. Add columns x_description, y_description, and z_description to the >> table subscription. In the above example these would contain 'Vol', >> 'No', and 'Issue' respectively. >> 2. Add columns x_data, y_data and z_data to the table issues. So for >> "Vol 5, No 2, Issue 7", these columns would be 5, 2 and 7 >> respectively. >> 3. Retrospectively parse subscription.numberingmethod into >> x_description, y_description, and z_description >> 4. Retrospectively parse serials.serialseq into x_data, y_data and z_data >> >> At this point, we could get rid of serials.serialseq, or we could keep >> it alongside this new data. I would lean toward keeping it as we >> cannot guarantee step 4 will work right, as a librarian can modify >> serials.serialseq by hand when receiving the item. >> >> The question is: is this a good idea, or a stupid idea? >> >> Please let me know either way! >> >> Thanks, >> Kyle >> >> > I think it's a good idea generally to store 'basic' informations that > could generate other informations, instead of storing only one generated > data that we can only use for displaying purposes. > > But before starting working at this, please take a look at Bug 7688 (if > you haven't yet). It allow to store numbering pattern in database > instead of having them hard-coded. In particular, description of X, Y > and Z are stored (so 1st point is already done ;)) > > -- > Julian Maurice > BibLibre > ______________________________**_________________ > Koha-devel mailing list > Koha-devel at lists.koha-**community.org > http://lists.koha-community.**org/cgi-bin/mailman/listinfo/**koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.**org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fridolyn.somers at biblibre.com Thu Aug 9 16:03:04 2012 From: fridolyn.somers at biblibre.com (Fridolyn SOMERS) Date: Thu, 09 Aug 2012 16:03:04 +0200 Subject: [Koha-devel] is hidelostitems syspref obsolete? Message-ID: <5023C318.7040600@biblibre.com> Hie, I wonder if with the 'OpacHiddenItems' system preference, you can reproduce what's managed by 'hidelostitems' system preference. For example, if LOST values are 0,1,2,3 (0 meaning not lost), you can use in OpacHiddenItems : itemslost [1, 2, 3]. So can we imagine removing 'hidelostitems' ? Best regards. -- Fridolyn SOMERS Biblibre - P?le Support fridolyn.somers at biblibre.com -------------- section suivante -------------- Une pi?ce jointe HTML a ?t? nettoy?e... URL: From paul.a at aandc.org Thu Aug 9 18:05:20 2012 From: paul.a at aandc.org (Paul) Date: Thu, 09 Aug 2012 12:05:20 -0400 Subject: [Koha-devel] 3.8.3 dependencies In-Reply-To: References: <5022CAA7.5020300@catalyst.net.nz> <5.2.1.1.2.20120808105248.03cae2b0@stormy.ca> <5.2.1.1.2.20120808160034.03356350@localhost> <5022CAA7.5020300@catalyst.net.nz> Message-ID: <5.2.1.1.2.20120808194323.030029a0@localhost> Tomas and Robin, Thanks for the replies. My comments below: At 05:42 PM 8/8/2012 -0300, Tomas Cohen Arazi wrote: >Robin, >On Wed, Aug 8, 2012 at 5:23 PM, Robin Sheat wrote: > > Op 08-08-12 22:09, Paul schreef: > >> > >> WARNING: on the 64-bit Ubuntu 12.04, do not attempt an apt-get install > >> of libyaz4-dev_4.2.18-1build1_i386.deb - I ended up with a bunch of > >> files fragments to purge, found with sudo dpkg --configure -a > >> > >> Strangely, libgraphics-magick-perl did not fully install (it's also got > >> some i386 bits that 64-bit Ubuntu 12.04 won't digest) but it does get > >> far enough to (apparently) meet Koha 3.8.3 dependencies. > > > > You shouldn't be touching i386 packages on a 64-bit machine unless you > > really know what you're doing. libgraphics-magick-perl should be pure 64 > > bit. Better, don't install .deb files of things that are in your apt > > repo anyway. I don't go near i386 packages and I rarely use apt-get install -f -- I read the "missing dependencies" and look for them myself. However, it would appear that the Ubuntu/Debian apt-get *can* have ideas of its own and install bits of i386 code (presumably they're quite compatible, as it is either the 64-bit packages that install some of them, or apt-get installs them without advance warning; remember "i386|amd64" is not normally part of the command line.) A bit off-topic, but until recently the Flash player was only 32 bit, and I think Skype still is. >I found the ubuntu.packages to cause that behaviour on 64bit setups. I >also found that fixing the libyaz (and some libmysqlXX-dev) versions >fixed it. I didn't talk about it as Mark was revisiting those packages >files for several ubuntu releases and the side effect was that it got >fixed. Mark and I talked about that fixes on IRC. I have found a solution (64-bit) for GraphicsMagick -- it needs (believe it or not) the Windows MetaFile component: Add http://mirrors.us.kernel.org precise main to /etc/apt/sources list $ apt-get install libwmf0.2-7 libgraphicsmagick3 libgraphics-magick-perl These are in fact (from /var/cache/apt/archives/): libwmf0.2-7_0.2.8.4-10ubuntu1_amd64.deb libgraphicsmagick3_1.3.12-1.1build1_amd64.deb libgraphics-magick-perl_1.3.12-1.1build1_amd64.deb >I don't know if it has been pushed into master (and 3.8.x) right now >but I recommend using koha_perl_deps.pl and searching for the right >packages until the fixed files get pushed. > >Paul: try > >$ dpkg -l | grep 386 None ... Again thanks and best regards, Paul From robin at catalyst.net.nz Thu Aug 9 18:10:42 2012 From: robin at catalyst.net.nz (Robin Sheat) Date: Thu, 09 Aug 2012 18:10:42 +0200 Subject: [Koha-devel] 3.8.3 dependencies In-Reply-To: <5.2.1.1.2.20120808194323.030029a0@localhost> References: <5022CAA7.5020300@catalyst.net.nz> <5.2.1.1.2.20120808105248.03cae2b0@stormy.ca> <5.2.1.1.2.20120808160034.03356350@localhost> <5022CAA7.5020300@catalyst.net.nz> <5.2.1.1.2.20120808194323.030029a0@localhost> Message-ID: <5023E102.1010703@catalyst.net.nz> Op 09-08-12 18:05, Paul schreef: > Add http://mirrors.us.kernel.org precise main to /etc/apt/sources list > $ apt-get install libwmf0.2-7 libgraphicsmagick3 libgraphics-magick-perl There are all in regular Ubuntu: $ apt-cache show libwmf0.2-7 libgraphicsmagick3 libgraphics-magick-perl | grep Filename Filename: pool/main/libw/libwmf/libwmf0.2-7_0.2.8.4-10ubuntu1_amd64.deb Filename: pool/universe/g/graphicsmagick/libgraphicsmagick3_1.3.12-1.1build1_amd64.deb Filename: pool/universe/g/graphicsmagick/libgraphics-magick-perl_1.3.12-1.1build1_amd64.deb -- Robin Sheat Catalyst IT Ltd. ? +64 4 803 2204 GPG: 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D From mtj at kohaaloha.com Fri Aug 10 10:28:57 2012 From: mtj at kohaaloha.com (Mason James) Date: Fri, 10 Aug 2012 20:28:57 +1200 Subject: [Koha-devel] is hidelostitems syspref obsolete? In-Reply-To: <5023C318.7040600@biblibre.com> References: <5023C318.7040600@biblibre.com> Message-ID: On 2012-08-10, at 2:03 AM, Fridolyn SOMERS wrote: > Hie, > > I wonder if with the 'OpacHiddenItems' system preference, you can reproduce what's managed by 'hidelostitems' system preference. > For example, if LOST values are 0,1,2,3 (0 meaning not lost), you can use in OpacHiddenItems : > itemslost [1, 2, 3]. > > So can we imagine removing 'hidelostitems' ? hmm, yes - i think so there are 2 OPAC system preferences... the behavior in 'hidelostitems' can be created using the 'OpacHiddenItems' pref? so, lets remove the 'hidelostitems ' pref? -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 535 bytes Desc: This is a digitally signed message part URL: From chris at bigballofwax.co.nz Fri Aug 10 10:31:52 2012 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Fri, 10 Aug 2012 20:31:52 +1200 Subject: [Koha-devel] is hidelostitems syspref obsolete? In-Reply-To: References: <5023C318.7040600@biblibre.com> Message-ID: On 10 August 2012 20:28, Mason James wrote: > > On 2012-08-10, at 2:03 AM, Fridolyn SOMERS wrote: > >> Hie, >> >> I wonder if with the 'OpacHiddenItems' system preference, you can reproduce what's managed by 'hidelostitems' system preference. >> For example, if LOST values are 0,1,2,3 (0 meaning not lost), you can use in OpacHiddenItems : >> itemslost [1, 2, 3]. >> >> So can we imagine removing 'hidelostitems' ? > > hmm, yes - i think so > > > there are 2 OPAC system preferences... > the behavior in 'hidelostitems' can be created using the 'OpacHiddenItems' pref? > > > so, lets remove the 'hidelostitems ' pref? > > If you are going to do that, please make sure that you don't make all the libraries now have to go through and set things up. It must be done automatically and with no loss of functionality. Removing a feature people are using is only acceptable if it is done in a way that is seamless and doesn't cause them a whole pile of work. Chris From fridolyn.somers at biblibre.com Fri Aug 10 12:34:14 2012 From: fridolyn.somers at biblibre.com (Fridolyn SOMERS) Date: Fri, 10 Aug 2012 12:34:14 +0200 Subject: [Koha-devel] is hidelostitems syspref obsolete? In-Reply-To: References: <5023C318.7040600@biblibre.com> Message-ID: <5024E3A6.3010209@biblibre.com> Hie, I agree it must be painless. But I propose it because it is difficult to maintain both features in code. So removing it will lead to less debugs (I hope). I was thinking of the migration : 1/ If 'hidelostitems' is false, juste remove it. 2/ If 'hidelostitems' is true and 'OpacHiddenItems' is empty : Add in 'OpacHiddenItems' the list of LOST authorised value without the '0' (if exists). 3/ If 'hidelostitems' is true and 'OpacHiddenItems' is not empty : Check if 'OpacHiddenItems' contains itemslost ? If not can we do like n?2 ? Best regards, Fridolyn SOMERS Biblibre - P?le Support fridolyn.somers at biblibre.com Le 10/08/2012 10:31, Chris Cormack a ?crit : > On 10 August 2012 20:28, Mason James wrote: >> On 2012-08-10, at 2:03 AM, Fridolyn SOMERS wrote: >> >>> Hie, >>> >>> I wonder if with the 'OpacHiddenItems' system preference, you can reproduce what's managed by 'hidelostitems' system preference. >>> For example, if LOST values are 0,1,2,3 (0 meaning not lost), you can use in OpacHiddenItems : >>> itemslost [1, 2, 3]. >>> >>> So can we imagine removing 'hidelostitems' ? >> hmm, yes - i think so >> >> >> there are 2 OPAC system preferences... >> the behavior in 'hidelostitems' can be created using the 'OpacHiddenItems' pref? >> >> >> so, lets remove the 'hidelostitems ' pref? >> >> > If you are going to do that, please make sure that you don't make all > the libraries now have to go through and set things up. It must be > done automatically and with no loss of functionality. Removing a > feature people are using is only acceptable if it is done in a way > that is seamless and doesn't cause them a whole pile of work. > > Chris -------------- section suivante -------------- Une pi?ce jointe HTML a ?t? nettoy?e... URL: From fridolyn.somers at biblibre.com Fri Aug 10 12:37:52 2012 From: fridolyn.somers at biblibre.com (Fridolyn SOMERS) Date: Fri, 10 Aug 2012 12:37:52 +0200 Subject: [Koha-devel] is hidelostitems syspref obsolete? In-Reply-To: <5024E3A6.3010209@biblibre.com> References: <5023C318.7040600@biblibre.com> <5024E3A6.3010209@biblibre.com> Message-ID: <5024E480.4030207@biblibre.com> created Bug 8619: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8619 Fridolyn SOMERS Biblibre - P?le Support fridolyn.somers at biblibre.com Le 10/08/2012 12:34, Fridolyn SOMERS a ?crit : > Hie, I agree it must be painless. > > But I propose it because it is difficult to maintain both features in > code. So removing it will lead to less debugs (I hope). > > I was thinking of the migration : > > 1/ > If 'hidelostitems' is false, juste remove it. > > 2/ > If 'hidelostitems' is true and 'OpacHiddenItems' is empty : > Add in 'OpacHiddenItems' the list of LOST authorised value without the > '0' (if exists). > > 3/ > If 'hidelostitems' is true and 'OpacHiddenItems' is not empty : > Check if 'OpacHiddenItems' contains itemslost ? > If not can we do like n?2 ? > > Best regards, > > Fridolyn SOMERS > Biblibre - P?le Support > fridolyn.somers at biblibre.com > Le 10/08/2012 10:31, Chris Cormack a ?crit : >> On 10 August 2012 20:28, Mason James wrote: >>> On 2012-08-10, at 2:03 AM, Fridolyn SOMERS wrote: >>> >>>> Hie, >>>> >>>> I wonder if with the 'OpacHiddenItems' system preference, you can reproduce what's managed by 'hidelostitems' system preference. >>>> For example, if LOST values are 0,1,2,3 (0 meaning not lost), you can use in OpacHiddenItems : >>>> itemslost [1, 2, 3]. >>>> >>>> So can we imagine removing 'hidelostitems' ? >>> hmm, yes - i think so >>> >>> >>> there are 2 OPAC system preferences... >>> the behavior in 'hidelostitems' can be created using the 'OpacHiddenItems' pref? >>> >>> >>> so, lets remove the 'hidelostitems ' pref? >>> >>> >> If you are going to do that, please make sure that you don't make all >> the libraries now have to go through and set things up. It must be >> done automatically and with no loss of functionality. Removing a >> feature people are using is only acceptable if it is done in a way >> that is seamless and doesn't cause them a whole pile of work. >> >> Chris > > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ -------------- section suivante -------------- Une pi?ce jointe HTML a ?t? nettoy?e... URL: From giamik at vfemail.net Sun Aug 12 19:29:46 2012 From: giamik at vfemail.net (George Mikuchadze) Date: Sun, 12 Aug 2012 21:29:46 +0400 Subject: [Koha-devel] gmail as smtp error In-Reply-To: References: <015401cd77c9$c36265f0$4a2731d0$@vfemail.net> Message-ID: <000301cd78b0$1334ff70$399efe50$@vfemail.net> Dear Chris, Thanks for reply: 1. The case of the delivery failure is very strange: Message is sent from the legal gmail address, which is indicated in the process_message_queue.pl parameters (for example: process_message_queue.pl -u library at sciencelib.ge -p password -m LOGIN) and the failure message I get in the library at sciencelib.ge mailbox. What about host file, the host has not routable ip (192.168.1.xx ) - it's a test system for using gmail as mailing server. 2. What about backporting the mods I've changed process_message_queue.pl script as described in the Bug 5251. But in C4/Letters.pm module (for koha v3.0) I 've made the following changes: I've replaced the "sub _send_message_by_email()" by the one from the koha v3.2 and only after added described lines. I'm not sure that it's a correct action. Best Regards George Mikuchadze -----Original Message----- From: Chris Nighswonger [mailto:cnighswonger at foundations.edu] Sent: Saturday, August 11, 2012 7:54 PM To: George Mikuchadze Cc: chris at bigballofwax.co.nz; koha at lists.katipo.co.nz Subject: Re: gmail as smtp error Hi George, Please always include the list on your emails as you will get more eyes on the problem as well as everyone benefiting from the answers. On Sat, Aug 11, 2012 at 10:01 AM, George Mikuchadze wrote: > Delivery to the following recipient failed permanently: > > koha at localhost.localhost or root at localhost.localhost (localhost > means result of `hostname` command) > > > Technical details of permanent failure: > > DNS Error: Domain name not found > It looks like your hostname is not set to a resolvable domain name. I'd take a look at the host file to be sure things there are in order. localhost is definitely not going to resolve on any public network. > > As I understand koha can?t get right patrons email. > As for koha not retrieving patrons' emails correctly, I'm not sure there either. I would suggest going over the section on notices in the manual (http://manual.koha-community.org/3.6/en/cronjobsch.html#noticescron) as there are a variety of options and sysprefs related to notices which must be properly configured in order for them to work correctly. My guess is that something is not configured correctly. > > How to configure koha 3.0 (prior to 3.2) to use gmail as smtp server? > This is probably not possible without backporting the mods in this commit: http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=d31c1603cca45c4f4b5b9fa8b2a1785e81f6da05 Even then, there may be other issues which crop up. Kind Regards, Chris From chris.nighswonger at gmail.com Sun Aug 12 21:43:31 2012 From: chris.nighswonger at gmail.com (Christopher Nighswonger) Date: Sun, 12 Aug 2012 15:43:31 -0400 Subject: [Koha-devel] gmail as smtp error In-Reply-To: <000301cd78b0$1334ff70$399efe50$@vfemail.net> References: <015401cd77c9$c36265f0$4a2731d0$@vfemail.net> <000301cd78b0$1334ff70$399efe50$@vfemail.net> Message-ID: On Sun, Aug 12, 2012 at 1:29 PM, George Mikuchadze wrote: > 1. The case of the delivery failure is very strange: > > Message is sent from the legal gmail address, which is indicated in the process_message_queue.pl parameters (for example: > process_message_queue.pl -u library at sciencelib.ge -p password -m LOGIN) and the failure message I get in the library at sciencelib.ge mailbox. > What about host file, the host has not routable ip (192.168.1.xx ) - it's a test system for using gmail as mailing server. Did you check out the note at the end of the CONFIGURE.gmail file? Sorry I cannot be of more help here, but this is most likely a problem with your local smtp server configuration. > > 2. What about backporting the mods > I've changed process_message_queue.pl script as described in the Bug 5251. > But in C4/Letters.pm module (for koha v3.0) I 've made the following changes: > I've replaced the "sub _send_message_by_email()" by the one from the koha v3.2 and only after added described lines. I'm sorry, but I really do not have the time necessary to walk you through a backport or to do it myself. There are plenty of vendors who offer this sort of service for Koha, however. Please see http://koha-community.org/support/paid-support/ for a list. Kind Regards, Chris From giamik at vfemail.net Mon Aug 13 12:30:04 2012 From: giamik at vfemail.net (George Mikuchadze) Date: Mon, 13 Aug 2012 14:30:04 +0400 Subject: [Koha-devel] gmail as smtp error In-Reply-To: References: <015401cd77c9$c36265f0$4a2731d0$@vfemail.net> <000301cd78b0$1334ff70$399efe50$@vfemail.net> Message-ID: <000601cd793e$9d90faf0$d8b2f0d0$@vfemail.net> Dear Chris, Thanks a lot. I use nullmailer as mta agent on the server and it works with no problems. I send mails from the server to any mail address using gmail account (library at sciencelib.ge). I cannot understand what kind of smtp server configuration You imply. Note about increasing debug level in Mail/Sendmail.pm I've also read. Best regards George Mikuchadze -----Original Message----- From: Christopher Nighswonger [mailto:chris.nighswonger at gmail.com] Sent: Sunday, August 12, 2012 11:44 PM To: George Mikuchadze Cc: koha-devel at lists.koha-community.org Subject: Re: [Koha-devel] gmail as smtp error On Sun, Aug 12, 2012 at 1:29 PM, George Mikuchadze wrote: > 1. The case of the delivery failure is very strange: > > Message is sent from the legal gmail address, which is indicated in the process_message_queue.pl parameters (for example: > process_message_queue.pl -u library at sciencelib.ge -p password -m LOGIN) and the failure message I get in the library at sciencelib.ge mailbox. > What about host file, the host has not routable ip (192.168.1.xx ) - it's a test system for using gmail as mailing server. Did you check out the note at the end of the CONFIGURE.gmail file? Sorry I cannot be of more help here, but this is most likely a problem with your local smtp server configuration. > > 2. What about backporting the mods > I've changed process_message_queue.pl script as described in the Bug 5251. > But in C4/Letters.pm module (for koha v3.0) I 've made the following changes: > I've replaced the "sub _send_message_by_email()" by the one from the koha v3.2 and only after added described lines. I'm sorry, but I really do not have the time necessary to walk you through a backport or to do it myself. There are plenty of vendors who offer this sort of service for Koha, however. Please see http://koha-community.org/support/paid-support/ for a list. Kind Regards, Chris From claire.hernandez at biblibre.com Tue Aug 14 14:49:13 2012 From: claire.hernandez at biblibre.com (Claire Hernandez) Date: Tue, 14 Aug 2012 14:49:13 +0200 Subject: [Koha-devel] KOCT translatable, please translate ! In-Reply-To: <50114B10.30905@biblibre.com> References: <500E770B.30903@biblibre.com> <50113775.8060709@biblibre.com> <50114B10.30905@biblibre.com> Message-ID: <502A4949.8040705@biblibre.com> On 26/07/2012 15:50, Claire Hernandez wrote: > On 26/07/2012 14:26, Paul Poulain wrote: >> The translations of KOCT to: spanish, gallician and italian have been >> pushed. >> >> Jonathan or Claire should publish soon the KOCT 0.23 on mozilla.org, >> with them. > For information, I will package the whole thing after holidays (> week > 33). > > Claire; Hello, KOCT 0.2.3 packaged and published on mozilla. Paul, it would be great I think to tag the repository with "koct_0.2.3" (for example) after application of the patch I sent you (install.rdf update). Thanks, Claire. From danielg.koha at gmail.com Thu Aug 16 01:45:37 2012 From: danielg.koha at gmail.com (Daniel Grobani) Date: Wed, 15 Aug 2012 16:45:37 -0700 Subject: [Koha-devel] Call for News for the August Newsletter Message-ID: Dear Koha Kommunitarians, I'm harvesting news for this month's newsletter. Please send me by the 25th anything you think your fellow community members might like to know about. "News" can be as short as a sentence or as long as a paper. I especially encourage you to send me a line or two for the gossip/society column about what you're currently working on. And if you know of a go-live not announced on the list, please be sure to let me know about it. Thanks, Daniel Grobani From koha.sekjal at gmail.com Fri Aug 17 16:57:07 2012 From: koha.sekjal at gmail.com (Ian Walls) Date: Fri, 17 Aug 2012 10:57:07 -0400 Subject: [Koha-devel] Officially supported OS versions Message-ID: Koha Developers, As I try to get back in the swing of things after a long absence, I'm finding a lot of changes to Koha's dependencies to be particularly frustrating, as I need to add new package repositories or even upgrade my OS. This leads me to the question: What OS versions does Koha run on? This is both a descriptive question (what's true now) as well as a prescriptive one (what systems SHOULD Koha run on). I should think that Debian 6+ is a given. Any current Ubuntu LTS may also be appropriate, though the current situation has me unable to install a dependency on 10.04. In the past, I know that RedHat installs have been particularly vicious, and may not even be possible at this time. Having a list of supported OS versions would simplify the lives of the QA team, because we would only need to test those systems that we've agreed to support. If someone can get Koha working on another OS, more power to them, but I think it's reasonable for people with moderate technical skills to be able to get Koha up and running on recommended systems without too many steps. One implication of this would be that patches introducing dependencies not easily available on a supported system would be rejected or deferred until such time as they were easily available. So, for example, if a patch introduced a dependency that's packaged for Debian Wheezy, but not for Squeeze, it would not be added to Koha until Wheezy was released. Thoughts, ideas, concerns, questions? -Ian -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmc at esilibrary.com Fri Aug 17 18:31:54 2012 From: gmc at esilibrary.com (Galen Charlton) Date: Fri, 17 Aug 2012 12:31:54 -0400 Subject: [Koha-devel] Officially supported OS versions In-Reply-To: References: Message-ID: <502E71FA.30401@esilibrary.com> Hi, On 08/17/2012 10:57 AM, Ian Walls wrote: > As I try to get back in the swing of things after a long absence, I'm > finding a lot of changes to Koha's dependencies to be particularly > frustrating, as I need to add new package repositories or even upgrade > my OS. As a data point for your descriptive question, Equinox uses Debian stable for Koha instance we host. > This leads me to the question: What OS versions does Koha run on? This > is both a descriptive question (what's true now) as well as a > prescriptive one (what systems SHOULD Koha run on). > > I should think that Debian 6+ is a given. I suggest expressing it more generically -- say "Koha is supported on Debian stable" (natch) or "Koha is supported on Debian stable and oldstable" (which would be my preference. > Any current Ubuntu LTS may > also be appropriate, though the current situation has me unable to > install a dependency on 10.04. I suggest targeting the current and the immediate previous LTS, with the LTS third-back being optional. > In the past, I know that RedHat installs > have been particularly vicious, and may not even be possible at this time. I think RHEL/Fedora/CentOS support is basically dependent on enough people stepping up who are willing to maintain it. > One implication of this would be that patches introducing dependencies > not easily available on a supported system would be rejected or deferred > until such time as they were easily available. So, for example, if a > patch introduced a dependency that's packaged for Debian Wheezy, but not > for Squeeze, it would not be added to Koha until Wheezy was released. I think that's a little too strict -- since most of Koha's dependencies are pure Perl modules, the bar for getting a module packaged for newstable into stable-backports is relatively low. In other words, I suggest we target Debian stable + stable-backports (and oldstable + oldstable-backports). Regards, Galen -- Galen Charlton Director of Support and Implementation Equinox Software, Inc. / The Open Source Experts email: gmc at 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 From M.de.Rooy at rijksmuseum.nl Fri Aug 17 18:32:35 2012 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Fri, 17 Aug 2012 16:32:35 +0000 Subject: [Koha-devel] Officially supported OS versions In-Reply-To: References: Message-ID: <809BE39CD64BFD4EB9036172EBCCFA310E0B56C3@S-MAIL-1B.rijksmuseum.intra> I am running on FC16. (But with some manual cpan installing sometimes..) Currently, often new dependencies creep quite silently into Koha. PerlDependencies.pm is updated afterwards in a followup or so. Developers later on stumble over it while git-fetching and upgrading. I agree that we could/should improve this situation. Communicate first before sending a patch with a new dependency? Marcel ________________________________ Van: koha-devel-bounces at lists.koha-community.org [koha-devel-bounces at lists.koha-community.org] namens Ian Walls [koha.sekjal at gmail.com] Verzonden: vrijdag 17 augustus 2012 16:57 To: koha-devel at lists.koha-community.org Onderwerp: [Koha-devel] Officially supported OS versions Koha Developers, As I try to get back in the swing of things after a long absence, I'm finding a lot of changes to Koha's dependencies to be particularly frustrating, as I need to add new package repositories or even upgrade my OS. This leads me to the question: What OS versions does Koha run on? This is both a descriptive question (what's true now) as well as a prescriptive one (what systems SHOULD Koha run on). I should think that Debian 6+ is a given. Any current Ubuntu LTS may also be appropriate, though the current situation has me unable to install a dependency on 10.04. In the past, I know that RedHat installs have been particularly vicious, and may not even be possible at this time. Having a list of supported OS versions would simplify the lives of the QA team, because we would only need to test those systems that we've agreed to support. If someone can get Koha working on another OS, more power to them, but I think it's reasonable for people with moderate technical skills to be able to get Koha up and running on recommended systems without too many steps. One implication of this would be that patches introducing dependencies not easily available on a supported system would be rejected or deferred until such time as they were easily available. So, for example, if a patch introduced a dependency that's packaged for Debian Wheezy, but not for Squeeze, it would not be added to Koha until Wheezy was released. Thoughts, ideas, concerns, questions? -Ian -------------- next part -------------- An HTML attachment was scrubbed... URL: From mtompset at hotmail.com Fri Aug 17 18:53:58 2012 From: mtompset at hotmail.com (Mark Tompsett) Date: Sat, 18 Aug 2012 00:53:58 +0800 Subject: [Koha-devel] Officially supported OS versions In-Reply-To: References: Message-ID: Greetings, I am an Ubuntu user. Koha runs well under 10.04 (3.6.x) and 12.04 (3.6.x, 3.8.x), though there are some quirks for the dependencies. This is remedied by taking the appropriate ?add a repo step? in wiki page here: http://wiki.koha-community.org/wiki/Koha_3.8_on_Debian_Squeeze#To_use It is important to make sure you have the correct repo added and the key installed. I typically have done tarball installs. Though, I am slowly coming around to the idea of koha-common in my Ubuntu environments. Admittedly, I needed something working, and didn?t have time to look at the koha-common install process. I have written a handy-dandy script (check_deps.sh) which uses apt-file to: 1) determine which is missing in {OS}.{version}.packages files ? though currently only debian and ubuntu have those kinds of files in the misc_install directory 2) determine what needs to be installed (can be apt-get?d) 3) determine what needs to be CPAN?d, because it?s not listed via apt-file. I can?t remember which bug report I attached it to. I also attempted an RPM-based version of it for yum (yuminstall.sh). However, the number of dependencies missing under CentOS 6.3 (5.8 won?t work by default, unless you upgrade perl) was just too high and my netbook too underpowered. I gave up on attempting Fedora because of my underpowered netbook. However, the script does list what is missing, and if there was man power to RPM package them (like that is going to happen), then it would be possible to support RPM-based OS?s too. However, given the man-power required. I don?t think it is recommended. In the past some people have exerted much effort trying to get it to run under Windows. Frankly, I use virtualbox with a wired connection as a bridged adapter, no need to get it to run natively. And again, I use Ubuntu on my VMs. The problem is that RPM-based OS? tend to be behind in releasing libraries. It is even worse for Windows versions (e.g. ActiveState? Perl). So, to summarize my take on preferences: 1) Debian 6+ first and foremost ? use packages (koha-common ? see wiki page above) if you aren?t developing, use git if you are. (http://wiki.koha-community.org/wiki/Version_Control_Using_Git) tarballs are a waste of your time (I had problems getting the tarball to build under debian ? yes, I tried for 3.6.3 ? but this was before I was aware of the koha-community repository.) 2) Ubuntu 10.04 and 12.04 LTS ? try to use packages, but at least set up the koha-community repository. Tarballs work, but are not recommended. 3) Some other DEB-based OS, though if given the choice, please choose Debian. Did I say how wonderful the packages were if you aren?t developing? And use git if you are? 4) If you have no other choice and must use something other than a DEB-based OS, tarball is your only option, and we make no promises that it will work or that we?ll be able to help you. So, what OS versions does Koha run on? Whatever you can get it to work on, but Debian 6+ and Ubuntu 10.04 LTS and Ubuntu 12.04 LTS are preferred. When Ubuntu 14.04 LTS comes out, it is my understanding that 10.04 support will be dropped. > One implication of this would be that patches introducing dependencies > not easily available on a supported system would be rejected or deferred > until such time as they were easily available. So, for example, if a patch > introduced a dependency that's packaged for Debian Wheezy, but not > for Squeeze, it would not be added to Koha until Wheezy was released. If it is merely a perl dependency, couldn?t it be packaged up on the koha-community repository? Wouldn?t a newer version in main replace the older koha-community version? I ask out of technical ignorance. If it behaves that way, then I don?t see why it would have to hold back a patch until an OS release. Hope this rambling is/was mildly useful. GPML, Mark Tompsett -------------- next part -------------- An HTML attachment was scrubbed... URL: From mtompset at hotmail.com Fri Aug 17 19:02:46 2012 From: mtompset at hotmail.com (Mark Tompsett) Date: Sat, 18 Aug 2012 01:02:46 +0800 Subject: [Koha-devel] Officially supported OS versions In-Reply-To: <502E71FA.30401@esilibrary.com> References: <502E71FA.30401@esilibrary.com> Message-ID: Greetings, > I suggest targeting the current and the immediate previous LTS, > with the LTS third-back being optional. I would suggest we don't go back the third LTS. Don't even acknowledge it. It's dead next year. Koha is newer than that. The further we go back, the more we have to support. From a support perspective, that's a potential nightmare. Not to mention, I had a bad time attempting 3.8.x on 8.04 -- I gave up after a few of dependency failures. GPML, Mark Tompsett From cnighswonger at foundations.edu Fri Aug 17 21:13:49 2012 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Fri, 17 Aug 2012 15:13:49 -0400 Subject: [Koha-devel] Officially supported OS versions In-Reply-To: References: Message-ID: On Fri, Aug 17, 2012 at 12:53 PM, Mark Tompsett wrote: > In the past some people have exerted much effort trying to get it to > run under Windows. Frankly, I use virtualbox with a wired connection as a > bridged adapter, no need to get it to run natively. And again, I use Ubuntu > on my VMs. The problem is that RPM-based OS? tend to be behind in releasing > libraries. It is even worse for Windows versions (e.g. ActiveState? Perl). > For the record: Should someone attempt running Koha on Win32, be sure to use Strawberry Perl as it has all of the mandatory packages available. Kind Regards, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From mtj at kohaaloha.com Fri Aug 17 23:22:03 2012 From: mtj at kohaaloha.com (Mason James) Date: Sat, 18 Aug 2012 09:22:03 +1200 Subject: [Koha-devel] Officially supported OS versions In-Reply-To: <502E71FA.30401@esilibrary.com> References: <502E71FA.30401@esilibrary.com> Message-ID: <662A556B-B8CF-42EE-A72B-5E1306577183@kohaaloha.com> On 2012-08-18, at 4:31 AM, Galen Charlton wrote: > Hi, > > On 08/17/2012 10:57 AM, Ian Walls wrote: >> As I try to get back in the swing of things after a long absence, I'm >> finding a lot of changes to Koha's dependencies to be particularly >> frustrating, as I need to add new package repositories or even upgrade >> my OS. > > As a data point for your descriptive question, Equinox uses Debian stable for Koha instance we host. > >> This leads me to the question: What OS versions does Koha run on? This >> is both a descriptive question (what's true now) as well as a >> prescriptive one (what systems SHOULD Koha run on). >> >> I should think that Debian 6+ is a given. > > I suggest expressing it more generically -- say "Koha is supported on Debian stable" (natch) or "Koha is supported on Debian stable and oldstable" (which would be my preference. 1+ for debian stable and old-stable, please :) cheers, Mason -- KohaAloha, NZ From tomascohen at gmail.com Fri Aug 17 23:31:59 2012 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Fri, 17 Aug 2012 18:31:59 -0300 Subject: [Koha-devel] Officially supported OS versions In-Reply-To: References: Message-ID: On Fri, Aug 17, 2012 at 11:57 AM, Ian Walls wrote: > Koha Developers, > > > As I try to get back in the swing of things after a long absence, I'm > finding a lot of changes to Koha's dependencies to be particularly > frustrating, as I need to add new package repositories or even upgrade my > OS. > > This leads me to the question: What OS versions does Koha run on? This is > both a descriptive question (what's true now) as well as a prescriptive one > (what systems SHOULD Koha run on). > > I should think that Debian 6+ is a given. Any current Ubuntu LTS may also > be appropriate, though the current situation has me unable to install a > dependency on 10.04. In the past, I know that RedHat installs have been > particularly vicious, and may not even be possible at this time. > > Having a list of supported OS versions would simplify the lives of the QA > team, because we would only need to test those systems that we've agreed to > support. If someone can get Koha working on another OS, more power to them, > but I think it's reasonable for people with moderate technical skills to be > able to get Koha up and running on recommended systems without too many > steps. > > One implication of this would be that patches introducing dependencies not > easily available on a supported system would be rejected or deferred until > such time as they were easily available. So, for example, if a patch > introduced a dependency that's packaged for Debian Wheezy, but not for > Squeeze, it would not be added to Koha until Wheezy was released. > > Thoughts, ideas, concerns, questions? +1 for supporting both Debian releases (stable and oldstable) and +1 for 'officially' supporting the last two LTS Ubuntu releases. When I say supporting the last two LTS releases I mean that we should develop with those in mind (creating the missing packages, etc). If a more recent (non-LTS) version has a package the LTS doesnt, we need to provide that package and not rely on people using the non-LTS... I belive this will make everything smoother to maintain, and we also have a very responsive community to assist those that have specific needs (e.g. their infrastructure uses X distro/version). As I was said several times: supporting every distro out-of-the-box would be great. If a distro becomes popular in our user base then we will find the way to suppport it (sponsors, interested companies, etc). Regards To+ From marc at msys.ch Sat Aug 18 07:50:04 2012 From: marc at msys.ch (Marc Balmer) Date: Sat, 18 Aug 2012 07:50:04 +0200 Subject: [Koha-devel] Officially supported OS versions In-Reply-To: <662A556B-B8CF-42EE-A72B-5E1306577183@kohaaloha.com> References: <502E71FA.30401@esilibrary.com> <662A556B-B8CF-42EE-A72B-5E1306577183@kohaaloha.com> Message-ID: <211697C1-9584-459C-9196-2A4DDC5E1AF8@msys.ch> another +1 for debian stable and oldstable -- Marc Balmer micro systems, http://www.msys.ch/ Tel. +41 61 383 05 10, Fax +41 61 383 05 12 Am 17.08.2012 um 23:22 schrieb Mason James : > > On 2012-08-18, at 4:31 AM, Galen Charlton wrote: > >> Hi, >> >> On 08/17/2012 10:57 AM, Ian Walls wrote: >>> As I try to get back in the swing of things after a long absence, I'm >>> finding a lot of changes to Koha's dependencies to be particularly >>> frustrating, as I need to add new package repositories or even upgrade >>> my OS. >> >> As a data point for your descriptive question, Equinox uses Debian stable for Koha instance we host. >> >>> This leads me to the question: What OS versions does Koha run on? This >>> is both a descriptive question (what's true now) as well as a >>> prescriptive one (what systems SHOULD Koha run on). >>> >>> I should think that Debian 6+ is a given. >> >> I suggest expressing it more generically -- say "Koha is supported on Debian stable" (natch) or "Koha is supported on Debian stable and oldstable" (which would be my preference. > > > 1+ for debian stable and old-stable, please :) > > > > cheers, Mason > -- > KohaAloha, NZ > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ From paul.a at aandc.org Sun Aug 19 21:36:06 2012 From: paul.a at aandc.org (Paul) Date: Sun, 19 Aug 2012 15:36:06 -0400 Subject: [Koha-devel] koha-zebra-daemon not starting Message-ID: <5.2.1.1.2.20120819152156.0346fdf8@stormy.ca> Koha 3.8.3 on Ubuntu 12.04 LTS server (new install, full upgrade) Everything went well on install. Data from 3.6.1 "converted" to 3.8.3 when I opened the staff-admin page; zebra reindex went well for authorities, but failed for biblios first time around: 14:27:16-19/08 zebraidx(3357) [warn] zebra_lock_create fail fname=/var/lock/koha/zebradb/biblios/norm..LCK [No such file or directory] 14:27:16-19/08 zebraidx(3357) [warn] zebra_lock_create fail fname=/var/lock/koha/zebradb/biblios/shadow..LCK [No such file or directory] 14:27:16-19/08 zebraidx(3357) [fatal] Could not select database biblios errCode=109 but after a reboot, rebuild_zebra.pl -b -r -v -x reported nothing fatal (single warning about a register not found, no details); cron job running normally. But neither OPAC nor staff search functions are operational. The only anomaly that I've found so far is that /etc/init.d/koha-zebra-daemon when run from the command line reports failure at line 73 (and does not create any error logs), but ps aux reports the daemon as running (well, "S+" -- sleep forground.) Anyone got any thoughts please? tnx and br - Paul From mtj at kohaaloha.com Mon Aug 20 04:24:41 2012 From: mtj at kohaaloha.com (Mason James) Date: Mon, 20 Aug 2012 14:24:41 +1200 Subject: [Koha-devel] koha-zebra-daemon not starting In-Reply-To: <5.2.1.1.2.20120819152156.0346fdf8@stormy.ca> References: <5.2.1.1.2.20120819152156.0346fdf8@stormy.ca> Message-ID: On 2012-08-20, at 7:36 AM, Paul wrote: > Koha 3.8.3 on Ubuntu 12.04 LTS server (new install, full upgrade) using what method? From paul.a at aandc.org Mon Aug 20 15:48:19 2012 From: paul.a at aandc.org (Paul) Date: Mon, 20 Aug 2012 09:48:19 -0400 Subject: [Koha-devel] koha-zebra-daemon not starting In-Reply-To: References: <5.2.1.1.2.20120819152156.0346fdf8@stormy.ca> <5.2.1.1.2.20120819152156.0346fdf8@stormy.ca> Message-ID: <5.2.1.1.2.20120820085329.053c5d38@localhost> At 02:24 PM 8/20/2012 +1200, Mason James wrote: >On 2012-08-20, at 7:36 AM, Paul wrote: > > Koha 3.8.3 on Ubuntu 12.04 LTS server (new install, full upgrade) >using what method? Apologies for the lack of clarity. In a nutshell: Ubuntu: latest ISO [ubuntu-12.04-server-amd64.iso, build 20120424.1 ] ==> CDRom, apt-get update, apt-get upgrade, apache2, perl, sendmail, mysql, yaz, idzebra-2.0 Koha: koha-3.08.03.tar.gz, install_misc/ubuntu.packages, make|test|install Koha db: mysql dump from production 3.6.1, restore, let Koha staff-admin "do its thing." Verify that "use zebra" is checked, re-index auths and biblios (separately), verify cron functions Everything (as far as I have verified so far) is fully functional, _EXCEPT_ OPAC and staff-admin search functions. I now have 3 servers running 3 different versions of Koha: 3.6.1 (production 64-bit machine), 3.6.7 (sandbox i386), and this latest 3.8.3 -- fyi, I've looked at users, groups, permissions (my first guess as to why zebra was non-funtional), compared with the two other installations and cannot see any obvious differences. My "end-game" is to get 3.8.3 onto the production server with the least possible downtime -- hence this trial on a near-identical 64-bit machine (6 core Intel i7-980X, solid state raided drives, 16Gb ram.) P. From tomascohen at gmail.com Mon Aug 20 16:47:29 2012 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Mon, 20 Aug 2012 11:47:29 -0300 Subject: [Koha-devel] koha-zebra-daemon not starting In-Reply-To: <5.2.1.1.2.20120819152156.0346fdf8@stormy.ca> References: <5.2.1.1.2.20120819152156.0346fdf8@stormy.ca> Message-ID: On Sun, Aug 19, 2012 at 4:36 PM, Paul wrote: > Koha 3.8.3 on Ubuntu 12.04 LTS server (new install, full upgrade) > > Everything went well on install. Data from 3.6.1 "converted" to 3.8.3 when > I opened the staff-admin page; zebra reindex went well for authorities, but > failed for biblios first time around: > > 14:27:16-19/08 zebraidx(3357) [warn] zebra_lock_create fail > fname=/var/lock/koha/zebradb/biblios/norm..LCK [No such file or directory] > 14:27:16-19/08 zebraidx(3357) [warn] zebra_lock_create fail > fname=/var/lock/koha/zebradb/biblios/shadow..LCK [No such file or directory] > 14:27:16-19/08 zebraidx(3357) [fatal] Could not select database biblios > errCode=109 > > but after a reboot, rebuild_zebra.pl -b -r -v -x reported nothing fatal > (single warning about a register not found, no details); cron job running > normally. > > But neither OPAC nor staff search functions are operational. > > The only anomaly that I've found so far is that > /etc/init.d/koha-zebra-daemon when run from the command line reports failure > at line 73 (and does not create any error logs), but ps aux reports the > daemon as running (well, "S+" -- sleep forground.) > > Anyone got any thoughts please? > > tnx and br - Paul You need to answer what method r u using for install. If using tarball, then you might be running the zebra daemon using de 'koha' user and 'koha' group. Do they exist? If this was the case, then this should create the missing dir: mkdir -p /var/lock/koha/zebradb/biblios/ ; chown -R koha:koha /var/lock/koha/zebradb/ Also (just in case): chown -R koha:koha /var/log/koha Also, every time you run rebuild_zebra.pl you should do it like: su - koha -c "KOHA_CONF=/etc/koha/koha-conf.xml PERL5LIB=/usr/share/koha/lib /usr/share/koha/bin/migration_tools/rebuild_zebra.pl -b -r -v -x" So everything is created with the right UID. Regards To+ From barry at oslo.ie Mon Aug 20 17:07:50 2012 From: barry at oslo.ie (Barry Cannon) Date: Mon, 20 Aug 2012 16:07:50 +0100 Subject: [Koha-devel] koha-zebra-daemon not starting In-Reply-To: References: <5.2.1.1.2.20120819152156.0346fdf8@stormy.ca> Message-ID: <503252C6.4090204@oslo.ie> Shouldn't running "zebrasrv -f /etc/koha/koha-conf.xml" (or whatever your path is) as the index owner give you a good indication of what is going on (it should at least get you pointed in the right direction as it should dump out the error to console) -Barry On 20/08/12 15:47, Tomas Cohen Arazi wrote: > On Sun, Aug 19, 2012 at 4:36 PM, Paul wrote: >> Koha 3.8.3 on Ubuntu 12.04 LTS server (new install, full upgrade) >> >> Everything went well on install. Data from 3.6.1 "converted" to 3.8.3 when >> I opened the staff-admin page; zebra reindex went well for authorities, but >> failed for biblios first time around: >> >> 14:27:16-19/08 zebraidx(3357) [warn] zebra_lock_create fail >> fname=/var/lock/koha/zebradb/biblios/norm..LCK [No such file or directory] >> 14:27:16-19/08 zebraidx(3357) [warn] zebra_lock_create fail >> fname=/var/lock/koha/zebradb/biblios/shadow..LCK [No such file or directory] >> 14:27:16-19/08 zebraidx(3357) [fatal] Could not select database biblios >> errCode=109 >> >> but after a reboot, rebuild_zebra.pl -b -r -v -x reported nothing fatal >> (single warning about a register not found, no details); cron job running >> normally. >> >> But neither OPAC nor staff search functions are operational. >> >> The only anomaly that I've found so far is that >> /etc/init.d/koha-zebra-daemon when run from the command line reports failure >> at line 73 (and does not create any error logs), but ps aux reports the >> daemon as running (well, "S+" -- sleep forground.) >> >> Anyone got any thoughts please? >> >> tnx and br - Paul > You need to answer what method r u using for install. If using > tarball, then you might be running the zebra daemon using de 'koha' > user and 'koha' group. Do they exist? If this was the case, then this > should create the missing dir: > > mkdir -p /var/lock/koha/zebradb/biblios/ ; chown -R koha:koha > /var/lock/koha/zebradb/ > > Also (just in case): > > chown -R koha:koha /var/log/koha > > Also, every time you run rebuild_zebra.pl you should do it like: > > su - koha -c "KOHA_CONF=/etc/koha/koha-conf.xml > PERL5LIB=/usr/share/koha/lib > /usr/share/koha/bin/migration_tools/rebuild_zebra.pl -b -r -v -x" > > So everything is created with the right UID. > > Regards > To+ > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ From marc at msys.ch Mon Aug 20 18:03:56 2012 From: marc at msys.ch (Marc Balmer) Date: Mon, 20 Aug 2012 18:03:56 +0200 Subject: [Koha-devel] =?utf-8?q?Disappearing_test_cases_or_did_another_par?= =?utf-8?q?t_of_MySQL_just_become_closed_source=3F_=C2=AB_The_MariaDB_Blog?= Message-ID: <671BA941-AD13-46E0-B07E-A542B6F74007@msys.ch> I stumbled over this blog entry: http://blog.mariadb.org/disappearing-test-cases/ It is this development of MySQL that make me so unhappy with the fact that Koha runs on MySQL only at the moment. Imo, Koha would be a much better product if it used PostgreSQL as the database system. -- Marc Balmer micro systems, http://www.msys.ch/ Tel. +41 61 383 05 10, Fax +41 61 383 05 12 From oleonard at myacpl.org Mon Aug 20 18:14:09 2012 From: oleonard at myacpl.org (Owen Leonard) Date: Mon, 20 Aug 2012 12:14:09 -0400 Subject: [Koha-devel] =?iso-8859-1?q?Disappearing_test_cases_or_did_anothe?= =?iso-8859-1?q?r_part_of_MySQL_just_become_closed_source=3F_=AB_Th?= =?iso-8859-1?q?e_MariaDB_Blog?= In-Reply-To: <671BA941-AD13-46E0-B07E-A542B6F74007@msys.ch> References: <671BA941-AD13-46E0-B07E-A542B6F74007@msys.ch> Message-ID: > Imo, Koha would be a much better product if it used PostgreSQL as the database system. Patches welcomed! -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org From chris.nighswonger at gmail.com Mon Aug 20 19:30:07 2012 From: chris.nighswonger at gmail.com (Christopher Nighswonger) Date: Mon, 20 Aug 2012 13:30:07 -0400 Subject: [Koha-devel] =?iso-8859-1?q?Disappearing_test_cases_or_did_anothe?= =?iso-8859-1?q?r_part_of_MySQL_just_become_closed_source=3F_=AB_Th?= =?iso-8859-1?q?e_MariaDB_Blog?= In-Reply-To: <671BA941-AD13-46E0-B07E-A542B6F74007@msys.ch> References: <671BA941-AD13-46E0-B07E-A542B6F74007@msys.ch> Message-ID: On Mon, Aug 20, 2012 at 12:03 PM, Marc Balmer wrote: > I stumbled over this blog entry: > > http://blog.mariadb.org/disappearing-test-cases/ > > It is this development of MySQL that make me so unhappy with the fact that Koha runs on MySQL only at the moment. > > Imo, Koha would be a much better product if it used PostgreSQL as the database system. > I'd bet the move to MariaDB will happen well before the move to PG unless opinions are accompanied by code. :-) MySQL is essentially closed source at this point anyway, and MariaDB is pretty much a drop-in replacement requiring only minimal changes. AAMOF I have a git branch hanging around somewhere with several patches to this end on it. Kind Regards, Chris From paul.a at aandc.org Tue Aug 21 01:36:57 2012 From: paul.a at aandc.org (Paul) Date: Mon, 20 Aug 2012 19:36:57 -0400 Subject: [Koha-devel] koha-zebra-daemon not starting In-Reply-To: References: <5.2.1.1.2.20120819152156.0346fdf8@stormy.ca> <5.2.1.1.2.20120819152156.0346fdf8@stormy.ca> Message-ID: <5.2.1.1.2.20120820184941.03366ab8@localhost> I've tried to keep this to a minimum, there is a 'conclusion' further down: At 11:47 AM 8/20/2012 -0300, Tomas and Barry wrote: >On Sun, Aug 19, 2012 at 4:36 PM, Paul wrote: > > Koha 3.8.3 on Ubuntu 12.04 LTS server (new install, full upgrade) >[snip] > > But neither OPAC nor staff search functions are operational. > > > > The only anomaly that I've found so far is that > > /etc/init.d/koha-zebra-daemon when run from the command line reports > failure > > at line 73 (and does not create any error logs), but ps aux reports the > > daemon as running (well, "S+" -- sleep forground.) > > > > Anyone got any thoughts please? > >You need to answer what method r u using for install. Pls see my earlier email [Mon, 20 Aug 2012 09:48:19 -0400] >If using >tarball, then you might be running the zebra daemon using de 'koha' >user and 'koha' group. Do they exist? If this was the case, then this >should create the missing dir: > >mkdir -p /var/lock/koha/zebradb/biblios/ ; chown -R koha:koha >/var/lock/koha/zebradb/ Yes - tarball, but the dir was already (correctly) there: paul at server:/var/lock/koha/zebradb$ ls -l total 0 drwxr-xr-x 2 koha koha 40 Aug 20 11:33 authorities drwxr-xr-x 2 koha koha 40 Aug 20 11:33 biblios >Also (just in case): >chown -R koha:koha /var/log/koha Again, correctly there: paul at server:/var/log$ ls -l | grep koha drwxr-xr-x 2 koha koha 4096 Aug 19 11:19 koha >Also, every time you run rebuild_zebra.pl you should do it like: > >su - koha -c "KOHA_CONF=/etc/koha/koha-conf.xml >PERL5LIB=/usr/share/koha/lib >/usr/share/koha/bin/migration_tools/rebuild_zebra.pl -b -r -v -x" What's the '-c'? (I don't think I've ever used this construct) and I don't think there's any difference, but I 'su koha' first, then 'cd usr/share/koha', then KOHA_CONF=/etc/koha/koha-conf.xml PERL5LIB=/usr/share/koha/lib ./bin/migration_tools/rebuild_zebra.pl -a -r -v and KOHA_CONF=/etc/koha/koha-conf.xml PERL5LIB=/usr/share/koha/lib ./bin/migration_tools/rebuild_zebra.pl -b -r -v -x and Barry Cannon wrote: >Shouldn't running "zebrasrv -f /etc/koha/koha-conf.xml" (or whatever your >path is) as the index owner give you a good indication of what is going on >(it should at least get you pointed in the right direction as it should >dump out the error to console) Interesting !!! or ;=} -- I tried that: koha at server:/$ zebrasrv -f /etc/koha/koha-conf.xml 11:51:06-20/08 [log] zebra_start 2.0.44 419ad759807269fdfa379799a051ed3a551c6541 11:51:06-20/08 [log] config /etc/koha/zebradb/zebra-biblios-dom.cfg 11:51:06-20/08 [log] Loaded filter module /usr/lib/idzebra-2.0/modules/mod-grs-xml.so [snip more filters for zebra-biblios-dom and zebra-authorities-dom 11:51:06-20/08 [server] Adding dynamic listener on unix:/var/run/koha/zebradb/bibliosocket id=1 11:51:06-20/08 [server] Adding dynamic listener on unix:/var/run/koha/zebradb/authoritysocket id=2 at which point that terminal just hangs on an ongoing op, but shows that the sockets were not previously opened. So, re-indexing again: for authorities: 25901................................ Records exported: 25933 ==================== REINDEXING zebra ==================== skipping biblios ==================== CLEANING ==================== and for biblios: 37301...........................................................................37401.................... Records exported: 37417 ==================== REINDEXING zebra ==================== 12:04:12-20/08 zebraidx(2841) [warn] Unknown register type: ==================== CLEANING ==================== Which corresponds to the ps aux | grep koha during the re-indexing: koha 2738 0.0 0.1 119084 4212 pts/2 S+ 12:01 0:00 su - koha -c KOHA_CONF=/etc/koha/koha-conf.xml PERL5LIB=/usr/share/koha/lib /usr/share/koha/bin/migration_tools/rebuild_zebra.pl -b -r -v -x koha 2747 73.8 1.4 259028 56272 pts/2 S+ 12:01 2:07 /usr/bin/perl /usr/share/koha/bin/migration_tools/rebuild_zebra.pl -b -r -v -x koha 2841 96.1 1.6 233556 64240 pts/2 Rl+ 12:04 0:27 zebraidx -c /etc/koha/zebradb/zebra-biblios-dom.cfg -v none,fatal,warn -g marcxml -d biblios update /tmp/q2UPWJgDrk/biblio and now we've got the search in OPAC and staff-admin finding the 37301 biblios. And I still don't know what the "[warn] Unknown register type: " might mean. Some hangover from 3.6.1 to 3.8.3? BUT ... the incremental cron (shows up in /var/log/syslog as working every 1 minute), does _NOT_ add new records. Conclusion: I'll keep going at this (half an hour here and there, it's our "tourist season", busiest time of the year) but somewhere, can't remember, there's something about Ubuntu 12.04 not renewing sockets, .LOKs, etc on reboot. Maybe I'm way off track, but it's the best avenue I have at the moment. Thoughts, please? Best - Paul From mtj at kohaaloha.com Tue Aug 21 07:21:28 2012 From: mtj at kohaaloha.com (Mason James) Date: Tue, 21 Aug 2012 17:21:28 +1200 Subject: [Koha-devel] koha-zebra-daemon not starting In-Reply-To: <5.2.1.1.2.20120820184941.03366ab8@localhost> References: <5.2.1.1.2.20120819152156.0346fdf8@stormy.ca> <5.2.1.1.2.20120819152156.0346fdf8@stormy.ca> <5.2.1.1.2.20120820184941.03366ab8@localhost> Message-ID: <08DE6856-3552-4FE0-BED1-6AE62FCD484A@kohaaloha.com> > > BUT ... the incremental cron (shows up in /var/log/syslog as working every 1 minute), does _NOT_ add new records. if you have problems setting up your cron stuff, use the debian packages the cron stuff works 'automagically' with the debian packages :) > > Conclusion: I'll keep going at this (half an hour here and there, it's our "tourist season", busiest time of the year) but somewhere, can't remember, there's something about Ubuntu 12.04 not renewing sockets, .LOKs, etc on reboot. Maybe I'm way off track, but it's the best avenue I have at the moment. Thoughts, please? > > Best - Paul From mtj at kohaaloha.com Tue Aug 21 09:14:12 2012 From: mtj at kohaaloha.com (Mason James) Date: Tue, 21 Aug 2012 19:14:12 +1200 Subject: [Koha-devel] =?iso-8859-1?q?Disappearing_test_cases_or_did_anothe?= =?iso-8859-1?q?r_part_of_MySQL_just_become_closed_source=3F_=AB_The_Maria?= =?iso-8859-1?q?DB_Blog?= In-Reply-To: References: <671BA941-AD13-46E0-B07E-A542B6F74007@msys.ch> Message-ID: <23069A4C-6B03-4F9D-9D79-C341873028E7@kohaaloha.com> On 2012-08-21, at 5:30 AM, Christopher Nighswonger wrote: > On Mon, Aug 20, 2012 at 12:03 PM, Marc Balmer wrote: >> I stumbled over this blog entry: >> >> http://blog.mariadb.org/disappearing-test-cases/ >> >> It is this development of MySQL that make me so unhappy with the fact that Koha runs on MySQL only at the moment. >> >> Imo, Koha would be a much better product if it used PostgreSQL as the database system. >> > > I'd bet the move to MariaDB will happen well before the move to PG > unless opinions are accompanied by code. :-) > > MySQL is essentially closed source at this point anyway, and MariaDB > is pretty much a drop-in replacement requiring only minimal changes. > AAMOF I have a git branch hanging around somewhere with several > patches to this end on it. > > Kind Regards, > Chris i would be happy to participate on either of these two tasks please consider making your development repos public :) From chris.nighswonger at gmail.com Tue Aug 21 13:28:29 2012 From: chris.nighswonger at gmail.com (Chris Nighswonger) Date: Tue, 21 Aug 2012 07:28:29 -0400 Subject: [Koha-devel] =?utf-8?q?Disappearing_test_cases_or_did_another_par?= =?utf-8?q?t_of_MySQL_just_become_closed_source=3F_=C2=AB_The_Maria?= =?utf-8?q?DB_Blog?= In-Reply-To: <23069A4C-6B03-4F9D-9D79-C341873028E7@kohaaloha.com> References: <671BA941-AD13-46E0-B07E-A542B6F74007@msys.ch> <23069A4C-6B03-4F9D-9D79-C341873028E7@kohaaloha.com> Message-ID: On Tue, Aug 21, 2012 at 3:14 AM, Mason James wrote: > > > > MySQL is essentially closed source at this point anyway, and MariaDB > > is pretty much a drop-in replacement requiring only minimal changes. > > AAMOF I have a git branch hanging around somewhere with several > > patches to this end on it. > > i would be happy to participate on either of these two tasks > > > please consider making your development repos public :) > > I'll dig around and post the mariadb patches. It appears that mariadb is a bit stricter syntactically than mysql. Kind Regards, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at bigballofwax.co.nz Tue Aug 21 22:50:44 2012 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Wed, 22 Aug 2012 08:50:44 +1200 Subject: [Koha-devel] Koha 3.8.4 released Message-ID: The Koha release team are proud to announce the release of 3.8.4. This is a maintenance release, and contains a lot of useful bug fixes. You can download the release from http://download.koha-community.org packages will be available shortly at http://debian.koha-community.org Please read below for the release notes. RELEASE NOTES FOR KOHA 3.8.4 22 Aug 2012 ======================================================================== Koha is the first free and open source software library automation package (ILS). Development is sponsored by libraries of varying types and sizes, volunteers, and support companies from around the world. The website for the Koha project is http://koha-community.org/ Koha 3.8.4 can be downloaded from: http://download.koha-community.org/koha-3.08.04.tar.gz Installation instructions can be found at: http://wiki.koha-community.org/wiki/Installation_Documentation OR in the INSTALL files that come in the tarball Koha 3.8.4 is a bugfix/maintenance release. Highlights of 3.8.4 ====================== 7943 blocker Untranslatable strings in OPAC's authority search 8486 blocker Critical error in Koha::Calendar::days_between calculation 8162 critical packaging scripts create user incorrectly 8251 critical Patrons are systematically debarred at checkin 8439 critical Printing basketgroup does not work on plack 8520 critical Authorities display incorrectly in staff results 8576 critical Software error on authority edition when using merge 8172 major Missing dereference marker for buildQuery parameter in addbooks.pl 8329 major GetLostItems in C4::Items.pm has a SELECT * 8414 major Intranet header toplinks display white rather than blue in < IE8 8448 major Holds Awaiting Pickup : Cancelling a hold on a waiting item with multiple holds displays a blank screen instead of a warning prompt 8503 major Software error n edit items with EasyAnalyticalRecords 8513 major OPAC detail page broken with XSLT 8547 major Enabling star ratings causes javascript errors that cause IE to have a boo boo 8572 major Attempting to view an invalid authority in the OPAC gives an error instead of 404 Bugs fixed in 3.8.4 ====================== 3383 normal Item due reminder digests - cannot display title information 6617 normal table of contents not printing right if entered right 7628 normal Required format is not enforced for Patron Categories 8391 normal Cannot view reading record through staff client 8419 normal Suspended holds appear on the daily holds queue 8434 normal Notice generation fails for Advanced Notices, Item Due, and Overdues when run in shell (due to error in Letters.pm) 8455 normal Check ins processed through "Check Out" tab of the Patron Record ignore Circulation System Preferences 8458 normal $stemmed_operand in C4::Search _build_stemmed_operand is not initialized. 8514 normal Display of patron results changed display order 8522 normal Markup errors cause problems with customized CSS 8532 normal Old/iffy data causes error checking out 8550 normal Z39.50 searches for ISBN/ISSN problematic 8573 normal Translation difficult in picture-upload.tt due to nested sentence in if/foreach/if/elsif - construction 8575 normal Number of items expected is wrong 8586 normal Small bug in die if no mapping in framework for biblioitems.biblioitemnumber 8590 normal checked out from missing on patron detail 3701 minor If the ReturnToShelvingCart syspref is on, and something needs to go in transit, the shelving cart setting is overriding the transit. 8062 minor Cart email broken for non english templates 8322 minor Removing space between end of marc data and fullstops 8351 minor fix wording when undoing an import 8357 minor UNIMARCslim2OPACDetail.xsl, title without class and too links to views 8392 minor Memberentry is not enforcing birthdate restrictions 8421 minor patron images fail when barcode for patron has a + 8422 minor Fix impossible warning in circulation.pl when OverduesBlockCirc set to Block 8440 minor Dates does not appear in suggestions management 8470 minor remove depreciated H:T:P test file 8476 minor Little bug in OPAC XSLT on OPACURLOpenInNewWindow 8518 minor Self checkout does not display debt amount if syspref AllowFineOverride is set to allow 8556 minor "Mark seen and continue" not translatable in inventory.tt 6655 trivial Sorting order of serial issues in OPAC 7143 trivial Bug for tracking changes to the about page 7367 trivial General OPAC typo omnibus 7368 trivial General staff client typo omnibus 8453 trivial need spaces after radio buttons on inventory 8544 trivial Make RSS icon styleable 7153 enhancement Show Open Library as Search Target in "More Searches" in OPAC detail page 8204 enhancement Authority viewer in OPAC ugly, unfriendly, and mostly useless New sysprefs in 3.8.4 ====================== * OPACSearchForTitleIn System requirements ====================== Important notes: * Perl 5.10 is required * Zebra is required Documentation ====================== As of Koha 3.2, the Koha manual is now maintained in DocBook. The home page for Koha documentation is http://koha-community.org/documentation/ As of the date of these release notes, only the English version of the Koha manual is available: http://manual.koha-community.org/3.8/en/ The Git repository for the Koha manual can be found at http://git.koha-community.org/gitweb/?p=kohadocs.git;a=summary Translations ====================== Complete or near-complete translations of the OPAC and staff interface are available in this release for the following languages: * Arabic (100%) * Armenian (100%) * Chinese (Taiwan) (100%) * Danish (75%) * English (New Zealand) (96%) * English (USA) * French (100%) * French (Canada) (69%) * German (100%) * German (Switzerland) (100%) * Greek (69%) * Italian (100%) * Norwegian Bokm?l (68%) * Portuguese (Brazil) (91%) * Spanish (91%) Partial translations are available for various other languages. The Koha team welcomes additional translations; please see http://wiki.koha-community.org/wiki/Translating_Koha for information about translating Koha, and join the koha-translate list to volunteer: http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-translate The most up-to-date translations can be found at: http://translate.koha-community.org/ Release Team ====================== The release team for Koha 3.8 is Release Manager: Paul Poulain Documentation Manager: Nicole C Engard Translation Manager: Fr?d?ric Demians QA Manager: Ian Walls QA team: Marcel de Rooy , Jonathan Druart Mason James Bug Wranglers: Katrin Fischer, Magnus Enger Release Maintainer (3.4.x): Chris Nighswonger Release Maintainer (3.6.x): Jared Camins-Esakov Release Maintainer (3.8.x): Chris Cormack Credits ====================== We thank the following individuals who contributed patches to Koha 3.8.4. 1 Tomas Cohen Arazi 1 D Ruth Bavousett 10 Jared Camins-Esakov 2 Colin Campbell 5 David Cook 4 Chris Cormack 1 Elliott Davis 1 Fr?d?ric Demians 2 Jonathan Druart 2 Nicole Engard 1 Magnus Enger 1 Chris Hall 4 Kyle M Hall 1 Mason James 2 Owen Leonard 1 Julian Maurice 1 Dobrica Pavlinusic 1 Meenakshi R 2 Marcel de Rooy 8 Fridolyn SOMERS 5 Robin Sheat 3 Mark Tompsett 4 Marc Veron 1 Savitra sirohi We also especially thank the following individuals who tested patches for Koha 3.8.4. 1 Joseph Alway 1 Tomas Cohen Arazi 7 Jared Camins-Esakov 1 David Cook 68 Chris Cormack 1 Elliott Davis 2 Fr?d?ric Demians 7 Jonathan Druart 2 Nicole C. Engard 5 Katrin Fischer 5 Kyle M Hall 9 Owen Leonard 1 Julian Maurice 1 Dobrica Pavlinusic 28 Paul Poulain 1 Marcel de Rooy 1 Zeno Tajoli 3 Mirko Tietgen 3 Marc Veron We regret any omissions. If a contributor has been inadvertantly missed, please send a patch against these release notes to koha-patches at lists.koha-community.org. Revision control notes ====================== The Koha project uses Git for version control. The current development version of Koha can be retrieved by checking out the master branch of git://git.koha-community.org/koha.git The branch for this version of Koha and future bugfixes in this release line is 3.8.x. The last Koha release was 3.8.3, which was released on July 22, 2012. Bugs and feature requests ====================== Bug reports and feature requests can be filed at the Koha bug tracker at http://bugs.koha-community.org/ Ehara taku toa i te toa takitahi, engari he toa takitini From paul.a at aandc.org Tue Aug 21 23:32:15 2012 From: paul.a at aandc.org (Paul) Date: Tue, 21 Aug 2012 17:32:15 -0400 Subject: [Koha-devel] koha-zebra-daemon not starting In-Reply-To: <08DE6856-3552-4FE0-BED1-6AE62FCD484A@kohaaloha.com> References: <5.2.1.1.2.20120820184941.03366ab8@localhost> <5.2.1.1.2.20120819152156.0346fdf8@stormy.ca> <5.2.1.1.2.20120819152156.0346fdf8@stormy.ca> <5.2.1.1.2.20120820184941.03366ab8@localhost> Message-ID: <5.2.1.1.2.20120821172557.0269bea8@localhost> At 05:21 PM 8/21/2012 +1200, Mason James wrote: > > > > BUT ... the incremental cron (shows up in /var/log/syslog as working > every 1 minute), does _NOT_ add new records. > >if you have problems setting up your cron stuff, use the debian packages > >the cron stuff works 'automagically' with the debian packages :) Yup -- and it works equally well on my two other Ubuntu-based servers running Koha 3.6.1 and 3.6.7 Question to all familiar with Ubuntu installs of Koha: do you use the non gui server "out-of-the-box" or have you added any gui apps (gdm, xorg, whatever)? The reason I'm asking is that there are documented kernel changes. Tnx - Paul. From mtj at kohaaloha.com Wed Aug 22 01:01:44 2012 From: mtj at kohaaloha.com (Mason James) Date: Wed, 22 Aug 2012 11:01:44 +1200 Subject: [Koha-devel] koha-zebra-daemon not starting In-Reply-To: <5.2.1.1.2.20120821172557.0269bea8@localhost> References: <5.2.1.1.2.20120820184941.03366ab8@localhost> <5.2.1.1.2.20120819152156.0346fdf8@stormy.ca> <5.2.1.1.2.20120819152156.0346fdf8@stormy.ca> <5.2.1.1.2.20120820184941.03366ab8@localhost> <5.2.1.1.2.20120821172557.0269bea8@localhost> Message-ID: <9CD1FDC7-7297-411A-BB04-BE4CE5EB5B83@kohaaloha.com> On 2012-08-22, at 9:32 AM, Paul wrote: > At 05:21 PM 8/21/2012 +1200, Mason James wrote: >> > >> > BUT ... the incremental cron (shows up in /var/log/syslog as working every 1 minute), does _NOT_ add new records. >> >> if you have problems setting up your cron stuff, use the debian packages >> >> the cron stuff works 'automagically' with the debian packages :) > > Yup -- and it works equally well on my two other Ubuntu-based servers running Koha 3.6.1 and 3.6.7 yup, so just do a package install, and fix your problem > > Question to all familiar with Ubuntu installs of Koha: do you use the non gui server "out-of-the-box" or have you added any gui apps (gdm, xorg, whatever)? never install any gui stuff on a server, unless you need it From paul.a at aandc.org Wed Aug 22 01:27:18 2012 From: paul.a at aandc.org (Paul) Date: Tue, 21 Aug 2012 19:27:18 -0400 Subject: [Koha-devel] koha-zebra-daemon not starting In-Reply-To: <9CD1FDC7-7297-411A-BB04-BE4CE5EB5B83@kohaaloha.com> References: <5.2.1.1.2.20120821172557.0269bea8@localhost> <5.2.1.1.2.20120820184941.03366ab8@localhost> <5.2.1.1.2.20120819152156.0346fdf8@stormy.ca> <5.2.1.1.2.20120819152156.0346fdf8@stormy.ca> <5.2.1.1.2.20120820184941.03366ab8@localhost> <5.2.1.1.2.20120821172557.0269bea8@localhost> Message-ID: <5.2.1.1.2.20120821190421.01b97d48@localhost> At 11:01 AM 8/22/2012 +1200, you wrote: >On 2012-08-22, at 9:32 AM, Paul wrote: > > > At 05:21 PM 8/21/2012 +1200, Mason James wrote: > >> > > >> > BUT ... the incremental cron (shows up in /var/log/syslog as working > every 1 minute), does _NOT_ add new records. > >> > >> if you have problems setting up your cron stuff, use the debian packages > >> > >> the cron stuff works 'automagically' with the debian packages :) > > > > Yup -- and it works equally well on my two other Ubuntu-based servers > running Koha 3.6.1 and 3.6.7 > > >yup, so just do a package install, and fix your problem O.K. I'll bite: a "package install" of exactly what? Does it cure the problem: "the incremental cron (shows up in /var/log/syslog as working every 1 minute), does _NOT_ add new records"? For your information -- because you maybe haven't read the whole thread -- I have three instances of Koha running on three totally independent servers, and *only* Koha 3.8.3 shows this anomaly; the other two are fully functional. All servers built by the same person (me) using the same methodology; all servers have same (give|take Koha version and one server with upgraded Ubuntu 11.10 vice 12.04) file structures, permissions, versions of perl, yaz, idzebra, mysql, etc. I'll be really happy to follow your suggestion to "just do a package install" but would respectfully ask you to be a little|much more precise as to exactly what ... Thanks for your interest, Paul From mtj at kohaaloha.com Wed Aug 22 01:40:53 2012 From: mtj at kohaaloha.com (Mason James) Date: Wed, 22 Aug 2012 11:40:53 +1200 Subject: [Koha-devel] koha-zebra-daemon not starting In-Reply-To: <5.2.1.1.2.20120821190421.01b97d48@localhost> References: <5.2.1.1.2.20120821172557.0269bea8@localhost> <5.2.1.1.2.20120820184941.03366ab8@localhost> <5.2.1.1.2.20120819152156.0346fdf8@stormy.ca> <5.2.1.1.2.20120819152156.0346fdf8@stormy.ca> <5.2.1.1.2.20120820184941.03366ab8@localhost> <5.2.1.1.2.20120821172557.0269bea8@localhost> <5.2.1.1.2.20120821190421.01b97d48@localhost> Message-ID: >> > At 05:21 PM 8/21/2012 +1200, Mason James wrote: >> >> > >> >> > BUT ... the incremental cron (shows up in /var/log/syslog as working every 1 minute), does _NOT_ add new records. >> >> >> >> if you have problems setting up your cron stuff, use the debian packages >> >> >> >> the cron stuff works 'automagically' with the debian packages :) >> > >> > Yup -- and it works equally well on my two other Ubuntu-based servers running Koha 3.6.1 and 3.6.7 >> >> >> yup, so just do a package install, and fix your problem > > O.K. I'll bite: a "package install" of exactly what? with the debian packages of *Koha* (what other packages could i possibly mean?) just do an install of Koha, using the 'packages' method, don't use the 'tar-file' method > > Does it cure the problem: "the incremental cron (shows up in /var/log/syslog as working every 1 minute), does _NOT_ add new records"? yup, thats what i said before the cron stuff works 'automagically' using the debian packages From mtompset at hotmail.com Wed Aug 22 01:58:47 2012 From: mtompset at hotmail.com (Mark Tompsett) Date: Wed, 22 Aug 2012 07:58:47 +0800 Subject: [Koha-devel] koha-zebra-daemon not starting In-Reply-To: <5.2.1.1.2.20120821172557.0269bea8@localhost> References: <5.2.1.1.2.20120820184941.03366ab8@localhost><5.2.1.1.2.20120819152156.0346fdf8@stormy.ca><5.2.1.1.2.20120819152156.0346fdf8@stormy.ca><5.2.1.1.2.20120820184941.03366ab8@localhost> <5.2.1.1.2.20120821172557.0269bea8@localhost> Message-ID: Greetings, > Question to all familiar with Ubuntu installs of Koha: do you use the non > gui server "out-of-the-box" or have you added any gui apps (gdm, xorg, > whatever)? The reason I'm asking is that there are documented kernel > changes. $ sudo apt-get install lynx This works well enough with the web install portion of the Koha installation. Why would I want to install anything gui on an Ubuntu server? If some gui-pieces make it in based on the tarball dselect, it happens. I used command-line only to build, install, and configure our Koha 3.6.3 installation from a tarball on Ubuntu 10.04 LTS. We hope to migrate to Koha to Ubuntu 12.04 LTS in the near future. The version of Koha has yet to be determined. Hope this is useful feedback. GPML, Mark Tompsett From mtompset at hotmail.com Wed Aug 22 02:06:38 2012 From: mtompset at hotmail.com (Mark Tompsett) Date: Wed, 22 Aug 2012 08:06:38 +0800 Subject: [Koha-devel] koha-zebra-daemon not starting In-Reply-To: <5.2.1.1.2.20120821190421.01b97d48@localhost> References: <5.2.1.1.2.20120821172557.0269bea8@localhost><5.2.1.1.2.20120820184941.03366ab8@localhost><5.2.1.1.2.20120819152156.0346fdf8@stormy.ca><5.2.1.1.2.20120819152156.0346fdf8@stormy.ca><5.2.1.1.2.20120820184941.03366ab8@localhost><5.2.1.1.2.20120821172557.0269bea8@localhost> <5.2.1.1.2.20120821190421.01b97d48@localhost> Message-ID: Greetings, A package install is relatively easy. Someone correct me if I'm wrong, but it goes something like: 1) mysqldump your Koha database. 2) Try following the instructions on http://wiki.koha-community.org/wiki/Koha_3.8_on_Debian_Squeeze (You probably will have some questions as you go along, so feel free to ask. Questions will help improve the documentation.) 3) Before the webinstall step, import your mysqldump. 4) Run webinstall. 5) Everything should be in place afterwards. The difference between a tarball install and a packages install is mostly the resulting directory structure locations of things. However, you get the added advantage of access to other scripts which people constantly refer to on the lists, but never really apply for tarball installations. GPML, Mark Tompsett From chris at bigballofwax.co.nz Wed Aug 22 02:09:12 2012 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Wed, 22 Aug 2012 12:09:12 +1200 Subject: [Koha-devel] koha-zebra-daemon not starting In-Reply-To: References: <5.2.1.1.2.20120819152156.0346fdf8@stormy.ca> <5.2.1.1.2.20120820184941.03366ab8@localhost> <5.2.1.1.2.20120821172557.0269bea8@localhost> <5.2.1.1.2.20120821190421.01b97d48@localhost> Message-ID: On 22 August 2012 12:06, Mark Tompsett wrote: > Greetings, > > A package install is relatively easy. Someone correct me if I'm wrong, but > it goes something like: > 1) mysqldump your Koha database. > 2) Try following the instructions on > http://wiki.koha-community.org/wiki/Koha_3.8_on_Debian_Squeeze > (You probably will have some questions as you go along, so feel free to > ask. Questions will help improve the documentation.) > 3) Before the webinstall step, import your mysqldump. > 4) Run webinstall. > 5) Everything should be in place afterwards. > > The difference between a tarball install and a packages install is mostly > the resulting directory structure locations of things. However, you get the > added advantage of access to other scripts which people constantly refer to > on the lists, but never really apply for tarball installations. > But really the main advantage is that your next upgrade is apt-get upgrade. Even without the scripts that's still a huge advantage. Also, the packages set up the cron jobs properly and without typos which is suspect is what is wrong here Chris From paul.a at aandc.org Wed Aug 22 02:39:59 2012 From: paul.a at aandc.org (Paul) Date: Tue, 21 Aug 2012 20:39:59 -0400 Subject: [Koha-devel] 3.8.4 interim [was: koha-zebra-daemon not starting] In-Reply-To: References: <5.2.1.1.2.20120821190421.01b97d48@localhost> <5.2.1.1.2.20120821172557.0269bea8@localhost> <5.2.1.1.2.20120820184941.03366ab8@localhost> <5.2.1.1.2.20120819152156.0346fdf8@stormy.ca> <5.2.1.1.2.20120819152156.0346fdf8@stormy.ca> <5.2.1.1.2.20120820184941.03366ab8@localhost> <5.2.1.1.2.20120821172557.0269bea8@localhost> <5.2.1.1.2.20120821190421.01b97d48@localhost> Message-ID: <5.2.1.1.2.20120821201313.01af8798@localhost> At 08:06 AM 8/22/2012 +0800, [someone, because this is not personal] wrote: >A package install is relatively easy. Someone correct me if I'm wrong, but >it goes something like: >1) mysqldump your Koha database. >2) Try following the instructions on >http://wiki.koha-community.org/wiki/Koha_3.8_on_Debian_Squeeze > (You probably will have some questions as you go along, so feel free > to ask. Questions will help improve the documentation.) >3) Before the webinstall step, import your mysqldump. >4) Run webinstall. >5) Everything should be in place afterwards. >The difference between a tarball install and a packages install is mostly >the resulting directory structure locations of things. However, you get >the added advantage of access to other scripts which people constantly >refer to on the lists, but never really apply for tarball installations. OK -- now I'm totally confused (end of the day, tired) but I got fed up on the last "attempt" at 3.8.3 (same results on a brand new install, wiped the server totally clean), then saw that Chris had announced 3.8.4, so wiped the server again, and it's worse than before [see below] because "apparently???" dpkg / dselect is attempting an i386 package for libxml2, and I end up with 5 modules "required" and four "listed" but not required. Now, I did the koha-3.08.04 via wget and suddenly learn that "package" is different from "tarball". Is the tarball different? or invalid? (see below for the i386 error.) I've been using tyarballs for years (and Koha in particular since 3.4.? through the whole 3.6 series) so do I have to change? With respect, why do I have to learn a different "resulting directory structure locations of things." Will I be able to compare a fully working 3.6.7 with a new 3.8.4? That's a new learning experience, and what are the structural differences? And is "Debian Squeeze" == "Ubuntu 12.04". And I guess I can restore the mysql db *before* installing Koha, but what's the significance? Anyway, until tomorrow, here's waht I got with 2.8.4 on 12.04 (all virgin): $ sudo dpkg --set-selections < install_misc/ubuntu.packages $ sudo dselect then at [I]nstall: Errors were encountered while processing: /var/cache/apt/archives/libxml2-dev_2.7.8.dfsg-5.1ubuntu4.1_i386.deb E: Sub-process /usr/bin/dpkg returned an error code (1) Some errors occurred while unpacking. Packages that were installed will be configured. This may result in duplicate errors or errors caused by missing dependencies. This is OK, only the errors above this message are important. Please fix them and run [I]nstall again Press enter to continue. Errors were encountered while processing: libxslt1-dev:i386 dselect: warning: subprocess installation script returned error exit status 100 Press to continue. paul at server:/koha-3.08.04$ ./koha_perl_deps.pl -m Installed Required Module is Module Name Version Version Required -------------------------------------------------------------------------------------------- DBD::SQLite2 0 * 0.33 No Graphics::Magick 0 * 1.3.05 No Lingua::Stem::Snowball 0 * 0.952 Yes Net::Z3950::ZOOM 0 * 1.16 Yes Readonly::XS 0 * 1.02 No Template 0 * 2.22 Yes Template::Plugin::HtmlToText 0 * 0.03 Yes Test::Strict 0 * 0.14 No XML::LibXSLT 0 * 1.59 Yes -------------------------------------------------------------------------------------------- Total modules reported: 9 * Module is missing or requires an upgrade. From chris at bigballofwax.co.nz Wed Aug 22 02:43:55 2012 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Wed, 22 Aug 2012 12:43:55 +1200 Subject: [Koha-devel] 3.8.4 interim [was: koha-zebra-daemon not starting] In-Reply-To: <5.2.1.1.2.20120821201313.01af8798@localhost> References: <5.2.1.1.2.20120819152156.0346fdf8@stormy.ca> <5.2.1.1.2.20120820184941.03366ab8@localhost> <5.2.1.1.2.20120821172557.0269bea8@localhost> <5.2.1.1.2.20120821190421.01b97d48@localhost> <5.2.1.1.2.20120821201313.01af8798@localhost> Message-ID: On 22 August 2012 12:39, Paul wrote: > At 08:06 AM 8/22/2012 +0800, [someone, because this is not personal] wrote: >> >> A package install is relatively easy. Someone correct me if I'm wrong, but >> it goes something like: >> 1) mysqldump your Koha database. >> 2) Try following the instructions on >> http://wiki.koha-community.org/wiki/Koha_3.8_on_Debian_Squeeze >> (You probably will have some questions as you go along, so feel free to >> ask. Questions will help improve the documentation.) >> 3) Before the webinstall step, import your mysqldump. >> 4) Run webinstall. >> 5) Everything should be in place afterwards. >> The difference between a tarball install and a packages install is mostly >> the resulting directory structure locations of things. However, you get the >> added advantage of access to other scripts which people constantly refer to >> on the lists, but never really apply for tarball installations. > > > OK -- now I'm totally confused (end of the day, tired) but I got fed up on > the last "attempt" at 3.8.3 (same results on a brand new install, wiped the > server totally clean), then saw that Chris had announced 3.8.4, so wiped the > server again, and it's worse than before [see below] because "apparently???" > dpkg / dselect is attempting an i386 package for libxml2, and I end up with > 5 modules "required" and four "listed" but not required. > I think I will bow out of this thread, my attempts at helping seem to only confuse you more. Chris From mtj at kohaaloha.com Wed Aug 22 02:56:17 2012 From: mtj at kohaaloha.com (Mason James) Date: Wed, 22 Aug 2012 12:56:17 +1200 Subject: [Koha-devel] 3.8.4 interim [was: koha-zebra-daemon not starting] In-Reply-To: <5.2.1.1.2.20120821201313.01af8798@localhost> References: <5.2.1.1.2.20120821190421.01b97d48@localhost> <5.2.1.1.2.20120821172557.0269bea8@localhost> <5.2.1.1.2.20120820184941.03366ab8@localhost> <5.2.1.1.2.20120819152156.0346fdf8@stormy.ca> <5.2.1.1.2.20120819152156.0346fdf8@stormy.ca> <5.2.1.1.2.20120820184941.03366ab8@localhost> <5.2.1.1.2.20120821172557.0269bea8@localhost> <5.2.1.1.2.20120821190421.01b97d48@localhost> <5.2.1.1.2.20120821201313.01af8798@localhost> Message-ID: <4AD05B82-6214-41D4-B3ED-416FE7CE226B@kohaaloha.com> On 2012-08-22, at 12:39 PM, Paul wrote: > At 08:06 AM 8/22/2012 +0800, [someone, because this is not personal] wrote: >> A package install is relatively easy. Someone correct me if I'm wrong, but it goes something like: >> 1) mysqldump your Koha database. >> 2) Try following the instructions on http://wiki.koha-community.org/wiki/Koha_3.8_on_Debian_Squeeze >> (You probably will have some questions as you go along, so feel free to ask. Questions will help improve the documentation.) >> 3) Before the webinstall step, import your mysqldump. >> 4) Run webinstall. >> 5) Everything should be in place afterwards. >> The difference between a tarball install and a packages install is mostly the resulting directory structure locations of things. However, you get the added advantage of access to other scripts which people constantly refer to on the lists, but never really apply for tarball installations. > > OK -- now I'm totally confused (end of the day, tired) but I got fed up on the last "attempt" at 3.8.3 (same results on a brand new install, wiped the server totally clean), then saw that Chris had announced 3.8.4, so wiped the server again, and it's worse than before [see below] because "apparently???" dpkg / dselect is attempting an i386 package for libxml2, and I end up with 5 modules "required" and four "listed" but not required. > > Now, I did the koha-3.08.04 via wget and suddenly learn that "package" is different from "tarball". Is the tarball different? or invalid? (see below for the i386 error.) I've been using tyarballs for years (and Koha in particular since 3.4.? through the whole 3.6 series) so do I have to change? a 'package' is a .deb file, see -> http://en.wikipedia.org/wiki/Deb_(file_format) a 'tar ball' is a tar file , see -> http://en.wikipedia.org/wiki/Tar_(file_format) http://wiki.koha-community.org/wiki/Koha_3.8_on_Debian_Squeeze http://wiki.koha-community.org/wiki/Building_Debian_Packages_-_The_Easy_Way http://wiki.koha-community.org/wiki/Commands_provided_by_the_Debian_packages From jcamins at cpbibliography.com Wed Aug 22 04:48:05 2012 From: jcamins at cpbibliography.com (Jared Camins-Esakov) Date: Tue, 21 Aug 2012 22:48:05 -0400 Subject: [Koha-devel] Koha version 3.6.8 released In-Reply-To: <20120822024513.D67D397FC9@cp-koha3.cpbibliography.com> References: <20120822024513.D67D397FC9@cp-koha3.cpbibliography.com> Message-ID: The Koha community is proud to release Koha version 3.06.08.000. This is a bugfix release, and contains a number of important fixes You can obtain Koha 3.06.08.000 from the http://download.koha-community.org site. Debian packages will be available from the http://debian.koha-community.org shortly also. Please read the release notes below for more information RELEASE NOTES FOR KOHA 3.6.8 22 Aug 2012 ======================================================================== Koha is the first free and open source software library automation package (ILS). Development is sponsored by libraries of varying types and sizes, volunteers, and support companies from around the world. The website for the Koha project is http://koha-community.org/ Koha 3.6.8 can be downloaded from: http://download.koha-community.org/koha-3.06.08.tar.gz Installation instructions can be found at: http://wiki.koha-community.org/wiki/Installation_Documentation OR in the INSTALL files that come in the tarball Koha 3.6.8 is a bugfix/maintenance release. Highlights of 3.6.8 ====================== 7329 critical The "undo import into catalog" command deletes items onloan without checking 7834 critical order search at the top of acq does nothing 8289 critical Upgrading from 2.2 does not work anymore 2505 major enable Perl warnings in all modules and scripts 8315 major fix 'C4::Output 3.02' errors in Koha Bugs fixed in 3.6.8 ====================== 4838 normal Repeated authority headings break biblio record data entry form 6634 normal manager_id not populated when paying fines 6720 normal Saved authorities always show as 'Default' 7586 normal Search: Language restriction does NOT show expected results (no items shown) 7807 normal GetSuggestionFromBiblionumber takes only one parameter 7886 normal C4/ShelfBrowser slow SQL performance 7900 normal Link to vendor from subscription details is broken 7952 normal PDF::Reuse under plack writes to console STDOUT instead to browser 8136 normal Changes the expected lenght of 100$a in rebuild_zebra.pl 8171 normal Improper escaping of quotes during z39.50 queries leads to broken html 8197 normal Software error when you have cleaned cookies in your browser and try to past the url to opac-topissues.pl 8226 normal 'OpacFooter' markup/css improvements 8282 normal Bug in modules list in about.pl 5312 minor XHTML correction in authority summary 6141 minor html glitches causing problems to translator 6679 minor Fixing code so it passes basic Perl::Critic tests 7815 minor Order pickup library list by name rather than by code 8009 minor Item descriptive data not populated on pay.pl 8166 minor Adding new currencies & exchange rates if not fill any field it save blank record 8191 minor New value for 8 position in coded data field 100 in unimarc 8232 minor Comments in OPAC contain untranslatable javascript messages 6350 trivial Bug for tracking updates to the history file 7143 trivial Bug for tracking changes to the about page 7367 trivial General OPAC typo omnibus 7368 trivial General staff client typo omnibus 7994 trivial Syntax error in yaml (syspref) files 8222 trivial The zip code field is mandatory by default 8138 enhancement Add 773$t field to xslt 8216 enhancement Enable critic tests on SIP modules New sysprefs in 3.6.8 ====================== * BorrowerMandatoryField System requirements ====================== Important notes: * Perl 5.10 is required * Zebra is required Documentation ====================== As of Koha 3.2, the Koha manual is now maintained in DocBook. The home page for Koha documentation is http://koha-community.org/documentation/ As of the date of these release notes, only the English version of the Koha manual is available: http://manual.koha-community.org/3.6/en/ The Git repository for the Koha manual can be found at http://git.koha-community.org/gitweb/?p=kohadocs.git;a=summary Translations ====================== Complete or near-complete translations of the OPAC and staff interface are available in this release for the following languages: * Arabic (51%) * Chinese (China) (96%) * Chinese (Taiwan) (99%) * Danish (100%) * English (New Zealand) (100%) * English (USA) * English (United Kingdom) (64%) * French (99%) * French (Canada) (95%) * German (100%) * Greek (94%) * Italian (100%) * Norwegian Bokm?l (62%) * Portuguese (Brazil) (99%) * Spanish (100%) * Tetun (52%) Partial translations are available for various other languages. The Koha team welcomes additional translations; please see http://wiki.koha-community.org/wiki/Translating_Koha for information about translating Koha, and join the koha-translate list to volunteer: http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-translate The most up-to-date translations can be found at: http://translate.koha-community.org/ Release Team ====================== The release team for Koha 3.6 is Release Manager: Chris Cormack Documentation Manager: Nicole C Engard Translation Manager: Fr?d?ric Demians QA Manager: Ian Walls Bug Wranglers: MJ Ray, Marcel de Rooy, Paul Poulain, Mason James Past Release Maintainer (3.6.x): Chris Nighswonger Release Maintainer (3.6.x): Jared Camins-Esakov Credits ====================== We thank the following individuals who contributed patches to Koha 3.6.8. 1 D Ruth Bavousett 5 Jared Camins-Esakov 3 Colin Campbell 4 Chris Cormack 1 Christophe Croullebois 2 Fr?d?ric Demians 1 Jonathan Druart 3 Katrin Fischer 1 Amit Gupta 1 Kyle M Hall 2 Claire Hernandez 2 Mason James 1 Srdjan Jankovic 1 Owen Leonard 1 Julian Maurice 1 Matthias Meusburger 4 Sophie Meynieux 3 Dobrica Pavlinusic 1 Maxime Pelletier 4 Paul Poulain 3 Marcel de Rooy 1 Fridolyn SOMERS 1 Robin Sheat 1 Marc Veron 2 christophe croullebois We also especially thank the following individuals who tested patches for Koha 3.6.8. 51 Jared Camins-Esakov 1 Fran?ois Charbonnier 41 Chris Cormack 2 Michael Davis 5 Katrin Fischer 1 Marijana Glavica 3 Kyle M Hall 1 Owen Leonard 1 Sophie Meynieux 31 Paul Poulain 2 Martin Renvoize 3 Marcel de Rooy 1 Robin Sheat 2 Marc Veron 1 Stacey Walker We regret any omissions. If a contributor has been inadvertantly missed, please send a patch against these release notes to koha-patches at lists.koha-community.org. Revision control notes ====================== The Koha project uses Git for version control. The current development version of Koha can be retrieved by checking out the master branch of git://git.koha-community.org/koha.git The branch for this version of Koha and future bugfixes in this release line is 3.6.x. The last Koha release was 3.8.2, which was released on June 22, 2012. Bugs and feature requests ====================== Bug reports and feature requests can be filed at the Koha bug tracker at http://bugs.koha-community.org/ Ehara taku toa i te toa takitahi, engari he toa takitini -------------- next part -------------- An HTML attachment was scrubbed... URL: From mtompset at hotmail.com Wed Aug 22 12:10:50 2012 From: mtompset at hotmail.com (Mark Tompsett) Date: Wed, 22 Aug 2012 18:10:50 +0800 Subject: [Koha-devel] 3.8.4 interim [was: koha-zebra-daemon not starting] In-Reply-To: <5.2.1.1.2.20120821201313.01af8798@localhost> References: <5.2.1.1.2.20120821190421.01b97d48@localhost> <5.2.1.1.2.20120821172557.0269bea8@localhost> <5.2.1.1.2.20120820184941.03366ab8@localhost> <5.2.1.1.2.20120819152156.0346fdf8@stormy.ca> <5.2.1.1.2.20120819152156.0346fdf8@stormy.ca> <5.2.1.1.2.20120820184941.03366ab8@localhost> <5.2.1.1.2.20120821172557.0269bea8@localhost> <5.2.1.1.2.20120821190421.01b97d48@localhost> <5.2.1.1.2.20120821201313.01af8798@localhost> Message-ID: Greetings, There are THREE ways to install koha (with respect to Ubuntu): 1) Packages (http://wiki.koha-community.org/wiki/Koha_3.8_on_Debian_Squeeze) 2) Tarball (http://wiki.koha-community.org/wiki/Koha_on_Ubuntu) 3) GIT (http://wiki.koha-community.org/wiki/Version_Control_Using_Git) Which way should you do? Are you going to develop, submit patches, etc for a non-production system? If yes, then (3) GIT! Are you using a debian-based OS? If yes, then (1) Packages! For everything else, there is (2) Tarball. Don't worry, my first install was tarball. That's why the instructions for the tarball installation have been improved on the wiki. I was trying to be a purist. Don't try to logically map between Ubuntu and Debian. That will only generate more confusion in your mind. You say you are trying to set up 3.8.4, so you need to: $ wget -O- http://debian.koha-community.org/koha/gpg.asc | sudo apt-key add - and $ echo deb http://debian.koha-community.org/koha squeeze main | sudo tee /etc/apt/sources.list.d/koha.list $ sudo apt-get update Why? Because there are perl packages which are not in the default repositories for Ubuntu. --- BEGIN SNIPPET --- $ sudo dpkg --set-selections < install_misc/ubuntu.packages $ sudo dselect --- END SNIPPET --- Yes, this is what INSTALL.Ubuntu has said for the longest time. However, remember that unless someone helps keep the file up to date, you will end up with missing libraries like you have listed. And remember that the main install base for Koha is Debian. This means that other Debian-based OS?s may not have those libraries packaged in the default repositories. From mtompset at hotmail.com Wed Aug 22 16:04:01 2012 From: mtompset at hotmail.com (Mark Tompsett) Date: Wed, 22 Aug 2012 22:04:01 +0800 Subject: [Koha-devel] 3.8.4 interim [was: koha-zebra-daemon not starting] In-Reply-To: <5.2.1.1.2.20120821201313.01af8798@localhost> References: <5.2.1.1.2.20120821190421.01b97d48@localhost> <5.2.1.1.2.20120821172557.0269bea8@localhost> <5.2.1.1.2.20120820184941.03366ab8@localhost> <5.2.1.1.2.20120819152156.0346fdf8@stormy.ca> <5.2.1.1.2.20120819152156.0346fdf8@stormy.ca> <5.2.1.1.2.20120820184941.03366ab8@localhost> <5.2.1.1.2.20120821172557.0269bea8@localhost> <5.2.1.1.2.20120821190421.01b97d48@localhost> <5.2.1.1.2.20120821201313.01af8798@localhost> Message-ID: Greetings, And having just looked through the 3.8.4 files in /install_misc/ubuntu*.packages, I have realized my patches didn't make it into the 3.8.X stream. I'll have to bug report and do a 3.8.X specific bug patch (they are in 3.6.7)... But that aside. As I was just chatting with tcohen on IRC, he reminded me that yaz3 was the problem. I actually finished looking at the ubuntu.packages file and installed these: $ sudo apt-get install apache2 daemon gettext mysql-server libmysqlclient18 yaz yaz-doc libyaz4 libyaz4-dev idzebra-2.0 idzebra-2.0-common idzebra-2.0-doc idzebra-2.0-utils libidzebra-2.0-0 $ sudo apt-get install libidzebra-2.0-dev libidzebra-2.0-mod-alvis libidzebra-2.0-mod-grs-marc libidzebra-2.0-mod-grs-regx libidzebra-2.0-mod-grs-xml libidzebra-2.0-mod-text $ sudo apt-get install libidzebra-2.0-modules libxml2-utils You only need gcc and make if you need CPAN to install something that is missing. However, I didn't get anything missing. And speaking of yaz. If you really want to get yaz and zebra from the source, check out: http://ftp.indexdata.dk/pub/yaz/ubuntu/README (change intrepid to the release you have and goodness browse around the site while you're there). You can always add indexdata's repository. Though, it isn't necessary. GPML, Mark Tompsett From mjr at phonecoop.coop Wed Aug 22 19:21:57 2012 From: mjr at phonecoop.coop (MJ Ray) Date: Wed, 22 Aug 2012 18:21:57 +0100 Subject: [Koha-devel] Officially supported OS versions In-Reply-To: Message-ID: Ian asked: > This leads me to the question: What OS versions does Koha run on? This is > both a descriptive question (what's true now) as well as a prescriptive one > (what systems SHOULD Koha run on). I think the role of koha-community should be to describe what Koha runs on. This has a consequence: I'd like developers and RMs to be pretty conservative about adding new dependencies or adopting features only found in new versions of dependencies, because each time that happens, we might kill support for some version of something. Which brings me to this... > I should think that Debian 6+ is a given. Any current Ubuntu LTS may also > be appropriate, though the current situation has me unable to install a > dependency on 10.04. In the past, I know that RedHat installs have been > particularly vicious, and may not even be possible at this time. In general, I don't think we should be supporting any particular distributions as a community. However, there are two small(?) exceptions to that: 1. the community distributions like debian and fedora are in a special place. We're all volunteers and we can develop packages on koha-community as an experimental place, before they get handed over into the distributions. I'd be very happy to see packages of koha and dependencies for debian and fedora; 2. some of the support providers may want to offer packages privately-controlled distributions for commercial reasons - if they want to do that linked from koha-community, that's fine, but if they stop resourcing it, I don't think the community should expect volunteers to work for the distribution businesses for free. So, in short: maybe offer packages for debian and fedora and any other similar ones, else just describe what works and help any third-party offerings. Hope that explains, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. http://koha-community.org supporter, web and library systems developer. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire (including development) at http://www.software.coop/ From paul.a at aandc.org Wed Aug 22 21:20:11 2012 From: paul.a at aandc.org (Paul) Date: Wed, 22 Aug 2012 15:20:11 -0400 Subject: [Koha-devel] 3.8.4 interim [was: koha-zebra-daemon not starting] In-Reply-To: References: <5.2.1.1.2.20120821201313.01af8798@localhost> <5.2.1.1.2.20120821190421.01b97d48@localhost> <5.2.1.1.2.20120821172557.0269bea8@localhost> <5.2.1.1.2.20120820184941.03366ab8@localhost> <5.2.1.1.2.20120819152156.0346fdf8@stormy.ca> <5.2.1.1.2.20120819152156.0346fdf8@stormy.ca> <5.2.1.1.2.20120820184941.03366ab8@localhost> <5.2.1.1.2.20120821172557.0269bea8@localhost> <5.2.1.1.2.20120821190421.01b97d48@localhost> <5.2.1.1.2.20120821201313.01af8798@localhost> Message-ID: <5.2.1.1.2.20120822144652.0359d578@localhost> At 10:04 PM 8/22/2012 +0800, Mark Tompsett wrote: >Greetings, > >And having just looked through the 3.8.4 files in >/install_misc/ubuntu*.packages, I have realized my patches didn't make it >into the 3.8.X stream. I'll have to bug report and do a 3.8.X specific bug >patch (they are in 3.6.7)... But that aside. As I was just chatting with >tcohen on IRC, he reminded me that yaz3 was the problem. > >I actually finished looking at the ubuntu.packages file and installed these: >$ sudo apt-get install apache2 daemon gettext mysql-server >libmysqlclient18 yaz yaz-doc libyaz4 libyaz4-dev idzebra-2.0 >idzebra-2.0-common idzebra-2.0-doc idzebra-2.0-utils libidzebra-2.0-0 >$ sudo apt-get install libidzebra-2.0-dev libidzebra-2.0-mod-alvis >libidzebra-2.0-mod-grs-marc libidzebra-2.0-mod-grs-regx >libidzebra-2.0-mod-grs-xml libidzebra-2.0-mod-text >$ sudo apt-get install libidzebra-2.0-modules libxml2-utils Mark - tnx for your interest (and sorry to read that Chris C. is ducking out of this thread -- tnx for all you do.) I managed to have a quick look at it again this morning, and hope to find another hour before the day is out, but I came to roughly the same conclusion. yaz3 must be replaced by yaz4. I ended up reinstalling the server [again] to be certain that everything was clean, and by: $ sudo apt-get install libyaz4 PLUS libyaz4-dev libnet-z3950-zoom-perl libxml-libxslt-perl libgraphics-magick-perl liblingua-stem-snowball-perl libtemplate-perl libtemplate-plugin-htmltotext-perl liblingua-ispell-perl libhtml-template-pro-perl libreadonly-xs-perl libtest-strict-perl THEN using: $ sudo dpkg --set-selections < install_misc/ubuntu.packages $ sudo dselect you get all the dependencies properly. Starting with dphg + dselect somehow *half* installs about 50 i386 bits and pieces, and while $sudo apt-get purge .*:i386 cleaned up quite nicely, I did a complete 12.04 re-install to make sure everything was copacetic. I did need to add the koha repository to get one file [template::htmltotext] as this is not an Ubuntu|Debian file, but is recorded after install as "koha". FYI, getting Robin's pgp required a couple of steps that you did not mention. Using: $ wget http://debian.koha-community.org/koha/gpg.asc | sudo apt-key add - gives the error "GPG error: http://archive.ubuntu.com dapper Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 14D36485A99CEB6D" To correct this: $ gpg --recv-keys 14D36485A99CEB6D And then add it to apt-keys: $ gpg --export --armor 14D36485A99CEB6D | sudo apt-key add - works fine. BTW, you wrote earlier: >Which way should you do? >Are you going to develop, submit patches, etc for a non-production system? >If yes, then (3) GIT! >Are you using a debian-based OS? If yes, then (1) Packages! >For everything else, there is (2) Tarball. While I'd love to have time to "submit patches", I juts seem to spend too much time maintaining a production system. I do not use a pure Debian system, but Ubuntu for all our servers and workstations. Hence your "For everything else, there is tarball." My current aim is to get the production server onto 3.8.x from 3.6.x, but need to document (internally here) how to do this cleanly. The tarball has always worked extremely well on i386 machines -- I just get the impression (not proven) that Ubuntu 12.04 gets its knickers in a twist on AMD64. But with a little time and effort workarounds can be found. Probably nothing wrong, just new quirks, with either Ubuntu or Koha, but I do not need to be under pressure for the production upgrade. Again tnx and more later - I'm rushing off to an outside meeting. Best - Paul >You only need gcc and make if you need CPAN to install something that is >missing. However, I didn't get anything missing. > >And speaking of yaz. If you really want to get yaz and zebra from the >source, check out: http://ftp.indexdata.dk/pub/yaz/ubuntu/README (change >intrepid to the release you have and goodness browse around the site while >you're there). You can always add indexdata's repository. Though, it isn't >necessary. > >GPML, >Mark Tompsett >_______________________________________________ >Koha-devel mailing list >Koha-devel at lists.koha-community.org >http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >website : http://www.koha-community.org/ >git : http://git.koha-community.org/ >bugs : http://bugs.koha-community.org/ --- Maritime heritage and history, preservation and conservation, research and education through the written word and the arts. and From mtompset at hotmail.com Wed Aug 22 21:56:22 2012 From: mtompset at hotmail.com (Mark Tompsett) Date: Thu, 23 Aug 2012 03:56:22 +0800 Subject: [Koha-devel] 3.8.4 interim [was: koha-zebra-daemon not starting] In-Reply-To: <5.2.1.1.2.20120822144652.0359d578@localhost> References: <5.2.1.1.2.20120821201313.01af8798@localhost> <5.2.1.1.2.20120821190421.01b97d48@localhost> <5.2.1.1.2.20120821172557.0269bea8@localhost> <5.2.1.1.2.20120820184941.03366ab8@localhost> <5.2.1.1.2.20120819152156.0346fdf8@stormy.ca> <5.2.1.1.2.20120819152156.0346fdf8@stormy.ca> <5.2.1.1.2.20120820184941.03366ab8@localhost> <5.2.1.1.2.20120821172557.0269bea8@localhost> <5.2.1.1.2.20120821190421.01b97d48@localhost> <5.2.1.1.2.20120821201313.01af8798@localhost> <5.2.1.1.2.20120822144652.0359d578@localhost> Message-ID: Greetings, Paul, Just some final details. Because I think there was some instructional misunderstandings... --- SNIP --- $ sudo apt-get install libyaz4 PLUS libyaz4-dev libnet-z3950-zoom-perl libxml-libxslt-perl libgraphics-magick-perl liblingua-stem-snowball-perl libtemplate-perl libtemplate-plugin-htmltotext-perl liblingua-ispell-perl libhtml-template-pro-perl libreadonly-xs-perl libtest-strict-perl --- SNIP --- The point was all the libraries you needed are there. I probably typed this in a command line earlier and forgot to include it. I did note that I had some apt-file searches for which I didn?t put a sudo apt-get install command line done. Sorry about that. --- SNIP --- $ sudo dpkg --set-selections < install_misc/ubuntu.packages $ sudo dselect --- SNIP --- Did you grab the ubuntu.packages from 3.6.7 or 3.6.8? That is the correct one. That's why I was noting my patch didn't make it into 3.8.X. I hope to solve this before 3.8.5 comes out. --- SNIP --- FYI, getting Robin's pgp required a couple of steps that you did not mention. Using: $ wget http://debian.koha-community.org/koha/gpg.asc | sudo apt-key add - gives the error "GPG error: http://archive.ubuntu.com dapper Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 14D36485A99CEB6D" --- SNIP --- That isn?t what I said to type: wget -O- http://debian.koha-community.org/koha/gpg.asc | sudo apt-key add - and that isn?t what is on the wiki: http://wiki.koha-community.org/wiki/Koha_3.8_on_Debian_Squeeze (under the Everyone title) >>Which way should you do? >>Are you going to develop, submit patches, etc for a non-production system? >>If yes, then (3) GIT! >>Are you using a debian-based OS? If yes, then (1) Packages! >>For everything else, there is (2) Tarball. --- SNIP --- While I'd love to have time to "submit patches", I juts seem to spend too much time maintaining a production system. I do not use a pure Debian system, but Ubuntu for all our servers and workstations. Hence your "For everything else, there is tarball." --- SNIP --- I didn?t say Debian, I said debian-based, which includes Ubuntu. I know the packages work, because I have done a packages install, just to understand the three ways of installing. In fact, I think it only installed 3 things from the debian.koha-community.org repository while doing it too. I was pleased by such a low number. Anyways, I?m glad these tips helped point you in the right direction. GPML, Mark Tompsett -------------- next part -------------- An HTML attachment was scrubbed... URL: From mtj at kohaaloha.com Wed Aug 22 22:09:48 2012 From: mtj at kohaaloha.com (Mason James) Date: Thu, 23 Aug 2012 08:09:48 +1200 Subject: [Koha-devel] Officially supported OS versions In-Reply-To: References: Message-ID: <7339CC15-E2E1-41EE-9BAD-F45FD78C157D@kohaaloha.com> > > So, in short: maybe offer packages for debian and fedora and any > other similar ones, else just describe what works and help > any third-party offerings. > > Hope that explains, > -- > MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. MJ, i agree on all your points :) just 1 more question ? any volunteers out there for a Koha Redhat/Fedora package-builder person? :) From info at AandC.org Wed Aug 22 23:57:37 2012 From: info at AandC.org (Archives and Collections Society) Date: Wed, 22 Aug 2012 17:57:37 -0400 Subject: [Koha-devel] 3.8.4 interim [was: koha-zebra-daemon not starting] In-Reply-To: References: <5.2.1.1.2.20120822144652.0359d578@localhost> <5.2.1.1.2.20120821201313.01af8798@localhost> <5.2.1.1.2.20120821190421.01b97d48@localhost> <5.2.1.1.2.20120821172557.0269bea8@localhost> <5.2.1.1.2.20120820184941.03366ab8@localhost> <5.2.1.1.2.20120819152156.0346fdf8@stormy.ca> <5.2.1.1.2.20120819152156.0346fdf8@stormy.ca> <5.2.1.1.2.20120820184941.03366ab8@localhost> <5.2.1.1.2.20120821172557.0269bea8@localhost> <5.2.1.1.2.20120821190421.01b97d48@localhost> <5.2.1.1.2.20120821201313.01af8798@localhost> <5.2.1.1.2.20120822144652.0359d578@localhost> Message-ID: <5.2.1.1.2.20120822173314.04a76df0@localhost> At 03:56 AM 8/23/2012 +0800, Mark Tompsett wrote: >--- SNIP --- >$ sudo apt-get install libyaz4 >PLUS >libyaz4-dev >libnet-z3950-zoom-perl >libxml-libxslt-perl >libgraphics-magick-perl >liblingua-stem-snowball-perl >libtemplate-perl >libtemplate-plugin-htmltotext-perl >liblingua-ispell-perl >libhtml-template-pro-perl >libreadonly-xs-perl >libtest-strict-perl >--- SNIP --- > >The point was all the libraries you needed are there. Mark - many thanks, but "are there" takes a bit of a detour. Yes, they're "there", (slight proviso for libtemplate-plugin-htmltotext-perl which needs the koha repository, as it's not available via Debian/Ubuntu standard repositories.) Also pls see my previous remarks if you're using *AMD64* (I think you said you used i386, but could be wrong.) >Did you grab the ubuntu.packages from 3.6.7 or 3.6.8? That is the correct >one. That's why I was noting my patch didn't make it into 3.8.X. >I hope to solve this before 3.8.5 comes out. I "grabbed the ubuntu.packages" from koha-3.08.04.tar.gz/koha-3.08.04/install_misc/ubuntu.packages (nothing to do with 3.6.x) which has e.g. in install_misc/ubuntu.packages libyaz3 *NOT* libyaz4. It wouldn't take long to update that file. >[snip] That isn???t what I said to type: >wget -O- http://debian.koha-community.org/koha/gpg.asc | sudo apt-key add - the -O- failed miserably (can't remember the details, something about /home/paul/) but at least gave me Robin S's pgp number and I moved on. The workaround in my previous email solved the problem. Now back to 3.8.4 tnx, a+, p. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomascohen at gmail.com Thu Aug 23 00:12:59 2012 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Wed, 22 Aug 2012 19:12:59 -0300 Subject: [Koha-devel] Fwd: 3.8.4 interim [was: koha-zebra-daemon not starting] In-Reply-To: References: <5.2.1.1.2.20120819152156.0346fdf8@stormy.ca> <5.2.1.1.2.20120820184941.03366ab8@localhost> <5.2.1.1.2.20120821172557.0269bea8@localhost> <5.2.1.1.2.20120821190421.01b97d48@localhost> <5.2.1.1.2.20120821201313.01af8798@localhost> <5.2.1.1.2.20120822144652.0359d578@localhost> Message-ID: ---------- Forwarded message ---------- From: Tomas Cohen Arazi Date: Wed, Aug 22, 2012 at 4:41 PM Subject: Re: [Koha-devel] 3.8.4 interim [was: koha-zebra-daemon not starting] To: Paul El ago 22, 2012 4:20 p.m., "Paul" escribi?: > > At 10:04 PM 8/22/2012 +0800, Mark Tompsett wrote: >> >> Greetings, >> >> And having just looked through the 3.8.4 files in /install_misc/ubuntu*.packages, I have realized my patches didn't make it into the 3.8.X stream. I'll have to bug report and do a 3.8.X specific bug patch (they are in 3.6.7)... But that aside. As I was just chatting with tcohen on IRC, he reminded me that yaz3 was the problem. >> >> I actually finished looking at the ubuntu.packages file and installed these: >> $ sudo apt-get install apache2 daemon gettext mysql-server libmysqlclient18 yaz yaz-doc libyaz4 libyaz4-dev idzebra-2.0 idzebra-2.0-common idzebra-2.0-doc idzebra-2.0-utils libidzebra-2.0-0 >> $ sudo apt-get install libidzebra-2.0-dev libidzebra-2.0-mod-alvis libidzebra-2.0-mod-grs-marc libidzebra-2.0-mod-grs-regx libidzebra-2.0-mod-grs-xml libidzebra-2.0-mod-text >> $ sudo apt-get install libidzebra-2.0-modules libxml2-utils > > > Mark - tnx for your interest (and sorry to read that Chris C. is ducking out of this thread -- tnx for all you do.) I managed to have a quick look at it again this morning, and hope to find another hour before the day is out, but I came to roughly the same conclusion. > > yaz3 must be replaced by yaz4. I ended up reinstalling the server [again] to be certain that everything was clean, and by: > > $ sudo apt-get install libyaz4 > PLUS > libyaz4-dev > libnet-z3950-zoom-perl > libxml-libxslt-perl > libgraphics-magick-perl > liblingua-stem-snowball-perl > libtemplate-perl > libtemplate-plugin-htmltotext-perl > liblingua-ispell-perl > libhtml-template-pro-perl > libreadonly-xs-perl > libtest-strict-perl > > THEN using: > > > $ sudo dpkg --set-selections < install_misc/ubuntu.packages > $ sudo dselect > > you get all the dependencies properly. Starting with dphg + dselect somehow *half* installs about 50 i386 bits and pieces, and while > > $sudo apt-get purge .*:i386 > > cleaned up quite nicely, I did a complete 12.04 re-install to make sure everything was copacetic. > > I did need to add the koha repository to get one file [template::htmltotext] as this is not an Ubuntu|Debian file, but is recorded after install as "koha". FYI, getting Robin's pgp required a couple of steps that you did not mention. Using: > > $ wget http://debian.koha-community.org/koha/gpg.asc | sudo apt-key add - > > gives the error "GPG error: http://archive.ubuntu.com dapper Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 14D36485A99CEB6D" > > To correct this: > $ gpg --recv-keys 14D36485A99CEB6D > > And then add it to apt-keys: > $ gpg --export --armor 14D36485A99CEB6D | sudo apt-key add - > > works fine. > > BTW, you wrote earlier: > > >> Which way should you do? >> Are you going to develop, submit patches, etc for a non-production system? If yes, then (3) GIT! >> Are you using a debian-based OS? If yes, then (1) Packages! >> For everything else, there is (2) Tarball. > > > While I'd love to have time to "submit patches", I juts seem to spend too much time maintaining a production system. I do not use a pure Debian system, but Ubuntu for all our servers and workstations. Hence your "For everything else, there is tarball." My current aim is to get the production server onto 3.8.x from 3.6.x, but need to document (internally here) how to do this cleanly. > > The tarball has always worked extremely well on i386 machines -- I just get the impression (not proven) that Ubuntu 12.04 gets its knickers in a twist on AMD64. But with a little time and effort workarounds can be found. Probably nothing wrong, just new quirks, with either Ubuntu or Koha, but I do not need to be under pressure for the production upgrade. is not a 12.04 problem, is a problem with the specific file you're using with dpkg, which lists some files not available anymore on 12.04. As Mark said that file has already been patched and its waiting for inclusion on next release. That said, you can do a clean install using the instructions and ommiting that --set-selections step. And installing the dependencies by hand. As Mark also said. I also use the tarball in our deployment (38 instances on a single BIG server) without issues. Besides that i386 packages pull which I reported and has been solved. Anyway, I think we should go back to what your original problem was. Is your incremental indexing working? Have you properly set your sax parser? (I'm an experienced Koha user and forgot to check that step last time, having weird behavior) Regards To+ From info at AandC.org Thu Aug 23 00:21:17 2012 From: info at AandC.org (Archives and Collections Society) Date: Wed, 22 Aug 2012 18:21:17 -0400 Subject: [Koha-devel] 3.8.4 interim [was: koha-zebra-daemon not starting] In-Reply-To: References: <5.2.1.1.2.20120822144652.0359d578@localhost> <5.2.1.1.2.20120819152156.0346fdf8@stormy.ca> <5.2.1.1.2.20120820184941.03366ab8@localhost> <5.2.1.1.2.20120821172557.0269bea8@localhost> <5.2.1.1.2.20120821190421.01b97d48@localhost> <5.2.1.1.2.20120821201313.01af8798@localhost> <5.2.1.1.2.20120822144652.0359d578@localhost> Message-ID: <5.2.1.1.2.20120822175905.04cefb40@localhost> At 04:41 PM 8/22/2012 -0300, Tomas Cohen Arazi wrote: [snip] > > The tarball has always worked extremely well on i386 machines -- I just > get the impression (not proven) that Ubuntu 12.04 gets its knickers in a > twist on AMD64. ? But with a little time and effort workarounds can be > found. ? Probably nothing wrong, just new quirks, with either Ubuntu or > Koha, but I do not need to be under pressure for the production upgrade. > >is not a 12.04 problem, is a problem with the specific file you're using >with dpkg, which lists some files not available anymore on 12.04. >As Mark said that file has already been patched and its waiting for >inclusion on next release. Thanks for the reply. But, as you say, "its waiting for inclusion on next release" so it's broken in this release. >That said, you can do a clean install using the instructions and ommiting >that --set-selections step. And installing the dependencies by hand. As >Mark also said. More or less what I've done -- but it would not be rocket science to edit install_misc/ubuntu.packages to avoid a certain amount of grief (and before anyone asks "well why don't you do it?" I will as soon as I'm certain that my experience is reproducible and bullet-proof. It may involve looking at the upstream .pl file to see how the list is invoked.) >I also use the tarball in our deployment (38 instances on a single BIG >server) without issues. I'm only trying a test install on relatively BIG server (64-bit, 6 core Intel i7-980X, solid state raided drives, 16Gb ram), mileage varies... > Besides that i386 packages pull which I reported and has been solved. When, where, how? I had to 'sudo apt-get purge .*:i386' for about 50 dependencies in the pull in koha-3.08.04.tar.gz >Anyway, I think we should go back to what your original problem was.? Is >your incremental indexing working? That was 3.8.3, now trashed, but it never worked -- I'll try it on a 3.8.4 install as soon as I'm away from this machine. >Have you properly set your sax parser? [snip] Yes. Best - P. From paul.a at aandc.org Thu Aug 23 00:21:47 2012 From: paul.a at aandc.org (Paul) Date: Wed, 22 Aug 2012 18:21:47 -0400 Subject: [Koha-devel] 3.8.4 interim [was: koha-zebra-daemon not starting] Message-ID: <5.2.1.1.2.20120822182137.04758d20@localhost> At 04:41 PM 8/22/2012 -0300, Tomas Cohen Arazi wrote: [snip] > > The tarball has always worked extremely well on i386 machines -- I just > get the impression (not proven) that Ubuntu 12.04 gets its knickers in a > twist on AMD64. ? But with a little time and effort workarounds can be > found. ? Probably nothing wrong, just new quirks, with either Ubuntu or > Koha, but I do not need to be under pressure for the production upgrade. > >is not a 12.04 problem, is a problem with the specific file you're using >with dpkg, which lists some files not available anymore on 12.04. >As Mark said that file has already been patched and its waiting for >inclusion on next release. Thanks for the reply. But, as you say, "its waiting for inclusion on next release" so it's broken in this release. >That said, you can do a clean install using the instructions and ommiting >that --set-selections step. And installing the dependencies by hand. As >Mark also said. More or less what I've done -- but it would not be rocket science to edit install_misc/ubuntu.packages to avoid a certain amount of grief (and before anyone asks "well why don't you do it?" I will as soon as I'm certain that my experience is reproducible and bullet-proof. It may involve looking at the upstream .pl file to see how the list is invoked.) >I also use the tarball in our deployment (38 instances on a single BIG >server) without issues. I'm only trying a test install on relatively BIG server (64-bit, 6 core Intel i7-980X, solid state raided drives, 16Gb ram), mileage varies... > Besides that i386 packages pull which I reported and has been solved. When, where, how? I had to 'sudo apt-get purge .*:i386' for about 50 dependencies in the pull in koha-3.08.04.tar.gz >Anyway, I think we should go back to what your original problem was.? Is >your incremental indexing working? That was 3.8.3, now trashed, but it never worked -- I'll try it on a 3.8.4 install as soon as I'm away from this machine. >Have you properly set your sax parser? [snip] Yes. Best - P. --- Maritime heritage and history, preservation and conservation, research and education through the written word and the arts. and From tomascohen at gmail.com Thu Aug 23 00:40:03 2012 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Wed, 22 Aug 2012 19:40:03 -0300 Subject: [Koha-devel] 3.8.4 interim [was: koha-zebra-daemon not starting] In-Reply-To: <5.2.1.1.2.20120822182137.04758d20@localhost> References: <5.2.1.1.2.20120822182137.04758d20@localhost> Message-ID: Paul, You're right. The current stable tarball includes: - Outdated INSTALL.ubuntu* files - Outdated misc/ubuntu.packages file All people that answered your questions is aware of that (we meet at IRC every day and have nice exchanges on that subject). We even fixed that problem, and it should be in future releaes soon (our workflow is not optimal sometimes, there have been more urgent issues to fix). What we're all saying is that you are right about that; and besides that, Koha runs flawlessly for of us on 64 bit servers, runnning on Ubuntu LTS distro (12.04 and 10.04). People just told you how to circumvent those issues. Regards To+ PS: Sorry for my poor english. PS2: I've struggled and got annoyed for the outdated docs, and even filled this http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8478. You'll see Mark's work there. From mtj at kohaaloha.com Thu Aug 23 02:25:43 2012 From: mtj at kohaaloha.com (Mason James) Date: Thu, 23 Aug 2012 12:25:43 +1200 Subject: [Koha-devel] Lets improve the Koha installation documentation In-Reply-To: References: <5.2.1.1.2.20120822182137.04758d20@localhost> Message-ID: <06AEAB3D-C3DD-4636-8796-E73E8959CA7A@kohaaloha.com> > > Regards > To+ > > PS: Sorry for my poor english. > PS2: I've struggled and got annoyed for the outdated docs, and even > filled this http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8478. > You'll see Mark's work there. Tomas there has been some discussion about ways to improve the Koha install docs the big problem is... there are too many 'Koha installation guides' on the kc.org wiki that have old ,incorrect, redundant or duplicated info i think we need to remove the duplicated installation documentation from the wiki and concentrate on improving the INSTALL.* files in the Koha git repository (just like we do with the Koha user-manual) lets have a single place for the Koha installation files (and a consistent format) lets have modifications to those critical and complex files go-thru a QA process and version control, too many people google-search for 'koha installation help guide', then find these incorrect guides and have horrible experiences installing Koha :/ what do other Koha devs think? does anyone else agree that these old or inaccurate install guides are causing problems for Koha newbies? Mason From paul.a at aandc.org Thu Aug 23 02:36:43 2012 From: paul.a at aandc.org (Paul) Date: Wed, 22 Aug 2012 20:36:43 -0400 Subject: [Koha-devel] 3.8.4 interim [was: koha-zebra-daemon not starting] In-Reply-To: References: <5.2.1.1.2.20120822182137.04758d20@localhost> <5.2.1.1.2.20120822182137.04758d20@localhost> Message-ID: <5.2.1.1.2.20120822194128.01e26d88@localhost> At 07:40 PM 8/22/2012 -0300, Tomas Cohen Arazi wrote: Tomas, >and besides >that, Koha runs flawlessly for of us on 64 bit servers, runnning on >Ubuntu LTS distro (12.04 and 10.04). > >People just told you how to circumvent those issues. Thanks for the reply -- I'm convinced that everyone is working towards the same goal. But, despite never having had this problem on 3.6.1, 4, 6, 7, I just can't get beyond it on 3.8.3 and 4. It *must* be my mistake (maybe a totally dumb one), but after four installs I'm back to a non-functional zebra. Coming back to my original issue -- 3.8.4 (after another full install) is showing the same error as 3.8.3 -- idzebra-2.0 is fully [??? an 'apt-get idzebra-2.0' comes up with "latest version" and no missing dependencies ???] installed but there's no daemon! So I must have missed something in the repositories/dependences. paul at server:~$ sudo /etc/init.d/koha-zebra-daemon start Starting Zebra Server /etc/init.d/koha-zebra-daemon: line 73: daemon: command not found I am now convinced that somehow, somewhere, zebra is *NOT* properly installed. So before I go any further and screw something up, here's where I'm at as far as Zebra is concerned: /etc/init.d/koha-zebra-daemon has the proper symlink: paul at server:/etc/init.d$ ls -l | grep koha lrwxrwxrwx 1 root root 37 Aug 22 19:11 koha-zebra-daemon -> /usr/share/koha/bin/koha-zebra-ctl.sh and that is the file that has the line 73 that causes the error: daemon --name=$NAME --errlog=$ERRLOG --stdout=$STDOUT --output=$OUTPUT --verbose=1 --respawn --delay=30 $OTHERUSER -- $ZEBRASRV $ZEBRAOPTIONS -f $KOHA_CONF koha-conf.xml has the user as 'koha' with the correct password, and the output belongs to 'koha': paul at server:/var/lock/koha/zebradb$ ls -l total 0 drwxr-xr-x 2 koha koha 40 Aug 22 19:48 authorities drwxr-xr-x 2 koha koha 40 Aug 22 19:48 biblios I guess that I can get back to things tomorrow and try manually installing: idzebra-2.0-common idzebra-2.0-doc idzebra-2.0-utils libidzebra-2.0-0 libidzebra-2.0-dev libidzebra-2.0-mod-alvis libidzebra-2.0-mod-grs-marc libidzebra-2.0-mod-grs-regx libidzebra-2.0-mod-grs-xml libidzebra-2.0-mod-text libidzebra-2.0-modules but I would have thought that idzebra-2.0 contained all the necessary dependences, or would have reported anything missing. Best -- P. --- Maritime heritage and history, preservation and conservation, research and education through the written word and the arts. and From chris at bigballofwax.co.nz Thu Aug 23 03:01:00 2012 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Thu, 23 Aug 2012 13:01:00 +1200 Subject: [Koha-devel] Lets improve the Koha installation documentation In-Reply-To: <06AEAB3D-C3DD-4636-8796-E73E8959CA7A@kohaaloha.com> References: <5.2.1.1.2.20120822182137.04758d20@localhost> <06AEAB3D-C3DD-4636-8796-E73E8959CA7A@kohaaloha.com> Message-ID: On 23 August 2012 12:25, Mason James wrote: >> >> Regards >> To+ >> >> PS: Sorry for my poor english. > > >> PS2: I've struggled and got annoyed for the outdated docs, and even >> filled this http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8478. >> You'll see Mark's work there. > > Tomas > > there has been some discussion about ways to improve the Koha install docs > > the big problem is... > there are too many 'Koha installation guides' on the kc.org wiki that have old ,incorrect, redundant or duplicated info > > > i think we need to remove the duplicated installation documentation from the wiki > and concentrate on improving the INSTALL.* files in the Koha git repository (just like we do with the Koha user-manual) > > > lets have a single place for the Koha installation files (and a consistent format) > > lets have modifications to those critical and complex files go-thru a QA process and version control, too > > > many people google-search for 'koha installation help guide', then find these incorrect guides and have horrible experiences installing Koha :/ > > > what do other Koha devs think? > does anyone else agree that these old or inaccurate install guides are causing problems for Koha newbies? > +1 for bringing them into version control and under signoff/qa process. Chris From abesottedphoenix at yahoo.com Thu Aug 23 03:06:27 2012 From: abesottedphoenix at yahoo.com (BWS Johnson) Date: Wed, 22 Aug 2012 18:06:27 -0700 (PDT) Subject: [Koha-devel] Lets improve the Koha installation documentation In-Reply-To: <06AEAB3D-C3DD-4636-8796-E73E8959CA7A@kohaaloha.com> References: <5.2.1.1.2.20120822182137.04758d20@localhost> <06AEAB3D-C3DD-4636-8796-E73E8959CA7A@kohaaloha.com> Message-ID: <1345683987.42263.YahooMailNeo@web140806.mail.bf1.yahoo.com> Salvete! > the big problem is... > there are too many 'Koha installation guides' on the kc.org wiki that > have old ,incorrect, redundant or duplicated info > ??? ??? Alternatively, we could mark those entries up with wiki tags to reflect that there is old, incorrect, or redundant redundant redundant information. :) Then we can have some folks that aren't eyeball deep in code go and fix 'em. Cheers, Brooke From mtj at kohaaloha.com Thu Aug 23 03:13:03 2012 From: mtj at kohaaloha.com (Mason James) Date: Thu, 23 Aug 2012 13:13:03 +1200 Subject: [Koha-devel] 3.8.4 interim [was: koha-zebra-daemon not starting] In-Reply-To: <5.2.1.1.2.20120822194128.01e26d88@localhost> References: <5.2.1.1.2.20120822182137.04758d20@localhost> <5.2.1.1.2.20120822182137.04758d20@localhost> <5.2.1.1.2.20120822194128.01e26d88@localhost> Message-ID: <5D60C882-A67B-48D6-B518-7B7AE354B30F@kohaaloha.com> On 2012-08-23, at 12:36 PM, Paul wrote: > At 07:40 PM 8/22/2012 -0300, Tomas Cohen Arazi wrote: > Tomas, > >> and besides >> that, Koha runs flawlessly for of us on 64 bit servers, runnning on >> Ubuntu LTS distro (12.04 and 10.04). >> >> People just told you how to circumvent those issues. > > Thanks for the reply -- I'm convinced that everyone is working towards the same goal. But, despite never having had this problem on 3.6.1, 4, 6, 7, I just can't get beyond it on 3.8.3 and 4. It *must* be my mistake (maybe a totally dumb one), but after four installs I'm back to a non-functional zebra. > > Coming back to my original issue -- 3.8.4 (after another full install) is showing the same error as 3.8.3 -- idzebra-2.0 is fully [??? an 'apt-get idzebra-2.0' comes up with "latest version" and no missing dependencies ???] installed but there's no daemon! So I must have missed something in the repositories/dependences. > > paul at server:~$ sudo /etc/init.d/koha-zebra-daemon start > Starting Zebra Server > /etc/init.d/koha-zebra-daemon: line 73: daemon: command not found $ sudo apt-get install daemon ? (i'm not why you are missing that package) From mtj at kohaaloha.com Thu Aug 23 03:50:20 2012 From: mtj at kohaaloha.com (Mason James) Date: Thu, 23 Aug 2012 13:50:20 +1200 Subject: [Koha-devel] 3.8.4 interim [was: koha-zebra-daemon not starting] In-Reply-To: <5D60C882-A67B-48D6-B518-7B7AE354B30F@kohaaloha.com> References: <5.2.1.1.2.20120822182137.04758d20@localhost> <5.2.1.1.2.20120822182137.04758d20@localhost> <5.2.1.1.2.20120822194128.01e26d88@localhost> <5D60C882-A67B-48D6-B518-7B7AE354B30F@kohaaloha.com> Message-ID: <15A82E0B-374D-49F3-B9AA-60246861DF10@kohaaloha.com> >> >> paul at server:~$ sudo /etc/init.d/koha-zebra-daemon start >> Starting Zebra Server >> /etc/init.d/koha-zebra-daemon: line 73: daemon: command not found > > $ sudo apt-get install daemon ? > > (i'm not why you are missing that package) my other hunch is that you have bunch of __FOO__ stuff in your /etc/init.d/koha-zebra-daemon file like this.. USER=__KOHA_USER__ GROUP=__KOHA_GROUP__ DBNAME=__DB_NAME__ NAME=koha-zebra-ctl.$DBNAME LOGDIR=__LOG_DIR__ ERRLOG=$LOGDIR/koha-zebradaemon.err STDOUT=$LOGDIR/koha-zebradaemon.log OUTPUT=$LOGDIR/koha-zebradaemon-output.log KOHA_CONF=__KOHA_CONF_DIR__/koha-conf.xml RUNDIR=__ZEBRA_RUN_DIR__ LOCKDIR=__ZEBRA_LOCK_DIR__ # you may need to change this depending on where zebrasrv is installed ZEBRASRV=__PATH_TO_ZEBRA__/zebrasrv ZEBRAOPTIONS="-v none,fatal,warn" which is causing your script to fail... From cnighswonger at foundations.edu Thu Aug 23 03:52:23 2012 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Wed, 22 Aug 2012 21:52:23 -0400 Subject: [Koha-devel] Lets improve the Koha installation documentation In-Reply-To: References: <5.2.1.1.2.20120822182137.04758d20@localhost> <06AEAB3D-C3DD-4636-8796-E73E8959CA7A@kohaaloha.com> Message-ID: On Wed, Aug 22, 2012 at 9:01 PM, Chris Cormack wrote: > > what do other Koha devs think? > > does anyone else agree that these old or inaccurate install guides are > causing problems for Koha newbies? > > > +1 for bringing them into version control and under signoff/qa process. > > If we follow through with this, it would be trivial to write up a script to pull the various *.INSTALL files from the repo and transform them into wiki pages. This could be cron'd up so the wiki pages always matched the files in the repo. Kind Regards, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at bigballofwax.co.nz Thu Aug 23 03:53:16 2012 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Thu, 23 Aug 2012 13:53:16 +1200 Subject: [Koha-devel] Lets improve the Koha installation documentation In-Reply-To: References: <5.2.1.1.2.20120822182137.04758d20@localhost> <06AEAB3D-C3DD-4636-8796-E73E8959CA7A@kohaaloha.com> Message-ID: On 23 August 2012 13:52, Chris Nighswonger wrote: > On Wed, Aug 22, 2012 at 9:01 PM, Chris Cormack > wrote: >> >> > what do other Koha devs think? >> > does anyone else agree that these old or inaccurate install guides are >> > causing problems for Koha newbies? >> > >> +1 for bringing them into version control and under signoff/qa process. >> > > If we follow through with this, it would be trivial to write up a script to > pull the various *.INSTALL files from the repo and transform them into wiki > pages. This could be cron'd up so the wiki pages always matched the files in > the repo. > +1 for this idea also Chris From mtompset at hotmail.com Thu Aug 23 06:12:33 2012 From: mtompset at hotmail.com (Mark Tompsett) Date: Thu, 23 Aug 2012 12:12:33 +0800 Subject: [Koha-devel] Lets improve the Koha installation documentation In-Reply-To: <06AEAB3D-C3DD-4636-8796-E73E8959CA7A@kohaaloha.com> References: <5.2.1.1.2.20120822182137.04758d20@localhost> <06AEAB3D-C3DD-4636-8796-E73E8959CA7A@kohaaloha.com> Message-ID: Greetings, Yes, I was hoping to getting around to cleaning up the documentation further. However until I have a 64-bit OS to attempt to install, I can't really address all the problems some people are encountering. Which bugs me, because I want good documentation for all three types of installs. The problem is you can't write step-by-step documentation for each OS, because a tarball install under Debian, Ubuntu, CentOS are all going to encounter different problems. Similarly, a git install will as well. You can only write "here's a problem you may encounter and here's an example of how to handle it". This gets compounded into a people looking for a step-by-step guide, and they'll keep hunting until they find one regardless of how dated it is. I believe the http://wiki.koha-community.org/wiki/Koha_on_Ubuntu is a good place for a basic set of tarball instructions. The problem then becomes OS specific when trying to install dependencies like http://wiki.koha-community.org/wiki/Koha_3.6_on_Centos_6.2_i386. This is another reason packages is a better way: the dependencies should all be there. GPML, Mark Tompsett From tomascohen at gmail.com Thu Aug 23 16:02:08 2012 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Thu, 23 Aug 2012 11:02:08 -0300 Subject: [Koha-devel] Lets improve the Koha installation documentation In-Reply-To: References: <5.2.1.1.2.20120822182137.04758d20@localhost> <06AEAB3D-C3DD-4636-8796-E73E8959CA7A@kohaaloha.com> Message-ID: I agree with all of you. And must add that a while ago I started the rewrite of the Ubuntu install files (look at the first commit on that bug), after which Mark put his hands on it and now we've got this fresh install instructions. For that purpose I set (on our infrastructure) both a 10.04 and 12.04 Ubuntu Server setups to test and QA those install instructions. Both are 64bit, hence when I signed-off on those instructions, I meant to say I fully tested them to work for amd64 arch. INSTALL files where way too old, and that made them difficult to maintain. If what we need is volunteers, I already volunteered for Ubuntu files. Regards To+ On Thu, Aug 23, 2012 at 1:12 AM, Mark Tompsett wrote: > Greetings, > > Yes, I was hoping to getting around to cleaning up the documentation > further. However until I have a 64-bit OS to attempt to install, I can't > really address all the problems some people are encountering. Which bugs me, > because I want good documentation for all three types of installs. > > The problem is you can't write step-by-step documentation for each OS, > because a tarball install under Debian, Ubuntu, CentOS are all going to > encounter different problems. Similarly, a git install will as well. You can > only write "here's a problem you may encounter and here's an example of how > to handle it". This gets compounded into a people looking for a step-by-step > guide, and they'll keep hunting until they find one regardless of how dated > it is. > > I believe the http://wiki.koha-community.org/wiki/Koha_on_Ubuntu is a good > place for a basic set of tarball instructions. The problem then becomes OS > specific when trying to install dependencies like > http://wiki.koha-community.org/wiki/Koha_3.6_on_Centos_6.2_i386. This is > another reason packages is a better way: the dependencies should all be > there. > > GPML, > Mark Tompsett From mtj at kohaaloha.com Thu Aug 23 16:41:51 2012 From: mtj at kohaaloha.com (Mason James) Date: Fri, 24 Aug 2012 02:41:51 +1200 Subject: [Koha-devel] Lets improve the Koha installation documentation In-Reply-To: References: <5.2.1.1.2.20120822182137.04758d20@localhost> <06AEAB3D-C3DD-4636-8796-E73E8959CA7A@kohaaloha.com> Message-ID: <25C7757E-2F8D-42EE-81E8-CAA3B2900F69@kohaaloha.com> On 2012-08-23, at 4:12 PM, Mark Tompsett wrote: > Greetings, > > Yes, I was hoping to getting around to cleaning up the documentation further. However until I have a 64-bit OS to attempt to install, I can't really address all the problems some people are encountering. Which bugs me, because I want good documentation for all three types of installs. > > The problem is you can't write step-by-step documentation for each OS, because a tarball install under Debian, Ubuntu, CentOS are all going to encounter different problems. nope, i disagree? its perfectly possible to write step-by-step documentation for each OS > Similarly, a git install will as well. You can only write "here's a problem you may encounter and here's an example of how to handle it". This gets compounded into a people looking for a step-by-step guide, and they'll keep hunting until they find one regardless of how dated it is. yes, so lets remove the incorrect guides from the wiki, so people won't accidentally 'find' them. From mtj at kohaaloha.com Thu Aug 23 16:49:39 2012 From: mtj at kohaaloha.com (Mason James) Date: Fri, 24 Aug 2012 02:49:39 +1200 Subject: [Koha-devel] Lets improve the Koha installation documentation In-Reply-To: References: <5.2.1.1.2.20120822182137.04758d20@localhost> <06AEAB3D-C3DD-4636-8796-E73E8959CA7A@kohaaloha.com> Message-ID: <7D888F97-6D33-469C-9986-F2C0B653D568@kohaaloha.com> On 2012-08-24, at 2:02 AM, Tomas Cohen Arazi wrote: > I agree with all of you. And must add that a while ago I started the > rewrite of the Ubuntu install files (look at the first commit on that > bug), after which Mark put his hands on it and now we've got this > fresh install instructions. > > For that purpose I set (on our infrastructure) both a 10.04 and 12.04 > Ubuntu Server setups to test and QA those install instructions. Both > are 64bit, hence when I signed-off on those instructions, I meant to > say I fully tested them to work for amd64 arch. > > INSTALL files where way too old, and that made them difficult to > maintain. If what we need is volunteers, > I already volunteered for Ubuntu files. awesome Tomaz i'll volunteer to update and do QA on the debian INSTALL.* files anyone wanna volunteer for any other distros? (fedora, centos, etc?) From cnighswonger at foundations.edu Thu Aug 23 17:14:21 2012 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Thu, 23 Aug 2012 11:14:21 -0400 Subject: [Koha-devel] Lets improve the Koha installation documentation In-Reply-To: <7D888F97-6D33-469C-9986-F2C0B653D568@kohaaloha.com> References: <5.2.1.1.2.20120822182137.04758d20@localhost> <06AEAB3D-C3DD-4636-8796-E73E8959CA7A@kohaaloha.com> <7D888F97-6D33-469C-9986-F2C0B653D568@kohaaloha.com> Message-ID: On Thu, Aug 23, 2012 at 10:49 AM, Mason James wrote: > > > I already volunteered for Ubuntu files. > > > awesome Tomaz > > i'll volunteer to update and do QA on the debian INSTALL.* files > > If we can agree to some sort of standardized formatting, I'll write a parser to generate the wiki pages from the INSTALL files. Kind Regards, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From robin at catalyst.net.nz Thu Aug 23 17:17:07 2012 From: robin at catalyst.net.nz (Robin Sheat) Date: Thu, 23 Aug 2012 17:17:07 +0200 Subject: [Koha-devel] Lets improve the Koha installation documentation In-Reply-To: References: <5.2.1.1.2.20120822182137.04758d20@localhost> <06AEAB3D-C3DD-4636-8796-E73E8959CA7A@kohaaloha.com> <7D888F97-6D33-469C-9986-F2C0B653D568@kohaaloha.com> Message-ID: <50364973.2020500@catalyst.net.nz> Op 23-08-12 17:14, Chris Nighswonger schreef: > > If we can agree to some sort of standardized formatting, I'll write a > parser to generate the wiki pages from the INSTALL files. Wiki formatting would make sense, wouldn't it? It's reasonably readable too. -- Robin Sheat Catalyst IT Ltd. ? +64 4 803 2204 GPG: 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D From gmc at esilibrary.com Thu Aug 23 17:24:12 2012 From: gmc at esilibrary.com (Galen Charlton) Date: Thu, 23 Aug 2012 11:24:12 -0400 Subject: [Koha-devel] Lets improve the Koha installation documentation In-Reply-To: References: <5.2.1.1.2.20120822182137.04758d20@localhost> <06AEAB3D-C3DD-4636-8796-E73E8959CA7A@kohaaloha.com> <7D888F97-6D33-469C-9986-F2C0B653D568@kohaaloha.com> Message-ID: <50364B1C.2060807@esilibrary.com> Hi, On 08/23/2012 11:14 AM, Chris Nighswonger wrote: > If we can agree to some sort of standardized formatting, I'll write a > parser to generate the wiki pages from the INSTALL files. Speaking of standardized formatting, how about AsciiDoc? [1] Some advantages: - producing HTML and other output is trivial - it wouldn't be hard to write a parser to produce MediaWiki output - based on experience from the Evergreen project, it's something that non-techie librarians can adapt to if they want to contribute changes. [1] http://www.methods.co.nz/asciidoc/ Regards, Galen -- Galen Charlton Director of Support and Implementation Equinox Software, Inc. / The Open Source Experts email: gmc at 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 From cnighswonger at foundations.edu Thu Aug 23 17:25:44 2012 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Thu, 23 Aug 2012 11:25:44 -0400 Subject: [Koha-devel] Lets improve the Koha installation documentation In-Reply-To: <50364973.2020500@catalyst.net.nz> References: <5.2.1.1.2.20120822182137.04758d20@localhost> <06AEAB3D-C3DD-4636-8796-E73E8959CA7A@kohaaloha.com> <7D888F97-6D33-469C-9986-F2C0B653D568@kohaaloha.com> <50364973.2020500@catalyst.net.nz> Message-ID: On Thu, Aug 23, 2012 at 11:17 AM, Robin Sheat wrote: > Op 23-08-12 17:14, Chris Nighswonger schreef: > > > > If we can agree to some sort of standardized formatting, I'll write a > > parser to generate the wiki pages from the INSTALL files. > > Wiki formatting would make sense, wouldn't it? > > I was hoping someone would suggest that... ;-) > It's reasonably readable too. > > For the most part We could to them in POD and then do something like pod2wiki: http://search.cpan.org/~jmcnamara/Pod-Simple-Wiki-0.14/bin/pod2wiki Which would allow such as 'perldoc INSTALL.foo' and such. Kind Regards, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From mtj at kohaaloha.com Thu Aug 23 21:00:07 2012 From: mtj at kohaaloha.com (Mason James) Date: Fri, 24 Aug 2012 07:00:07 +1200 Subject: [Koha-devel] Lets improve the Koha installation documentation In-Reply-To: References: <5.2.1.1.2.20120822182137.04758d20@localhost> <06AEAB3D-C3DD-4636-8796-E73E8959CA7A@kohaaloha.com> <7D888F97-6D33-469C-9986-F2C0B653D568@kohaaloha.com> <50364973.2020500@catalyst.net.nz> Message-ID: <8B184978-E741-47A5-B29A-F4764D0F7EFA@kohaaloha.com> On 2012-08-24, at 3:25 AM, Chris Nighswonger wrote: > On Thu, Aug 23, 2012 at 11:17 AM, Robin Sheat wrote: > Op 23-08-12 17:14, Chris Nighswonger schreef: > > > > If we can agree to some sort of standardized formatting, I'll write a > > parser to generate the wiki pages from the INSTALL files. > > Wiki formatting would make sense, wouldn't it? > > > I was hoping someone would suggest that... ;-) > > It's reasonably readable too. > > > For the most part > > We could to them in POD and then do something like pod2wiki: http://search.cpan.org/~jmcnamara/Pod-Simple-Wiki-0.14/bin/pod2wiki > > Which would allow such as 'perldoc INSTALL.foo' and such. yep, thats the idea Chris :) there looks to be some good conversion tools between asciidoc, pod, and wiki (and then html, docbook, pdf and latex too) some conversion tools are going to work better that others. and some probably won't work at all i'll attempt to do some 'conversion testing' to see what the best/worst formats are https://github.com/giftnuss/p5-pod-asciidoc http://stackoverflow.com/questions/7612374/how-to-convert-asciidoc-to-perl-pod http://search.cpan.org/~dagolden/Pod-WikiDoc/ https://github.com/agentzh/nginx-devel-utils/blob/master/wiki2pod.pl http://search.cpan.org/~jmcnamara/Pod-Simple-Wiki-0.14/bin/pod2wiki http://code.google.com/p/mastermind-strategy/source/browse/wiki/wiki2pod?spec=svn198&r=198 From robin at catalyst.net.nz Thu Aug 23 21:27:54 2012 From: robin at catalyst.net.nz (Robin Sheat) Date: Thu, 23 Aug 2012 21:27:54 +0200 Subject: [Koha-devel] Lets improve the Koha installation documentation In-Reply-To: <8B184978-E741-47A5-B29A-F4764D0F7EFA@kohaaloha.com> References: <5.2.1.1.2.20120822182137.04758d20@localhost> <06AEAB3D-C3DD-4636-8796-E73E8959CA7A@kohaaloha.com> <7D888F97-6D33-469C-9986-F2C0B653D568@kohaaloha.com> <50364973.2020500@catalyst.net.nz> <8B184978-E741-47A5-B29A-F4764D0F7EFA@kohaaloha.com> Message-ID: <5036843A.4000408@catalyst.net.nz> Op 23-08-12 21:00, Mason James schreef: > there looks to be some good conversion tools between asciidoc, pod, and wiki > (and then html, docbook, pdf and latex too) While you're exploring, I hear good things about markdown as a human-writable but still parseable format, and I'd give good odds there's a markdown to mediawiki converter. -- Robin Sheat Catalyst IT Ltd. ? +64 4 803 2204 GPG: 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D From mtompset at hotmail.com Thu Aug 23 21:28:05 2012 From: mtompset at hotmail.com (Mark Tompsett) Date: Fri, 24 Aug 2012 03:28:05 +0800 Subject: [Koha-devel] Lets improve the Koha installation documentation In-Reply-To: References: <5.2.1.1.2.20120822182137.04758d20@localhost><06AEAB3D-C3DD-4636-8796-E73E8959CA7A@kohaaloha.com><7D888F97-6D33-469C-9986-F2C0B653D568@kohaaloha.com><50364973.2020500@catalyst.net.nz> Message-ID: Greetings, Right now. People are probably doing ?less INSTALL.blah?. Less is standard. We?ve got a perl application being installed, so perldoc isn?t a far fetched expectation. As long as we get a format where people can easily ? ? after a ?sudo apt-get install ?, I don?t care. Particularly if there is a README.1ST file, or just a base INSTALL file, that tells people how to read the INSTALL files. But this begs the question: are we creating a meta-problem? Additionally, the notion of converting the documents to a Wiki page makes me wonder if perhaps we have forgotten to ask the reason for having the install files. Is the INSTALL.blah file supposed to be there as an offline version of the Wiki? Perhaps, it is supposed to complement, but not replace? Right now, the current instructions that Tomas Cohen and I have worked on for Ubuntu do refer back to the Wiki page, because frankly, ?just tell them to do these commands without explaining it? makes the instructions shorter. The Wiki is flushed out and explains parts a little more. I?d really like to flush it out more, but writing and testing good documentation is time consuming and I have other projects to work on. So, I?m not so keen on the convert it back to a wiki page. It also creates the problem of information overload. People skim it, think they have read and understood it, but they really have not. People want to install quickly and without hassle. Reading and following something that is a long step by step guide can be tiring, boring, and prone to error. We already have people making installation mistakes. Documentation is supposed to reduce that. So, shorter install files, and longer wikis make some sense to me. I pondered versioning the instructions for OS releases, but decided against that, since the instructions should overlap significantly between OS releases. I even started a re-attempt of Koha 3.4 on Ubuntu 8.04, but gave up as I would have to CPAN the roughly 18 modules missing. I briefly considered 3.6 and 3.8, but Perl 5.10 and Modern::Perl were a big enough stumbling block for a ?new to linux? person that I figured documenting how to tweak your perl version is beyond the scope of a ?normal? install. Should we split only by OS version? Well, there was a lot in there, so I better summarize/clarify (in no particular order): - Why do we include an installation instructions in the form of INSTALL.{OS} currently? - Is INSTALL.{OS} meant to be a replacement or complement to the Wiki version? - Should INSTALL.{OS} be longer, the same (identical), or shorter than the Wiki version? - Should INSTALL.{OS} be something other than plain text? How will people know how to read it? - Is INSTALL.{OS} sufficient for documentation purposes? Why not INSTALL.tarball, INSTALL.git, INSTALL.packages (which reflect the three types of install)? Why not a mix (e.g. INSTALL.tarball.{OS})? I?m just brainstorming a little. A good program needs good documentation. And I hope to help improve it. GPML, Mark Tompsett -------------- next part -------------- An HTML attachment was scrubbed... URL: From mtj at kohaaloha.com Thu Aug 23 22:40:50 2012 From: mtj at kohaaloha.com (Mason James) Date: Fri, 24 Aug 2012 08:40:50 +1200 Subject: [Koha-devel] Lets improve the Koha installation documentation In-Reply-To: References: <5.2.1.1.2.20120822182137.04758d20@localhost><06AEAB3D-C3DD-4636-8796-E73E8959CA7A@kohaaloha.com><7D888F97-6D33-469C-9986-F2C0B653D568@kohaaloha.com><50364973.2020500@catalyst.net.nz> Message-ID: <8113F9D3-E53A-4EB3-A8A4-05F2878F098B@kohaaloha.com> On 2012-08-24, at 7:28 AM, Mark Tompsett wrote: > Greetings, > > Right now. People are probably doing ?less INSTALL.blah?. Less is standard. We?ve got a perl application being installed, so perldoc isn?t a far fetched expectation. As long as we get a format where people can easily ? ? after a ?sudo apt-get install ?, I don?t care. Particularly if there is a README.1ST file, or just a base INSTALL file, that tells people how to read the INSTALL files. But this begs the question: are we creating a meta-problem? > > Additionally, the notion of converting the documents to a Wiki page makes me wonder if perhaps we have forgotten to ask the reason for having the install files. > Is the INSTALL.blah file supposed to be there as an offline version of the Wiki? other way around, the wiki pages are built from the INSTALL.* files in the git repo > Should we split only by OS version? yes, i think thats enough each INSTALL.* file contains the 2 [or 3] install methods (tarball, git, [packages]) INSTALL (a tiny file saying "please read the INSTALL file for your OS") INSTALL.Debian INSTALL.Ubuntu INSTALL.Fedora INSTALL.Centos INSTALL.Netbsd INSTALL.Openbsd INSTALL.WEB (for the web install, for all OS) From paul.a at aandc.org Fri Aug 24 19:37:41 2012 From: paul.a at aandc.org (Paul) Date: Fri, 24 Aug 2012 13:37:41 -0400 Subject: [Koha-devel] 3.8.4 interim [was: koha-zebra-daemon not starting] In-Reply-To: <15A82E0B-374D-49F3-B9AA-60246861DF10@kohaaloha.com> References: <5D60C882-A67B-48D6-B518-7B7AE354B30F@kohaaloha.com> <5.2.1.1.2.20120822182137.04758d20@localhost> <5.2.1.1.2.20120822182137.04758d20@localhost> <5.2.1.1.2.20120822194128.01e26d88@localhost> <5D60C882-A67B-48D6-B518-7B7AE354B30F@kohaaloha.com> Message-ID: <5.2.1.1.2.20120824124338.01bdd320@localhost> At 01:50 PM 8/23/2012 +1200, Mason James wrote: > >> paul at server:~$ sudo /etc/init.d/koha-zebra-daemon start > >> Starting Zebra Server > >> /etc/init.d/koha-zebra-daemon: line 73: daemon: command not found > > $ sudo apt-get install daemon ? Thanks - that was the problem, and I have no idea why it "went AWOL." >my other hunch is that you have bunch of __FOO__ stuff in your >/etc/init.d/koha-zebra-daemon file That had installed perfectly, but thanks, it pushed me into doing a lot more digging around. Anyway, as of this morning, Koha 3.8.4 is running on AMD64 Ubuntu 12.04 LTS. However, I have (after asking our staff to try it out), got a very weird dilemma: from the new test machine, all NEW records (biblios and items, both Z39.50 imports and manual entries) are saving to our *PRODUCTION* server (3.6.1) -- all EDITS of existing biblios/items are saving correctly to the *TEST* server (3.8.4). Both servers are on the same LAN, but under different computer names 'server' and 'nelson', different IPs 192.168.0.91 and .95, different db names 'koha' and 'koha384', different URLs 'http://koha' and 'http://koha-admin' compared to 'http://koha3' and 'http://koha-admin3', hosts files all updated, router updated (static, no DHCP). Similarities are that I restored a mysql dump from production to test and therefore users/staff logins/passwords are the same. The test machine is saving something: we experimented with entering a new book by an existing author; on the "1 tab" when cataloging and checking the "authority" (little red box at the end of the 100$a line) it correctly incremented the number of times "Used" from 4 to 5 - 6 - 7 each time we saved that book - but a subsequent "authority" search only found the 4 again. However, now (accidentally) checking the production machine, an "authority" search finds all 7 !!! with the associated biblios and items. Anyone got any thoughts? Is there something is the mysql "restore" that points to the wrong db? [I used 'mysql --user= --password=my_pw koha384 < /usr/share/koha/koha361dump_1jan12.sql] I have fairly detailed installation notes if anyone would like them... but as I'll probably do another complete reinstall (before upgrading the production machine mid-September), I will verify and refine them -- then try and assist with the "documentation project." Thanks - Paul From melia at bywatersolutions.com Fri Aug 24 20:47:13 2012 From: melia at bywatersolutions.com (Melia Meggs) Date: Fri, 24 Aug 2012 11:47:13 -0700 Subject: [Koha-devel] holds rewrite testing Message-ID: Hi, There are two major Holds Rewrite patches that were signed off in July. Because these patches are far-reaching and have the potential to impact a lot of other things in Koha, we really need some help with thorough testing. One of these patches has now passed QA, but I think they could both use some additional sign-offs. Please test! http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5911 http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5786 Thanks, Melia -- Melia Meggs Chief Operations Officer ByWater Solutions bywatersolutions.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From williams at amigos.org Fri Aug 24 22:31:22 2012 From: williams at amigos.org (Robert Williams) Date: Fri, 24 Aug 2012 20:31:22 +0000 Subject: [Koha-devel] 3.8.4 interim [was: koha-zebra-daemon not starting] In-Reply-To: <5.2.1.1.2.20120824124338.01bdd320@localhost> References: <5D60C882-A67B-48D6-B518-7B7AE354B30F@kohaaloha.com> <5.2.1.1.2.20120822182137.04758d20@localhost> <5.2.1.1.2.20120822182137.04758d20@localhost> <5.2.1.1.2.20120822194128.01e26d88@localhost> <5D60C882-A67B-48D6-B518-7B7AE354B30F@kohaaloha.com> <5.2.1.1.2.20120824124338.01bdd320@localhost> Message-ID: <502E8CA9F1E0AE47BF682CCEDDAACDC803D69CDB@exchange.amigos.org> Paul: I'm wondering if you could have the staffClientBaseURL system preference set (not changed after loading the database from the production server)? If so, logging in to the staff interface on the test server may be "sending" you to the production server? --Robert ********************************************* Robert L. Williams Manager, Open Source ILS Services Amigos Library Services, Inc. 14400 Midway Road Dallas, TX 75244-3509 800-843-8482, x2870 972-340-2870 (direct) 972-991-6061 (fax) -----Original Message----- From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Paul Sent: Friday, August 24, 2012 12:38 PM To: Koha Devel Cc: Koha Devel Subject: Re: [Koha-devel] 3.8.4 interim [was: koha-zebra-daemon not starting] At 01:50 PM 8/23/2012 +1200, Mason James wrote: > >> paul at server:~$ sudo /etc/init.d/koha-zebra-daemon start > >> Starting Zebra Server > >> /etc/init.d/koha-zebra-daemon: line 73: daemon: command not found > > $ sudo apt-get install daemon ? Thanks - that was the problem, and I have no idea why it "went AWOL." >my other hunch is that you have bunch of __FOO__ stuff in your >/etc/init.d/koha-zebra-daemon file That had installed perfectly, but thanks, it pushed me into doing a lot more digging around. Anyway, as of this morning, Koha 3.8.4 is running on AMD64 Ubuntu 12.04 LTS. However, I have (after asking our staff to try it out), got a very weird dilemma: from the new test machine, all NEW records (biblios and items, both Z39.50 imports and manual entries) are saving to our *PRODUCTION* server (3.6.1) -- all EDITS of existing biblios/items are saving correctly to the *TEST* server (3.8.4). Both servers are on the same LAN, but under different computer names 'server' and 'nelson', different IPs 192.168.0.91 and .95, different db names 'koha' and 'koha384', different URLs 'http://koha' and 'http://koha-admin' compared to 'http://koha3' and 'http://koha-admin3', hosts files all updated, router updated (static, no DHCP). Similarities are that I restored a mysql dump from production to test and therefore users/staff logins/passwords are the same. The test machine is saving something: we experimented with entering a new book by an existing author; on the "1 tab" when cataloging and checking the "authority" (little red box at the end of the 100$a line) it correctly incremented the number of times "Used" from 4 to 5 - 6 - 7 each time we saved that book - but a subsequent "authority" search only found the 4 again. However, now (accidentally) checking the production machine, an "authority" search finds all 7 !!! with the associated biblios and items. Anyone got any thoughts? Is there something is the mysql "restore" that points to the wrong db? [I used 'mysql --user= --password=my_pw koha384 < /usr/share/koha/koha361dump_1jan12.sql] I have fairly detailed installation notes if anyone would like them... but as I'll probably do another complete reinstall (before upgrading the production machine mid-September), I will verify and refine them -- then try and assist with the "documentation project." Thanks - Paul _______________________________________________ Koha-devel mailing list Koha-devel at lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ From mtj at kohaaloha.com Fri Aug 24 23:16:20 2012 From: mtj at kohaaloha.com (Mason James) Date: Sat, 25 Aug 2012 09:16:20 +1200 Subject: [Koha-devel] 3.8.4 interim [was: koha-zebra-daemon not starting] In-Reply-To: <5.2.1.1.2.20120824124338.01bdd320@localhost> References: <5D60C882-A67B-48D6-B518-7B7AE354B30F@kohaaloha.com> <5.2.1.1.2.20120822182137.04758d20@localhost> <5.2.1.1.2.20120822182137.04758d20@localhost> <5.2.1.1.2.20120822194128.01e26d88@localhost> <5D60C882-A67B-48D6-B518-7B7AE354B30F@kohaaloha.com> <5.2.1.1.2.20120824124338.01bdd320@localhost> Message-ID: <22663D99-ED2F-4C34-B245-06C21D5E6BB6@kohaaloha.com> On 2012-08-25, at 5:37 AM, Paul wrote: > At 01:50 PM 8/23/2012 +1200, Mason James wrote: >> >> paul at server:~$ sudo /etc/init.d/koha-zebra-daemon start >> >> Starting Zebra Server >> >> /etc/init.d/koha-zebra-daemon: line 73: daemon: command not found >> > $ sudo apt-get install daemon ? > > Thanks - that was the problem, and I have no idea why it "went AWOL." my guess is that you cocked-up step 1.5 of the Koha ubuntu install guide? $ sudo dpkg --set-selections < install_misc/ubuntu.packages http://git.koha-community.org/cgi-bin/gitweb.cgi?p=koha.git;a=blob;f=INSTALL.ubuntu#l76 cheers... From paul.a at aandc.org Sat Aug 25 00:29:21 2012 From: paul.a at aandc.org (Paul) Date: Fri, 24 Aug 2012 18:29:21 -0400 Subject: [Koha-devel] 3.8.4 interim [was: koha-zebra-daemon not starting] In-Reply-To: <22663D99-ED2F-4C34-B245-06C21D5E6BB6@kohaaloha.com> References: <5.2.1.1.2.20120824124338.01bdd320@localhost> <5D60C882-A67B-48D6-B518-7B7AE354B30F@kohaaloha.com> <5.2.1.1.2.20120822182137.04758d20@localhost> <5.2.1.1.2.20120822182137.04758d20@localhost> <5.2.1.1.2.20120822194128.01e26d88@localhost> <5D60C882-A67B-48D6-B518-7B7AE354B30F@kohaaloha.com> <5.2.1.1.2.20120824124338.01bdd320@localhost> Message-ID: <5.2.1.1.2.20120824182106.0354caf8@localhost> At 09:16 AM 8/25/2012 +1200, Mason James wrote: >my guess is that you cocked-up step 1.5 of the Koha ubuntu install guide? > $ sudo dpkg --set-selections < install_misc/ubuntu.packages > >http://git.koha-community.org/cgi-bin/gitweb.cgi?p=koha.git;a=blob;f=INSTALL.ubuntu#l76 >cheers... my guess is $ sudo dpkg --set-selections < install_misc/ubuntu.packages has some errors. I've offered to supply the documentation, others on this dev list have confirmed that it's not exactly up-to-date, so on and so forth... Please don't accuse me of "cocking up" From mtj at kohaaloha.com Sat Aug 25 01:47:10 2012 From: mtj at kohaaloha.com (Mason James) Date: Sat, 25 Aug 2012 11:47:10 +1200 Subject: [Koha-devel] 3.8.4 interim [was: koha-zebra-daemon not starting] In-Reply-To: <5.2.1.1.2.20120824182106.0354caf8@localhost> References: <5.2.1.1.2.20120824124338.01bdd320@localhost> <5D60C882-A67B-48D6-B518-7B7AE354B30F@kohaaloha.com> <5.2.1.1.2.20120822182137.04758d20@localhost> <5.2.1.1.2.20120822182137.04758d20@localhost> <5.2.1.1.2.20120822194128.01e26d88@localhost> <5D60C882-A67B-48D6-B518-7B7AE354B30F@kohaaloha.com> <5.2.1.1.2.20120824124338.01bdd320@localhost> <5.2.1.1.2.20120824182106.0354caf8@localhost> Message-ID: <85047153-B458-4DDB-A57A-A368B4BE505B@kohaaloha.com> On 2012-08-25, at 10:29 AM, Paul wrote: > At 09:16 AM 8/25/2012 +1200, Mason James wrote: >> my guess is that you cocked-up step 1.5 of the Koha ubuntu install guide? >> $ sudo dpkg --set-selections < install_misc/ubuntu.packages >> http://git.koha-community.org/cgi-bin/gitweb.cgi?p=koha.git;a=blob;f=INSTALL.ubuntu#l76 >> cheers... > > my guess is > > $ sudo dpkg --set-selections < install_misc/ubuntu.packages > > has some errors. nope, looks fine to me... $ grep -n daemon ./install_misc/ubuntu.packages 3:daemon install From paul.a at aandc.org Sat Aug 25 02:22:24 2012 From: paul.a at aandc.org (Paul) Date: Fri, 24 Aug 2012 20:22:24 -0400 Subject: [Koha-devel] 3.8.4 interim [was: koha-zebra-daemon not starting] In-Reply-To: <85047153-B458-4DDB-A57A-A368B4BE505B@kohaaloha.com> References: <5.2.1.1.2.20120824182106.0354caf8@localhost> <5.2.1.1.2.20120824124338.01bdd320@localhost> <5D60C882-A67B-48D6-B518-7B7AE354B30F@kohaaloha.com> <5.2.1.1.2.20120822182137.04758d20@localhost> <5.2.1.1.2.20120822182137.04758d20@localhost> <5.2.1.1.2.20120822194128.01e26d88@localhost> <5D60C882-A67B-48D6-B518-7B7AE354B30F@kohaaloha.com> <5.2.1.1.2.20120824124338.01bdd320@localhost> <5.2.1.1.2.20120824182106.0354caf8@localhost> Message-ID: <5.2.1.1.2.20120824200649.02ab7008@localhost> At 11:47 AM 8/25/2012 +1200, Mason James wrote: >On 2012-08-25, at 10:29 AM, Paul wrote: > > > At 09:16 AM 8/25/2012 +1200, Mason James wrote: > >> my guess is that you cocked-up step 1.5 of the Koha ubuntu install guide? > >> $ sudo dpkg --set-selections < install_misc/ubuntu.packages > >> > http://git.koha-community.org/cgi-bin/gitweb.cgi?p=koha.git;a=blob;f=INSTALL.ubuntu#l76 > >> cheers... > > > > my guess is > > > > $ sudo dpkg --set-selections < install_misc/ubuntu.packages > > > > has some errors. > >nope, looks fine to me... > >$ grep -n daemon ./install_misc/ubuntu.packages >3:daemon install Agree - line 3 says that, but I'm still wondering why I've been there (four times at least), done it (four times), not succeeded (four times). It has something to do with amd64 vice i386 12.04 LTS. What I will do is try a more recent .ISO -- maybe ubuntu-12.04-server-amd64.iso, build 20120424.1 is not the latest, or best, or most bullet-proof. And in any|all case, it does NOT solve my problem of why the test machine is saving to a totally separate db on the production server. From paul.a at aandc.org Sat Aug 25 03:22:29 2012 From: paul.a at aandc.org (Paul) Date: Fri, 24 Aug 2012 21:22:29 -0400 Subject: [Koha-devel] 3.8.4 interim [was: koha-zebra-daemon not starting] Message-ID: <5.2.1.1.2.20120824212221.01cf0128@aandc.org> A tad of clarification. I had written: >However, I have (after asking our staff to try it out), got a very weird >dilemma: from the new test machine, all NEW records (biblios and items, >both Z39.50 imports and manual entries) are saving to our *PRODUCTION* >server (3.6.1) -- all EDITS of existing biblios/items are saving correctly >to the *TEST* server (3.8.4). > >Both servers are on the same LAN, but under different computer names >'server' and 'nelson', different IPs 192.168.0.91 and .95, different db >names 'koha' and 'koha384', different URLs 'http://koha' and >'http://koha-admin' compared to 'http://koha3' and 'http://koha-admin3', >hosts files all updated, router updated (static, no DHCP). From the install log of the production machine (passwords snipped): # This file contains settings used # during the installation of Koha. # It is meant for use during future # upgrades of Koha, and should not # be edited. KOHA_INSTALLED_VERSION=3.06.01.000 LOG_DIR=/var/log/koha DB_TYPE=mysql DB_NAME=koha306 DB_HOST=localhost DB_USER=koha WEBMASTER_EMAIL=webmaster at nelson WEBSERVER_DOMAIN=nelson WEBSERVER_HOST=nelson The same from the test machine: # This file contains settings used # during the installation of Koha. # It is meant for use during future # upgrades of Koha, and should not # be edited. KOHA_INSTALLED_VERSION=3.08.04.000 LOG_DIR=/var/log/koha DB_TYPE=mysql DB_NAME=koha384 DB_HOST=localhost DB_USER=koha WEBMASTER_EMAIL=webmaster at server WEBSERVER_DOMAIN=server WEBSERVER_HOST=server Similarities are that I restored a mysql dump from production to test and therefore users/staff logins/passwords are the same. The test machine is saving something: we experimented with entering a new book by an existing author; on the "1 tab" when cataloging and checking the "authority" (little red box at the end of the 100$a line) it correctly incremented the number of times "Used" from 4 to 5 - 6 - 7 each time we saved that book - but a subsequent "authority" search only found the 4 again. However, now (accidentally) checking the production machine, an "authority" search finds all 7 !!! with the associated biblios and items. Anyone got any thoughts? Is there something is the mysql "restore" that points to the wrong db? [I used 'mysql --user= --password=my_pw koha384 < /usr/share/koha/koha361dump_1jan12.sql] I have fairly detailed installation notes if anyone would like them... but as I'll probably do another complete reinstall (before upgrading the production machine mid-September), I will verify and refine them -- then try and assist with the "documentation project." Thanks - Paul From chris at bigballofwax.co.nz Sat Aug 25 03:29:39 2012 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Sat, 25 Aug 2012 13:29:39 +1200 Subject: [Koha-devel] 3.8.4 interim [was: koha-zebra-daemon not starting] In-Reply-To: <5.2.1.1.2.20120824212221.01cf0128@aandc.org> References: <5.2.1.1.2.20120824212221.01cf0128@aandc.org> Message-ID: Did you miss Robert's reply? Chris On Aug 25, 2012 1:22 PM, "Paul" wrote: > A tad of clarification. I had written: > > However, I have (after asking our staff to try it out), got a very weird >> dilemma: from the new test machine, all NEW records (biblios and items, >> both Z39.50 imports and manual entries) are saving to our *PRODUCTION* >> server (3.6.1) -- all EDITS of existing biblios/items are saving correctly >> to the *TEST* server (3.8.4). >> >> Both servers are on the same LAN, but under different computer names >> 'server' and 'nelson', different IPs 192.168.0.91 and .95, different db >> names 'koha' and 'koha384', different URLs 'http://koha' and ' >> http://koha-admin' compared to 'http://koha3' and 'http://koha-admin3', >> hosts files all updated, router updated (static, no DHCP). >> > > From the install log of the production machine (passwords snipped): > > # This file contains settings used > # during the installation of Koha. > # It is meant for use during future > # upgrades of Koha, and should not > # be edited. > KOHA_INSTALLED_VERSION=3.06.**01.000 > LOG_DIR=/var/log/koha > DB_TYPE=mysql > DB_NAME=koha306 > DB_HOST=localhost > DB_USER=koha > WEBMASTER_EMAIL=webmaster@**nelson > WEBSERVER_DOMAIN=nelson > WEBSERVER_HOST=nelson > > The same from the test machine: > > # This file contains settings used > # during the installation of Koha. > # It is meant for use during future > # upgrades of Koha, and should not > # be edited. > KOHA_INSTALLED_VERSION=3.08.**04.000 > LOG_DIR=/var/log/koha > DB_TYPE=mysql > DB_NAME=koha384 > DB_HOST=localhost > DB_USER=koha > WEBMASTER_EMAIL=webmaster@**server > WEBSERVER_DOMAIN=server > WEBSERVER_HOST=server > > > > Similarities are that I restored a mysql dump from production to test and > therefore users/staff logins/passwords are the same. The test machine is > saving something: we experimented with entering a new book by an existing > author; on the "1 tab" when cataloging and checking the "authority" (little > red box at the end of the 100$a line) it correctly incremented the number > of times "Used" from 4 to 5 - 6 - 7 each time we saved that book - but a > subsequent "authority" search only found the 4 again. However, now > (accidentally) checking the production machine, an "authority" search finds > all 7 !!! with the associated biblios and items. > > Anyone got any thoughts? Is there something is the mysql "restore" that > points to the wrong db? [I used 'mysql --user= --password=my_pw koha384 > < /usr/share/koha/koha361dump_**1jan12.sql] > > I have fairly detailed installation notes if anyone would like them... but > as I'll probably do another complete reinstall (before upgrading the > production machine mid-September), I will verify and refine them -- then > try and assist with the "documentation project." > > Thanks - Paul > ______________________________**_________________ > Koha-devel mailing list > Koha-devel at lists.koha-**community.org > http://lists.koha-community.**org/cgi-bin/mailman/listinfo/**koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.**org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mtj at kohaaloha.com Sat Aug 25 04:13:56 2012 From: mtj at kohaaloha.com (Mason James) Date: Sat, 25 Aug 2012 14:13:56 +1200 Subject: [Koha-devel] 3.8.4 interim [was: koha-zebra-daemon not starting] In-Reply-To: <5.2.1.1.2.20120824200649.02ab7008@localhost> References: <5.2.1.1.2.20120824182106.0354caf8@localhost> <5.2.1.1.2.20120824124338.01bdd320@localhost> <5D60C882-A67B-48D6-B518-7B7AE354B30F@kohaaloha.com> <5.2.1.1.2.20120822182137.04758d20@localhost> <5.2.1.1.2.20120822182137.04758d20@localhost> <5.2.1.1.2.20120822194128.01e26d88@localhost> <5D60C882-A67B-48D6-B518-7B7AE354B30F@kohaaloha.com> <5.2.1.1.2.20120824124338.01bdd320@localhost> <5.2.1.1.2.20120824182106.0354caf8@localhost> <5.2.1.1.2.20120824200649.02ab7008@localhost> Message-ID: >> >> nope, looks fine to me... >> >> $ grep -n daemon ./install_misc/ubuntu.packages >> 3:daemon install > > Agree - line 3 says that, but I'm still wondering why I've been there (four times at least), done it (four times), not succeeded (four times). It has something to do with amd64 vice i386 12.04 LTS. What I will do is try a more recent .ISO -- maybe ubuntu-12.04-server-amd64.iso, build 20120424.1 is not the latest, or best, or most bullet-proof. > > And in any|all case, it does NOT solve my problem of why the test machine is saving to a totally separate db on the production server. > thats a completely separate problem, for a completely new topic thread From paul.a at aandc.org Sat Aug 25 14:30:11 2012 From: paul.a at aandc.org (Paul) Date: Sat, 25 Aug 2012 08:30:11 -0400 Subject: [Koha-devel] 3.8.4 interim [was: koha-zebra-daemon not starting] Message-ID: <5.2.1.1.2.20120825082842.02a60278@aandc.org> [sending again to the LIST - apologies, only went to Robert yesterday] At 08:31 PM 8/24/2012 +0000, Robert Williams wrote: >Paul: > >I'm wondering if you could have the staffClientBaseURL system preference >set (not changed after loading the database from the production server)? >If so, logging in to the staff interface on the test server may be >"sending" you to the production server? Robert, Many thanks for the suggestion. The 'staffClientBaseURL' was indeed blank ... I filled it in with the test server url, and it's still saving to the production machine (different url, different db name, ...) Best - Paul >--Robert > >********************************************* >Robert L. Williams >Manager, Open Source ILS Services >Amigos Library Services, Inc. >14400 Midway Road >Dallas, TX 75244-3509 >800-843-8482, x2870 >972-340-2870 (direct) >972-991-6061 (fax) > > >-----Original Message----- >From: koha-devel-bounces at lists.koha-community.org >[mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Paul >Sent: Friday, August 24, 2012 12:38 PM >To: Koha Devel >Cc: Koha Devel >Subject: Re: [Koha-devel] 3.8.4 interim [was: koha-zebra-daemon not starting] > >At 01:50 PM 8/23/2012 +1200, Mason James wrote: > > >> paul at server:~$ sudo /etc/init.d/koha-zebra-daemon start > > >> Starting Zebra Server > > >> /etc/init.d/koha-zebra-daemon: line 73: daemon: command not found > > > $ sudo apt-get install daemon ? > >Thanks - that was the problem, and I have no idea why it "went AWOL." > > >my other hunch is that you have bunch of __FOO__ stuff in your > >/etc/init.d/koha-zebra-daemon file > >That had installed perfectly, but thanks, it pushed me into doing a lot >more digging around. Anyway, as of this morning, Koha 3.8.4 is running on >AMD64 Ubuntu 12.04 LTS. > >However, I have (after asking our staff to try it out), got a very weird >dilemma: from the new test machine, all NEW records (biblios and items, >both Z39.50 imports and manual entries) are saving to our *PRODUCTION* >server (3.6.1) -- all EDITS of existing biblios/items are saving correctly >to the *TEST* server (3.8.4). > >Both servers are on the same LAN, but under different computer names >'server' and 'nelson', different IPs 192.168.0.91 and .95, different db >names 'koha' and 'koha384', different URLs 'http://koha' and >'http://koha-admin' compared to 'http://koha3' and 'http://koha-admin3', >hosts files all updated, router updated (static, no DHCP). > >Similarities are that I restored a mysql dump from production to test and >therefore users/staff logins/passwords are the same. The test machine is >saving something: we experimented with entering a new book by an existing >author; on the "1 tab" when cataloging and checking the "authority" (little >red box at the end of the 100$a line) it correctly incremented the number >of times "Used" from 4 to 5 - 6 - 7 each time we saved that book - but a >subsequent "authority" search only found the 4 again. However, now >(accidentally) checking the production machine, an "authority" search finds >all 7 !!! with the associated biblios and items. > >Anyone got any thoughts? Is there something is the mysql "restore" that >points to the wrong db? [I used 'mysql --user= --password=my_pw koha384 >< /usr/share/koha/koha361dump_1jan12.sql] > >I have fairly detailed installation notes if anyone would like them... but >as I'll probably do another complete reinstall (before upgrading the >production machine mid-September), I will verify and refine them -- then >try and assist with the "documentation project." > >Thanks - Paul > >_______________________________________________ >Koha-devel mailing list >Koha-devel at lists.koha-community.org >http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >website : http://www.koha-community.org/ >git : http://git.koha-community.org/ >bugs : http://bugs.koha-community.org/ >_______________________________________________ >Koha-devel mailing list >Koha-devel at lists.koha-community.org >http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >website : http://www.koha-community.org/ >git : http://git.koha-community.org/ >bugs : http://bugs.koha-community.org/ --- Maritime heritage and history, preservation and conservation, research and education through the written word and the arts. and From williams at amigos.org Sat Aug 25 20:09:46 2012 From: williams at amigos.org (Robert Williams) Date: Sat, 25 Aug 2012 18:09:46 +0000 Subject: [Koha-devel] 3.8.4 interim [was: koha-zebra-daemon not starting] In-Reply-To: <5.2.1.1.2.20120825082842.02a60278@aandc.org> References: <5.2.1.1.2.20120825082842.02a60278@aandc.org> Message-ID: <502E8CA9F1E0AE47BF682CCEDDAACDC803D6A4CA@exchange.amigos.org> Paul: You wrote: >Both servers are on the same LAN, but under different computer names >'server' and 'nelson', different IPs 192.168.0.91 and .95, different db >names 'koha' and 'koha384', different URLs 'http://koha' and >'http://koha-admin' compared to 'http://koha3' and 'http://koha-admin3', >hosts files all updated, router updated (static, no DHCP). I've thought of and rejected several ideas. I'm thinking that, outside of the "BaseURL" sys pref settings, if it was an entry in the MySQL db or in a problem with the underlying Koha code, the dump/transfer/reload cycle would commonly end in problems for everyone. So I'm thinking it's likely a system setup thing. It seems to me most likely to be related to a domain name lookup problem (DNS issue/hosts issue?). But it possibly could be on the client side rather than the server side. Since your URLs do not correspond to your machine (host) names, the client's DNS lookup could be involved. You might try flushing the Firefox cache, flushing the local OS's DNS cache (ipconfig /flushdns on Windows clients, run with admin privileges), and then pinging the koha-admin, koha-admin3 names from the client command line and see what you get. Or alternatively, just check the local hosts file on the client, or the DNS server for your local network if implemented, and make sure there are not errors. If you change the Apache configuration to use the IP addresses and port numbers (and access the sites by the direct IP address temporarily), you can determine if it's actually a DNS issue or not. Don't know that this will be helpful, but it sounds from your message like something different than what you've already tried. Here's hoping it helps. --Robert ________________________________________ From: koha-devel-bounces at lists.koha-community.org [koha-devel-bounces at lists.koha-community.org] on behalf of Paul [paul.a at aandc.org] Sent: Saturday, August 25, 2012 7:30 AM To: koha-devel at lists.koha-community.org Subject: Re: [Koha-devel] 3.8.4 interim [was: koha-zebra-daemon not starting] [sending again to the LIST - apologies, only went to Robert yesterday] At 08:31 PM 8/24/2012 +0000, Robert Williams wrote: >Paul: > >I'm wondering if you could have the staffClientBaseURL system preference >set (not changed after loading the database from the production server)? >If so, logging in to the staff interface on the test server may be >"sending" you to the production server? Robert, Many thanks for the suggestion. The 'staffClientBaseURL' was indeed blank ... I filled it in with the test server url, and it's still saving to the production machine (different url, different db name, ...) Best - Paul >--Robert > >********************************************* >Robert L. Williams >Manager, Open Source ILS Services >Amigos Library Services, Inc. >14400 Midway Road >Dallas, TX 75244-3509 >800-843-8482, x2870 >972-340-2870 (direct) >972-991-6061 (fax) > > >-----Original Message----- >From: koha-devel-bounces at lists.koha-community.org >[mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Paul >Sent: Friday, August 24, 2012 12:38 PM >To: Koha Devel >Cc: Koha Devel >Subject: Re: [Koha-devel] 3.8.4 interim [was: koha-zebra-daemon not starting] > >At 01:50 PM 8/23/2012 +1200, Mason James wrote: > > >> paul at server:~$ sudo /etc/init.d/koha-zebra-daemon start > > >> Starting Zebra Server > > >> /etc/init.d/koha-zebra-daemon: line 73: daemon: command not found > > > $ sudo apt-get install daemon ? > >Thanks - that was the problem, and I have no idea why it "went AWOL." > > >my other hunch is that you have bunch of __FOO__ stuff in your > >/etc/init.d/koha-zebra-daemon file > >That had installed perfectly, but thanks, it pushed me into doing a lot >more digging around. Anyway, as of this morning, Koha 3.8.4 is running on >AMD64 Ubuntu 12.04 LTS. > >However, I have (after asking our staff to try it out), got a very weird >dilemma: from the new test machine, all NEW records (biblios and items, >both Z39.50 imports and manual entries) are saving to our *PRODUCTION* >server (3.6.1) -- all EDITS of existing biblios/items are saving correctly >to the *TEST* server (3.8.4). > >Both servers are on the same LAN, but under different computer names >'server' and 'nelson', different IPs 192.168.0.91 and .95, different db >names 'koha' and 'koha384', different URLs 'http://koha' and >'http://koha-admin' compared to 'http://koha3' and 'http://koha-admin3', >hosts files all updated, router updated (static, no DHCP). > >Similarities are that I restored a mysql dump from production to test and >therefore users/staff logins/passwords are the same. The test machine is >saving something: we experimented with entering a new book by an existing >author; on the "1 tab" when cataloging and checking the "authority" (little >red box at the end of the 100$a line) it correctly incremented the number >of times "Used" from 4 to 5 - 6 - 7 each time we saved that book - but a >subsequent "authority" search only found the 4 again. However, now >(accidentally) checking the production machine, an "authority" search finds >all 7 !!! with the associated biblios and items. > >Anyone got any thoughts? Is there something is the mysql "restore" that >points to the wrong db? [I used 'mysql --user= --password=my_pw koha384 >< /usr/share/koha/koha361dump_1jan12.sql] > >I have fairly detailed installation notes if anyone would like them... but >as I'll probably do another complete reinstall (before upgrading the >production machine mid-September), I will verify and refine them -- then >try and assist with the "documentation project." > >Thanks - Paul > >_______________________________________________ >Koha-devel mailing list >Koha-devel at lists.koha-community.org >http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >website : http://www.koha-community.org/ >git : http://git.koha-community.org/ >bugs : http://bugs.koha-community.org/ >_______________________________________________ >Koha-devel mailing list >Koha-devel at lists.koha-community.org >http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >website : http://www.koha-community.org/ >git : http://git.koha-community.org/ >bugs : http://bugs.koha-community.org/ --- Maritime heritage and history, preservation and conservation, research and education through the written word and the arts. and _______________________________________________ Koha-devel mailing list Koha-devel at lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ From williams at amigos.org Sat Aug 25 20:28:54 2012 From: williams at amigos.org (Robert Williams) Date: Sat, 25 Aug 2012 18:28:54 +0000 Subject: [Koha-devel] 3.8.4 interim [was: koha-zebra-daemon not starting] In-Reply-To: <502E8CA9F1E0AE47BF682CCEDDAACDC803D6A4CA@exchange.amigos.org> References: <5.2.1.1.2.20120825082842.02a60278@aandc.org>, <502E8CA9F1E0AE47BF682CCEDDAACDC803D6A4CA@exchange.amigos.org> Message-ID: <502E8CA9F1E0AE47BF682CCEDDAACDC803D6A5DA@exchange.amigos.org> Paul: Sorry, upon further reflection after sending another response, I think I've debunked my DNS thoughts (my brain's too dead to be thinking :-) ). They might play a part, but they don't seem to address the fact that one form submission succeeds in reaching the correct server/database. It'll be interesting to hear what actually resolves the problem! Sorry for the noise. --Robert ________________________________________ From: koha-devel-bounces at lists.koha-community.org [koha-devel-bounces at lists.koha-community.org] on behalf of Robert Williams [williams at amigos.org] Sent: Saturday, August 25, 2012 1:09 PM To: koha-devel at lists.koha-community.org Subject: Re: [Koha-devel] 3.8.4 interim [was: koha-zebra-daemon not starting] Paul: You wrote: >Both servers are on the same LAN, but under different computer names >'server' and 'nelson', different IPs 192.168.0.91 and .95, different db >names 'koha' and 'koha384', different URLs 'http://koha' and >'http://koha-admin' compared to 'http://koha3' and 'http://koha-admin3', >hosts files all updated, router updated (static, no DHCP). I've thought of and rejected several ideas. I'm thinking that, outside of the "BaseURL" sys pref settings, if it was an entry in the MySQL db or in a problem with the underlying Koha code, the dump/transfer/reload cycle would commonly end in problems for everyone. So I'm thinking it's likely a system setup thing. It seems to me most likely to be related to a domain name lookup problem (DNS issue/hosts issue?). But it possibly could be on the client side rather than the server side. Since your URLs do not correspond to your machine (host) names, the client's DNS lookup could be involved. You might try flushing the Firefox cache, flushing the local OS's DNS cache (ipconfig /flushdns on Windows clients, run with admin privileges), and then pinging the koha-admin, koha-admin3 names from the client command line and see what you get. Or alternatively, just check the local hosts file on the client, or the DNS server for your local network if implemented, and make sure there are not errors. If you change the Apache configuration to use the IP addresses and port numbers (and access the sites by the direct IP address temporarily), you can determine if it's actually a DNS issue or not. Don't know that this will be helpful, but it sounds from your message like something different than what you've already tried. Here's hoping it helps. --Robert ________________________________________ From: koha-devel-bounces at lists.koha-community.org [koha-devel-bounces at lists.koha-community.org] on behalf of Paul [paul.a at aandc.org] Sent: Saturday, August 25, 2012 7:30 AM To: koha-devel at lists.koha-community.org Subject: Re: [Koha-devel] 3.8.4 interim [was: koha-zebra-daemon not starting] [sending again to the LIST - apologies, only went to Robert yesterday] At 08:31 PM 8/24/2012 +0000, Robert Williams wrote: >Paul: > >I'm wondering if you could have the staffClientBaseURL system preference >set (not changed after loading the database from the production server)? >If so, logging in to the staff interface on the test server may be >"sending" you to the production server? Robert, Many thanks for the suggestion. The 'staffClientBaseURL' was indeed blank ... I filled it in with the test server url, and it's still saving to the production machine (different url, different db name, ...) Best - Paul >--Robert > >********************************************* >Robert L. Williams >Manager, Open Source ILS Services >Amigos Library Services, Inc. >14400 Midway Road >Dallas, TX 75244-3509 >800-843-8482, x2870 >972-340-2870 (direct) >972-991-6061 (fax) > > >-----Original Message----- >From: koha-devel-bounces at lists.koha-community.org >[mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Paul >Sent: Friday, August 24, 2012 12:38 PM >To: Koha Devel >Cc: Koha Devel >Subject: Re: [Koha-devel] 3.8.4 interim [was: koha-zebra-daemon not starting] > >At 01:50 PM 8/23/2012 +1200, Mason James wrote: > > >> paul at server:~$ sudo /etc/init.d/koha-zebra-daemon start > > >> Starting Zebra Server > > >> /etc/init.d/koha-zebra-daemon: line 73: daemon: command not found > > > $ sudo apt-get install daemon ? > >Thanks - that was the problem, and I have no idea why it "went AWOL." > > >my other hunch is that you have bunch of __FOO__ stuff in your > >/etc/init.d/koha-zebra-daemon file > >That had installed perfectly, but thanks, it pushed me into doing a lot >more digging around. Anyway, as of this morning, Koha 3.8.4 is running on >AMD64 Ubuntu 12.04 LTS. > >However, I have (after asking our staff to try it out), got a very weird >dilemma: from the new test machine, all NEW records (biblios and items, >both Z39.50 imports and manual entries) are saving to our *PRODUCTION* >server (3.6.1) -- all EDITS of existing biblios/items are saving correctly >to the *TEST* server (3.8.4). > >Both servers are on the same LAN, but under different computer names >'server' and 'nelson', different IPs 192.168.0.91 and .95, different db >names 'koha' and 'koha384', different URLs 'http://koha' and >'http://koha-admin' compared to 'http://koha3' and 'http://koha-admin3', >hosts files all updated, router updated (static, no DHCP). > >Similarities are that I restored a mysql dump from production to test and >therefore users/staff logins/passwords are the same. The test machine is >saving something: we experimented with entering a new book by an existing >author; on the "1 tab" when cataloging and checking the "authority" (little >red box at the end of the 100$a line) it correctly incremented the number >of times "Used" from 4 to 5 - 6 - 7 each time we saved that book - but a >subsequent "authority" search only found the 4 again. However, now >(accidentally) checking the production machine, an "authority" search finds >all 7 !!! with the associated biblios and items. > >Anyone got any thoughts? Is there something is the mysql "restore" that >points to the wrong db? [I used 'mysql --user= --password=my_pw koha384 >< /usr/share/koha/koha361dump_1jan12.sql] > >I have fairly detailed installation notes if anyone would like them... but >as I'll probably do another complete reinstall (before upgrading the >production machine mid-September), I will verify and refine them -- then >try and assist with the "documentation project." > >Thanks - Paul > >_______________________________________________ >Koha-devel mailing list >Koha-devel at lists.koha-community.org >http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >website : http://www.koha-community.org/ >git : http://git.koha-community.org/ >bugs : http://bugs.koha-community.org/ >_______________________________________________ >Koha-devel mailing list >Koha-devel at lists.koha-community.org >http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >website : http://www.koha-community.org/ >git : http://git.koha-community.org/ >bugs : http://bugs.koha-community.org/ --- Maritime heritage and history, preservation and conservation, research and education through the written word and the arts. and _______________________________________________ Koha-devel mailing list Koha-devel at lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ _______________________________________________ Koha-devel mailing list Koha-devel at lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ From paul.a at aandc.org Sat Aug 25 21:59:18 2012 From: paul.a at aandc.org (Paul) Date: Sat, 25 Aug 2012 15:59:18 -0400 Subject: [Koha-devel] 3.8.4 interim [was: koha-zebra-daemon not starting] In-Reply-To: <502E8CA9F1E0AE47BF682CCEDDAACDC803D6A5DA@exchange.amigos.o rg> References: <502E8CA9F1E0AE47BF682CCEDDAACDC803D6A4CA@exchange.amigos.org> <5.2.1.1.2.20120825082842.02a60278@aandc.org> <502E8CA9F1E0AE47BF682CCEDDAACDC803D6A4CA@exchange.amigos.org> Message-ID: <5.2.1.1.2.20120825153427.029d6eb8@localhost> At 06:28 PM 8/25/2012 +0000, Robert Williams wrote: >Paul: > >Sorry, upon further reflection after sending another response, I think >I've debunked my DNS thoughts (my brain's too dead to be thinking :-) ). >They might play a part, but they don't seem to address the fact that one >form submission succeeds in reaching the correct server/database. It'll be >interesting to hear what actually resolves the problem! Robert -- tnx for the input. I have more or less come to the conclusion that the ISO image of the server is corrupt, damaged or in some way deficient (so I'm downloading the latest and will do a fresh install.) As to DNS, it was one of my first thoughts, but: verify IP addresses: paul at server:/$ sudo ifconfig -a eth0 Link encap:Ethernet HWaddr e0:69:95:ec:35:30 inet addr:192.168.0.1 Bcast:192.168.0.255 Mask:255.255.255.0 eth0:1 Link encap:Ethernet HWaddr e0:69:95:ec:35:30 inet addr:192.168.0.95 Bcast:192.168.0.255 Mask:255.255.255.0 paul at server:/$ ping koha PING koha (192.168.0.90) 56(84) bytes of data. 64 bytes from nelson (192.168.0.90): icmp_req=1 ttl=64 time=0.123 ms paul at server:/$ ping koha3 PING koha3 (192.168.0.1) 56(84) bytes of data. 64 bytes from server (192.168.0.1): icmp_req=1 ttl=64 time=0.016 ms paul at server:/$ ping koha-admin PING koha-admin (192.168.0.91) 56(84) bytes of data. 64 bytes from koha-admin (192.168.0.91): icmp_req=1 ttl=64 time=0.114 ms paul at server:/$ ping koha-admin3 PING koha-admin3 (192.168.0.95) 56(84) bytes of data. 64 bytes from koha-admin3 (192.168.0.95): icmp_req=1 ttl=64 time=0.017 ms ======================== Then I thought of envelope variables (apart from the system ones, which are OK), but: koha at server:/$ echo $PERL5LIB /usr/share/koha/lib koha at server:/$ echo $KOHA_CONF /etc/koha/koha-conf.xml ======================== Then I found Bug 8162: have we got the right user, privileges? But that seems OK. mysql> SELECT host,user FROM user; +-----------+------------------+ | host | user | +-----------+------------------+ | 127.0.0.1 | root | | ::1 | root | | localhost | debian-sys-maint | | localhost | koha | | localhost | paul | | localhost | root | | server | root | +-----------+------------------+ 7 rows in set (0.00 sec) mysql> SHOW GRANTS FOR 'koha'@'localhost'; +-------------------------------------------------------------------------------------------------------------+ | GRANT USAGE ON *.* TO 'koha'@'localhost' IDENTIFIED BY PASSWORD '*0BECD2563417B53867228AE94D7F1A9A1A1CED70' | | GRANT ALL PRIVILEGES ON `koha384`.* TO 'koha'@'localhost' | +-------------------------------------------------------------------------------------------------------------+ 2 rows in set (0.00 sec) mysql> show variables; [snipped] | version 5.5.24-0ubuntu0.12.04.1 | version_comment (Ubuntu) | version_compile_machine x86_64 | version_compile_os debian-linux-gnu ================= I did find one instance of the production server in the dumped|restored db (an added "menu item" in the Admin interface under Staff Client preferences | Appearance | IntranetNav. But even after deleting this, there is no change. I did do a trace from Firefox when saving a "did not work properly" new biblio, but it came back OK: (Request-Line) POST /cgi-bin/koha/cataloguing/addbiblio.pl HTTP/1.1 Host koha-admin3 User-Agent Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:14.0) Gecko/20100101 Firefox/14.0.1 Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language en-us,en;q=0.5 Accept-Encoding gzip, deflate Connection keep-alive Referer http://koha-admin3/cgi-bin/koha/cataloguing/addbiblio.pl?biblionumber=0&z3950=1&frameworkcode=Default&breedingid=75054 Cookie CGISESSID=2813f39fe44d1410997864e44d54e928; marcdocs_1=true Content-Type application/x-www-form-urlencoded Content-Length 40421 (Status-Line) HTTP/1.1 302 Found Date Sat, 25 Aug 2012 16:30:38 GMT Server Apache/2.2.22 (Ubuntu) Location /cgi-bin/koha/cataloguing/additem.pl?biblionumber=17721&frameworkcode= Content-Length 0 Keep-Alive timeout=5, max=100 Connection Keep-Alive Content-Type text/x-perl redirect=items&confirm_not_duplicate=0&frameworkcode=Default&op=addbiblio&frameworkcode=&biblionumber=0&breedingid=75054&tag_000_indicator1_78277136320=&tag_000_indicator2_78277136320=&tag_000_code_00_78277_970808=00&tag_000_subfield_00_78277_970808=01176cam+a2200313+a+4500&tag_001_indicator1_453413487163=&tag_001_indicator2_453413487163= [snip the rest of 32 kb] >Sorry for the noise. Please don't apologize - any assistance to saving my sanity is appreciated. I'm taking this as a "personal challenge" as I can install Koha 3.4, 3.6.x on 32 and 64 bit machines without any difficulty; but cannot for the life of me get 3.8.3 or 3.8.4 up and running. The devel team give me the impression that it's my end that "needs attention", so I'll try again (the new ISO has just finished downloading ...) Again tnx -- Paul >--Robert >________________________________________ >From: koha-devel-bounces at lists.koha-community.org >[koha-devel-bounces at lists.koha-community.org] on behalf of Robert Williams >[williams at amigos.org] >Sent: Saturday, August 25, 2012 1:09 PM >To: koha-devel at lists.koha-community.org >Subject: Re: [Koha-devel] 3.8.4 interim [was: koha-zebra-daemon not starting] > >Paul: > > > >You wrote: > > >Both servers are on the same LAN, but under different computer names > >'server' and 'nelson', different IPs 192.168.0.91 and .95, different db > >names 'koha' and 'koha384', different URLs 'http://koha' and > >'http://koha-admin' compared to 'http://koha3' and 'http://koha-admin3', > >hosts files all updated, router updated (static, no DHCP). > >I've thought of and rejected several ideas. I'm thinking that, outside of >the "BaseURL" sys pref settings, if it was an entry in the MySQL db or in >a problem with the underlying Koha code, the dump/transfer/reload cycle >would commonly end in problems for everyone. > >So I'm thinking it's likely a system setup thing. It seems to me most >likely to be related to a domain name lookup problem (DNS issue/hosts >issue?). But it possibly could be on the client side rather than the >server side. Since your URLs do not correspond to your machine (host) >names, the client's DNS lookup could be involved. You might try flushing >the Firefox cache, flushing the local OS's DNS cache (ipconfig /flushdns >on Windows clients, run with admin privileges), and then pinging the >koha-admin, koha-admin3 names from the client command line and see what >you get. Or alternatively, just check the local hosts file on the client, >or the DNS server for your local network if implemented, and make sure >there are not errors. > >If you change the Apache configuration to use the IP addresses and port >numbers (and access the sites by the direct IP address temporarily), you >can determine if it's actually a DNS issue or not. > >Don't know that this will be helpful, but it sounds from your message like >something different than what you've already tried. Here's hoping it helps. > > > >--Robert > >________________________________________ >From: koha-devel-bounces at lists.koha-community.org >[koha-devel-bounces at lists.koha-community.org] on behalf of Paul >[paul.a at aandc.org] >Sent: Saturday, August 25, 2012 7:30 AM >To: koha-devel at lists.koha-community.org >Subject: Re: [Koha-devel] 3.8.4 interim [was: koha-zebra-daemon not starting] > >[sending again to the LIST - apologies, only went to Robert yesterday] >At 08:31 PM 8/24/2012 +0000, Robert Williams wrote: > >Paul: > > > >I'm wondering if you could have the staffClientBaseURL system preference > >set (not changed after loading the database from the production server)? > >If so, logging in to the staff interface on the test server may be > >"sending" you to the production server? > >Robert, > >Many thanks for the suggestion. The 'staffClientBaseURL' was indeed blank >... I filled it in with the test server url, and it's still saving to the >production machine (different url, different db name, ...) > >Best - Paul > > > >--Robert > > > >********************************************* > >Robert L. Williams > >Manager, Open Source ILS Services > >Amigos Library Services, Inc. > >14400 Midway Road > >Dallas, TX 75244-3509 > >800-843-8482, x2870 > >972-340-2870 (direct) > >972-991-6061 (fax) > > > > > >-----Original Message----- > >From: koha-devel-bounces at lists.koha-community.org > >[mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Paul > >Sent: Friday, August 24, 2012 12:38 PM > >To: Koha Devel > >Cc: Koha Devel > >Subject: Re: [Koha-devel] 3.8.4 interim [was: koha-zebra-daemon not > starting] > > > >At 01:50 PM 8/23/2012 +1200, Mason James wrote: > > > >> paul at server:~$ sudo /etc/init.d/koha-zebra-daemon start > > > >> Starting Zebra Server > > > >> /etc/init.d/koha-zebra-daemon: line 73: daemon: command not found > > > > $ sudo apt-get install daemon ? > > > >Thanks - that was the problem, and I have no idea why it "went AWOL." > > > > >my other hunch is that you have bunch of __FOO__ stuff in your > > >/etc/init.d/koha-zebra-daemon file > > > >That had installed perfectly, but thanks, it pushed me into doing a lot > >more digging around. Anyway, as of this morning, Koha 3.8.4 is running on > >AMD64 Ubuntu 12.04 LTS. > > > >However, I have (after asking our staff to try it out), got a very weird > >dilemma: from the new test machine, all NEW records (biblios and items, > >both Z39.50 imports and manual entries) are saving to our *PRODUCTION* > >server (3.6.1) -- all EDITS of existing biblios/items are saving correctly > >to the *TEST* server (3.8.4). > > > >Both servers are on the same LAN, but under different computer names > >'server' and 'nelson', different IPs 192.168.0.91 and .95, different db > >names 'koha' and 'koha384', different URLs 'http://koha' and > >'http://koha-admin' compared to 'http://koha3' and 'http://koha-admin3', > >hosts files all updated, router updated (static, no DHCP). > > > >Similarities are that I restored a mysql dump from production to test and > >therefore users/staff logins/passwords are the same. The test machine is > >saving something: we experimented with entering a new book by an existing > >author; on the "1 tab" when cataloging and checking the "authority" (little > >red box at the end of the 100$a line) it correctly incremented the number > >of times "Used" from 4 to 5 - 6 - 7 each time we saved that book - but a > >subsequent "authority" search only found the 4 again. However, now > >(accidentally) checking the production machine, an "authority" search finds > >all 7 !!! with the associated biblios and items. > > > >Anyone got any thoughts? Is there something is the mysql "restore" that > >points to the wrong db? [I used 'mysql --user= --password=my_pw koha384 > >< /usr/share/koha/koha361dump_1jan12.sql] > > > >I have fairly detailed installation notes if anyone would like them... but > >as I'll probably do another complete reinstall (before upgrading the > >production machine mid-September), I will verify and refine them -- then > >try and assist with the "documentation project." > > > >Thanks - Paul > > > >_______________________________________________ > >Koha-devel mailing list > >Koha-devel at lists.koha-community.org > >http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > >website : http://www.koha-community.org/ > >git : http://git.koha-community.org/ > >bugs : http://bugs.koha-community.org/ > >_______________________________________________ > >Koha-devel mailing list > >Koha-devel at lists.koha-community.org > >http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > >website : http://www.koha-community.org/ > >git : http://git.koha-community.org/ > >bugs : http://bugs.koha-community.org/ > >--- >Maritime heritage and history, preservation and conservation, >research and education through the written word and the arts. > and > >_______________________________________________ >Koha-devel mailing list >Koha-devel at lists.koha-community.org >http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >website : http://www.koha-community.org/ >git : http://git.koha-community.org/ >bugs : http://bugs.koha-community.org/ >_______________________________________________ >Koha-devel mailing list >Koha-devel at lists.koha-community.org >http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >website : http://www.koha-community.org/ >git : http://git.koha-community.org/ >bugs : http://bugs.koha-community.org/ >_______________________________________________ >Koha-devel mailing list >Koha-devel at lists.koha-community.org >http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >website : http://www.koha-community.org/ >git : http://git.koha-community.org/ >bugs : http://bugs.koha-community.org/ --- Maritime heritage and history, preservation and conservation, research and education through the written word and the arts. and From paul.a at aandc.org Sat Aug 25 22:17:35 2012 From: paul.a at aandc.org (Paul) Date: Sat, 25 Aug 2012 16:17:35 -0400 Subject: [Koha-devel] 3.8.4 installation: order of db install Message-ID: <5.2.1.1.2.20120825160438.03a05f58@stormy.ca> Does anyone have any thoughts on the order of the following towards the end of installation: 1) Apache2: verify that "koha-admin" responds (empty db) 2) Restore a "dump" from a previous 3.6.x 3) Update the db with ./updatedatabase.pl (is -I needed; seems to fail for me) 4) Reindex zebra (-a , -b) 5) [?? I think it's stopped by a full reindex] start|stop zebra cron -z (incremental) The reason that I ask is that all *my* 3.6.x installs have "updatedatabase"-ed automatically on opening staff-admin; but (so far) all my 3.8.x installs have just got stuck on a staff-admin screen "Maintenance: contact your admin" and I've had to go back and run the .pl so get the staff page to open. Thanks - Paul From ramses02 at yahoo.com Sun Aug 26 09:01:36 2012 From: ramses02 at yahoo.com (Oscar Gaona) Date: Sun, 26 Aug 2012 00:01:36 -0700 (PDT) Subject: [Koha-devel] Koha 3.8.x: Loan for 0 days Message-ID: <1345964496.17685.YahooMailNeo@web121304.mail.ne1.yahoo.com> Hi all I've been configuring a Circulation Rule with Zero (0) days for loans in Koha 3.2, 3.4 and 3.6 without problems ('Checked out on' date and 'Due date' are the same) but for Koha 3.8.x this seems impossible: 'Due date' displays a date 21 days after the 'Cheked out on' date. Where can be the problem? Any idea to solve it? Thanks in advance. Oscar? -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.a at aandc.org Sun Aug 26 18:39:27 2012 From: paul.a at aandc.org (Paul) Date: Sun, 26 Aug 2012 12:39:27 -0400 Subject: [Koha-devel] Koha 3.8.4 on Ubuntu server 12.04 Message-ID: <5.2.1.1.2.20120826120902.03c1c678@stormy.ca> Koha 3.8.4 on Ubuntu server 12.04 LTS including importing an existing 3.6.1 database. Finally got my trials and tribulations behind me, 3.8.4 up and running (now on to detail, customization and pre-production testing.) A couple of points following previous threads (YMMV, but this worked without a single error for me this morning): 1) Use ubuntu-12.04.1-server-amd64.iso (598,902,661 bytes) which replaces ubuntu-12.04-server-amd64.iso (717,533,184 bytes) -- I'm not certain what the hiccough was, but there have been considerable changes made. This latest ISO, much smaller than the previous one, allowed everything below normally. 2) Add the debian.koha-community.org/koha repository to /etc/apt/sources.list.d/koha.list before looking for dependencies. 3) Before using dpkg, dselect from the Koha .gz, $ sudo apt-get install libtemplate-plugin-htmltotext-perl zip unzip yaz idzebra-2.0 daemon dselect libyaz4 libyaz4-dev libnet-z3950-zoom-perl libxml-libxslt-perl libgraphics-magick-perl liblingua-stem-snowball-perl libtemplate-perl liblingua-ispell-perl libhtml-template-pro-perl libreadonly-xs-perl libtest-strict-perl 4) Koha will try to install (and report "missing/not required") DBD::SQLite2 which as far as I can tell is superceded by libdbd-sqlite3-perl (i.e version 3) which I installed. 'Make test' will report it, but 'make install' is fully functional. 5) After installing and configuring Mysql, Koha and Apache2, doing the following *in this order* allowed clean updating of a db restore, Zebra indexing and zebra incremental cron: a) Verify from a workstation browser: http://koha3 ==> OPAC (will report "under maintenance.") Do NOT YET verify http://koha-admin3 ==> Staff client login b) NOW restore a working copy of a working db: c) http://koha-admin3 ==> Staff client login will go through "upgrade" process d) Setup Zebra daemon at boot e) Reindex Zebra (auths and biblios) f) Set up cron Zebra incremental Thanks to all involved, best regards, Paul From robin at catalyst.net.nz Mon Aug 27 10:45:36 2012 From: robin at catalyst.net.nz (Robin Sheat) Date: Mon, 27 Aug 2012 10:45:36 +0200 Subject: [Koha-devel] 3.8.4 interim [was: koha-zebra-daemon not starting] In-Reply-To: <5.2.1.1.2.20120824212221.01cf0128@aandc.org> References: <5.2.1.1.2.20120824212221.01cf0128@aandc.org> Message-ID: <503B33B0.5000901@catalyst.net.nz> Op 25-08-12 03:22, Paul schreef: > However, I have (after asking our staff to try it out), got a very weird > dilemma: from the new test machine, all NEW records (biblios and items, > both Z39.50 imports and manual entries) are saving to our *PRODUCTION* > server (3.6.1) -- all EDITS of existing biblios/items are saving > correctly to the *TEST* server (3.8.4). Can you confirm that you are checking both search results and details? I'm wondering if both instances are pointing to the same zebra server. -- Robin Sheat Catalyst IT Ltd. ? +64 4 803 2204 GPG: 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D From paul.a at aandc.org Mon Aug 27 15:36:48 2012 From: paul.a at aandc.org (Paul) Date: Mon, 27 Aug 2012 09:36:48 -0400 Subject: [Koha-devel] 3.8.4 interim [was: koha-zebra-daemon not starting] In-Reply-To: <503B33B0.5000901@catalyst.net.nz> References: <5.2.1.1.2.20120824212221.01cf0128@aandc.org> <5.2.1.1.2.20120824212221.01cf0128@aandc.org> Message-ID: <5.2.1.1.2.20120827084638.04cae140@localhost> At 10:45 AM 8/27/2012 +0200, Robin Sheat wrote: >Op 25-08-12 03:22, Paul schreef: > > However, I have (after asking our staff to try it out), got a very weird > > dilemma: from the new test machine, all NEW records (biblios and items, > > both Z39.50 imports and manual entries) are saving to our *PRODUCTION* > > server (3.6.1) -- all EDITS of existing biblios/items are saving > > correctly to the *TEST* server (3.8.4). Robin - thanks. It's all a bit moot now as the test server has been successfully (and totally) rebuilt (using the new " .1 " version of the ISO, see my email to this list yesterday Sun, 26 Aug 2012 12:39:27 -0400), but: >Can you confirm that you are checking both search results and details? ['are' ==> 'was'] yes >I'm wondering if both instances are pointing to the same zebra server. This was not a case of sebra|search, the records were being *saved* to a differently named mysql/innodb on a differently IP'd machine. After saving a new Z39.50 biblio on the test server and shutting it down, the new record was on the production server and found by the zebra on the production server. I'm pretty certain from all my notes that both servers had separate zebra servers indexing separate sql db's. I even went as far as shutdown -h of the production server; 3.8.4 on the test server still appeared (i.e. no errors) to save new records, but they went nowhere -- and could not be found by either zebra server on either the production (after restarting) or the test box. While it's quite possible I screwed something up, the new LTS distro has made a number of fundamental changes concerning 'cloud' networking (OpenStack, MAAS, Keystone) which just possibly could have had some impact on our LAN (I have no proof of this, and our static IP LAN seems perfect after numerous "every-which-way" verifications.) Also, the older distro had a few ugly points in handling i386 modules if it couldn't find AMD64, but again, I could find no reason for this to account for my dilemma. Again thanks and br, Paul From tomascohen at gmail.com Mon Aug 27 16:18:27 2012 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Mon, 27 Aug 2012 11:18:27 -0300 Subject: [Koha-devel] 3.8.4 interim [was: koha-zebra-daemon not starting] In-Reply-To: <5.2.1.1.2.20120827084638.04cae140@localhost> References: <5.2.1.1.2.20120824212221.01cf0128@aandc.org> <503B33B0.5000901@catalyst.net.nz> <5.2.1.1.2.20120827084638.04cae140@localhost> Message-ID: On Mon, Aug 27, 2012 at 10:36 AM, Paul wrote: > While it's quite possible I screwed something up, the new LTS distro has > made a number of fundamental changes concerning 'cloud' networking > (OpenStack, MAAS, Keystone) which just possibly could have had some impact > on our LAN (I have no proof of this, and our static IP LAN seems perfect > after numerous "every-which-way" verifications.) Also, the older distro had > a few ugly points in handling i386 modules if it couldn't find AMD64, but > again, I could find no reason for this to account for my dilemma. We use and used 12.04 since its release in several production servers and didn't have any problem. I even managed to do a: Koha 3.0.x + Ubuntu 10.04 => Koha 3.8.x + Ubuntu 12.04 migration a while ago without issues. The only problem we had to solve, had to do with a bug in Xen and Ubuntu using submenues in grub2, which were ok but old Xen didn't handle well (SuSE Dom0). The cloud stuff is not installed by default thou, unless you're using MASS images. Regards To+ From lculber at mdah.state.ms.us Mon Aug 27 16:51:29 2012 From: lculber at mdah.state.ms.us (Linda) Date: Mon, 27 Aug 2012 09:51:29 -0500 Subject: [Koha-devel] improving install instructions Message-ID: <503B8971.8010105@mdah.state.ms.us> All, We've been using the multiple instances instructions from the wiki. In general they've been very good. The problem we've had is with permissions in zebra. As as newbie, I'd appreciate any clarification on how to get that right during the install. Thanks. -- Linda Culberson lculber at mdah.state.ms.us Miss. Dept. of Archives and History Archives& Records Services P.O. Box 571 Jackson, MS 39205-0571 Phone: (601) 576-6873 From aszomor at szomor.hu Mon Aug 27 17:15:20 2012 From: aszomor at szomor.hu (aszomor at szomor.hu) Date: Mon, 27 Aug 2012 17:15:20 +0200 Subject: [Koha-devel] [Koha] Koha 3.8.4 released In-Reply-To: References: Message-ID: <20120827171520.13214oxir45f0i6g@webmail.dravanet.hu> Dear All, Where I find the information of how to update my koha from 3.8.3 to 3.8.4. Best Regards, Attila. Koha version: 3.08.03.000 OS version ('uname -a'): Linux koha 3.2.0-29-generic #46-Ubuntu SMP Fri Jul 27 17:03:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux Perl interpreter: /usr/bin/perl Perl version: 5.014002 Perl @INC: /usr/share/koha/lib /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl . MySQL version: mysql Ver 14.14 Distrib 5.5.24, for debian-linux-gnu (x86_64) using readline 6.2 Apache version: Server version: Apache/2.2.22 (Ubuntu) Zebra version: Zebra 2.0.44 (C) 1994-2010, Index Data ApS Zebra is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. SHA1 ID: 419ad759807269fdfa379799a051ed3a551c6541 Using ICU From paul. at aandc.org Sat Aug 25 02:28:35 2012 From: paul. at aandc.org (Paul) Date: Fri, 24 Aug 2012 20:28:35 -0400 Subject: [Koha-devel] 3.8.4 interim [was: koha-zebra-daemon not starting] In-Reply-To: <502E8CA9F1E0AE47BF682CCEDDAACDC803D69CDB@exchange.amigos.o rg> References: <5.2.1.1.2.20120824124338.01bdd320@localhost> <5D60C882-A67B-48D6-B518-7B7AE354B30F@kohaaloha.com> <5.2.1.1.2.20120822182137.04758d20@localhost> <5.2.1.1.2.20120822182137.04758d20@localhost> <5.2.1.1.2.20120822194128.01e26d88@localhost> <5D60C882-A67B-48D6-B518-7B7AE354B30F@kohaaloha.com> <5.2.1.1.2.20120824124338.01bdd320@localhost> Message-ID: <5.2.1.1.2.20120824202320.02ab7008@localhost> At 08:31 PM 8/24/2012 +0000, Robert Williams wrote: >Paul: > >I'm wondering if you could have the staffClientBaseURL system preference >set (not changed after loading the database from the production server)? >If so, logging in to the staff interface on the test server may be >"sending" you to the production server? Robert, Many thanks for the suggestion. The 'staffClientBaseURL' was indeed blank ... I filled it in with the test server url, and it's still saving to the production machine (different url, different db name, ...) Best - Paul >--Robert > >********************************************* >Robert L. Williams >Manager, Open Source ILS Services >Amigos Library Services, Inc. >14400 Midway Road >Dallas, TX 75244-3509 >800-843-8482, x2870 >972-340-2870 (direct) >972-991-6061 (fax) > > >-----Original Message----- >From: koha-devel-bounces at lists.koha-community.org >[mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Paul >Sent: Friday, August 24, 2012 12:38 PM >To: Koha Devel >Cc: Koha Devel >Subject: Re: [Koha-devel] 3.8.4 interim [was: koha-zebra-daemon not starting] > >At 01:50 PM 8/23/2012 +1200, Mason James wrote: > > >> paul at server:~$ sudo /etc/init.d/koha-zebra-daemon start > > >> Starting Zebra Server > > >> /etc/init.d/koha-zebra-daemon: line 73: daemon: command not found > > > $ sudo apt-get install daemon ? > >Thanks - that was the problem, and I have no idea why it "went AWOL." > > >my other hunch is that you have bunch of __FOO__ stuff in your > >/etc/init.d/koha-zebra-daemon file > >That had installed perfectly, but thanks, it pushed me into doing a lot >more digging around. Anyway, as of this morning, Koha 3.8.4 is running on >AMD64 Ubuntu 12.04 LTS. > >However, I have (after asking our staff to try it out), got a very weird >dilemma: from the new test machine, all NEW records (biblios and items, >both Z39.50 imports and manual entries) are saving to our *PRODUCTION* >server (3.6.1) -- all EDITS of existing biblios/items are saving correctly >to the *TEST* server (3.8.4). > >Both servers are on the same LAN, but under different computer names >'server' and 'nelson', different IPs 192.168.0.91 and .95, different db >names 'koha' and 'koha384', different URLs 'http://koha' and >'http://koha-admin' compared to 'http://koha3' and 'http://koha-admin3', >hosts files all updated, router updated (static, no DHCP). > >Similarities are that I restored a mysql dump from production to test and >therefore users/staff logins/passwords are the same. The test machine is >saving something: we experimented with entering a new book by an existing >author; on the "1 tab" when cataloging and checking the "authority" (little >red box at the end of the 100$a line) it correctly incremented the number >of times "Used" from 4 to 5 - 6 - 7 each time we saved that book - but a >subsequent "authority" search only found the 4 again. However, now >(accidentally) checking the production machine, an "authority" search finds >all 7 !!! with the associated biblios and items. > >Anyone got any thoughts? Is there something is the mysql "restore" that >points to the wrong db? [I used 'mysql --user= --password=my_pw koha384 >< /usr/share/koha/koha361dump_1jan12.sql] > >I have fairly detailed installation notes if anyone would like them... but >as I'll probably do another complete reinstall (before upgrading the >production machine mid-September), I will verify and refine them -- then >try and assist with the "documentation project." > >Thanks - Paul > >_______________________________________________ >Koha-devel mailing list >Koha-devel at lists.koha-community.org >http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >website : http://www.koha-community.org/ >git : http://git.koha-community.org/ >bugs : http://bugs.koha-community.org/ >_______________________________________________ >Koha-devel mailing list >Koha-devel at lists.koha-community.org >http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >website : http://www.koha-community.org/ >git : http://git.koha-community.org/ >bugs : http://bugs.koha-community.org/ --- Maritime heritage and history, preservation and conservation, research and education through the written word and the arts. and From paul at aandc.org Sat Aug 25 03:16:31 2012 From: paul at aandc.org (Paul) Date: Fri, 24 Aug 2012 21:16:31 -0400 Subject: [Koha-devel] 3.8.4 interim [was: koha-zebra-daemon not starting] Message-ID: <5.2.1.1.2.20120824211000.02b89068@aandc.org> A tad of clarification. I had written: >However, I have (after asking our staff to try it out), got a very weird >dilemma: from the new test machine, all NEW records (biblios and items, >both Z39.50 imports and manual entries) are saving to our *PRODUCTION* >server (3.6.1) -- all EDITS of existing biblios/items are saving correctly >to the *TEST* server (3.8.4). > >Both servers are on the same LAN, but under different computer names >'server' and 'nelson', different IPs 192.168.0.91 and .95, different db >names 'koha' and 'koha384', different URLs 'http://koha' and >'http://koha-admin' compared to 'http://koha3' and 'http://koha-admin3', >hosts files all updated, router updated (static, no DHCP). From the install log of the production machine (passwords snipped): # This file contains settings used # during the installation of Koha. # It is meant for use during future # upgrades of Koha, and should not # be edited. KOHA_INSTALLED_VERSION=3.06.01.000 LOG_DIR=/var/log/koha DB_TYPE=mysql DB_NAME=koha306 DB_HOST=localhost DB_USER=koha WEBMASTER_EMAIL=webmaster at nelson WEBSERVER_DOMAIN=nelson WEBSERVER_HOST=nelson The same from the test machine: # This file contains settings used # during the installation of Koha. # It is meant for use during future # upgrades of Koha, and should not # be edited. KOHA_INSTALLED_VERSION=3.08.04.000 LOG_DIR=/var/log/koha DB_TYPE=mysql DB_NAME=koha384 DB_HOST=localhost DB_USER=koha WEBMASTER_EMAIL=webmaster at server WEBSERVER_DOMAIN=server WEBSERVER_HOST=server Similarities are that I restored a mysql dump from production to test and therefore users/staff logins/passwords are the same. The test machine is saving something: we experimented with entering a new book by an existing author; on the "1 tab" when cataloging and checking the "authority" (little red box at the end of the 100$a line) it correctly incremented the number of times "Used" from 4 to 5 - 6 - 7 each time we saved that book - but a subsequent "authority" search only found the 4 again. However, now (accidentally) checking the production machine, an "authority" search finds all 7 !!! with the associated biblios and items. Anyone got any thoughts? Is there something is the mysql "restore" that points to the wrong db? [I used 'mysql --user= --password=my_pw koha384 < /usr/share/koha/koha361dump_1jan12.sql] I have fairly detailed installation notes if anyone would like them... but as I'll probably do another complete reinstall (before upgrading the production machine mid-September), I will verify and refine them -- then try and assist with the "documentation project." Thanks - Paul From paul.poulain at biblibre.com Mon Aug 27 17:46:36 2012 From: paul.poulain at biblibre.com (Paul Poulain) Date: Mon, 27 Aug 2012 17:46:36 +0200 Subject: [Koha-devel] KOCT reviewed by mozilla and 2 new patches Message-ID: <503B965C.2030808@biblibre.com> Hello koha-devel, During my holidays, someone from mozilla reviewed our koct plugin and found some problems. They've been fixed by Jonathan, I just pushed 2 new patches to koha contrib/global.git repository. It changes nothing to features or translations. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From glawson at rhcl.org Mon Aug 27 20:09:31 2012 From: glawson at rhcl.org (glaws) Date: Mon, 27 Aug 2012 13:09:31 -0500 Subject: [Koha-devel] Overdue Notices Message-ID: <503BB7DB.4050606@rhcl.org> I have a question about overdue notices in Koha 3.8.3. Not sure if this is a bug or not... When a patron has overdue items, the "First Overdue Notice" will generate a list of those items. Perfect. When other overdue items subsequently become overdue within an undetermined but limited amount of time, a "First Overdue Notice" is generated for those items, but if the first set of items have not been resolved (by returning them), they are repeated in the second "First Overdue Notice". See attached .pdf. Desired/correct functionality? -- Greg Lawson Network Administrator Rolling Hills Consolidated Library 1912 N. Belt Highway St. Joseph, MO 64506 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: overdue_notices.pdf Type: application/pdf Size: 938892 bytes Desc: not available URL: From Katrin.Fischer at bsz-bw.de Mon Aug 27 21:15:22 2012 From: Katrin.Fischer at bsz-bw.de (Fischer, Katrin) Date: Mon, 27 Aug 2012 21:15:22 +0200 Subject: [Koha-devel] Overdue Notices References: <503BB7DB.4050606@rhcl.org> Message-ID: <028B1A54D03E7B4482CDCA4EC8F06BFD0162682B@Bodensee.bsz-bw.de> Hi Greg, are you maybe using the --list-all option with overdues.pl? I think in that case all overdue items are listed with each notice. Hope this helps, Katrin -----Urspr?ngliche Nachricht----- Von: koha-devel-bounces at lists.koha-community.org im Auftrag von glaws Gesendet: Mo 27.08.2012 20:09 An: koha-devel at lists.koha-community.org Betreff: [Koha-devel] Overdue Notices I have a question about overdue notices in Koha 3.8.3. Not sure if this is a bug or not... When a patron has overdue items, the "First Overdue Notice" will generate a list of those items. Perfect. When other overdue items subsequently become overdue within an undetermined but limited amount of time, a "First Overdue Notice" is generated for those items, but if the first set of items have not been resolved (by returning them), they are repeated in the second "First Overdue Notice". See attached .pdf. Desired/correct functionality? -- Greg Lawson Network Administrator Rolling Hills Consolidated Library 1912 N. Belt Highway St. Joseph, MO 64506 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mtj at kohaaloha.com Mon Aug 27 22:18:43 2012 From: mtj at kohaaloha.com (Mason James) Date: Tue, 28 Aug 2012 08:18:43 +1200 Subject: [Koha-devel] Lets improve the Koha installation documentation In-Reply-To: <5036843A.4000408@catalyst.net.nz> References: <5.2.1.1.2.20120822182137.04758d20@localhost> <06AEAB3D-C3DD-4636-8796-E73E8959CA7A@kohaaloha.com> <7D888F97-6D33-469C-9986-F2C0B653D568@kohaaloha.com> <50364973.2020500@catalyst.net.nz> <8B184978-E741-47A5-B29A-F4764D0F7EFA@kohaaloha.com> <5036843A.4000408@catalyst.net.nz> Message-ID: On 2012-08-24, at 7:27 AM, Robin Sheat wrote: > Op 23-08-12 21:00, Mason James schreef: >> there looks to be some good conversion tools between asciidoc, pod, and wiki >> (and then html, docbook, pdf and latex too) > > While you're exploring, I hear good things about markdown as a > human-writable but still parseable format, and I'd give good odds > there's a markdown to mediawiki converter. > i've just discovered the 'pandoc' tool, which looks like it does every conversion possible :) http://johnmacfarlane.net/pandoc/ http://packages.debian.org/squeeze/pandoc i'll get some tests sorted this week, for the various doc formats. stay tuned? From paul.a at aandc.org Tue Aug 28 02:16:30 2012 From: paul.a at aandc.org (Paul) Date: Mon, 27 Aug 2012 20:16:30 -0400 Subject: [Koha-devel] Environment variables Message-ID: <5.2.1.1.2.20120827144843.02daced0@stormy.ca> I'm in the process of comparing the Wiki page with my own notes and am wondering if I am missing a "bigger picture" although I'm pretty sure my findings (3.8.4 on 12.04.1) are reliable. The Wiki suggests editing /etc/cron.d/koha to include KOHA_CONF=/etc/koha/koha-conf.xml, KOHAPATH=/usr/share/koha and PERL5LIB=$KOHAPATH/lib --- then "Alternatively you could ..." edit /etc/bash.bashrc.local to export KOHA_CONF and PERL5LIB I have found on 3.6 and 3.8 you must (rather than "alternatively could") add the two export lines to /home/koha/.bashrc [1] -- if not the variables are lost on reboot and the cron will fail (C4 not found.) The /etc/cron.d/koha does not need the env vars: paul at server: cat /etc/cron.d/koha */1 * * * * koha $KOHAPATH/bin/migration_tools/rebuild_zebra.pl -a -b -z &> /dev/null My notes: CONCLUSION: 3.8.4: cataloguing and zebra incremental cron fully functional. To renew PERL5LIB=/usr/share/koha/lib and KOHA_CONF=/etc/koha/koha-conf.xml after reboot, the 'export' must be in /home/koha/.bashrc; also /etc/cron.d/koha does not require any $ENV statements Am I missing something? tnx - paul [1] I tried all combinations of env vars in /home/koha/.bashrc and /etc/bash.bashrc.local, plus env vars or not in cron. I was a little surprised that the /etc/bash.bashrc.local did *not* restore the env vars to koha after reboot. Could someone running Debian Squeeze let me know if this is a Ubuntu or more general *deb problem? Or if there is a way of forcing 'local' to recognize user=koha? From info at AandC.org Tue Aug 28 03:10:31 2012 From: info at AandC.org (Archives and Collections Society) Date: Mon, 27 Aug 2012 21:10:31 -0400 Subject: [Koha-devel] Environment variables In-Reply-To: References: <5.2.1.1.2.20120827144843.02daced0@stormy.ca> <5.2.1.1.2.20120827144843.02daced0@stormy.ca> Message-ID: <5.2.1.1.2.20120827210809.02b35160@localhost> At 09:33 PM 8/27/2012 -0300, Tomas Cohen Arazi wrote: >/etc/environment is a better place for those vars. Note? that a single >koha install on the same box is not the only use case. Then how do you make them user specific? Or should Zebra *not* be 'user=koha' specific? Best - Paul >Regards >To+ >El ago 27, 2012 9:16 p.m., "Paul" ><paul.a at aandc.org> escribi??: >I'm in the process of comparing the Wiki page ><http://wiki.koha-community.org/wiki/Koha_on_Ubuntu> >with my own notes and am wondering if I am missing a "bigger picture" >although I'm pretty sure my findings (3.8.4 on 12.04.1) are reliable. > >The Wiki suggests editing ? /etc/cron.d/koha ? to include >KOHA_CONF=/etc/koha/koha-conf.xml, KOHAPATH=/usr/share/koha and >PERL5LIB=$KOHAPATH/lib --- then "Alternatively you could ..." edit >/etc/bash.bashrc.local to export KOHA_CONF and PERL5LIB > >I have found on 3.6 and 3.8 you must (rather than "alternatively could") >add the two export lines to /home/koha/.bashrc [1] -- if not the variables >are lost on reboot and the cron will fail (C4 not found.) > >The /etc/cron.d/koha does not need the env vars: > >paul at server: cat /etc/cron.d/koha >*/1 * * * * ? ? koha ? ? >$KOHAPATH/bin/migration_tools/rebuild_zebra.pl -a >-b -z &> /dev/null > >My notes: > >CONCLUSION: >3.8.4: cataloguing and zebra incremental cron fully functional. >To renew PERL5LIB=/usr/share/koha/lib and >KOHA_CONF=/etc/koha/koha-conf.xml after reboot, the 'export' must be in >/home/koha/.bashrc; also /etc/cron.d/koha does not require any $ENV statements > >Am I missing something? > >tnx - paul > >[1] I tried all combinations of env vars in /home/koha/.bashrc and >/etc/bash.bashrc.local, plus env vars or not in cron. I was a little >surprised that the /etc/bash.bashrc.local did *not* restore the env vars >to koha after reboot. ? Could someone running Debian Squeeze let me know >if this is a Ubuntu or more general *deb problem? ? Or if there is a way >of forcing 'local' to recognize user=koha? > >_______________________________________________ >Koha-devel mailing list >Koha-devel at lists.koha-community.org >http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >website : http://www.koha-community.org/ >git : http://git.koha-community.org/ >bugs : http://bugs.koha-community.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.poulain at biblibre.com Tue Aug 28 12:30:44 2012 From: paul.poulain at biblibre.com (Paul Poulain) Date: Tue, 28 Aug 2012 12:30:44 +0200 Subject: [Koha-devel] BibLibre sandboxes unavailable tomorrow Message-ID: <503C9DD4.9070009@biblibre.com> Hello Koha users & developers, Tomorrow, we will do some changes to our infrastructure, sandboxes (http://wiki.koha-community.org/wiki/Sandboxes) may be unavailable tomorrow (european work hours) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From fridolyn.somers at biblibre.com Tue Aug 28 12:49:08 2012 From: fridolyn.somers at biblibre.com (Fridolyn SOMERS) Date: Tue, 28 Aug 2012 12:49:08 +0200 Subject: [Koha-devel] Environment variables In-Reply-To: <5.2.1.1.2.20120827144843.02daced0@stormy.ca> References: <5.2.1.1.2.20120827144843.02daced0@stormy.ca> Message-ID: <503CA224.3090305@biblibre.com> Hie, My point of view is that those env vars should be specific to 'koha' user, so added in ".bashrc". Those vars are specified in Apache conf and Zebra daemons, they must be set in env only to allow script direct launching in command line. In case of multiple instances, we use a script per instance to set correct vars in env (use "source envXXX.sh"). Best regards, -- Fridolyn SOMERS Biblibre - P?le Support fridolyn.somers at biblibre.com Le 28/08/2012 02:16, Paul a ?crit : > I'm in the process of comparing the Wiki page > with my own notes > and am wondering if I am missing a "bigger picture" although I'm > pretty sure my findings (3.8.4 on 12.04.1) are reliable. > > The Wiki suggests editing /etc/cron.d/koha to include > KOHA_CONF=/etc/koha/koha-conf.xml, KOHAPATH=/usr/share/koha and > PERL5LIB=$KOHAPATH/lib --- then "Alternatively you could ..." edit > /etc/bash.bashrc.local to export KOHA_CONF and PERL5LIB > > I have found on 3.6 and 3.8 you must (rather than "alternatively > could") add the two export lines to /home/koha/.bashrc [1] -- if not > the variables are lost on reboot and the cron will fail (C4 not found.) > > The /etc/cron.d/koha does not need the env vars: > > paul at server: cat /etc/cron.d/koha > */1 * * * * koha $KOHAPATH/bin/migration_tools/rebuild_zebra.pl -a > -b -z &> /dev/null > > My notes: > > CONCLUSION: > 3.8.4: cataloguing and zebra incremental cron fully functional. > To renew PERL5LIB=/usr/share/koha/lib and > KOHA_CONF=/etc/koha/koha-conf.xml after reboot, the 'export' must be > in /home/koha/.bashrc; also /etc/cron.d/koha does not require any $ENV > statements > > Am I missing something? > > tnx - paul > > [1] I tried all combinations of env vars in /home/koha/.bashrc and > /etc/bash.bashrc.local, plus env vars or not in cron. I was a little > surprised that the /etc/bash.bashrc.local did *not* restore the env > vars to koha after reboot. Could someone running Debian Squeeze let > me know if this is a Ubuntu or more general *deb problem? Or if there > is a way of forcing 'local' to recognize user=koha? > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ -------------- section suivante -------------- Une pi?ce jointe HTML a ?t? nettoy?e... URL: From chrisc at catalyst.net.nz Tue Aug 28 23:40:12 2012 From: chrisc at catalyst.net.nz (Chris Cormack) Date: Wed, 29 Aug 2012 09:40:12 +1200 Subject: [Koha-devel] [Koha] Communicating with Koha Session variables In-Reply-To: <1346170021325-5724623.post@n5.nabble.com> References: <1346170021325-5724623.post@n5.nabble.com> Message-ID: <20120828214012.GH7186@rorohiko.wgtn.cat-it.co.nz> * sheldon_tappin (thecarterii at hotmail.com) wrote: > Hi All, > > I would like to create a web app using php that should communicate with Koha > ILS for authentication purposes. > Can anyone provide the information on how I can talk to the session or > cookie variables in koha. > > Your help will be very beneficial to our library. > Hi Sheldon The cookie won't tell you anything, not even if the person is logged in or not, it you need to check that the session id in the cookie is a valid one in the database. I would suggest you instead write your app to either use SIP2 to authenticate, or the Koha ILS-DI implementation I hope this helps Chris -- Chris Cormack Catalyst IT Ltd. +64 4 803 2238 PO Box 11-053, Manners St, Wellington 6142, New Zealand -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From oleonard at myacpl.org Wed Aug 29 16:14:58 2012 From: oleonard at myacpl.org (Owen Leonard) Date: Wed, 29 Aug 2012 10:14:58 -0400 Subject: [Koha-devel] Coding guidelines for command-line scripts Message-ID: We have the beginnings of some coding guidelines for command-line scripts, but it doesn't look like they are firm: http://wiki.koha-community.org/wiki/Coding_Guidelines#Command-line_argument_conventions I was testing Bug 8674, "Need a delete biblios script" (http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8674), and was frustrated that there was no help option, but was unsure whether that should block the script from getting a signoff. Would everyone agree that new command-line scripts must accept "--help" (and include relevant help, of course) ? Should it also be the standard that command-line scripts should not perform any action unless an argument is passed? Anything else? -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org From mtompset at hotmail.com Wed Aug 29 16:40:47 2012 From: mtompset at hotmail.com (Mark Tompsett) Date: Wed, 29 Aug 2012 22:40:47 +0800 Subject: [Koha-devel] Coding guidelines for command-line scripts In-Reply-To: References: Message-ID: Greetings, > http://wiki.koha-community.org/wiki/Coding_Guidelines#Command-line_argument_conventions Good start, particularly the reference to the gnu link. > [snip] > Would everyone agree that new command-line scripts must accept > "--help" (and include relevant help, of course) ? I was thinking perhaps short versions might be considered passable too? So -h would suffice, though --help would be preferred. With GetLongOpts() > Should it also be the standard that command-line scripts should not > perform any action unless an argument is passed? Actually, this is what I like about the koha_perl_deps.pl script. No parameters gives the help, though this is definitely not a normally expected behaviour. +1 for required help parameter. I do like less typing, so I'm not so strict on --help vs. -h. http://www.gnu.org/prep/standards/standards.html#index-CGI-programs_002c-standard-options-for Yet, if this is the standard we want to stick with. I'm okay with it. GPML, Mark Tompsett From jcamins at cpbibliography.com Wed Aug 29 16:42:40 2012 From: jcamins at cpbibliography.com (Jared Camins-Esakov) Date: Wed, 29 Aug 2012 10:42:40 -0400 Subject: [Koha-devel] Coding guidelines for command-line scripts In-Reply-To: References: Message-ID: Owen, et. al., Would everyone agree that new command-line scripts must accept > "--help" (and include relevant help, of course) ? > +1 Should it also be the standard that command-line scripts should not > perform any action unless an argument is passed? > I like this idea. +1 too Regards, Jared -- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins at cpbibliography.com (web) http://www.cpbibliography.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cnighswonger at foundations.edu Wed Aug 29 16:56:32 2012 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Wed, 29 Aug 2012 10:56:32 -0400 Subject: [Koha-devel] Coding guidelines for command-line scripts In-Reply-To: References: Message-ID: Sorry, forgot the list... On Wed, Aug 29, 2012 at 10:14 AM, Owen Leonard wrote: > > Would everyone agree that new command-line scripts must accept > "--help" (and include relevant help, of course) ? > > +1 > Should it also be the standard that command-line scripts should not > perform any action unless an argument is passed? > +1 Kind Regards, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmc at esilibrary.com Wed Aug 29 17:01:40 2012 From: gmc at esilibrary.com (Galen Charlton) Date: Wed, 29 Aug 2012 11:01:40 -0400 Subject: [Koha-devel] Coding guidelines for command-line scripts In-Reply-To: References: Message-ID: <503E2ED4.4060606@esilibrary.com> Hi, On 08/29/2012 10:14 AM, Owen Leonard wrote: > Would everyone agree that new command-line scripts must accept > "--help" (and include relevant help, of course) ? +1 > Should it also be the standard that command-line scripts should not > perform any action unless an argument is passed? +1 > Anything else? Command-line scripts should return an exit code of 0 on success and not-0 on failure. Regards, Galen -- Galen Charlton Director of Support and Implementation Equinox Software, Inc. / The Open Source Experts email: gmc at 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 From mtompset at hotmail.com Wed Aug 29 17:15:44 2012 From: mtompset at hotmail.com (Mark Tompsett) Date: Wed, 29 Aug 2012 23:15:44 +0800 Subject: [Koha-devel] Coding guidelines for command-line scripts In-Reply-To: <503E2ED4.4060606@esilibrary.com> References: <503E2ED4.4060606@esilibrary.com> Message-ID: Greetings, > Command-line scripts should return an exit code of 0 on success and not-0 > on failure. This is generally the case and a good rule of thumb, which I support, but there may be cases of exceptions. GREP 0: Found 1: Not Found 2: Error If for some reason the script is grep-like in nature (I'm being hypothetical), then it should return like grep. Generally, scripts won't be, so: +1 for 0=success and not-0=failure. GPML, Mark Tompsett From danielg.koha at gmail.com Wed Aug 29 20:03:42 2012 From: danielg.koha at gmail.com (Daniel Grobani) Date: Wed, 29 Aug 2012 11:03:42 -0700 Subject: [Koha-devel] Official Koha Newsletter: Volume 3, Issue 8: August 2012 Message-ID: [Below is the text of the newsletter. For active links and a more readable format, please visit http://koha-community.org/koha-newsletter-volume-3-issue-8-august-2012] Official Koha Newsletter (ISSN 2153-8328) Volume 3, Issue 8: August 2012 Edited by Daniel Grobani, Koha Community Newsletter Editor. Please submit news items to danielg.koha at gmail.com. Table of Contents Koha Development Koha 3.8.4 Released Koha 3.6.8 Released Koha 3.10 Release Delayed Koha Statistics Release Manager?s Newsletter Koha Community New Koha Libraries Community Gossip Past Koha Events August General IRC Meeting Global Bug Squashing Day Upcoming Koha Events August General IRC Meeting PASIFIKA Koha workshop Help Make KohaCon13 a Success! Koha Development Koha 3.8.4 Released by Chris Cormack The Koha release team are proud to announce the release of Koha 3.8.4. This is a maintenance release and contains a lot of useful bug fixes. You can download the release here. Debian packages will be available here soon. Release notes are here. Koha 3.6.8 Released by Jared Camins-Esakov The Koha release team are proud to announce the release of Koha 3.6.8. This is a maintenance release and contains a lot of useful bug fixes. You can download the release here. Release notes are here. Koha 3.10 Release Delayed by Paul Poulain The official release of Koha 3.10.0 is delayed by one month. For Koha 3.4 and Koha 3.8, we faced some nasty bugs that were not detected before the release. We think the ?feature freeze? was too short to identify all potential problems. That?s why I have the following plan that delays the release by one month: 1. until 22 Sep: development 2. 22 Sep: feature freeze, no more large or core enhancements pushed for 3.10, whatever the patch submission date 3. 22 Oct: string freeze, no more string changes 4. 22 Nov: Koha 3.10.0 is released If you plan to upgrade your version immediately when the new one is released, please note that the release will be made on 22 November. I could release a 3.10.0RC1 (?Release Candidate?) on 22 October for early adopters. If you?re interested in such a RC1, let me know! Koha Statistics Chris Cormack, Koha Community statistics wizard, has posted statistics for Koha 3.8.4 and Koha 3.6.8, and signoff statistics for July. Chris also addressed on his blog how long it takes patches and enhancements to make it into master. Release Manager?s Newsletter Paul Poulain, Koha 3.8 & 3.10 Release Manager, publishes a monthly newsletter dedicated to Koha development. It can be found on the Koha Community website in the Koha News category. The latest issue is here. Koha Community New Koha Libraries Clatsop Community College (USA) (via ByWater Solutions) Indiana Supreme Court Law Library (USA) (via ByWater Solutions) French Cultural Center of Boston (USA) (via ByWater Solutions) Kenya Polytechnic University College Library (Kenya) LCC International University Library (Lithuania) (via ByWater Solutions) Palco and Lucas Public Libraries (USA) (via ByWater Solutions) Community Gossip Nancy Keener reports that the Systems staff at Washoe County Library System will be presenting a program on ?Migrating to Koha? at the Nevada Library Association conference in Las Vegas this October. They will also be doing a program on ?Do-it Yourself?, Self-Service Kiosks, and using Linux in the library. Nancy, whose library is hosting KohaCon13, also says, ?This same Nevada Library Association conference will be held in Reno next October at the same time and place as KohaCon13. It is our hope to get a better deal on rooms and meeting space by having the two separate conferences in the same location. It also will show Nevada libraries that the Koha community is a vibrant and innovative group.? Catalyst Academy students continue to contribute patches to Koha. Koha 3.8.0 had 15 patches from Academy students. Irma Birchall reports that a mailing list for Australian Koha users has been established. Rutgers MLS students will be using Koha in their ?Library Systems and Software? class this fall. Hosting is being donated by ByWater Solutions. The National Library of the Philippines and its use of Koha was featured in an article in the online Sun Star newspaper. Jesse Maseto posted a description of the stages a Koha bug moves through on the way to being fixed. Koha Kenya is an association of information managers, librarians and IT specialists fostering the diffusion of open source technology in libraries and Information Centers across Kenya. More info is here. Kathryn Tyree of Catalyst IT went from not having a git checkout of Koha to having her first patch pass QA in less than 90 minutes. Past Koha Events August General IRC Meeting The August general IRC meeting was held on 8 August 2012. More information, including the agenda and links to the minutes, is here. Global Bug Squashing Day by Magnus Enger Global bug squashing days are days designated to a concerted effort to get bugs and patches moving along in the right direction. A Global bug squashing day was held on Friday, 10 August 2012, and there was much rejoicing. More info is here. Upcoming Koha Events September General IRC Meeting The September general IRC meeting will be held on 5 September 2012 at 18:00 UTC. More information, including the agenda, will be available here. PASIFIKA Koha workshop Pacific libraries using or considering using Koha are invited to a free one-day PASIFIKA Koha workshop on Monday 10 September 2012 at the University of the South Pacific Laucala campus based in Suva, Fiji Islands. More info is here. Help Make KohaCon13 a Success! KohaCon13 will be held Reno, Nevada, USA, at a date to be determined. There will be three days of conference, one day of an activity, and three days of hackfest. Main and summary wiki pages have been created. Community members are encouraged to volunteer to help organize the conference. A volunteer IRC meeting has already been held. From chrisc at catalyst.net.nz Wed Aug 29 22:14:53 2012 From: chrisc at catalyst.net.nz (Chris Cormack) Date: Thu, 30 Aug 2012 08:14:53 +1200 Subject: [Koha-devel] Coding guidelines for command-line scripts In-Reply-To: <503E2ED4.4060606@esilibrary.com> References: <503E2ED4.4060606@esilibrary.com> Message-ID: <20120829201452.GM7186@rorohiko.wgtn.cat-it.co.nz> * Galen Charlton (gmc at esilibrary.com) wrote: > Hi, > > On 08/29/2012 10:14 AM, Owen Leonard wrote: > >Would everyone agree that new command-line scripts must accept > >"--help" (and include relevant help, of course) ? > +1 > > >Should it also be the standard that command-line scripts should not > >perform any action unless an argument is passed? > +1 > > >Anything else? > > Command-line scripts should return an exit code of 0 on success and > not-0 on failure. > +1 Chris -- Chris Cormack Catalyst IT Ltd. +64 4 803 2238 PO Box 11-053, Manners St, Wellington 6142, New Zealand From mtj at kohaaloha.com Thu Aug 30 01:58:49 2012 From: mtj at kohaaloha.com (Mason James) Date: Thu, 30 Aug 2012 11:58:49 +1200 Subject: [Koha-devel] Coding guidelines for command-line scripts In-Reply-To: <20120829201452.GM7186@rorohiko.wgtn.cat-it.co.nz> References: <503E2ED4.4060606@esilibrary.com> <20120829201452.GM7186@rorohiko.wgtn.cat-it.co.nz> Message-ID: On 2012-08-30, at 8:14 AM, Chris Cormack wrote: > * Galen Charlton (gmc at esilibrary.com) wrote: >> Hi, >> >> On 08/29/2012 10:14 AM, Owen Leonard wrote: >>> Would everyone agree that new command-line scripts must accept >>> "--help" (and include relevant help, of course) ? >> > > +1 > >> >>> Should it also be the standard that command-line scripts should not >>> perform any action unless an argument is passed? >> > > +1 > >> >>> Anything else? >> >> Command-line scripts should return an exit code of 0 on success and >> not-0 on failure. >> > +1 i'll have a go at writing a test for it :) From robin at catalyst.net.nz Thu Aug 30 12:39:53 2012 From: robin at catalyst.net.nz (Robin Sheat) Date: Thu, 30 Aug 2012 12:39:53 +0200 Subject: [Koha-devel] Coding guidelines for command-line scripts In-Reply-To: References: Message-ID: <503F42F9.8090406@catalyst.net.nz> Op 29-08-12 16:14, Owen Leonard schreef: > Would everyone agree that new command-line scripts must accept > "--help" (and include relevant help, of course) ? It also should say what it does. Stuff like: $ mcomp --help usage: /usr/bin/mcomp dosfile [cmpoptions] unixfile is bad. > Should it also be the standard that command-line scripts should not > perform any action unless an argument is passed? Probably in general, if it's something that's not reversible, yeah. -- Robin Sheat Catalyst IT Ltd. ? +64 4 803 2204 GPG: 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D From jonathan.druart at biblibre.com Thu Aug 30 14:55:46 2012 From: jonathan.druart at biblibre.com (Jonathan Druart) Date: Thu, 30 Aug 2012 14:55:46 +0200 Subject: [Koha-devel] Syspref format (995$x=foo) Message-ID: Hi all, As a result of a QA comment from Marcel (see Bug 8307), I come back to you. I introduce a syspref which can be filled with the form: xxx$y=v where xxx is a field, y a subfield and v a value. Does that make sense for you ? Does someone have a better suggestion ? Thank you for your attention. Regards, Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: From fridolyn.somers at biblibre.com Thu Aug 30 16:50:01 2012 From: fridolyn.somers at biblibre.com (Fridolyn SOMERS) Date: Thu, 30 Aug 2012 16:50:01 +0200 Subject: [Koha-devel] Syspref format (995$x=foo) In-Reply-To: References: Message-ID: <503F7D99.7050004@biblibre.com> If it is only for item status, why not setting only the value and using mapping of 'items.notforloan' to find field and subfield? -- Fridolyn SOMERS Biblibre - P?le Support fridolyn.somers at biblibre.com Le 30/08/2012 14:55, Jonathan Druart a ?crit : > Hi all, > > As a result of a QA comment from Marcel (see Bug 8307), I come back to > you. > > I introduce a syspref which can be filled with the form: xxx$y=v where > xxx is a field, y a subfield and v a value. > > Does that make sense for you ? Does someone have a better suggestion ? > > Thank you for your attention. > > Regards, > Jonathan > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ -------------- section suivante -------------- Une pi?ce jointe HTML a ?t? nettoy?e... URL: From gmc at esilibrary.com Thu Aug 30 18:18:01 2012 From: gmc at esilibrary.com (Galen Charlton) Date: Thu, 30 Aug 2012 12:18:01 -0400 Subject: [Koha-devel] Syspref format (995$x=foo) In-Reply-To: <503F7D99.7050004@biblibre.com> References: <503F7D99.7050004@biblibre.com> Message-ID: <503F9239.9030505@esilibrary.com> Hi, On 08/30/2012 10:50 AM, Fridolyn SOMERS wrote: > If it is only for item status, why not setting only the value and using > mapping of 'items.notforloan' to find field and subfield? I agree with Fridolyn -- since the intent of the enhancement appears to be providing a way to specify item field values, I would prefer that the syspref accept item column names rather than a subfield derived from the MARC mapping. Doing this would also simplify the change required in finishreceive.pl. Also, the syspref name 'AcqItemStatusWhenReceived' is very specific; if that's *all* it is supposed to do, why not simply have it take the desired status value. If it's meant to be able to set default values for other item fields, I think the syspref should be renamed to something a little more general. Regards, Galen -- Galen Charlton Director of Support and Implementation Equinox Software, Inc. / The Open Source Experts email: gmc at 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