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

Re: [Koha-devel] Building Debian packages
by Robin Sheat 29 Jul '10

29 Jul '10

Op woensdag 28-07-2010 om 10:17 uur [tijdzone -0300], schreef Tiago Murakami: > I install beta version of koha 3.2 in a Debian Squeeze as described in > "Koha 3.2 on Debian Squeeze" - > http://wiki.koha-community.org/wiki/Debian , but zebra don´t work. I > tried on Ubuntu Lucid, as a described in Koha on Lucid using Koha > packages and don´t work too. > > Its necessary any other configuration for zebra? Which package did you install? 'koha' contains a standard configuration and is useful to get a single instance up and running quickly, and 'koha-common' (which contains all the code and support scripts) allows a more complex setup, at the expense of not giving you one up front. If you use the 'koha' package, you'll need to set up the zebra-related cron jobs and launch scripts yourself, as the site that it gives you isn't hooked into the Koha site management system that koha-common on its own uses. My recommendation at the moment would be to just install koha-common, and use the koha-create script to generate a single instance. What I might do in the future when I get time is make the 'koha' package install its default site in such a way that it gets managed by the koha-common tools. This would mean that the koha-rebuild-zebra cron job and such like magically happen. In fact, I've created a bug: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5071 so that this doesn't fall off my radar. I've also edited the wiki page at http://wiki.koha-community.org/wiki/Koha_3.2_on_Debian_Squeeze to hopefully clarify this. -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D

1 0

Re: [Koha-devel] Deprecated System Preferences
by Nicole Engard 27 Jul '10

27 Jul '10

On Tue, Jul 27, 2010 at 4:46 AM, Zeno Tajoli <tajoli(a)cilea.it> wrote: >> Version [section "Admin"] > > This preference is used in C4/Installer.pm an C4/Context.pm > It record the exact version of Koha. We need it to update Koha between > different version. Is not deprecated, as I know. > I don'r know it useful to not show it. This one (if it must show) makes sense to show on Local Use or Admin. Nicole

1 0

Deprecated System Preferences
by Nicole Engard 27 Jul '10

27 Jul '10

Hello all, There is a discussion going on on this bug report: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3756 regarding deprecated preferences and the fact that they still show in Koha. I want to submit a patch (as is suggested) to remove these preferences, but I need confirmation that they are in fact deprecated. Below is the list of preferences can you all chip in and tell me which are really deprecated so that I don't delete something important? Some of these I think we do need but never made it to the new sys prefs interface ... others I remember reading were deprecated. acquisitions AnonymousPatron AutoEmailPrimaryAddress BakerTaylorPassword BranchTransferLimitsType defaultSortOrder FrameworksLoaded holdCancelLength ILS-DI:AuthorizedIPs kohaspsuggest libraryAddress marc MIME OAI-PMH:Set OAI-PMH:Subset OpacCloud OPACdefaultSortOrder OPACDisplayExtendedSubInfo OPACNoResultsFound OPACRerunSearch OPACSubscriptionDisplay OrderPdfTemplate pdfformat PINESISBN printcirculationslips RandomizeHoldsQueueWeight sortbynonfiling SyndeticsCoverImageSize TemplateEncoding Version z3950AuthorAuthFields Thanks a ton, Nicole C. Engard

3 2

Re: [Koha-devel] Deprecated System Preferences
by Zeno Tajoli 27 Jul '10

27 Jul '10

At 19.09 26/07/2010, Nicole Engard wrote: >Hello all, > >There is a discussion going on on this bug report: >http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3756 >regarding deprecated preferences and the fact that they still show in >Koha. I want to submit a patch (as is suggested) to remove these >preferences, but I need confirmation that they are in fact deprecated. > Below is the list of preferences >Version [section "Admin"] This preference is used in C4/Installer.pm an C4/Context.pm It record the exact version of Koha. We need it to update Koha between different version. Is not deprecated, as I know. I don'r know it useful to not show it. >z3950AuthorAuthFields [section "Cataloguing"] It is used in cataloguing/addbiblio.pl and in acqui/neworderempty.pl. Those scripts use the system preferences in two subroutines called "MARCfindbreeding". Is a list of marc tags about authors. This list is different in Unimarc and in Marc21. I think we need to keep it. Bye Zeno Tajoli CILEA - Segrate (MI) tajoliAT_SPAM_no_prendiATcilea.it (Indirizzo mascherato anti-spam; sostituisci quanto tra AT con @)

1 0

Building Debian packages
by Robin Sheat 26 Jul '10

26 Jul '10

As I mentioned a little while back, I've started maintaining the Koha Debian packages. It occurred to me that some of you may want to make your own for internal use or whatever, so I've put the process I use to make them up on the wiki: http://wiki.koha-community.org/wiki/Building_Debian_Packages It'll need a fair bit of adaptation, as currently it's pretty customised to my configuration, and deployment of the debian.koha-community.org packages, but all the important steps are there. -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D

1 0

To define default 9xx fields for Unimarc setup in all languages
by Zeno Tajoli 25 Jul '10

25 Jul '10

Hi to all I sent this mail to different Koha-mailing list because the topic is quite wide. If you are also on koha-dev list, replaty to this list. Instead replay on koha general list. I send the mail also to koha-france because many user of Unimarc are French. But I don't know French, please replay to koha general list or to koha-dev. Today the complete Unimarc setups are the English and French, As I know Italian, Ukrain, Russian and Poland setups are direct translation of English or Frence setup But on local fields English and French are not compatible. Many 9xx fields need to be the same in different languages because the indexes definitions in the file etc/zebradb/marc_defs/unimarc/biblios/record.abs are based on specific 9xx values. And the file record.abs is only one for all Unimarc setup So my proposal, for 3.2 and also [if possible ] for 3.0.x We re-write English setup in 9xx fields and we use it a minimun and a standard that ALL unimarc setups need to follow. It means that we need same change also to French setup. I want to discuss with everyone about this topic. I will write all the patch to fix the situation. So my proposal: Fields: 001 Local number -> biblio.biblionumber 090$a Local number -> biblioitems.biblioitemnumber 099$c date of creation -> biblio.datecreated 099$d Date/time last modified -> biblio.timestamp 995$0 Withdrawn status -> items.wthdrawn 995$2 Lost status -> items.itemlost 995$3 Use restrictions -> items.restricted 995$5 Date acquired -> items.dateaccessioned 995$6 Copy number -> items.copynumber 995$7 URI -> items.uri 995$8 Koha collection -> items.ccode 995$9 Internal item number -> items.itemnumber 995$a Homebranch (free text) ->items.homebranch 995$b Homebranch (coded) 995$d Holding branch (free text) -> items.holdingbranch 995$d Holding branch (coded) 995$e Shelving location-> items.location 995$f Barcode -> items.barcode 995$j Inventory number -> items.stocknumber [only 3.2] 995$k Call number -> items.itemcallnumber, 995$l Numbering (volume or other part) -> items.materials 995$m Date of loan or deposit -> items.datelastborrowed 995$n Expiration of loan date -> items.onloan 995$o Circulation type (not for loan) -> items.notforloan 995$r Type of item and material -> items.itype 995$v Serial Enumeration / chronology -> items.enumchron [only serials] 995$u Copy note -> items.itemnotes 942$0 Koha issues (borrowed), all copies -> biblioitems.totalissues 942$2 Source of classification or shelving scheme -> biblioitems.cn_source 942$6 Koha normalized classification for sorting -> biblioitems.cn_sort 942$c Koha [default] item type -> biblioitems.itemtype 942$s Serial record flag -> biblio.serial 1)Fields 001 and 090$a, BIB Identifier in two places As French setup, to ahve a correct Unimarc we need BIB id in two places: 001 -> biblio.biblionumber 090 $9 -> biblioitems.biblioitemnumber biblio.biblionumber and biblioitems.biblioitemnumber must be numerir, we need to stress this fact in data conversions 2)Field 995 as item field with those subfields: This proposal is full compatible with French Unimarc setup and it has also the items subfields that are mandatory for circulation, inventory, acquisitions and serials. 3)Field 942 as biblio/item field. This field is new for all unimarc setup, in english unimarc setup there is 990 but 990 is similar, not identical. I select 942 instead of 990 because 990 is present in French setup with a specific meaning. I ask to French people to accept to put biblioitems.totalissues in 942$0, it is the base of the popularity index. Now the base of popularity index is in 995$s. This proposal is only a minimum, if you think there are others 9xx fields/subfields that MUST be present in every setup, please replay. If you want to discuss it, please replay. Bye to all Zeno Tajoli Zeno Tajoli CILEA - Segrate (MI) tajoliAT_SPAM_no_prendiATcilea.it (Indirizzo mascherato anti-spam; sostituisci quanto tra AT con @)

2 1

Default MARC dialect
by Magnus Enger 22 Jul '10

22 Jul '10

Hi all! During my quest to add support for NORMARC (the Norwegian dialect of MARC) to Koha, I have come across several places[1] where UNIMARC is treated as the default if MARC21 is not specified. Here is an example from the subroutine GetMarcNotes in C4/Biblio.pm: 1268 if ( $marcflavour eq "MARC21" ) { 1269 $scope = '5..'; 1270 } else { # assume unimarc if not marc21 1271 $scope = '3..'; 1272 } When $marcflavour is "NORMARC" this fails, because NORMARC is more similar to MARC21 than to UNIMARC. I can think of two solutions to this: 1. Add NORMARC to the conditional: if ( $marcflavour eq "MARC21" || $marcflavour eq "NORMARC" ) { $scope = '5..'; } else { # assume unimarc if not marc21 $scope = '3..'; } 2. Reverse the logic: if ( $marcflavour eq "UNIMARC" ) { $scope = '3..'; } else { # assume marc21 if not unimarc $scope = '5..'; } I would prefer the second solution, because - in all the places I have found this situation it would be resolved by this solution, because NORMARC is so similar to MARC21 - as far as I know there are more MARC dialects that resemble MARC21 than there are dialects that resemble UNIMARC, so this solution would perhaps make it easier to add more dialects in the future If anyone has a completely different solution or pro/con arguments they would like to add I'm all ears! Regards, Magnus Enger libriotech.no PS. Just for the record: I'm no fan of NORMARC and would prefer if Norwegian libraries started using MARC21, but for Koha to be accepted in Norway it needs to support NORMARC... Notes: [1] http://wiki.github.com/MagnusEnger/KohaNor/existing-files

3 3

git bisect
by Colin Campbell 20 Jul '10

20 Jul '10

A handy introduction to using git bisect to track down bugs: > http://www.effectiveperlprogramming.com/blog/date/2010/07 C. -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 208 366 1295 (phone) +44 (0) 7759 633626 (mobile) colin.campbell(a)ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com

1 0

system preference question (anonymous preferences)
by Nicole Engard 19 Jul '10

19 Jul '10

There are 2 system preferences in my most recent version of HEAD: - AnonSuggestions -- Set to anonymous borrowernumber to enable Anonymous suggestions - AnonymousPatron -- Set the identifier (borrowernumber) of the 'Mister anonymous' patron. Used for Suggestion and reading history privacy Does this mean that AnonSuggestions is not used? I personally think we need both and that Anon should be for suggestions and AnonymousPatron for reading history. Can someone please clarify these for me? Thanks Nicole

3 6

New Debian packages and new Debian packages maintainer.
by Robin Sheat 19 Jul '10

19 Jul '10

Hi folks, I've taken over maintenance of the Debian Koha packages, and just did my first upload to them. These packages track the git master branch, and I'll be updating them every so often, hopefully about once a week or so. Perhaps more if I get the whole process into one script. Anyway, if you've been using these packages, Debian will probably start complaining that the signature has changed. The key that I'm using has the details: pub 1024D/A99CEB6D 2004-09-26 [vervaldatum: 2012-09-21] Vingerafdruk van de Sleutel = 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D uid Robin Sheat <robin(a)kallisti.net.nz> uid Robin Sheat <robin(a)ufies.org> uid Robin Sheat (work) <robin(a)catalyst.net.nz> uid Robin Sheat <robin.sheat(a)member.fsf.org> sub 2048g/DF7647FD 2004-09-26 [vervaldatum: 2012-09-21] To tell Debian it's OK to use, run: wget -O- http://debian.koha-community.org/koha/gpg.asc | sudo apt-key add - (all on one line.) Don't forget to file bugs if you discover any issues with the packages, I'm slowly learning how this whole packaging process works. -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204

1 0