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

Some thoughts about an »official« Koha LiveCD
by Mirko 20 Oct '12

20 Oct '12

Hello everyone, as of the last IRC meeting, we have a LiveCD manager and that leads us one step into the direction of an »official«, maintained Koha LiveCD as opposed to various more or less outdated disks that are to be found scattered across the interwebs. I was wondering if we should start to gather some ideas of what we would agree on to be deserving the label »official Koha LiveCD« -- or if we would not want that label at all. Some things that came to minds (to my own and those of others in discussions about it) are - being up-to-date One of the problems now is that a lot of the available liveCDs are very outdated, thus carrying bugs and security risks. LiveCDs are old as soon as they get out by default. It would be important to have the latest stable version ready. I don't know if it is realistic to expect a fresh disk each month (or even two, for stable and oldstable)?! Would there be less stressful release cycles imaginable for this kind of release? - promoting liveCDs for testing, not for production LiveCDs are very common in GNU/Linux land and a nice way to try things without having to go through a more or less complicated installation routine and maybe breaking what you had running before. But I think once you tested and decided to use the system, you should go for a real installation and I'd like to see that promoted to avoid having people run outdated versions forever. There is even the idea of an expiration date for LiveCDs to decrease the number of outdated, insecure Koha systems. - promoting package installation Having the choice to install directly from the live medium after testing would be desirable. The best/ easiest/ recommended way of installation is an installation with Debian packages. I hope to see the inclusion of this way of installation as a goal of the development of an »official« disk. - bug tracking/ transparency Koha development happens mostly in the open and can be observed on bugzilla and git. It would be nice to see a »LiveCD« section on bugzilla that is assigned to the LiveCD Manager to be able to give feedback on bugs specific to this form of release, discuss development and also have some people test new releases of the disk before release. There is probably a lot more I forgot but I thought it might be useful to start a discussion about it. What are your thoughts on the points given here, what other things do you consider important? I'd be particularly interested in Vimal's views of course, but also like to see participation by everybody else. I send this email to both lists but I would propose to discuss on [koha-devel]. Vimal, are you subscribed to the developer list[1]? That would be a good thing to do if you have not done so already. -- Mirko [1] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel

2 1

Re: [Koha-devel] Some thoughts about an »official« Koha LiveCD
by Waylon Robertson 20 Oct '12

20 Oct '12

________________________________ From: Waylon Robertson <wrobertson1981(a)yahoo.co.nz> To: Mirko <5p4m(a)gmx.de> Sent: Saturday, 20 October 2012 1:44 PM Subject: Re: [Koha-devel] Some thoughts about an »official« Koha LiveCD what about, with this LiveCD (which i presume would be created with the use of a kickstart script) include the ability to install, with an appropiately created kickstart script. so it installs the OS and everything necessary to run koha, and koha itself. ________________________________ From: Mirko <5p4m(a)gmx.de> To: Koha-devel(a)lists.koha-community.org; koha(a)lists.katipo.co.nz Cc: vimal0212(a)gmail.com Sent: Saturday, 20 October 2012 7:27 AM Subject: [Koha-devel] Some thoughts about an »official« Koha LiveCD Hello everyone, as of the last IRC meeting, we have a LiveCD manager and that leads us one step into the direction of an »official«, maintained Koha LiveCD as opposed to various more or less outdated disks that are to be found scattered across the interwebs. I was wondering if we should start to gather some ideas of what we would agree on to be deserving the label »official Koha LiveCD« -- or if we would not want that label at all. Some things that came to minds (to my own and those of others in discussions about it) are - being up-to-date One of the problems now is that a lot of the available liveCDs are very outdated, thus carrying bugs and security risks. LiveCDs are old as soon as they get out by default. It would be important to have the latest stable version ready. I don't know if it is realistic to expect a fresh disk each month (or even two, for stable and oldstable)?! Would there be less stressful release cycles imaginable for this kind of release? - promoting liveCDs for testing, not for production LiveCDs are very common in GNU/Linux land and a nice way to try things without having to go through a more or less complicated installation routine and maybe breaking what you had running before. But I think once you tested and decided to use the system, you should go for a real installation and I'd like to see that promoted to avoid having people run outdated versions forever. There is even the idea of an expiration date for LiveCDs to decrease the number of outdated, insecure Koha systems. - promoting package installation Having the choice to install directly from the live medium after testing would be desirable. The best/ easiest/ recommended way of installation is an installation with Debian packages. I hope to see the inclusion of this way of installation as a goal of the development of an »official« disk. - bug tracking/ transparency Koha development happens mostly in the open and can be observed on bugzilla and git. It would be nice to see a »LiveCD« section on bugzilla that is assigned to the LiveCD Manager to be able to give feedback on bugs specific to this form of release, discuss development and also have some people test new releases of the disk before release. There is probably a lot more I forgot but I thought it might be useful to start a discussion about it. What are your thoughts on the points given here, what other things do you consider important? I'd be particularly interested in Vimal's views of course, but also like to see participation by everybody else. I send this email to both lists but I would propose to discuss on [koha-devel]. Vimal, are you subscribed to the developer list[1]? That would be a good thing to do if you have not done so already. -- Mirko [1] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel _______________________________________________ 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/

1 0

Re: [Koha-devel] DOM, id:x, reindexing (bug8665?)
by Paul 19 Oct '12

19 Oct '12

At 04:22 PM 10/17/2012 -0400, it was written: >Paul, >Isn't this the problem you were trying to solve to begin with? Progress! Thanks all around. After a mini-marathon our cataloguers have edited *all* duplicate 001 fields. Zebra -z doesn't keep up with 001, so for our plug-in to work I had to CRON a complete re-catalogue every couple of minutes, and if the ladies went too fast they created brand-new duplicates -- which has highlighted another "change" to zebra. Deleting a biblio, after deleting any items attached, also requires a complete re-index (else staff page still lists it and OPAC produces a 404.) Is this expected behaviour? I don't remember this in 3.6.1, but no longer have a working copy of that version. So now the ladies are working on 'authorities', starting with PERSO_NAME, which appear (thanks to the above) to be functional for those that were imported (mysql restore) from 3.6.1, but non-functional for new records (those entered directly into 3.8.4/5 -- this could well be that for the last six weeks the "authority search" while cataloguing a 100$a (and 700, 64x, etc) did not function, it now does.) I've had a look at the command line ./merge_authority.pl but it looks as though -f -t is intrinsically slower than using the staff interface -- plus I'd have to do it myself, our ladies do not use the CLI. Is there something I'm missing with that (or another) perl script that could actually find potential unlinked 100$a fields and "automate" merging to some extent? But I'm also confused that the manual and preference page seem to differ a little over '/misc/migration_tools/merge_authorities.pl' and '/bin/migration_tools/merge_authority.pl -- are these the same script? And while a cron job is not required if 'dontmerge' is set to "Do", could it be helpful in 3.8.5 with authority preferences set (I think the closest to 3.6.1) to: AutoCreateAuthorities 'Generate' BiblioAddsAuthorities 'Allow' dontmerge 'Do' MARCAuthorityControlField008 {default} UseAuthoritiesForTracings 'Don't use' Linker CatalogModuleRelink 'Do' LinkerKeepStale 'Do' LinkerModule {default} LinkerOptions {blank} LinkerRelink 'Do' Many thanks for all your assistance so far; and best regards. Paul

1 0

doubt
by Leonardo Alvarez Figueras 19 Oct '12

19 Oct '12

Hi all . I'm a college student , developing new Koha , work with version 3.06, this version has a bug in the module to ensure the provision of services under the standard OAI-PMH and need to fix it . If someone could help me or guide about it , thank you very much . 10mo. ANIVERSARIO DE LA CREACION DE LA UNIVERSIDAD DE LAS CIENCIAS INFORMATICAS... CONECTADOS AL FUTURO, CONECTADOS A LA REVOLUCION http://www.uci.cu http://www.facebook.com/universidad.uci http://www.flickr.com/photos/universidad_uci

2 1

Koha 3.10 string freeze coming soon
by Paul Poulain 18 Oct '12

18 Oct '12

Hello Koha, The Koha 3.10 string freeze will come, as expected and announced, on next monday. After this date, no patches that introduces a string change will be pushed, except if the string is absolutely required to fix a bug. If a patch is submitted that fixes a bug AND contain a string change, I may ask for 2 separate patches, one that fixes the bug and one that changes the string. The 1st being pushed for 3.10.0, the 2nd being for later (3.10.1) See you later ! -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

2 1

Test of bug 7736 failed, which status ?
by Zeno Tajoli 18 Oct '12

18 Oct '12

Hi to all, I have finished to test the patch for bug 7736. In fact the patch can't be used as written in the instructions. It not clear if are wrong instructions or code. So, which status do I need to insert ? In discussion, Assigned or Failed QA ? Bye Zeno Tajoli -- Dott. Zeno Tajoli tajoliAT_SPAM_no_prendiATcilea.it fax +39 02 2135520 CILEA - Consorzio Interuniversitario http://www.cilea.it/disclaimer

2 2

License discussions
by Bob Birchall 18 Oct '12

18 Oct '12

The following article is only relevant in the context that we have an upcoming discussion of Koha's license: http://www.techrepublic.com/blog/european-technology/open-source-developmen… Thanks to Katipo Communications for giving us the GPL from the outset. Bob

1 0

Re: [Koha-devel] DOM, id:x, reindexing (bug8665?)
by Paul 18 Oct '12

18 Oct '12

Dear Jared, Many thanks for the reply. Comments|questions interspersed below: At 04:22 PM 10/17/2012 -0400, Jared Camins-Esakov wrote: >Our cataloguers are doing a sterling job ridding our db of duplicate 001 >fields, but every time they do a simple edit of *only* the 001, both OPAC >and staff-admin page find TWO absolutely identical (biblio, barcode, etc) >records. > >Zebra incremental (-z) counts the *edit* as a completely new record. > >I can get rid of it by doing a full zebra reindex (-a and -b). This >"error" is totally reprodicible in our db. Can anyone elso confirm it >please? (edit a 001 tag, save, wait for the CRON -z, and search on title.) > >This is the way Zebra works. I understand that -- however (purely based on personal experience after only two years of use) the "concept" of Koha is that the CRON takes care of updating the search engine after cataloguers' edits (and I don't think that even a reboot does a "complete" re-cataloguing job.) For example, if I edit the date of publication in a biblio, zebra finds the edit, makes the change within sixty seconds (our CRON starts '*/1') and does not create a second biblio. But if I edit (again in a biblio) the 001, we get an entirely identical, but supplemental and erroneous record that "sticks." I've got more than enough computing power to CRON a complete reindex every minute, and if that was all that was necessary to fix everything I can do it very easily -- but should this go into the users' manual? I fear that other users may not have an 8-core I7 with raided ssd's and 16Gb ram. Nor do I think it fixes all the problems. Continued below... >A serious addition to this, is that we seem to have totally lost search >capability on serials. Â Example: we have a series of 40 "Warship >Profiles" which a mysql query (the one I gave under bug 8665) gives me: > >biblionumbers: >17472, 17473, 17474, 17475, 17476, 17477, 17478, 17479, 17480, 17482, >17483, 17484, 17485, 17486, 17487, 17488, 17489, 17493, 17494, 17495, >17496, 17497, 17498, 17499, 17500, 17501, 17502, 17503, 17504, 17505, >17506, 17508, 17509, 17511, 17513, 17514, 17516, 17517, 17518, 17520 > >id (Control Number 001): Â 01032053 > >but NONE of the records can be found -- not by biblionumber, nor by >control-number, nor by barcode, nor by title, author, etc ... Â The >records are there (other mysql queries give me the barcodes, values, >shelving locations, titles, authors, etc) but as far as staff and our >patrons are concerned, they plain don't exist. Only for a mysql query. > > >Isn't this the problem you were trying to solve to begin with? You can >access those records directly, as an aside: just go to >/cgi-bin/koha/catalogue/detail.pl?biblionumber=XXXX Yes -- it is one of the "problem[s] you were trying to solve to begin with" ... a "normal" search: http://koha-admin/cgi-bin/koha/catalogue/search.pl?q=biblionumber=17472 comes up with "No results match your search for 'biblionumber=17472' in NMA Catalog." >(easiest is to just view another record, then change the biblionumber in >the URL). Many thanks - from a quick try that works - is there a way in staff-admin to directly use 'detail.pl'? (how I explain that to our lady cataloguers downstairs is going to be challenging, and it remains to be seen if changing biblionumber or 001 will get these records back into the OPAC.) >>[snip] There must have been a good reason, hence our efforts to normalize >>001 to be a unique identifier. >No, this was a bug. There is a patch to restore biblionumber as the z:id. Please (and I'm not trying to be obtuse), how do I install the patch to our production box? That's exactly my next question: >Chris C. has a comment in Bug 8665 "Use a user-specified field for z:id." >Â I am no expert with zebra (and so far haven't worked out the role or the >wheareabouts of id:x), but: Â If z:id is currently set to '001', how do I >set it to biblionumber in 3.8.5? > >Perhaps this will help our non-existent "authorities"? > >There's another bug, also patched, related to this. It has to do with >extra spaces in a configuration file. Again, desperately trying to be diplomatic and not annoy you, how do I get the patch into production. I made a huge mistake (me, personally, and I take all the blame) when I upgraded from 3.6.1 to 3.8.x without enough testing at our end. Now I'm between the devil and the deep blue sea; go back to 3.6.1 and discard two months of cataloguing (maybe try to export these - now over a thousand - biblios from 3.8.5 and re-import them in 3.6.1?) or patch 3.8.5? I remain relatively confident that the mysql is retaining the data and that it's 'only' a zebra problem. So it's patching 3.8.5 that I'd prefer. As I said below, I'll put time and effort into it, and share the results with this community. Best regards, Paul >All suggestions would be truly appreciated -- I'll be more than happy to >try and follow any suggested cures, and will obviously share the outcome here.

1 0

Re: [Koha-devel] DOM, id:x, reindexing (bug8665?)
by Archives and Collections Society 18 Oct '12

18 Oct '12

Dear Jared, Many thanks for the reply. Comments|questions interspersed below: At 04:22 PM 10/17/2012 -0400, Jared Camins-Esakov wrote: >Our cataloguers are doing a sterling job ridding our db of duplicate 001 >fields, but every time they do a simple edit of *only* the 001, both OPAC >and staff-admin page find TWO absolutely identical (biblio, barcode, etc) >records. > >Zebra incremental (-z) counts the *edit* as a completely new record. > >I can get rid of it by doing a full zebra reindex (-a and -b). This >"error" is totally reprodicible in our db. Can anyone elso confirm it >please? (edit a 001 tag, save, wait for the CRON -z, and search on title.) > >This is the way Zebra works. I understand that -- however (purely based on personal experience after only two years of use) the "concept" of Koha is that the CRON takes care of updating the search engine after cataloguers' edits (and I don't think that even a reboot does a "complete" re-cataloguing job.) For example, if I edit the date of publication in a biblio, zebra finds the edit, makes the change within sixty seconds (our CRON starts '*/1') and does not create a second biblio. But if I edit (again in a biblio) the 001, we get an entirely identical, but supplemental and erroneous record that "sticks." I've got more than enough computing power to CRON a complete reindex every minute, and if that was all that was necessary to fix everything I can do it very easily -- but should this go into the users' manual? I fear that other users may not have an 8-core I7 with raided ssd's and 16Gb ram. Nor do I think it fixes all the problems. Continued below... >A serious addition to this, is that we seem to have totally lost search >capability on serials. Â Example: we have a series of 40 "Warship >Profiles" which a mysql query (the one I gave under bug 8665) gives me: > >biblionumbers: >17472, 17473, 17474, 17475, 17476, 17477, 17478, 17479, 17480, 17482, >17483, 17484, 17485, 17486, 17487, 17488, 17489, 17493, 17494, 17495, >17496, 17497, 17498, 17499, 17500, 17501, 17502, 17503, 17504, 17505, >17506, 17508, 17509, 17511, 17513, 17514, 17516, 17517, 17518, 17520 > >id (Control Number 001): Â 01032053 > >but NONE of the records can be found -- not by biblionumber, nor by >control-number, nor by barcode, nor by title, author, etc ... Â The >records are there (other mysql queries give me the barcodes, values, >shelving locations, titles, authors, etc) but as far as staff and our >patrons are concerned, they plain don't exist. Only for a mysql query. > > >Isn't this the problem you were trying to solve to begin with? You can >access those records directly, as an aside: just go to >/cgi-bin/koha/catalogue/<http://detail.pl?biblionumber=XXXX>detail.pl?biblionumber=XXXX > Yes -- it is one of the "problem[s] you were trying to solve to begin with" ... a "normal" search: http://koha-admin/cgi-bin/koha/catalogue/search.pl?q=biblionumber=17472 comes up with "No results match your search for 'biblionumber=17472' in NMA Catalog." >(easiest is to just view another record, then change the biblionumber in >the URL). Many thanks - from a quick try that works - is there a way in staff-admin to directly use 'detail.pl'? (how I explain that to our lady cataloguers downstairs is going to be challenging, and it remains to be seen if changing biblionumber or 001 will get these records back into the OPAC.) >>[snip] There must have been a good reason, hence our efforts to normalize >>001 to be a unique identifier. >No, this was a bug. There is a patch to restore biblionumber as the z:id. Please (and I'm not trying to be obtuse), how do I install the patch to our production box? That's exactly my next question: >Chris C. has a comment in Bug 8665 "Use a user-specified field for z:id." >Â I am no expert with zebra (and so far haven't worked out the role or the >wheareabouts of id:x), but: Â If z:id is currently set to '001', how do I >set it to biblionumber in 3.8.5? > >Perhaps this will help our non-existent "authorities"? > >There's another bug, also patched, related to this. It has to do with >extra spaces in a configuration file. Again, desperately trying to be diplomatic and not annoy you, how do I get the patch into production. I made a huge mistake (me, personally, and I take all the blame) when I upgraded from 3.6.1 to 3.8.x without enough testing at our end. Now I'm between the devil and the deep blue sea; go back to 3.6.1 and discard two months of cataloguing (maybe try to export these - now over a thousand - biblios from 3.8.5 and re-import them in 3.6.1?) or patch 3.8.5? I remain relatively confident that the mysql is retaining the data and that it's 'only' a zebra problem. So it's patching 3.8.5 that I'd prefer. As I said below, I'll put time and effort into it, and share the results with this community. Best regards, Paul >All suggestions would be truly appreciated -- I'll be more than happy to >try and follow any suggested cures, and will obviously share the outcome here.

1 0

DOM, id:x, reindexing (bug8665?)
by Paul 17 Oct '12

17 Oct '12

Would one of you please be kind enough to save my sanity (if I have any left)? Our cataloguers are doing a sterling job ridding our db of duplicate 001 fields, but every time they do a simple edit of *only* the 001, both OPAC and staff-admin page find TWO absolutely identical (biblio, barcode, etc) records. Zebra incremental (-z) counts the *edit* as a completely new record. I can get rid of it by doing a full zebra reindex (-a and -b). This "error" is totally reprodicible in our db. Can anyone elso confirm it please? (edit a 001 tag, save, wait for the CRON -z, and search on title.) A serious addition to this, is that we seem to have totally lost search capability on serials. Example: we have a series of 40 "Warship Profiles" which a mysql query (the one I gave under bug 8665) gives me: biblionumbers: 17472, 17473, 17474, 17475, 17476, 17477, 17478, 17479, 17480, 17482, 17483, 17484, 17485, 17486, 17487, 17488, 17489, 17493, 17494, 17495, 17496, 17497, 17498, 17499, 17500, 17501, 17502, 17503, 17504, 17505, 17506, 17508, 17509, 17511, 17513, 17514, 17516, 17517, 17518, 17520 id (Control Number 001): 01032053 but NONE of the records can be found -- not by biblionumber, nor by control-number, nor by barcode, nor by title, author, etc ... The records are there (other mysql queries give me the barcodes, values, shelving locations, titles, authors, etc) but as far as staff and our patrons are concerned, they plain don't exist. Only for a mysql query. I have a feeling that all this is "associated with" Bug 8665, but would appreciate a little more understanding (is there a full write up somewhere? I've searched but can't find one.) I believe that 3.6 (at least .1, but changed sometime before .7) used biblionumber as the primary reference; now field 001 has become "primary." Why? There must have been a good reason, hence our efforts to normalize 001 to be a unique identifier. Chris C. has a comment in Bug 8665 "Use a user-specified field for z:id." I am no expert with zebra (and so far haven't worked out the role or the wheareabouts of id:x), but: If z:id is currently set to '001', how do I set it to biblionumber in 3.8.5? Perhaps this will help our non-existent "authorities"? All suggestions would be truly appreciated -- I'll be more than happy to try and follow any suggested cures, and will obviously share the outcome here. Many thanks in advance - Paul

2 1