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

Koha packages for master
by Robin Sheat 04 Oct '12

04 Oct '12

The packages for master have been lagging for some time now, as dependencies were introduced that didn't have packages. This evening I started to fix this, however ran in to a problem: Data::Pagination has no copyright information, therefore it's dubious as to whether we should be using it, and I'm reluctant to distribute it. I've asked for clarification on this: https://rt.cpan.org/Public/Bug/Display.html?id=80000 however it means that packages for master will have to wait a while, until this is sorted. We should be more careful about our dependencies and whether we're allowed to distribute them. (Note: I'm 99.99% certain it'll be fine, it's just that only the author can really make that call for sure.) -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D

2 3

A new open source project on Drupal related to sigb (and so koha)
by Claire Hernandez 04 Oct '12

04 Oct '12

Hello, I am pleased to announce that we contributed a new drupal module called opac: http://drupal.org/project/opac Announcement is here: http://drupal.biblibre.com/en/blog/entry/biblibre-contributes-the-drupal-op… evolves a lot but you can begin to test it and give us feedbacks :) The first sigb we connected is, of course, koha. It is an other way to provide opac and others things around, it is and independant full project related to whatever sigb you want. I would like to introduce a difficulty we encounted: we wanted to build on top of Ils-di but not everything can be done with it (and we found some bugs). We wonder how to expose koha services to build a significant drupal site. Ncip2 is not sufficient for us, so we've made a choice. For the moment, we are building a Koha::REST interface. The project is published http://git.biblibre.com/?p=koha-restful;a=summary but not yet submitted to the community. You can have a look and tell us what you think. If you want to send us patches, please do it, if you prefer I could clone it in github but the risk is that the project wont be up to date everyday. Regards, Claire.

5 5

dselect non-funcitonal on Ubuntu
by Tomas Cohen Arazi 04 Oct '12

04 Oct '12

This simple test probes dselect is currently broken on Ubuntu amd64 12.04/10.04 (as root): $ echo "apache2 install" | dpkg --set-selections $ dselect install Reading package lists... Done Building dependency tree Reading state information... Done The following NEW packages will be installed: gcc-4.6-base:i386 libasn1-8-heimdal:i386 libc6:i386 libcap2:i386 libcomerr2:i386 libdb5.1:i386 libexpat1:i386 libgcc1:i386 libgcrypt11:i386 libgnutls26:i386 libgpg-error0:i386 libgssapi3-heimdal:i386 libhcrypto4-heimdal:i386 libheimbase1-heimdal:i386 libheimntlm0-heimdal:i386 libhx509-5-heimdal:i386 libkrb5-26-heimdal:i386 libldap-2.4-2:i386 libp11-kit0:i386 libpcre3:i386 libroken18-heimdal:i386 libsasl2-2:i386 libsasl2-modules:i386 libsqlite3-0:i386 libssl1.0.0:i386 libtasn1-3:i386 libuuid1:i386 libwind0-heimdal:i386 zlib1g:i386 0 upgraded, 29 newly installed, 0 to remove and 0 not upgraded. Need to get 8,500 kB of archives. After this operation, 22.2 MB of additional disk space will be used. Do you want to continue [Y/n]? So I propose the removal of dselect usage from the docs and use of simple apt-get commands (perhaps providing a convenient script). Regards To+

9 27

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

03 Oct '12

At 10:22 AM 10/1/2012 +1300, Robin Sheat wrote: >Paul schreef op za 29-09-2012 om 17:54 [-0400]: > > 17:32:00-29/09 zebraidx(2632) [warn] isamb: Inconsistent register (2) > > zebraidx: isamb.c:1102: insert_leaf: Assertion `*lookahead_mode' > > failed. > > 17:32:00-29/09 zebraidx(2637) [warn] previous transaction didn't reach > > commit > > > > that are "novel." > > > > Any suggestions, thoughts? > >Those errors are really annoying. > >Have a look to see if there's something funny about the MARC for biblio >17765. Especially missing 999$c and $d (I think.) I've been following up on on Robin's suggestion looking for "something funny" in our records that might explain current indexing (or at least reassure me that it's not a db rather than system error) and wrote a script to verify our inhouse barcodes: mysql> select items.barcode, items.biblionumber, biblio.title, biblio.author, items.itemcallnumber from items join biblio on (items.biblionumber = biblio.biblionumber) where items.barcode NOT REGEXP '^[[:digit:]]{1}[[:alnum:]]{4}[[:digit:]]{8}$'; +------------------+--------------+----------------------+-------------------------+----------------+ | barcode | biblionumber | title | author | itemcallnumber | +------------------+--------------+----------------------+-------------------------+----------------+ | 1AERO9107_221230 | 16603 | Heroes of the air, | Fraser, Chelsea Curtis, | AERO-FRAS-1 | | 1AERO111564 | 17408 | Fights and flights / | Samson, Charles Rumney, | AERO-SAMS-1 | +------------------+--------------+----------------------+-------------------------+----------------+ 2 rows in set (0.02 sec) However, these are totally unfindable in Koha (by barcode, biblionumber, callnumber, etc) via any type of search (normal, advanced etc) [N.B. we have these two items under a different biblio, call, barcode, all valid and searchable.] But, I can use 'Tools ==> Export bibliographic and holdings' and produce what appear to be perfectly valid Marc21 records Could these 2 be (I'm wildly guessing) the reason for the "[warn] isamb: Inconsistent register (2)"? Does anyone have a ready made method to delete a complete record in Mysql? They're unwanted elements -- but how to remove them? tnx and br -- paul

2 1

Re: [Koha-devel] dselect non-funcitonal on Ubuntu
by Paul 02 Oct '12

02 Oct '12

At 02:53 PM 10/2/2012 -0300, Tomas Cohen Arazi wrote: >On Mon, Oct 1, 2012 at 11:33 PM, Mark Tompsett <mtompset(a)hotmail.com> wrote: > > Greetings, > > > > The âgoodâ thing about this bug is that it only affects people who > do git or > > tarball installs in a multi-arch environment. That is, it affects us as > > developers, not really the average user of Koha who has hopefully been > > transitioned to a package install. > >Any 'new' Ubuntu setup (amd64) is multiarch by default. All our >desktops are +4GB RAM and run 64bit OS's. Is not that rare. > >Multiarch is set when writing in /etc/dpkg/dpkg.cfg.d/multiarch the >instruction to accept another architecture as foreign: ><code> >foreign-architecture i386 ></code> And it appears to work well -- it will *not* install i386 packages without 'sudo apt-get install -f' It just gives you a list of required dependencies and a hint that you must use '-f' The Debian/Ubuntu pro/cons of multiarch can be read either way. Until there is a catastrophic failure of apt-get combined with dselect I feel that any capable admin would appreciate keeping them. Efficiency, flexibility and warning levels are quite sufficient. Best - Paul Who has however found one "package" (in the loosest sense of the word) that has the ability to either invisibly use the '-f' or circumvent it. From memory, in a *desktop* environment, if you don't want to use Unity, but go for "Gnome 2 classic" with 'gnome-session-fallback' or somesuch, it will install the i386 version of gcc and its libraries. You then can delete them with no apparent ill effect. But this is the [non-damaging] exception to prove the rule. Most current/new users of Koha will be using an AMD64 *server*.

1 0

3.08.05 : Bug in PO FR
by Fridolyn SOMERS 01 Oct '12

01 Oct '12

Hie, I noticed there is a bug in OPAC PO fr-FR in 3.08.05 : perl translateinstall fr-FR tmpl_process3.pl: Warning: unconsistent%s count:(10/9): line:2841 msgid:"%s %s%s%s%sKoha online%s catalog &rsaquo; %sAuthority search result%sNo results found%s %s" msgstr:"%s %s%s%s%sKoha en-ligne%s catalogue &rsaquo; %sRecherche des autorités%sPas de résultat %s" The %s missing will crash translated file opac-tmpl/prog/en/modules/opac-authoritiessearchresultlist.tt I corrected it on translate.koha-community.org. Best regards, -- Fridolyn SOMERS Biblibre - Pôle Support 09 74 77 07 15 fridolyn.somers(a)biblibre.com <mailto:fridolyn.somers@biblibre.com>

3 2

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

01 Oct '12

Hi Tomas, Follow up: just finished brand new install 12.04.1 LTS plus Koha 3.8.4 (restore of the production sql dump) on the sandbox, absolutely identical to the production server, except Koha is "out-of-the box" with no customization at all. The "Current problems" (see below for the production server) are identical, EXCEPT: Records exported: 17765 ==================== REINDEXING zebra ==================== 17:31:07-29/09 zebraidx(2632) [warn] Missing attribute 'type' in attribute info 17:31:07-29/09 zebraidx(2632) [warn] Unknown register type: 17:32:00-29/09 zebraidx(2632) [warn] isamb: Inconsistent register (2) zebraidx: isamb.c:1102: insert_leaf: Assertion `*lookahead_mode' failed. 17:32:00-29/09 zebraidx(2637) [warn] previous transaction didn't reach commit ==================== CLEANING ==================== Note -- same number of biblios found, but zebra can no longer find biblionumbers above 17765, whereas the production server CAN find [OPAC and staff client] 'biblionumber:18099' so it's the three new 'warns' (the other two are consistent with the production server): 17:32:00-29/09 zebraidx(2632) [warn] isamb: Inconsistent register (2) zebraidx: isamb.c:1102: insert_leaf: Assertion `*lookahead_mode' failed. 17:32:00-29/09 zebraidx(2637) [warn] previous transaction didn't reach commit that are "novel." Any suggestions, thoughts? Many thanks - Paul 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/

3 2

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

30 Sep '12

Still trying to get authorities to link in 3.8, until now based on bug (8071), but have come across bug 7284 (included in 3.6.5?) but am now confused by <http://wiki.koha-community.org/wiki/Bug7284_authority_matching_improvement#…> which states in more general terms "If you upgrade from 3.6 to 3.8, the authority matching won't work anymore until you've updated the zebra configuration file". It also says that file: etc/[koha/?]zebradb/marc_defs/marc21/authorities/koha-indexdefs-to-zebra.xsl should exist -- but it is absent from my 3.8 (the other two are there) in production and the sandbox: paul@nelson:/etc/koha/zebradb/marc_defs/marc21/authorities$ ls authority-koha-indexdefs.xml authority-zebra-indexdefs.xsl record.abs Given that our "master" db comes from 3.6.1, am I missing an intermediate step? tnx and br -- paul

1 0

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