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

Re: [Koha-devel] Cataloguing authorities 3.6/3.8
by Paul 28 Sep '12

28 Sep '12

At 06:19 PM 9/26/2012 -0300, Tomas Cohen Arazi wrote: >Paul, count on me To solve those issues in time. >How do you deploy Koha on your server? >Regards >To+ [snip] Tomas -- many, many thanks (I'm just back from 2 days conferencing); we have as a precautionary measure stopped our cataloguers from using Koha. I use tarballs (specifically koha-3.08.04.tar.gz, 48,836,564 bytes, dated 21 August 2012) on Ubuntu 12.04.01 LTS installed from ISO, update, upgrade, clean, mysql, apache2, etc. Koha dependencies using apt-get only (no cspan), make test (no errors), make install, restore the db (from Koha 3.6.1), wait for the staff-client to do its magic and get from 'About Koha' in production: Koha version: 3.08.04.000 OS version ('uname -a'): Linux nelson 3.2.0-31-generic #50-Ubuntu SMP Sun Sep 16 03:16:45 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 Customization (probably irrelevant) limited to CSS, images and one template (search tab order) and perl mods to barcodes and control numbers (proven on 3.6.1, fully functional on 3.8.4, designed for serial continuity with other of our internal systems -- if you want the details, I can supply, but nothing touches the logic flow of Koha.) Current problems: a) "Authority" searches (all variations including "author", "subject", with far reaching implications) is not functional. I believe that this is a known bug (8071) which refers to 4 files. I have tried on our sandbox a straight replacement of these four with no changes, and am currently totally rebuilding it from scratch for further testing. b) Re-indexing (zebra incremental) has become weird/problematic: the cron runs, but does nothing for NEW records; it does update MODIFICATIONS to the 3.6.1 db entries. Replicating it manually as user 'koha' requires inserting 'perl' for the instruction to work (i.e koha@nelson:/usr/share/koha/bin/migration_tools$ perl rebuild_zebra.pl -b -v -x ) but gives strange results: Records exported: 17765 ==================== REINDEXING zebra ==================== 15:38:46-28/09 zebraidx(5988) [warn] Missing attribute 'type' in attribute info 15:38:46-28/09 zebraidx(5988) [warn] Unknown register type: ==================== CLEANING ==================== 17765 is the number of records in the 3.6.1 "imported" db. Since then we have added records up to biblionumber:18099 which get indexed (despite the message above) but *only* with the manual "perl" instruction. Cron doesn't touch them. I cannot get rebuild_zebra to report 18099 (even as root), but it indexes them anyway. And the authorities are always at "zero" whatever I do. Is the user-list Barry Cannon email (Wed, 26 Sep 2012 15:25:21 +0100) relevant? He seems to be having the same problem (upgrade to 3.8) and saying something about DOM v. grs1 (I have no clue what he's referring to.) Gory details: koha@nelson:/$ printenv | grep koha PERL5LIB=/usr/share/koha/lib USER=koha MAIL=/var/mail/koha KOHAPATH=/usr/share/koha KOHA_CONF=/etc/koha/koha-conf.xml HOME=/home/koha LOGNAME=koha koha@nelson:/$ crontab -l KOHA_CONF=/etc/koha/koha-conf.xml KOHAPATH=/usr/share/koha PERL5LIB=$KOHAPATH/lib */1 * * * * koha $KOHA_PATH/bin/migration_tools/rebuild_zebra.pl -b -a -z &> /dev/null paul@nelson:/var/log$ sudo cat syslog | grep CRON Sep 28 15:41:01 nelson CRON[5277]: (koha) CMD (koha $KOHA_PATH/bin/migration_tools/rebuild_zebra.pl -b -a -z &> /dev/null) On staff-client after entering new biblio ==> "Items for Arctic fever : (Record #18099)" OPAC (and staff-client) search 'biblionumber:18099' ==> No results found! koha@nelson:/usr/share/koha$ rebuild_zebra.pl -b -a -z rebuild_zebra.pl: command not found koha@nelson:/usr/share/koha$ cd bin/migration_tools koha@nelson:/usr/share/koha/bin/migration_tools$ rebuild_zebra.pl -b -a -z rebuild_zebra.pl: command not found koha@nelson:/usr/share/koha/bin/migration_tools$ perl rebuild_zebra.pl -b -a -z ^^^^ 14:53:18-28/09 zebraidx(5514) [warn] Missing attribute 'type' in attribute info 14:53:19-28/09 zebraidx(5514) [warn] Unknown register type: NOW ... OPAC and staff client find 'biblionumber:18099' and 'Arctic fever : , the search for the Northwest Passage /' BUT ... in 'authority search' ==> Wilkinson, Douglas Details 0 biblio(s) Delete yet we have six books by this author. What are "Missing attribute 'type'" and "Unknown register type"? What were the changes in sql data structure from 3.6 to 3.8? Can I save our cataloguers' work and 'back-import' into 3.6.1? As I said, I'm rebuilding the sandbox *identically* to the production server. What would you suggest as tests leading to the cleanest repair of our production box? Many tnx - paul >El sep 26, 2012 4:43 p.m., "Paul" ><<mailto:paul.a@aandc.org>paul.a(a)aandc.org> escribiÃ³: >Mark, > >I truly appreciate you reply. I don't top post, so plz see below > >At 12:42 AM 9/27/2012 +0800, Mark Tompsett wrote: >Greetings, > >Anyway, I'm about to start a complete new install (o/s + 3.8.4) on the >sandbox to test how I can "fix" the production server > > >This would be a great opportunity to do a packages or git installation. >You only have to get the data from the live machine: >$ Â mysqldump -u {the user name} -p {the koha database name} > PleaseTryIt.sql > > >I back up every day at 3.00am, and can do a "specific" without problem. > >And transfer the data into the instance database, or git database before >doing the web install. >A git install is similar to a tarball install (you still get to name your >database whatever you'd like, and still have those nasty long building >sequences), and if you search bugzilla for patches, you can see if your >problem has already been fixed with a patch that someone else provided. > > >Maybe our library is unique? Â We like to have functional IT, never touch >it (security concerns excepted), and review every couple of years. We >started Koha in 2011 (3.4.x?) and settled with 3.6.1 as soon as it came >out. We had a fully functional, adapted to our requirements, system. I >made the decision to "upgrade" to 3.8.[4 at the time] because we were in >our two year cycle to upgrade four servers and 29 workstations from Ubuntu >10.04 LTS to 12.04 LTS. > >I am now under serious pressure from our Board for my "incompetence" in >breaking a system that met our charity's needs. > >While I am *personally* fully prepared to try and be part of a community >developing a great system, this cannot spill over into my $dayjob keeping >a charity's databases of more than 650,000 items "up and running." > >I am currently PO'd at myself for not doing enough QA -- and this denotes >no disrespect for all the people involved with QA within the Koha >community, although I have to admit I was a bit surprised by someone >mentioning that all versions of 3.8 have this glitch concerning indexing >authorities. We use open licence/GPL Ubuntu, OpenOffice, Apache, Sendmail, >Mysql, perl, php, various java, etc, and while they all have their ups and >downs I don't remember a "sort of step backwards" like this. > >If it is, then you can apply the patch on the live system (after testing >on your sandbox) -- without you having to figure out how to do it yourself. > > >Sorry -- I'm responsible and need to "figure out how to do it." Â Not >necessarily down the last detail, but at least enough to feel comfortable >and responsible with what I'm doing. I'm not fully up to date with all >coding today, but after more than half a century involvement in IT I can >certainly "understand it" even if I can't "write it." > >BTW, more problems were fixed in 3.8.5, and a packages installation on >your sandbox would be good practice for doing an upgrade from tarball to >packages in live. Upgrades become so much easier, and the down time is >mostly reindexing. > > >Again, sorry, but I'm not looking for practice. I'm under severe pressure >to *fix* Koha. My boss doesn't understand "sandboxes" -- she listens to >cataloguers' complaints, hears that our coordination with other >institutions is broken, and yells at me. > >Just trying to suggest something to save you headaches in the future, like >the one you are having now because you said you wanted the headaches and >didn't want to try the suggestion before. > > >Mark - I truly appreciate and understand your pov. Â Over the last 18 >months Koha has been good to us, and I would like this to continue. I >developed a number of "customizations", a few purely cosmetic, but mostly >rewriting control number and barcode perl scripts to coordinate with half >a million other "items" that we hold in other databases, and to coordinate >our "authorities" (and biblios) with other Canadian national institutions >... it *was* working before 3.8 ... and all I need to do is get back on track. > >If I have to back track to 3.6.1, I don't know how to convert 3.8 >biblio/items back to 3.6 and I'll "be responsible" for telling the >cataloguers to redo [currently] about 600 entries, increasing by about 80 >every day. Â I'm getting a tad desperate to avoid this. > >Thanks for your help, time and consideration. > >Best regards >Paul > >_______________________________________________ >Koha-devel mailing list ><mailto:Koha-devel@lists.koha-community.org>Koha-devel(a)lists.koha-community.org >http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >website : <http://www.koha-community.org/>http://www.koha-community.org/ >git : <http://git.koha-community.org/>http://git.koha-community.org/ >bugs : <http://bugs.koha-community.org/>http://bugs.koha-community.org/

1 0

Signed off patches to the patches list?
by Magnus Enger 26 Sep '12

26 Sep '12

Hi! http://wiki.koha-community.org/wiki/Git_bz_configuration still says "It is still considered good practice to send the signed off patch to the patches mailing list", but it seems that few folks do it and using git bz seems to have made this practice obsolete. Any objections to deleting this line and the command that accomplishes it? Best regards, Magnus libriotech.no

9 16

Re: [Koha-devel] Cataloguing authorities 3.6/3.8
by Paul 26 Sep '12

26 Sep '12

At 09:04 PM 9/24/2012 -0300, Tomas Cohen Arazi wrote: >On Mon, Sep 24, 2012 at 8:11 PM, Jared Camins-Esakov ><jcamins(a)cpbibliography.com> wrote: >However, there was a bug in Koha 3.8.1-3.8.4 > > that made the links not show up in searches. I believe it has been fixed in > > 3.8.5. I do not have a bug number off the top of my head. > >8071? I realize that I will be told "this is not the way to do it", but ... Bug 8071 has "4 files changed". The 3.8.5 tarball has /authorities/blinddetail-biblio-search.pl /C4/AuthoritiesMarc.pm /C4/Biblio.pm but I can't find .../authorities/blinddetail-biblio-search.tt -- is this generated? or where can I find it? It exists on my sandbox and production as /usr/share/koha/intranet/intranet-tmpl/prog/en/modules/authorities/blinddetail-biblio-search.tt -- the lines correspond (more or less) to the "attachment" for the bug, but I cannot follow the edit: what does @@ -13,24 +13,6 @@ mean? I can rem out lines 13-24 (actually 17-33 in my 3.8.4 according to the "-" lines that Fridolyn SOMERS wrote), but what is +13,6? I don't see an obvious "+". I need to get our production server running after proof of concept on the sandbox. Can someone please tell me where to find a "modded bug 8071" copy of blinddetail-biblio-search.tt? At the moment, our cataloguers have put about 450 biblios into our production database since we upgraded to 3.8.4 on 14 September - either I can get 3.8.4 past this glitch, or I can restore 3.6.1 on the production server and tell our cataloguers to start over ... Again, I realize that I will be told "this is not the way to do it", but I tried installing|upgrading 3.8.5 over the top of 3.8.4 (on the sandbox, using 'perl Makefile.PL --prev-install-log /usr/share/koha/misc/koha-install-log') and ended up with a bigger muddle (only in part attributable to our customization, but my customization scripts were written for 3.8.4, so I would have to start over) so need to try just replacing the 4 files (sandbox restored from backup to 3.8.4 - now working pre-bug8071 again.) Thanks for your understanding. Paul

4 10

yuipath
by Marcel de Rooy 26 Sep '12

26 Sep '12

Hi, Did a git fetch right now. Current master seems to have a broken opac display when pointing yuipath to Yahoo. Setting it back to local resolves the display. Do you see it too? Since some yui files were removed or moved around, you may know what happened and/or is needed? Thanks, Marcel

3 4

Re: [Koha-devel] combining and minification of javascript and css
by Paul 26 Sep '12

26 Sep '12

At 08:36 PM 4/7/2012 -0400, Chris Nighswonger wrote: >On Sat, Apr 7, 2012 at 6:02 PM, Dobrica Pavlinusic <dpavlin(a)rot13.org> wrote: >I would like to address this one as part of performance work. >[snip] >Minification alone doesn't buy us much: > >OPAC search: >minify js 334974 -> 311553 93.01% >minify css 148277 -> 133128 89.78% > >intranet search: >minify js 382102 -> 362172 94.78% >minify css 134754 -> 123771 91.85% > >But combining JS and CSS files together saves us round-trips to server: > >OPAC 32 -> 20 requests >intranet 27 -> 13 requests Has anyone tried using "page speed v1.12" (the google add-on to bugzilla) which although designed for chrome will work with firefox? Google seem to be quite keen on the 'minify' principle (see <http://code.google.com/p/minify/>.) It has started pushing me towards looking at various combinations of 'minify' (in itself not a great saver, as stated above, as it seems just to remove white space and comments then unify logic on a single line basis), 'combination' (which might have limits with the variety of somewhat older browsers) and x-cache which has advantages, but only in a stable environment -- try changing a favicon ;={ First thoughts from my end seem to point towards combining (css files separately from js at this point in time) into what's needed to display the page ("instant gui gratification") and what can be slightly delayed ("page functions") and getting the download server==>client in the correct order. Best - Paul

3 2

Debian Squeeze packages and CPAN for master
by Zeno Tajoli 26 Sep '12

26 Sep '12

Hi to all I'm testing a patch and so I have installed the master version from git (ver.3.09.00.057). After the commands sudo dpkg --set-selections < install_misc/debian.packages sudo apt-get dselect-upgrade the command "perl koha_perl_deps.pl -m -u" gives me a list of perl modules to install I find this situation: a)Modules in debian squeeze with a correct version: Cache::Memcached::Fast [libcache-memcached-fast-perl in debian] DBD::Mock [libdbd-mock-perl in debian] Test::MockModule [libtest-mockmodule-perl in debian] Test::Strict [libtest-strict-perl in debian] Test::YAML::Valid [libtest-yaml-valid-perl in debian] Time::Progress [libtime-progress-perl in debian] b)Modules in debian squeeze with a too early version: DateTime::Format::MySQL JSON::Any MooseX::Storage String::RewritePrefix c)Modulese not in debian squeeze: CHI CHI::Driver::Memcached Data::Pagination Data::Paginator Template::Plugin::HtmlToText For MooseX::Types I don't understand the exact situation. Do I prepare a patch for install_misc/debian.packages with all packages in a) section ? For b) section, are we sure of required versions of all packages ? Bye Zeno Tajoli -- Dott. Zeno Tajoli tajoliAT_SPAM_no_prendiATcilea.it fax +39 02 2135520 CILEA - Consorzio Interuniversitario http://www.cilea.it/disclaimer

2 1

New 3.6 and 3.8 packages - a note
by Robin Sheat 25 Sep '12

25 Sep '12

I've uploaded new Debian packages for the latest 3.6 and 3.8 releases. Normally this isn't worth an email, but in this case it's necessary to be aware that Debian won't automatically upgrade it for you when you ask. New dependencies have been added, and so it is now necessary to do: sudo apt-get dist-upgrade to allow the new things to be included. If you don't know about the packages, have a look here: http://wiki.koha-community.org/wiki/Koha_3.8_on_Debian_Squeeze -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D

3 3

Bug 4177 (opaccloud) - Dead feature / dead code? - Releted to French catalogs.
by Marc Véron 25 Sep '12

25 Sep '12

Bug 4177 is still marked as "New". Last activity 2011-08-23 http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4177 It is related to French catalogs. Is this feature still functional? If not, we could remove dead code and set it to RESOLVED. Comments welcome... Marc

1 0

ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/*mysqld/mysqld.sock' (2)
by Samuel Desseaux 25 Sep '12

25 Sep '12

Hi I have a problem while installing koha on a machine (i install with debian package) I have this message "ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/*mysqld/mysqld.sock' (2)" What i don't understand is >mysql well running $ service mysql status /usr/bin/mysqladmin Ver 8.42 Distrib 5.1.49, for debian-linux-gnu on x86_64 Copyright 2000-2008 MySQL AB, 2008 Sun Microsystems, Inc. This software comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to modify and redistribute it under the GPL license Server version 5.1.49-3 Protocol version 10 Connection Localhost via UNIX socket UNIX socket /var/run/mysqld/mysqld.sock Uptime: 2 min 12 sec Threads: 2 Questions: 842 Slow queries: 0 Opens: 135 Flush tables: 1 Open tables: 32 Queries per second avg: 6.378. >no problem when i restart $ service mysql restart Stopping MySQL database server: mysqld. Starting MySQL database server: mysqld. Checking for corrupt, not cleanly closed and upgrade needing tables.. But, the problem could come from that $locate libmysqlclient.so /usr/lib/libmysqlclient.so.16 /usr/lib/libmysqlclient.so.16.0.0 As the debian package include mysql-server5.1, there may be a conflict. How can i fix this problem? best regards samuel

2 2

Cataloguing authorities 3.6/3.8
by Paul 25 Sep '12

25 Sep '12

We have just discovered a problem with 3.8.4 -- before I can rule out whether it is 'our' db or setup that is at fault, or a more general issue, I would appreciate some help. Basically our "authorities" are no longer functional. EXAMPLE A: TOPIC_TERM "World War" comes up with 414 results ranging from 'World War 1' to 'World War, 1939-1945 Naval operations, Japanese' all "Used 0 times" -- all were previously functional, searchable, mostly from Z39.50 imports, and had single|multiple biblios attached. EXAMPLE B: PERSO_NAME 1) Add a new biblio from Z39.50. The author is 'Thomas, W. Donald'; we have several books by this author; using the default framework, click the icon at the end of line 100$a in addbiblio.pl, brings up the pop-up 'catalogue authority plugin', no sign of this author. [authorities/auth_finder.pl?authtypecode=PERSO_NAME&index=tag_100_subfield_a_995647_916674&value_mainstr=Thomas,%20W.%20Donald&value_main=] 2) Search authorities/authorities-home.pl?op=do_search&type=intranet&marclist=mainmainentry&operator=contains&value=Thomas%2C+W.+Donald&orderby=HeadingAsc --- Authority search results No results found 3) "Search the catalogue" from the home page (catalogue/search.pl?q=Thomas%2C+W.+Donald) comes up with 9 results, the first 5 are all by this author (the last four, fuzzy, irrelevant.) 4) From any one of the relevant entries, click the author's name: catalogue/search.pl?q=au:"Thomas, W. Donald" gives all five proper results 5) checkmarc.pl gives 'Configuration OK, you don't have errors in your MARC parameters table' 6) authtypes.pl has the following "Define authority types": /... PERSO_NAME Personal Name Personal Names 100 etc, etc The first 4 biblios were from our 3.6.1 db, which imported without error into 3.8.4 ; the fifth is today's Z39.50 import The cron -z is running every minute, but to verify zebra, I manually did a 'rebuild_zebra.pl -a -r -v' and a 'rebuild_zebra.pl -b -r -v -x' which went through all authorities and biblios without error but one warning: Records exported: 37716 ==================== REINDEXING zebra ==================== 14:58:44-24/09 zebraidx(6239) [warn] Unknown register type: ==================== CLEANING ==================== So ... new biblios and items are being recorded, but the cross referencing to authorities appears to have died with the upgrade to 3.8.4 Most unfortunately, I can reproduce this in my sandbox and the [now updated] production server. We missed this entirely during our testing - mea culpa. Thoughts anyone? Many tnx - paul

3 2