- Koha-devel - lists.koha-community.org

Koha 3.12.00 release candidate 1 now out!
by Jared Camins-Esakov 15 May '13

15 May '13

Good morning! The release of 3.12.00 is swiftly approaching, but that doesn't mean you have to wait another week before trying it out! I have uploaded a tarball and .deb package for Koha 3.12.00-RC1 to download.koha-community.org. Please take it for a spin, see what works, what doesn't, and why this release will be talked about for decades to come! Regards, Jared Camins-Esakov -- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins(a)cpbibliography.com (web) http://www.cpbibliography.com/

1 0

Old bugs to check
by MJ Ray 14 May '13

14 May '13

Would you check some of these rather old bugs to suggest what to do, please? Maybe some can be RESOLVED FIXED by now or need a question. Please leave your reply on the bug web page - I might not see replies to this mail. Ideally, tell irc.oftc.net #koha know that you're looking at a bug. http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5144 Duplicate holds allowed if patron clicks back button after placing hold http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3343 duplicate subfields in authority http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6329 patron categories should show which fields are required http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5317 transfer messages inconsistent http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4034 Checking out an item on hold for that patron (but not waiting) results in incorrect message http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4363 Support the patron internet resources field in Sip2 http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5541 links show title twice if 856$y and 856$3 populated http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=1985 Email notification of new OPAC comments http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5800 Hold Policy "home library only" incompatible with CircControl "patron home library" http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5323 koha package should install a setup that works with koha-common http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5428 Back to results after deleting a record http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6382 Automatic Status Changing on Check In http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3460 Hold options inconsistent for "Damaged" items http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5414 staged import dies silently if MARC::Record chokes on a too-large MARC record http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5985 Incorrect date in budgets and failed to edit funds children http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5439 3M RFID sensitization http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6359 number one printing on quick label page http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2442 add babelfish links to the bug display page header or footer http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6173 Cronjob to send account expiry notices -- Email robot driven by MJ Ray (slef), member of www.software.coop, http://koha-community.org supporter, web and library systems developer. Available for hire (including development) at http://www.software.coop/

1 0

Re: [Koha-devel] [Koha] How to update two koha databases in different servers.
by Waylon Robertson 12 May '13

12 May '13

Yes, easiest method, doing realtime updates, is mysql replication. Now, theres two methods of doing this, first is using mysql's own replication method, and second is using MySQL::Replication as found on cpan. Brilliant perl based replication system. ________________________________ From: otuoma peter <otuomathegreat(a)yahoo.com> To: "koha(a)lists.katipo.co.nz" <koha(a)lists.katipo.co.nz> Sent: Saturday, 11 May 2013 10:57 PM Subject: [Koha] How to update two koha databases in different servers. I have two koha installations. One on a production server and another on a standby back-up server. Is there a way I can have all the changes made to the database on the production server also updated to the standby back-up server? I am thinking of doing it using an entry in a cronjob file that runs once everyday at night. If possible, I only need to import the updates. Thanks in advance. _______________________________________________ Koha mailing list http://koha-community.org Koha(a)lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha

2 1

Call for news for the May newsletter
by Daniel Grobani 10 May '13

10 May '13

Dear Koha kommunitarians, I'm harvesting news for this month's newsletter. Please send me by the 20th 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

1 0

Re: [Koha-devel] Major surprise - "automatic" upgrade
by Paul 08 May '13

08 May '13

At 11:40 AM 5/7/2013 +0000, Marcel de Rooy wrote: > > To reproduce upgrade, restore db; sftp [...] koha-3.08.05.tar.gz and > > koha-3.08.10.tar.gz /home/paul; "untar" koha-3.08.10.tar.gz in /home/paul/; > > cp koha-3.08.10.tar.gz to / > >Hey: untar 3.8.10 and copy 3.8.10 to root ?? > > > koha@hardy:/$ ls -l / > > drwxrwxr-x 42 koha koha 4096 Feb 23 05:09 koha-3.08.10 > >Paul: If I read well what you are doing here, you are restoring your >database to 3.8.5 and your code to 3.8.10 !! Marcel - thanks for your comments. The 3.8.10 "code" is the installation tarball -- not a /usr/share/koha functional system. >The 3.8.10 script cleanup_database does not complain about that; it does >not really care about the exact version. There is/was no 3.8.10 script cleanup_database in the tarball. I used /usr/share/koha/bin/cronjobs/cleanup_database.pl in the fully working 3.8.5. Surely this script (no diff, btw, between 3.8.5 and 3.8.10) is created from the tarball during install/upgrade. >It gets a db handle. It runs. >But if you go to OPAC or staff, of course Koha will complain. The newer >code sees the older database.. > >Mystery solved? Respectfully, no. Where did the "newer code" come from without running Makefile.pl, make, make install as a "sudoer"? I was simply running cleanup_database.pl as user=koha without sudo privileges. Again thanks for your interest and best regards, Paul

2 2

a suggestion for signing-off patches?
by Mason James 08 May '13

08 May '13

hi All when signing off patches, could we agree to make it compulsory for people to add a quick comment to either the bug ticket, (or to the patch itself)? it just needs to be a few words, like 'works great!', or 'tested ok', etc... what do people think? http://wiki.koha-community.org/wiki/Sign_off_on_patches#Sign-off

3 5

Re: [Koha-devel] Major surprise - "automatic" upgrade
by Paul 08 May '13

08 May '13

At 07:22 AM 5/8/2013 +1200, Chris Cormack wrote: [snip] > > No - it gets overwritten (new file dated as per the tarball.) > > > > That's exactly the problem ..., but further it would have had to run > > 'Makefile.PL --prev-install-log /path/to/koha-install-log' > > > >No, as you wrote above, you replaced your 3.8.5 code with 3.8.10. > >Then you ran the webinstaller to upgrade the database. Chris, thanks. Please bear with me and see if I properly understand: a) I started with a brand new Ubuntu 12.04 server, put an untarred /koha-3.08.05 and ran as a "sudoer" (user=paul) Makefile.PL, make, make test and make install. This installed a fully working Koha 3.8.5 system at /usr/share/koha (plus various other bits and pieces.) b) I deleted /koha-3.08.05. Koha (3.8.5 with our cusomizations at /usr/share/koha, etc) continued for all my "playing in the sandbox" activities for about six months, including testing everything I ever do on the production 3.8.5 c) at some point (late February 2013), I untarred /koha-3.08.10 and promptly forgot that I had done this. In any case, I never got around to playing with 3.8.10 (I would have noticed the upgrade instantly, as some of our "customizations" disappear!) d) Last week, as user=koha (not a sudoer), I ran from the 3.8.5 /usr/share/koha: koha@hardy:/usr/share/koha/bin/cronjobs$ ./cleanup_database.pl --zebraqueue -v Zebraqueue purge triggered for 30 days 131575 records were deleted. Done with zebraqueue purge. and ended up with a 3.8.10 /usr/share/koha system. OPAC reported "closed for maintenance" and the browser staff page prompted me (logging in as "koha", it refused "paul") for the *db* update: Web installer Step 3 Updating database structure Update report : Upgrade to 3.08.06.000 (3.8.6 release) done Upgrade to 3.08.07.000 (3.8.7 release) done Upgrade to 3.08.08.000 (3.8.8 release) done Upgrade to 3.08.09.000 (3.8.9 release) done Upgrade to 3.08.10.000 (3.8.9 release) done Everything went OK, update done. Continue to log in to Koha >All of this has absolutely nothing to do with the clean up script, its >all to do with you replacing the 3.8.5 code with 3.8.10, ie upgrading >it. The make upgrade would do that copy, but you did it yourself. So, if I understand correctly, the "Web installer, step 3, Updating database structure" somehow has permission to run /koha-3.08.10/Makefile.PL, make, 'make upgrade'. OK, I agree that the 3.8.10 tarball installation code was available to "koha", I'm just at a loss to understand how "koha" got around permissions (certainly the koha name/password is in plain text in koha-conf.xml, but that name/pw is not in the sudoer|admin group.) This *should* have required *sudo* permissions -- else, e.g. command line as user=koha, it fails: koha@hardy:/koha-3.08.10$ perl Makefile.PL --prev-install-log /usr/share/koha/misc/koha-install-log / ... / Writing Makefile for koha Writing MYMETA.yml Unable to open MYMETA.yml: Permission denied at /usr/share/perl/5.14/ExtUtils/MM_Any.pm line 1170. koha@hardy:/koha-3.08.10$ And also -- the "Web Installer Updating database structure" was so fast, I really don't see how it could have copied hundreds of files to /usr/share/koha, even if it had prepared for everything in the background (the cleanup_database.pl took at least an hour.) Finally, nothing seems to have been recorded in any logs (koha or system.) I must be missing something major, and truly appreciate your assistance. Best regards - Paul > > > >> This doesn't seem like a thing that anything in Koha would do. In > >> a quick test, I couldn't make it happen. > > > > > > And I had never seen it before ... > > >And you never will again, unless you go around replacing a version of >the code with a newer version of the code. > >Chris

1 0

Re: [Koha-devel] Major surprise - "automatic" upgrade
by Paul 07 May '13

07 May '13

At 05:40 PM 5/7/2013 +1200, Chris Cormack wrote: >* Robin Sheat (robin(a)catalyst.net.nz) wrote: > > Robin Sheat schreef op di 07-05-2013 om 17:13 [+1200]: > > > So, it deletes the same records twice? That seems a bit fishy. > > > > Oh, I overlooked where you said you restored the DB. Ignore this bit. > > > > One important thing is that you never look at the version the very > > moment _before_ you run cleanup_database.pl so we really have no > > reference to come from. > > >Also we can see it hasn't updated the database, because it would not be in >maintenance mode if it had. That is not updated until you log into the >webinstaller and upgrade the db. Thanks Chris - agreed (although there is apparently no MySQL differences between 3.8.5 and 3.8.10 - despite the browser running through five steps before either admin or OPAC are functional.) >All that has happened is you have the koha-conf.xml and the the apache2 >config pointing to your 3.8.10 code. Again agreed -- but the 3.8.10 code is in exactly the same place as the 3.8.5, so no difference in the "pointers." >Like I previously said this can only happen if you untarred over top of >your old directory or you run make upgrade. /koha-3.08.05 had been moved to backup. /koha-3.08.10 was there. But the bigger problem is that I did not *knowingly* upgrade, AND I ran cleanup_database.pl as user=koha who is not a sudoer (required for make, make upgrade.) Certainly no password was requested. >So there is a lot more diagnostics we need to see exactly what you >have done. Including seeing which koha-conf.xml you have set before >you run the cleanup script and what directory that file points to. paul@hardy:/$ diff -s /etc/koha/koha-conf.xml /home/paul/koha-conf.xml_3.8.5 Files /etc/koha/koha-conf.xml and /home/paul/koha-conf.xml_3.8.5 are identical Relevant part (consistent with apache, no changes over v. 5 ==> 10):    <config> <db_scheme>mysql</db_scheme> <database>koha384</database> <hostname>localhost</hostname> <port>3306</port> <user>koha</user> <pass>************</pass> <biblioserver>biblios</biblioserver> <biblioservershadow>1</biblioservershadow> <authorityserver>authorities</authorityserver> <authorityservershadow>1</authorityservershadow> <intranetdir>/usr/share/koha/intranet/cgi-bin</intranetdir> <opacdir>/usr/share/koha/opac/cgi-bin/opac</opacdir> <opachtdocs>/usr/share/koha/opac/htdocs/opac-tmpl</opachtdocs> <intrahtdocs>/usr/share/koha/intranet/htdocs/intranet-tmpl</intrahtdocs> <includes>/usr/share/koha/intranet/htdocs/intranet-tmpl/prog/en/includes/</includes> <logdir>/var/log/koha</logdir> <pazpar2url>http://hardy:11002/search.pz2</pazpar2url> <install_log>/usr/share/koha/misc/koha-install-log</install_log> <useldapserver>0</useldapserver> <zebra_bib_index_mode>dom</zebra_bib_index_mode> <zebra_auth_index_mode>dom</zebra_auth_index_mode> </config> </yazgfs> Best - Paul _______________________________________________ Koha-devel mailing list Koha-devel(a)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. <http://NavalMarineArchive.com> and <http://UltraMarine.ca>

2 2

Re: [Koha-devel] Major surprise - "automatic" upgrade
by Paul 07 May '13

07 May '13

At 06:41 PM 4/30/2013 -0400, Ian Walls wrote: [snip] >This is definitely a confusing situation, and I'm sorry it's cause you >alarm.Â Hopefully with more information we can get to the bottom of >exactly how it's happening, understand it, and prevent it from happening >to you (and anyone else) again. Thanks to all for your patience, summary of my "reproducible upgrade" is that under some | [perhaps] exceptional conditions 'cleanup_database.pl' does upgrade the Koha version. Under what might be called "normal" conditions, absolutely everything is as expected with no problems. You'll see from the notes below, that having a *koha owned* koha-3.08.10 at / prompts a version upgrade [the *Important Note* below.] There is no "verbosity" using -v with './cleanup_database.pl' Best - Paul Update 6 May: Logged in as user=koha, no tarred|untarred Koha installation files on this box koha@hardy:/$ cat /usr/share/koha/misc/koha-install-log | grep KOHA_INSTALLED_VERSION KOHA_INSTALLED_VERSION=3.08.05.000 koha@hardy:/usr/share/koha/bin/cronjobs$ ./cleanup_database.pl --zebraqueue 1 -v Zebraqueue purge triggered for 1 days. 19847 records were deleted. Done with zebraqueue purge. cat /usr/share/koha/misc/koha-install-log | grep KOHA_INSTALLED_VERSION KOHA_INSTALLED_VERSION=3.08.05.000 So far, so good; OPAC and staff-admin both functional. To reproduce upgrade, restore db; sftp [...] koha-3.08.05.tar.gz and koha-3.08.10.tar.gz /home/paul; "untar" koha-3.08.10.tar.gz in /home/paul/; cp koha-3.08.10.tar.gz to / koha@hardy:/$ ls -l /home/paul /.../ -rwxrw-r-- 1 paul paul 48446365 Sep 22 2012 koha-3.08.05.tar.gz -rwxrw-r-- 1 paul paul 50084604 Mar 2 19:34 koha-3.08.10.tar.gz drwxrwxr-x 42 paul paul 4096 Feb 23 05:09 koha-3.08.10 koha@hardy:/$ ls -l / / ... / -rw-r--r-- 1 koha koha 50084604 May 6 18:26 koha-3.08.10.tar.gz drwxrwxr-x 42 koha koha 4096 Feb 23 05:09 koha-3.08.10 [Important Note: if chown is either "me" or root, the following version upgrade does not happen.] koha@hardy:/usr/share/koha/bin/cronjobs$ ./cleanup_database.pl --zebraqueue 1 -v Zebraqueue purge triggered for 1 days. 19847 records were deleted. Done with zebraqueue purge. cat /usr/share/koha/misc/koha-install-log | grep KOHA_INSTALLED_VERSION KOHA_INSTALLED_VERSION=3.08.10.000 ... and OPAC announces under "maintenance". Trying to staff-admin: Web installer Step 3 We are upgrading from Koha 3.08.05.000 to 3.08.10.000, you must update your database Web installer Step 3 Updating database structure Update report : Upgrade to 3.08.06.000 (3.8.6 release) done Upgrade to 3.08.07.000 (3.8.7 release) done Upgrade to 3.08.08.000 (3.8.8 release) done Upgrade to 3.08.09.000 (3.8.9 release) done Upgrade to 3.08.10.000 (3.8.9 release) done Everything went OK, update done. Continue to log in to Koha _______________________________________________ Koha-devel mailing list Koha-devel(a)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. <http://NavalMarineArchive.com> and <http://UltraMarine.ca>

6 8

Re: [Koha-devel] Koha-devel Digest, Vol 90, Issue 19
by Vimal Kumar V. 07 May '13

07 May '13

Dear Indra, The benchmark is 1. Languages have majority of users 2. Completion of translation Regrads, On Tue, May 7, 2013 at 3:30 PM, <koha-devel-request(a)lists.koha-community.org > wrote: > Send Koha-devel mailing list submissions to > koha-devel(a)lists.koha-community.org > > To subscribe or unsubscribe via the World Wide Web, visit > > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > or, via email, send a message with subject or body 'help' to > koha-devel-request(a)lists.koha-community.org > > You can reach the person managing the list at > koha-devel-owner(a)lists.koha-community.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Koha-devel digest..." > > > Today's Topics: > > 1. Re: Major surprise - "automatic" upgrade (Chris Cormack) > 2. Please select 5 popular languages for inclusion in Koha Live > DVD (Vimal Kumar) > 3. Re: Please select 5 popular languages for inclusion in Koha > Live DVD (Indranil Das Gupta) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 7 May 2013 17:40:12 +1200 > From: Chris Cormack <chrisc(a)catalyst.net.nz> > To: Robin Sheat <robin(a)catalyst.net.nz> > Cc: koha-devel(a)lists.koha-community.org > Subject: Re: [Koha-devel] Major surprise - "automatic" upgrade > Message-ID: <20130507054012.GD19162(a)rorohiko.wgtn.cat-it.co.nz> > Content-Type: text/plain; charset="us-ascii" > > * Robin Sheat (robin(a)catalyst.net.nz) wrote: > > Robin Sheat schreef op di 07-05-2013 om 17:13 [+1200]: > > > So, it deletes the same records twice? That seems a bit fishy. > > > > Oh, I overlooked where you said you restored the DB. Ignore this bit. > > > > One important thing is that you never look at the version the very > > moment _before_ you run cleanup_database.pl so we really have no > > reference to come from. > > > Also we can see it hasn't updated the database, because it would not > be in maintenance mode if it had. > > That is not updated until you log into the webinstaller and upgrade > the db. > All that has happened is you have the koha-conf.xml and the the > apache2 config pointing to your 3.8.10 code. > > Like I previously said this can only happen if you untarred over top > of your old directory or you run make upgrade. > > So there is a lot more diagnostics we need to see exactly what you > have done. Including seeing which koha-conf.xml you have set before > you run the cleanup script and what directory that file points to. > > Chris > > -- > Chris Cormack > Catalyst IT Ltd. > +64 4 803 2238 > PO Box 11-053, Manners St, Wellington 6142, New Zealand >

1 0