IRC log for #koha, 2006-07-13

← Previous day | Today | Next day → | Search | Index

All times shown according to UTC.

Time Nick Message
12:19 kados sheesh
12:19 phone ringing off the hook
12:19 owen: ok, I'm back :-)
12:20 so ... where shall we start?
12:21 owen Yesterday as far as we got was, "needs to fit 800x600" monitor
12:22 kados right
12:22 so as far as the OPAC goes ...
12:22 the 800 x 600 thing
12:23 anything else?
12:23 the faceted searches we're going to skip I think, right?
12:23 owen Was that issue with the search form or the results?
12:23 kados the search form I think
12:23 owen Both look okay to me
12:23 Only the simple search is a little squeezed, but that's just the big form field.
12:24 kados I'll send you a screenshot
12:26 owen: check your inbox
12:28 owen I think yes to skipping the faceted searches, in the interests of time
12:30 Wow, kados, that's remarkably different than Firefox's rendering.
12:31 kados owen: that _is_ firefox :-)
12:31 owen: it looked the same way on the circ computer at the plains
12:31 owen: which I assume is win98 or 2000
12:32 owen Just have to resize the form field a little
12:33 kados so ...
12:33 as far as maintenance goes, are you using a fresh copy of the dev-week code?
12:33 cuz that's what's up on zoomopac
12:34 (do you need write access to more than just the template files?
12:34 (to upload changes?
12:34 owen I don't know
12:34 kados ok, well now you've got access to the koha-tmpl dir
12:35 let me know if you need more
12:40 http://zoomopac.liblime.com/cg[…]tail.pl?bib=49201
12:40 I suspect these are triple or even quadrupal encoded
12:41 marc8->latin1->latin1->latin1 :)
12:52 owen Did you see the issues with "you did not specify any search criteria" with sorted search results?
12:53 kados yea
12:53 I think that's fixed in devweek
12:53 but if not I'll certainly have a look
12:54 (not that interesting to you :-)
12:58 thd: 1106 is fixed
12:59 thd kados: is the fix committed or where can I test the fix
12:59 kados thd: afognak has the fix
12:59 thd: and it's commited
12:59 thd goody
13:06 kados: works nicely now
13:06 kados thd: great!
13:06 thd kados: where is the working editor code if it is not in devel-week?
13:07 kados: only on the Liblime server?
13:08 kados thd: it is now working in dev-week and rel_2_2 afaik
13:08 thd: dev-week for sure
13:09 thd kados: you have updated devel-week since it was not working yesterday?
13:09 kados thd: yes
13:09 thd: dev-week is now completely in sync with rel_2_2 except without the MARC editor bugs :-)
13:10 thd: didn't you see the 40+ commits this morning? :-)
13:10 thd kados: I had to avoid overfilling an email quota with commits so I do not see them in real time.
13:11 kados ahh
13:13 thd kados: I would need to have much more time than I have to fix my local mail system again to solve that quota problem
13:14 kados:  what Koha SQL columns need linking to the bibliographic framework for 2.2.4?
13:15 kados ?
13:15 thd kados: did you link only 2 yesterday
13:15 ?
13:15 kados linking?
13:16 thd kados: items.onloan etc linked to 952 $X?
13:17 kados ahh
13:18 yes, that's the only one
13:18 thd: I could use your advice on a good mapping scheme
13:18 thd kados: did you not need another for date?
13:18 kados date is in issues, not in items
13:19 thd kados: I thought you added date because things were not working.  Not that they worked afterwards.
13:20 kados: what do you want to map in a good mapping scheme?
13:20 kados well ...
13:20 thd: items fields mainly
13:21 thd: we need to come up with a scheme for call number
13:21 thd: that may include adding a column to items (fine by me)
13:21 thd: all of the statuses need to be mapped
13:21 things like datelastborrowed would be useful too
13:22 datelastseen, etc.
13:22 the more we can store in zebra the better
13:22 because then we can search on it
13:22 thd kados: what are all of the statuses?
13:22 kados: how many are they?
13:22 kados notforloan, itemlost, wthdrawn,binding I think
13:23 thd: we also need to clean up the descriptive language of the item labels
13:23 thd: so that a librarian is not confused :-)
13:23 thd kados: those are already mapped except for binding
13:23 kados paidfor
13:23 another status
13:24 thd kados: the descriptions were written to not confuse me :)
13:24 kados :-)
13:24 yes, I understand that
13:25 thd kados: do you think that we might run out of punctuation symbols?
13:25 kados thd: also, barcode should not be a mandatory field
13:25 thd: but I agree we need a method to alert if a field hasn't been filled in but let the cataloger proceed
13:25 thd kados: I never set it to mandatory except by request
13:26 kados thd: it's set to mandatory in the framework I believe
13:26 thd kados: I think that had been your request at one time
13:28 kados perhaps :-)
13:30 thd kados: I have code for filling the various call number parts for use in labels etc.
13:30 kados in perl?
13:31 thd yes
13:32 kados: however, there is no code for what we had discussed previously for the case where NPL needs a couple of system preferences for treating fiction differently etc.
13:34 kados well ... not necessarily
13:34 it can be achieved with minimal coding
13:34 if we distinguish between classification and call number
13:34 and local call number
13:35 and define local call number as either classification or call number depending on whether it's fiction or non-fiction
13:37 thd kados: to remind you we need a preference for call number type LCC, DDC, UDC, etc. and a preference for cutter type and rule and a preference for secondary classification defined by an exception list such as material type specifying fiction.
13:39 kados hmmm
13:39 thd kados: mere classification is unknown because there are many different classifications and MARC never has one and only one place to hide a given classification.
13:39 kados couldn't we just define it in the framework instead of a preference?
13:40 thd kados: define what in the framework?
13:41 kados thd: define the type of classification being used
13:41 thd kados: we could add a column to the framework to specify which locations are good for identifying particular parts of a call number.
13:42 kados thd: ie, the mappings would define it for us
13:43 thd kados: the type of classification that a library is using is up to the library and cannot be defined for all libraries
13:44 kados thd: what I mean is that each library will have to define that part of their framework
13:44 thd kados: the bibliographic framework should not be the place to define whether the library prefers DDC, UDC, LCC, etc.  should it.
13:44 kados hmmm
13:45 so what is our objective?
13:45 thd kados: you could define the standard locations in advance but they are multiple
13:45 kados to search and display call numbers correctly right?
13:45 do we need to distinguish between call numbers and classification?
13:46 thd kados: the objective is to fill the call number by the library's preference
13:46 kados thd: fill it with values coming from the MARC?
13:46 thd: because with zebra, we don't need it to be in the koha tables to search or display it
13:46 thd kados: call numbers are numbers of which the classification element is only one part
13:47 kados thd: the only reason for it to be in the koha tables with zebra is if it is used by the system in managing the collection somehow (like circ rules)
13:47 (or inventory)
13:48 thd kados: it does not need to be in the SQL tables
13:50 kados: MARC has provided 852 $k $h $i $m
13:51 kados thd: http://wiki.koha.org/doku.php?[…]rchingdefinitions
13:51 thd kados: I provided all those in 952 in the framework
13:51 kados thd: this is a document I wrote for NPL to help them clearly define their cataloging practices
13:51 thd: I think it would also be useful in this case
13:52 thd: the 'organization of materials' section is most relevant
13:52 thd: I could use some expansion on what I've written to more accurately describe the components of collection organization
13:56 thd kados: it seems as if they are using 942$c for the equivalent of $852 $k call number prefix
13:57 kados thd: that is my mistake
13:57 thd: it should read 952$c
13:58 fixed
14:01 thd kados: do they have the values in 952 $c on their spine labels?
14:04 kados yes
14:04 owen: right?
14:04 owen Sorry, what? What's 952 $c?
14:04 thd kados: then they are using that for 852 $k
14:06 owen: the MARC location defined in the framework used originally by NPL to store the contents of `items.location`
14:07 owen Our current production database doesn't store anything in items.location.
14:08 thd kados: I think that you had it correct previously it was 942 $c
14:09 owen: do the item type codes that you use appear on the spine labels?
14:10 owen Yes
14:10 thd kados: you were correct originally you should revert to the previous version in the wiki
14:11 kados right
14:11 owen biblioitems.itemtype
14:13 thd owen kados: NPL uses biblioitems.itemtype stored in 942 $c as the equivalent of 852 $k
14:13 kados right
14:13 thd kados: all our libraries do the same as far as I know
14:14 s/our/your/
14:15 kados yep
14:15 but 942 $c is not where the spine labels are printed from
14:15 afaik the spine labels are coming from a value mapped to callnumber
14:15 thd kados: so you should fill 852 $o in the current standard MARC 21 framework with the contents of 942 $c
14:16 kados but that's the itemtype
14:16 not the call number
14:16 thd kados: I thought that NPL was not yet using Koha for spine labels
14:16 kados they aren't
14:16 but they do generate spine labels
14:16 from fields in the MARc
14:17 thd kados: yes but that is way in which NPL is using the itemtypes that it has defined
14:18 kados: 852 $k is usually something like JUV, REF, FIC, etc. at most libraries
14:19 kados: those are item types of some sort but not a true material type
14:20 kados right
14:20 is there a standard that defines them somewhere?
14:21 thd kados: no just common practise
14:21 kados: material types have multiple standards
14:21 kados which turns out not to be very consistant :-)
14:22 thd kados: amazing how far a little cultural conformism will go to address the same problem in the same manner
14:24 kados: oh you were saying it was not consistent.  Each library has to apply the basic intent to its own needs.
14:25 kados: yet English language usage provides FIC more usually as opposed to FICT, REF as opposed to REFE, etc.
14:26 kados :-)
14:26 thd kados: and then there is the need to economise the space on the small spine label.
14:27 kados right ... any suggestions on that?
14:28 thd kados: the 852 $h $i tend to be more standard than 852 $k and $m which depends on how the library wants to organise its collection
14:30 kados: spine labels should be 852 $k $h $i $m with the addition of c. $t where $t > 1 .
14:32 kados: in the current MARC 21 framework that is 952 $o $h $i $t
14:34 kados: so 952 $o could be filled from the values contained in 942 $c for NPL.
14:37 kados: 952 $h would come from either 082 $a, 092, 055 $a, or 852 $h depending on what was filled.
14:38 kados: 055 and 852 should be tested for having the correct indicators or the correct number type when indicators were not set.
14:42 kados: 952 $i would come from either 082 $b, 092, 055 $b, or 852 $i depending on what was filled except that libraries may have their own preferred cuttering scheme and the supplied item part of the number may not be unique in the library's own collection.
14:43 kados: 952 $m is seldom used but would come from 852 $m only from previous records of the same library.
14:44 kados: 952 $t would come from 852 $t only from previous records of the same library.
14:45 kados hmmm
14:45 that's a lot to parse
14:46 it occurs to me to ask why we're trying to map 852 to 952
14:46 thd kados: I already have most of the code for parsing that neatly written for you n Perl
14:47 kados thd: but why do we need to parse it at all?
14:47 thd: with zebra?
14:48 thd kados: well one reason for continuing to use a Koha specific items field is that you have the data in the wrong locations in existing records
14:48 kados thd: rebuildnonmarc can fix that up
14:48 thd: given a proper framework
14:49 thd kados: another reason would be that you do not have enough subfields for everything that you need to track in one field unless you use capital letters.
14:50 kados capital letters--
14:50 thd kados: 852 $A $B etc.
14:50 kados capital letters--
14:54 thd: how many items do we need to track?
14:54 thd: have you considered writing a 'standaard MARC holdings' framework?
14:54 thd kados: there are not enough lowercase letters and numbers and punctuation to hold all the predefined or reserved 852 subfields in addition to things that are not in 852 such as the things in 876-878
14:55 kados thd: I've been thinking it might be useful to separate the holdings definitions
14:55 thd: from the standard MARC framework
14:55 thd: to make it easier for customization  (ie, a smaller file)
14:56 thd kados: I did write a more standard MARC holdings framework in the recommendations comment within the standard MARC 21 framework
14:56 kados ahh
14:56 thd: perhaps I'll just pull that out then
14:56 thd: add the onloan stuff
14:56 thd: does it include call number goodness?
14:58 thd kados: It cannot be really standard unless you change all the code that needs one and only one MARC field defined for holdings.
14:59 kados: my recommendation is just like what I had specified for 952 except that their is a greater alignment between MARC 21 subfield names and what I specified.
15:00 kados thd: I think we could create a holdings framework
15:00 thd: and link holdings records to bib records
15:01 thd kados: oh you mean really standard
15:02 kados: do you mean with multiple fields for the holdings instead of everything in one field?
15:02 kados thd: well ... for 2.4 I mean just 852
15:02 thd: for 3.0 I mean a really standard one with multiple fields for holdings
15:04 thd kados: so 3.0 could work with the needed code changes but there is not enough room in 852 for everything needed unless you can use capital letters for the subfields
15:06 kados: would you change the data type as needed to allow capital letters for the subfields for 2.4. ?
15:07 kados thd: no
15:07 thd kados: otherwise you would need to remove standard subfields from MARC 21 to use 852
15:07 kados thd: too many components rely on aA equivilence
15:08 thd:  you mean that not all koha item fields map to standard 852?
15:08 thd kados: the best I have then is what I recommended for 85k in the framework comments with the addition of punctuation symbols for status etc.
15:10 kados: the problem is that they map to 852, 876-8 and a few others including one or two  that are no part of standard MARC.
15:10 kados hmmm
15:11 thd kados: which is why it had filled all th letters and numbers when you looked
15:11 kados tumer is removing that limitation for 3.0
15:11 right
15:13 thd kados: 876 has some additional medium or long term status indications, where purchased, for how much, replacement price etc.
15:14 kados: those are all mapped to existing Koha items columns and are not in 852
15:17 kados: 852 has a very few things which I did not map to 952 such as the address of the library
15:23 kados: 952 as I defined it is basically 852 combined with 876-8 with a few minor additions and omissions.  Obviously, the subfield names cannot match perfectly so I wrote the verbose librarian text to keep everything straight.
15:23 by subfield names I mean $a $b etc.
15:25 kados thd: I don't think it matters if they are all mapped to 852
15:25 I'm not sure what is preventing us now from being completely compliant with MARC Holdings
15:25 other than a fully defined framework
15:27 thd kados: you have a fully defined framework but you do not have code allowing the use of more than one field for holdings.
15:27 kados thd: code meaning the editor?
15:27 thd: what code is needed?
15:29 thd kados: wherever there is code that falls down when biblioitems.itemnumber is linked to multiple fields.
15:29 s/biblioitems/items/
15:30 kados hmmm
15:32 thd kados: because standard MARC needs 852 and 876-8 not just 852.
15:33 kados: you need to be able to distinguish between 852 $c shelving location and 876 $c cost
15:35 kados I see
15:35 thd kados: Koha also needs to distinguish different types of cost which MARC stores yet again in other locations acquisitions cost from replacement cost
15:36 kados Koha does too
15:36 cost and replacementcost
15:36 ahh, but they aren't in 852
15:36 in standard MARC
15:36 thd kados: but Koha has them both in the items table
15:36 kados but we aren't limited to using the items table now
15:36 thd kados: nothing about acquisitions is in 852
15:37 kados I see no reason to map cost to items at all
15:37 thd kados: do you not want to know what your items cost?
15:37 kados thd: with zebra we can still see that data
15:38 thd: we are no longer limited to searching/seeing data in the koha tables
15:39 thd kados: yes exactly but if acquisitions cost is associated with an item and not only in SQL then you need it stored in MARC which means that you need more than one field.
15:39 for standard MARC 21.
15:40 kados thd: so I suppose we should create holdings based on more than one field
15:41 thd kados: well you were proposing to do that for 3.0 not 2.4 a few minutes ago.
15:43 kados thd: I didn't understand the issues fully
15:44 it's hard to decide what is best in this case
15:45 thd kados: do you have a good concept of how much work that would be to fix on top of encoding?
15:47 kados thd: no
15:47 thd kados: you had said that tumer was going to do that for 3.0 does tumer have an idea?
15:48 kados thd: maybe
15:48 :-)
16:00 thd kados: some problems are amazingly simple to solve if you look at them closely.
16:01 kados: other problems like encoding rely on external software libraries that you cannot have time to rewrite yourself if they do not work.
16:01 kados: obviously, many uses of Encode::decode are needed for encoding where that can work.
16:01 kados: Debian stable may be at a special disadvantage with the out of date MySQL libraries that do not understand UTF-8.
16:02 kados: it was issues like that which drove me to switch to Debian testing much to my later regret.
16:02 chris thats what backports are for :)
16:03 thd chris: is there a backport of MySQL for upgrading that library?
16:03 kados thd: yes
16:03 thd: backports.org
16:03 hey chris
16:03 chris morning
16:03 kados chris: I'm ready to do a 2.3.0 release
16:04 chris: and I'd like to re-tag dev_week as rel_2_4
16:04 chris: if that's possible and you have time to show me how :-)
16:04 chris its pretty easy
16:04 easiest way
16:04 dewey easiest way is to try
16:04 chris do a clean checkout of dev_week
16:05 thd kados: what is 2.3 as distinct from 2.4?  Isa it the unstable version of 2.4?
16:05 kados thd: yes
16:06 thd kados chris: at the time I switched to testing I could net get the updated applications I needed from backports.  I should have been more patient.
16:07 chris then cvs tag -b branchname
16:07 kados can I then delete dev_week tag?
16:07 chris nope, you cant delete tags
16:07 kados ahh
16:08 chris you'll just be branching a new branch at that point
16:08 thd chris: what can be deleted in CVS?
16:08 chris nothing, thats pretty much the point of version control
16:08 doesnt hurt kados
16:08 kados k
16:08 chris you could just tag it
16:09 not branch .. but then youd still be working in the dev_week branch
16:09 thats what the script taht creates the tarball does
16:09 kados hmmm
16:09 chris tags up the files when you make a release
16:09 so at any point you can check out those files using that that tag
16:09 depends on what you want to do
16:10 kados well ...
16:10 what I think I want
16:10 is to have a branch that will become 2.4.0
16:10 I suppose I can just use dev_week for that
16:10 chris yep
16:10 kados poorly named, but fine
16:11 ok, I"ll just do that then
16:11 chris thats what id do, and use the script to tag the files as 2.3.0
16:11 kados no sense making it more complicated
16:11 ok
16:11 so when I run the script will it show up on savannah?
16:11 chris if you tell it to
16:11 kados cool
16:12 chris hmm did i commit my fixes to the script to dev_week?
16:12 lemme check
16:14 looks like its all set up for savannah yep
16:14 kados sweet
16:14 chris misc/buildrelease
16:14 kados I'll give it a shot then
16:16 chris: any specific way I should run it?
16:16 chris: and from a specific directory?
16:17 chris id run it from the base
16:17 in ./misc/buildrelease
16:17 in= ie
16:17 sorry prolly need
16:18 perl misc/buildrelease
16:18 kados perl misc/buildrelease
16:18 yea
16:18 ok
16:18 chris it should ask you
16:18 it makes a good guess
16:18 so if you are in the base .. then the guess will be right
16:18 (making sure you are in the dev week checkout of course :-))
16:19 kados chris: should it be a fresh check out?
16:19 chris doesnt have to be
16:19 but is probably safest
16:19 kados k
16:20 chris hmm interesting synchronicity
16:20 http://www.bigballofwax.co.nz/[…]07/11/eclipse-ide
16:21 kados neat
16:21 nice new website chris :-)
16:21 chris id encourage you to take a look at eclipse sometime .. with the epic plugin
16:21 kados will do
16:22 chris the syntax highlighting, and completion ... plus cvs integration
16:22 make it pretty cool
16:22 kados cool
16:22 chris ie you type " and it does the matching "
16:22 {} etc
16:22 kados sweet
16:22 chris plus you type $
16:22 and you get a list of variables you have already used
16:23 so its really good writing new big chunks of code
16:23 kados Would you like to tag the CVS repository?
16:23 I'm guessing Y
16:23 chris yes
16:23 kados well here it comes :-)
16:23 chris kados: that blog is my first real play with ruby on rails
16:24 kados cool
16:24 yea, I browsed some books at B&N last week about ruby
16:24 ok, the tarbal is in my dir now
16:24 is it also on savannah?
16:24 chris sweet
16:24 no
16:24 its not that cool :-)
16:24 kados :-)
16:24 chris you will have to go to savannah and do the release thingy
16:25 hmm lemme look
16:25 i havent done a savannah one before
16:25 but it should be similair to sourceforge
16:27 hmm maybe not
16:27 http://download.savannah.nongn[…]rg/releases/koha/
16:27 i think you just have to stick it in here, somehow
16:27 kados their searches suck
16:28 ahh
16:28 chris then write some release notes for the news bit
16:28 https://savannah.nongnu.org/projects/koha/
16:28 for on that page
16:28 kados yea
16:28 I've done news before
16:28 that's pretty simple
16:30 chris https://savannah.gnu.org/faq/?[…]o_I_add_files.txt
16:30 so we need a gpg key
16:30 kados k, I can handle that
16:37 chris :)
17:27 is half an hour up yet? :-)
17:31 kados yea, it's uploaded
17:31 and I did a news item on it
17:31 chris excellent
17:31 kados http://download.savannah.nongn[…]rg/releases/koha/
17:31 russ news item ? where?
17:32 chris on savannah
17:32 kados russ: probably not newsworthy in a general sense
17:32 chris http://koha.org/download/  <-- should we write something here
17:32 to make sure ppl know that 2.3.0 is unstable
17:32 kados definitely
17:32 but I plan on doing 2.3.1 in a day or two
17:32 so I'm not sure just how much news we want to generate :-)
17:32 chris otherwise they will click on the 2.2.5 link
17:33 kados yea ... 2.2.5 is still good I think
17:33 chris and see 2.3.0 sitting there
17:33 and grab it cos its newer
17:33 kados can't we just link directly to the download ?
17:33 russ two minutes
17:33 kados ie, not the file list?
17:33 chris probably the best bet
17:34 kados too bad you can't put text in the list
17:34 names and such like on sourceforge
17:34 chris yep
17:35 but then you also have to click 54 times to actually download the file
17:35 kados yea :-)
17:35 chris i think linking to the file and having good text around the link is the way to go
17:35 kados yea I agree
17:35 russ kados - can we move those wiki notes into the en section?
17:36 kados russ: sure
17:36 chris ill have a go with 2.3 after work, on my koha at home
17:36 kados russ: be my guest :-)
17:36 chris: I haven't touched the installation scripts yet
17:36 chris: but I can send you a tarbal of my migration stuff
17:36 chris but if i follow your docs on the wiki it should work eh?
17:36 kados yea
17:36 chris ill have a go by hand first
17:36 kados cool
17:37 chris so i have an understanding, then ill try out the automatic way
17:37 kados yep
17:37 it's no walk in the park :-)
17:37 chris :)
17:37 kados and there are some hard-coded things still
17:37 that need to be moved to the config file
17:37 chris yep i figure ppl will be asking questions sooner or later
17:37 kados yea
17:40 nothing like a release to make you feel like you've acomplished something in a day :-)
17:40 even if I know it's not a stable release :-)
17:41 chris :-)
17:53 thd kados: have you solved the problem of migrating a rel_2_2 installation with UTF-8 data?
17:53 kados thd: not yet
17:53 thd: it's more a 'how to migrate from mysql 4.0 to 4.1' problem
17:53 thd: for NPL it's hopeless
17:54 thd: because they had marc-8 data that was interpreted as latin1 data and I think it's been completely mangled in some cases :-)
17:54 thd kados: so you did not worry about the issue for NPL because NPL had relatively little MARC 8 data?
17:54 kados right
17:55 thd kados: If you had a script that searched for encoding problems you could concentrate on upgrading those records.
17:57 kados thd: I've got one
17:57 thd: it just needs to be updated a bit to deal with these specific probs
17:58 thd kados: really, would it also work for Afognak double encoding, and other similar problems that you have seen?
17:58 kados yes, given enough time to troubleshoot
18:00 thd kados: I think tumer has many records that he needs to find before his records including the problem ones become canonical for Turkey
18:01 kados: nothing like a new national authority file complete with encoding problems :)
18:02 kados :-)
18:03 that wouldn't bode well for Koha :-)
18:04 thd kados: no, having the national library of Turkey using Koha should be all to the good as long as the records can be shared without problems.
18:06 russ philip you there?
18:06 thd russ: I do not see philip logged in?
18:07 russ oops wrong channel
18:07 :-)
18:16 thd kados: looking at http://wiki.koha.org/doku.php?[…]tion_of_materials.  Does NPL not have full call numbers in 952 $k?
18:16 kados they do
18:16 thd kados: also, I have noticed that you have been using the old WIKI namespace
18:17 kados: the new namespace from devweek has en for English
18:18 kados yea, russ is gonna fix that for me :-)
18:18 thd kados: That way Pascal or whomever can make a French translation under /fr/ instead of /en/
18:18 kados yep
18:19 thd kados: russ had been cleaning the whole thing so that you would not have made the mistake in the first place.
18:19 kados :-)
18:20 thd kados: pierrick had also been working on that but he is no longer participating :(
18:22 kados: if using multiple holdings fields is discovered to be too much work for 2.4 do you know of any problems using punctuation for subfields all in one items field?
18:25 kados thd: looking at the framework right now
18:25 thd: got some questions
18:25 INSERT INTO `marc_subfield_structure` VALUES ('952', '2', 'Source of classification or shelving scheme (similar to 852 $2)', 'Source of classification or shelving scheme', 0, 0, '', 10, '', '', '', NULL, 0, '', '', '');
18:25 is that really necessary?
18:26 some of these seem like they won't ever be used
18:26 thd kados: it is necessary for designating the call number for fiction in the case of NPL.
18:26 kados how so?
18:27 (btw: items.wthdrawn not items.withdrawn ... a minor misspelling in the framework due to a poorly named column name)
18:28 thd kados: indicators are used to specify if the call number is LCC, DDC, NLM. or SUDOC, not that Koha is providing access to the 952 indicator currently.
18:29 kados: anything that uses some other classification is supposed to specify the classification in $2
18:29 kados specify what about it?
18:29 the name of it?
18:29 thd kados: the classification code and version number
18:30 kados: kados has not seen nearly enough correctly encoded records
18:30 kados :-)
18:31 thd kados: NPL's private scheme may not have a standard classification code but they can pretend if there is not one for generic local scheme
18:31 kados they aren't really up to doing that :-)
18:32 and it doesn't really serve any purpose
18:32 thd kados: no of course not but you have the system do it for them
18:32 kados: it allows classification searches to use information in the records to do an intelligent search
18:33 kados ok so I'll call it NPL v1
18:33 :-)
18:33 thd: do you know NPL's MARC ORG code?
18:34 thd kados: no but classification codes in MARC 21 are all lower case
18:34 kados thd: it's 'ONe' :-)
18:34 thd kados: do you not have the code list bookmarked
18:34 kados thd: 'ONe' :-)
18:34 thd: that's it ... pretty cool, eh?
18:35 thd kados: does LC do vanity classification codes for a special fee? :)
18:35 s/classification/organisation/
18:39 kados: the only thing that I remember having put in 952 that is not most likely to be useful is article '952', 's', 'Copyright article-fee code (similar to 018 $a, 852 $s)'
18:40 kados: although WIPO might care very much about that
18:41 kados: do you think they observe the rules they establish for everyone internally?
18:41 kados thd: so ... question
18:41 thd yes
18:42 kados if we created a full MARC authorities file
18:42 with MARC holdings
18:42 852, etc.
18:42 how many fields would need to contain itemnumber?
18:43 and could we acomplish the same thing with a link?
18:43 ie, link the itemnumber field to a field elsewhere in the record
18:43 thd kados: changing the code to use a link would be more MARC like but may not be the most efficient
18:44 kados with zebra I don't think it matters
18:44 in terms of searching we have no problem
18:44 of course, display is not a problem either
18:44 thd kados: do you mean full MARC holdings file not full MARC authorities file
18:44 ?
18:45 kados correct
18:46 thd kados: quite a few fields
18:50 kados: some are more important than others
19:04 kados: perhaps about 25 fields
19:04 kados ...
19:04 541 - IMMEDIATE SOURCE OF ACQUISITION NOTE (R)
19:04 561 - OWNERSHIP AND CUSTODIAL HISTORY (R)
19:04 562 - COPY AND VERSION IDENTIFICATION NOTE (R)
19:04 563 - BINDING INFORMATION (R)
19:04 583 - ACTION NOTE (R)
19:04 841 - HOLDINGS CODED DATA VALUES (NR)
19:04 842 - TEXTUAL PHYSICAL FORM DESIGNATOR (NR)
19:04 843 - REPRODUCTION NOTE (R)
19:04 844 - NAME OF UNIT (NR)
19:04 845 - TERMS GOVERNING USE AND REPRODUCTION NOTE (R)
19:04 850 - HOLDING INSTITUTION (R)
19:04 852 - LOCATION (R)
19:04 853 - CAPTIONS AND PATTERN--BASIC BIBLIOGRAPHIC UNIT (R)
19:05 854 - CAPTIONS AND PATTERN--SUPPLEMENTARY MATERIAL (R)
19:05 855 - CAPTIONS AND PATTERN--INDEXES (R)
19:05 856 - ELECTRONIC LOCATION AND ACCESS (R)
19:05 863 - ENUMERATION AND CHRONOLOGY--BASIC BIBLIOGRAPHIC UNIT (R)
19:05 864 - ENUMERATION AND CHRONOLOGY--SUPPLEMENTARY MATERIAL (R)
19:05 865 - ENUMERATION AND CHRONOLOGY--INDEXES (R)
19:05 866 - TEXTUAL HOLDINGS--BASIC BIBLIOGRAPHIC UNIT (R)
19:05 867 - TEXTUAL HOLDINGS--SUPPLEMENTARY MATERIAL (R)
19:05 868 - TEXTUAL HOLDINGS--INDEXES (R)
19:05 876 - ITEM INFORMATION--BASIC BIBLIOGRAPHIC UNIT (R)
19:05 877 - ITEM INFORMATION--SUPPLEMENTARY MATERIAL (R)
19:05 878 - ITEM INFORMATION--INDEXES (R)
19:06 kados: do you think that would be enough?
19:07 kados enough for what?
19:08 thd linking to items.itemnumber ?
19:09 kados hmmm
19:09 we need to link all of those?
19:13 thd kados: the only scary ones are 853-855 and 863-868
19:14 kados: 866-868 are not scary for humans, they are merely scary for computers.
19:34 kados: you would not need to link specifically to 841 but the shiny forest in SQL would be much more efficient to parse for the scary cases.
19:36 kados: I can present a simplified case for the only users that you can obtain now in any case
19:39 kados: acquisitions would need 541, 583, and 876 that is just 3 fields with 877-8 for very special cases
19:43 kados: cataloguing would need 852 or 856, and sometimes 863-868
19:44 tumer: is that really you?
19:44 tumer yep awake and zebraing
19:45 thd tumer: kados had said that you were intending to eliminate the dependence that Koha had on using one and only one MARC field for holdings.
19:45 tumer i already  did
19:45 thd for 3.0
19:46 tumer yep
19:46 thd tumer: really?
19:46 dewey really are quite different
19:46 thd tumer: and it works?
19:46 tumer yes i have separate marc record for holdings niw
19:47 thd: which field is best to hold the biblionumber in holdings record?
19:47 thd tumer: and do these separate holdings records use more than one of the holdings fields?
19:48 tumer they have their own 001 005 007 852- to 999 all
19:48 a complete marc record
19:49 any field to put anything in
19:49 no restrictions
19:49 well within reason
19:50 if kados spares same space i will commit the whole lot to the cvs
19:50 thd tumer: well if you are doing something non-standard for Koha I like some field with a letter in it like 90k but I realise that may require some code change
19:51 tumer i used to now i stick with standard LC nummbers
19:52 separate holdings,bibblios and authorities records you do not require fields with letters there is abundance of fields
19:52 thd tumer: well the standard place for the link number is 004 - CONTROL NUMBER FOR RELATED BIBLIOGRAPHIC RECORD
19:53 tumer great thanks
19:53 thd tumer: that would be the place for storing the 001 from the bibliographic record
19:53 tumer i hope to get a full koha intranet working on this model by weekend
19:54 thd tumer: are you no longer using SQL code for tracking the items?
19:54 tumer i already have biblionumber in 001 in biblios itemnumber 001 in holdings
19:55 there is nothing in sql any more only blobs of marc records
19:55 except issues and borrowers and subscript ofcourse
19:55 thd tumer: do you mean you are creating a separate holdings record for each item even if you have duplicate items for the same biblio?
19:57 tumer yes because even a second copy is a different entity which has copy 2 in it
19:57 thd tumer: do you have multiple copies of the same biblio in your library?
19:58 tumer yes but all call numbers end with c1 c2 etc so they are different and unique
19:58 thd tumer: you do not attempt to make use of the repeatable fields so that you have for example 852 $t1 and 852 $t for the first and second copies?
19:59 tumer: you do not attempt to make use of the repeatable fields so that you have for example 852 $t1 and 852 $t2 for the first and second copies?
19:59 tumer its easeier to manage them this way
19:59 thd tumer: yes that is very evident
19:59 tumer easier on indexing releases the starin on zebra
20:00 s/starin/strain
20:00 thd tumer: and there I was thinking about how to do it the most difficult way
20:00 kados: are you there?
20:04 tumer: that is brilliant to have done it the way that is both easiest and most efficient
20:04 tumer well thanks i dont know whether correct but thats how i designed it
20:05 thd tumer: that is perfectly in conformance with the standard which is the only important obstacle
20:06 tumer: I would like to persuade you to proceed with authorities in a standards compliant manner
20:07 tumer thd: i have to redesign authorities, the way they are now is not working
20:07 thd tumer: It may be a little painful in the short run but you will be much happier if they interoperate well with other systems
20:08 tumer: what about them is not working?
20:08 tumer thats my intention
20:08 thd tumer: specifically is not working?
20:08 tumer: what specifically is not working about authorities?
20:09 tumer all linking of authorities etc i have to study it a bit more
20:09 now we have thd producing some things i did some other all non complimenting each other
20:10 the editor does not work with them either
20:10 thd tumer: the editor code was never fixed for authorities
20:11 tumer i know
20:11 thd tumer: the authorities editor code needs to be copied from the bibliographic editor code
20:12 tumer yes but try to add a authors name to a bibliographic record from authorities. Its now a mess
20:12 thd tumer: do you mean with encoding?
20:12 tumer no
20:13 you try filling 700 it fills 690
20:13 all the java script messing it all up
20:13 thd tumer: ooooh that is bad
20:13 tumer i reported a bug but in vain
20:15 thd tumer: unfortunately, the only Koha libraries actually using authorities merely use the script designed to  fill existing values in the bibliographic records into the database.
20:16 tumer its not obvious untill you use subfield cloning -- the bug i mean
20:17 whats the use of creating authorities that you do not comply with?
20:17 thd tumer: those libraries are all using UNIMARC
20:17 tumer: they comply if they comply by using already compliant records.
20:19 tumer well its not good for me
20:19 we are creating 90% of our records
20:19 thd tumer: subdivided subjects will seem to need repeated $9s for most free floating subdivision $z $x $y $v
20:20 tumer thd i am so far away from the subject, also they have to be freely ordered
20:21 thd tumer: I suspect that having repeated $9 in the same way that BnF has repeated $3 for subject subdivisions is the only way to have a manageable authority file.
20:22 tumer thd:ok
20:22 thd tumer: repeatable $9 should allow for freely ordering the subfields
20:23 tumer: your library is  translating LC authority files, is it not?
20:23 tumer but i dont even know whether we actually fill $x $y $z from differnt authorities or one record that has all fields in it
20:24 currently its hybrid. LC subject headings beung translated but no actual records
20:24 thd tumer: decades ago LC stopped creating authority records with all the subdivisions in the authorised form
20:24 for subject
20:25 tumer BnF do dont they?
20:26 thd tumer: LC subject authority records only comprise about 13% of subject authority strings
20:26 13% of subject bibliographic strings I mean
20:27 tumer: BnF bends the UNMARC rule that specifies $3 as not repeatable for subject subdivisions
20:27 tumer thats a relief, I thought i was going to have them all like that in millions
20:29 thd tumer: subject authority files would be millions of authorised forms if they had to be complete subject strings with all the subdivisions in one record
20:30 tumer: LC only has circa 125,000 authorised subject headings which can be used to build all the others.
20:31 tumer i am in more clear now
20:31 chris is there authorities for other languages thd?
20:31 thd yes it is very easy
20:32 chris: although tumer says there are none yet for Turkish so he must create them
20:32 chris right
20:32 im betting there are none for maori too
20:33 which would be needed if the total emmersion schools were to use them
20:33 immersion even
20:34 maybe thats something the future foundation could do, help hold/build authority records for other languages
20:34 thd tumer chris: preserve the original LC record you may be translating into Turkish or Maori by giving the original heading in a 7XX linking field in the authority record
20:35 chris ahh good idea
20:36 tumer i give it in 750
20:36 i even linked them so searching in one language brings the other as well
20:37 but thats not standart i know
20:38 thd tumer: that is standard
20:39 chris: national libraries usually do that or some really large university library
20:39 chris: although most counties lack authority records
20:41 chris: authority records are found in Latin America even if under used but they are largely absent even in some relatively rich countries like Italy
20:42 tumer: you have done it precisely correctly as long as you are not still using $6 to link outside the record
20:43 $6 is for linking fields within the same record
20:44 tumer which subfield should it be 8?
20:44 thd tumer: $8 is also for linking within the record
20:44 tumer or a specific field?
20:45 as i say i know zilch about authorities
20:46 thd tumer: $0 is used for linking from the authority record to the original record although you should also preserve the original record control number in 035
20:47 tumer: an example is 750 #0$aSummer resorts$0(DLC)sh#85130430#$wna
20:48 tumer: http://www.loc.gov/marc/author[…]link.html#mrca750
20:49 tumer i will look into it
20:49 i have to check this zebra which is refusing to start
20:50 thd tumer: be careful not to be kicked from behind by your zebra
21:41 kados Burgundavia: still waiting for that email :-)
21:41 Burgundavia: I'll hold you to your purpose :-)
21:41 Burgundavia kados: it is stuck in the loop of no time
21:42 kados :-)
21:42 Burgundavia I am about to run out to the local LUG meeting
21:42 kados I hear you
21:42 cool
21:42 Burgundavia it is mostly written, just missing the mockup
21:42 kados excellent
21:42 can't wait to read it
21:42 I'll be working pretty much all week on 2.3.x
21:43 Burgundavia I just saw that annoucement
21:43 kados so now would be a really great time to have the ideas/mockup
21:43 Burgundavia what is policy on posting stuff to koha.org?
21:43 kados posting what?
21:43 announcements?
21:43 Burgundavia yep
21:43 the new development announcement
21:44 kados do you mean to savannah? or koha-devel? or on the website koha.org?
21:44 well I'm the release manager
21:44 so I can basically do anything :-)
21:44 muhahaha
21:44 if you have something you need announced you can generally send it to russ or someone
21:44 Burgundavia the website, in the little news box which has nothing in it
21:44 nothing new, that is
21:44 kados right
21:45 chris yep, ppl have to tell us news, then we'll put it there
21:45 kados well basically if someone has time to write something they submit it to russ
21:45 or someone
21:45 the project is really loosely defined
21:45 there are not that many core developers
21:45 so we basically know what's going on :-)
21:46 Burgundavia indeed
21:46 kados and news and stuff is loose as well
21:46 plus, koha.org is really just the project page ...
21:46 chris pretty much anything thats interesting or new, and someone tells us about can go up
21:46 Burgundavia the start of a major new development cycle is pretty good news, I think
21:46 kados the liblime team has enough trouble keeping our marketing website up to date :-)
21:46 Burgundavia gets people all excited, reminds them the project is not dead
21:46 kados yep
21:47 but it's really the tail end of the dev cycle
21:47 chris yep
21:47 kados we've been working on this release for about two years now :-)
21:47 Burgundavia 2.3?
21:47 kados yea
21:47 Burgundavia see, that is not how (as an outsider), interpreted your email
21:47 kados right
21:47 chris work leading up to 2.4 and 3.0 has been going on since 2.2.0 was released
21:48 kados yea
21:49 chris when 2.4 comes out there will be tons of fanfare on koha.org .. and on the main koha-devel list
21:49 Burgundavia yep
21:49 kados so 2.3.0 is basically where we've said "ok, stuff is actually working ... now lets test and bugfix, etc. and in a month or so, we'll have a stable product"
21:49 chris but for now 2.3 is so bleeding edge we dont really want too many people trying it
21:49 cos their will be blood everywhere :-)
21:50 Burgundavia no, but you do want people to be excited about it existing
21:50 chris there even
21:50 kados yea, bleeding edge is key
21:50 chris its hard to get them excited without them asking where is it, can i have it
21:50 kados Burgundavia: not really, because the core developers don't even know how to install it :-)
21:50 Burgundavia heh
21:50 chris its a tricky one
21:50 kados Burgundavia: only tumer and I have got it going so far :-)
21:50 chris maybe in a week or so
21:50 kados yea
21:50 Burgundavia ok
21:50 chris when we are at 2.3.2 ish
21:50 kados yep
21:51 I'll do 2.3.1 tomorrow afternoon
21:51 Burgundavia just don't want to miss an opportunity to get us talked about
21:51 kados already spotted some probs
21:51 also I want to get some public demos going
21:51 so folks can try it out with real data
21:52 Burgundavia: well, when you get to that email, I'm all eyes :-)
21:52 Burgundavia ok
21:52 chris yep its true, more publicity would be good, but id hate to have ppl see it, and then try it out and say it sucks because they cant install it :-)
21:52 Burgundavia too many projects, so little time
21:53 kados heh
21:53 chris but there are few new libraries running koha
21:53 Burgundavia somewhere in there I also need to finish that edubuntu case study
21:53 chris which we should do some news about
21:54 Burgundavia chris: just to introduce myself, I am Corey Burger. I work for Userful in the day and volunteer with Ubuntu/Edubuntu at night
21:54 chris ahhh ive seen your name around :)
21:54 Burgundavia nothing bad I hope :)
21:54 chris im Chris Cormack, i work for Katipo Communications in the day .. and some of the night too, and Koha all over the place
21:54 Burgundavia cool
21:55 chris trying to remember where ive seen it
21:55 Burgundavia I am co-author on the Official Ubuntu Book?
21:55 chris ahh
21:55 that'll be it
21:55 planet ubuntu
21:56 Burgundavia ubuntu is everywhere
21:56 chris yep
21:57 i met mark at linuxconf.au this year
21:57 Burgundavia ah yes
21:57 I was supposed to be at the Paris development conference, but it clashed with ALA in New Orleans, sadly
21:57 chris ahh yes
21:57 how was ALA?
21:57 Burgundavia big
21:57 chris it sounded big
21:58 Burgundavia a big, giant Windows world, with a few beacons of hope: our booth and Index Data's
21:58 chris :-)
21:58 Burgundavia our booth = Userful's
21:58 chris right
21:58 i think liblime was sharing with index data?
21:59 Burgundavia had a laugh at SirsiDynix claiming to built on "open standards"
21:59 yep
21:59 chris yeah
21:59 interestingly enough sirsidynix are taking up the first 2 hours of the first day of lianza (the nz equiv of the ala conference) here this year
21:59 Burgundavia interesting. What with?
22:00 chris the keynote address
22:00 Burgundavia ah
22:00 chris and then chairing a panel
22:00 Burgundavia "how libraries can spend more money on us"
22:00 russ http://www.lianza.org.nz/event[…]06/programme.html
22:01 chris im picking that will be the angle they will take
22:01 Burgundavia library I know is migrating Dynix Classic --> Sirsi Unicorn. Loosing 900k in fines, due to Unicorn not understanding that fines should persist after the book/thing has been removed from the collection
22:01 chris roll up roll up, get locked in to our solution, ull never escape
22:01 yikes thats a lot to lose
22:02 Burgundavia not too mention the headache of the migration itself
22:02 russ oooh that would cripple a public library in our region
22:02 chris 2 libraries in nz have migrated from old dynix to koha in the last year
22:02 Burgundavia they said that getting support for classic has basically been impossible since the merger
22:02 chris yeah
22:03 the ones who migrated really had no choice, migrate or upgrade
22:03 Burgundavia it is important to publicize any libraries that do migrate
22:03 the koha website gives the impression that it is a one library trick
22:03 chris yep, we are working with the libraries to get them to do some publicity
22:03 Burgundavia well, two, if you county athen county
22:04 count, that is
22:04 chris yeah, its more like a 200 library trick
22:04 but its hard to show that in a nice way
22:04 we used to have a map
22:04 on the old website ... and we need something like that again
22:04 Burgundavia a little news piece on the main website
22:04 X library has migrated from Y to Koha
22:05 chris http://old.koha.org/about/map/index.html <-- old map
22:05 Burgundavia I have noticed libraries hate being pathfinders on technology
22:05 russ i guess we have steered clear of that in the past
22:05 chris we try to get the libraries to give us the permission for that
22:05 Burgundavia ok, that is an amazing map
22:06 chris thats old too, theres lots more than that now
22:06 Burgundavia who does Koha marketing?
22:06 chris no one :)
22:06 Burgundavia hmm
22:06 chris katipo markets its services ... which semi markets koha
22:06 liblime does the same
22:07 paul in france does the same
22:07 Burgundavia but you have no Koha case studies, in printed form
22:07 nor a product guide
22:07 chris in printed, nope
22:07 we have lots in html
22:07 in the wiki
22:07 and at www.kohadocs.org
22:07 hehe
22:07 russ lol
22:08 chris have you looked at wiki.koha.org ... and www.kohadocs.org ?
22:08 Burgundavia yep I have dug through
22:08 chris thats pretty much what we have
22:08 we'd love printed material
22:08 Burgundavia most oss projects are bad on this
22:08 chris but suffer from the same only so many hours in the day proble
22:08 m
22:09 Burgundavia hence the edubuntu case study
22:09 chris right
22:09 Burgundavia http://ubuntu.ca/Edubuntu-casestudy.png
22:09 chris we have some printed material
22:10 some brochure stuff etc, that we (katipo) have used at ALIA online, and lianza
22:10 Burgundavia ah
22:10 chris and i think liblime has some
22:10 Burgundavia let me get this edubuntu case study out the door and the OPAC UI critique and I will see if I can take stock of what is available
22:11 chris but there is no really general koha ones
22:11 excellent :)
22:11 Burgundavia ideally you wanat something you can co-brand: liblime/katipo/koha-fr and koha
22:11 chris yeah that would be ideal
22:12 Burgundavia does koha have a palette? (aside from purple)
22:12 chris koha the project?
22:12 Burgundavia yep
22:12 chris hmm ill defer to russ on that one
22:13 you dont want me doing anything to do with design :-)
22:13 Burgundavia heh
22:14 russ ahh not really
22:14 Burgundavia ok
22:14 the blue and green on the website are not bad
22:14 anyway, I have to run
22:14 russ it is mainly the green and the purple
22:14 Burgundavia I will get my work IRC client on this channel as well
22:14 russ catch you later
22:15 chris cya later
23:16 thd kados: are you still awake?
02:39 ToinS hello world
02:40 chris hi toins
02:40 ToinS hello chris
03:43 chris toins: with the work you are doing with C4::Koha ... are you planning to use get_itemtypeinfos_of instead of GetItemTypes ?
03:44 or keep using GetItemTypes ?
03:44 ToinS i've not really worked on koha.pm
03:45 i've just meet getitemtypes in a script and renamed it
03:45 so i don't knw
03:45 chris ahh ok
03:45 btoumi hi all
03:45 ToinS hi btoumi
03:45 btoumi hi toins:
03:45 hi chris
03:46 chris hi btoumi
03:46 toins: i just noticed the FIXME but im not sure who wrote that
03:46 btoumi chris i have a question for u
03:47 can I?
03:47 chris i think they do different things, so i think keep using GetItemTypes for now
03:47 sure btoumi
03:50 ToinS chris: ok !
03:53 btoumi i work on fines
03:54 but i can't see all value for accounttype can u help me?
03:55 chris right
03:55 there is Pay
03:56 btoumi i find fu o f m lr lc status but not all
03:56 chris as well as those ones
03:57 L, F, Rep, F, FU, A, Pay
03:57 are the ones i know
03:57 btoumi ok
03:58 chris plus the
03:58 CS, CB, CW, CF and CL
03:58 btoumi can u configure them or not?
03:59 chris no, they arent configurable
03:59 you can add more if you need more tho
03:59 btoumi now i learn more about the fines functionnement
04:00 chris all the C ones are credits
04:01 btoumi because for my library we must  manage fines
04:01 chris right
04:02 btoumi but now the calcul of fines is do by fines2.pl ?
04:02 chris yes
04:02 and Accounts2.pm
04:03 btoumi i find a lot of problem with this file
04:03 chris and Circulation/Fines.pm
04:03 fines2.pl ?
04:03 btoumi yes
04:03 it uses a table whio not exist
04:04 chris ahh 2 seconds
04:04 ill update it
04:04 btoumi ok thanks
04:04 chris hm which table does it use?
04:06 maybe im looking at the wrong file
04:06 is it misc/fines2.pl ?
04:08 btoumi just one minute i think i make confuse with file i think i must sleep now
04:08 ;=)
04:08 chris :-)
04:09 btoumi i confirm
04:10 chris in head?
04:10 btoumi not fines2.pl but fines.pm because in fines2.pl u use fines.pm
04:10 chris ah ha
04:10 btoumi yes i work only in head
04:11 line 161 in fines.pm
04:12 chris ahh yes i see it
04:12 categoryitem
04:12 that should be issuingrules
04:12 btoumi yes
04:12 chris 2 mintues ill fix that sql up
04:13 btoumi i do it in my repository but i wasn't sure
04:13 that why i ask u
04:14 chris back before issuingrules existed, the issuing rules where in a table called categoryitem (borrower categories, plus itemtypes = categoryitem)
04:14 but issuingrules replaced that
04:15 there we go
04:16 damn
04:16 i edited that file just a while ago and didnt even notice that :-)
04:18 btoumi i'm happy to help u ;=)
04:19 chris :)
04:21 btoumi perahps i have another question for u but not for the moment
04:21 ty
04:22 chris no problem
04:25 btoumi another probleme with fines
04:25 chris yep?
04:26 hi arnaud
04:26 alaurin hi, how are u .????
04:26 btoumi calcfines was not called in export
04:27 chris ahh, it should be, can you fix that?
04:27 btoumi yes i do it
04:27 chris arnaud: im good thanks, and you?
04:32 alaurin fine, i'm near of my holidays, so , I feel good !!!!!
04:33 ToinS hello arnaud
04:36 alaurin hi Toins
04:37 btoumi chris: ok for fines.pm i have some probleme with my repository because call to calfine is ok in fines.pm
04:37 chris ahh ok
04:37 btoumi need one week for sleep
04:38 ;=)
04:39 chris hehe
04:40 paul hello world
04:40 chris hi paul
04:41 oh no
04:41 paul so works from Antoine home !!!
04:42 chris up near the Notre Dame de la Guarde ?
04:42 paul yep
04:42 chris there must be a great view for Antoine's home
04:42 paul my new home being close to ND
04:42 chris ohh cool
04:43 paul just on the other side of the hill (not sure of the word hill)
04:43 chris i think hill is right ... its a big hill though :)
04:49 will you get cable or adsl in your office paul?
04:49 paul adsl
04:49 something like 4MB dn / 800KB up
04:49 s/B/b/
04:49 chris cool, thats not bad at all
04:50 i have 2mb dn, 2mb up
04:50 on a cable modem
04:50 paul I had 6Mb previously, but my main concern is the up bandwidth
04:50 chris yeah
04:51 paul to investigage zoom & unimarc things...
04:51 chris excellent
04:51 did you see there is a 2.3.0 ?
04:51 paul ToinS will start cleaning acquistion module this afternoon
04:51 yep. it's a dev_week snapshot I bet ?
04:51 chris yep
04:52 cool, we merged all our fixes in the acquistion module in head a few weeks ago
04:52 so it probably needs some cleaning :)
04:52 paul did you look at ToinS code cleaning on suggestions ?
04:53 chris yes its really good
07:43 kados hi paul
07:44 paul hello kados
07:44 good morning to you
07:44 (working from ToinS home, because I still don't have any connexion at my new home :( )
07:45 do you have a few seconds for some questions ?
07:45 kados sure
07:45 paul http://wiki.koha.org/doku.php?[…]ingzebraplugin226
07:45 ToinS hi kados
07:45 kados hey ToinS
07:45 paul I'm not sure to understand :
07:45 - run rebuild-nonmarc from rel_2_2 if your framework has changed
07:45 #
07:45 run missing090field.pl (from dev-week)
07:45 #
07:45 run biblio_framework.sql from within the mysql monitor (from dev-week)
07:46 #
07:46 run phrase_log.sql from within the mysql monitor (from dev-week)
07:46   5.
07:46      export your MARC records
07:46   6.
07:46      run them through a preprocess routine to convert to utf-8
07:46   7.
07:46      double-check again for missing 090 fields (very critical)
07:46 rebuild non marc is OK I think
07:46 kados except it should say from dev_week :-)
07:47 paul i have completed this page & will continue as well, when I encounter something I don't understand well
07:47 kados have you done those steps? or don't understand how?
07:47 paul I haven't done anything yet
07:48 I just want to know what does those scripts ;-)
07:48 kados http://cvs.savannah.nongnu.org[…]_with_tag=R_2-3-0
07:48 they are in the zebraplugin dir
07:48 paul (+ learn what you mean by "preprocess routine to convert to utf-8 ? don't you have one already ?)
07:49 kados well ... preprocess includes many things
07:49 every previous version of Koha produced improper MARC records
07:49 so all of those marc records must be preprocessed
07:49 change encoding is just one step
07:49 dewey kados: that doesn't look right
07:50 kados other steps are to add a new leader
07:50 paul dewey : do back to bed please. It's time to sleep in new zealand...
07:50 dewey paul: excuse me?
07:50 kados add all of the fixed fields
07:50 (used for searching by date and format/content/audience)
07:51 plus ...
07:51 koha 2.x doesn't export items properly
07:51 so it's necessary to query items table to get the right values for items fields
07:51 all of that is covered under preprocessing
07:52 ToinS have someone ever seen this error : HTML::Template->param() : You gave me an odd number of parameters to param()! ???
07:52 paul yes ToinS : you have a 'XX' => $variable and $variable is probably empty.
07:52 try 'XX' => "$variable"
07:52 ToinS ok
07:52 paul kados: is there a script that does all of this for you somewhere ?
07:53 kados paul: it's not completely written yet
07:53 paul: and every client has different needs
07:53 paul yes, but that would be nice to have a starter ;-)
07:53 kados right ... but MARC21 is quite different than UNIMARC
07:53 I'm afraid it won't be useful to you
07:54 paul because I can accept that " so it's necessary to query items table to get the right values for items fields" but I don't know what it means exactly & what to code to fix this !!!
07:54 kados well ...
07:54 what it means is that somewhere in rel_2_2 code
07:55 when items are updated, MARC isn't
07:55 paul on transfers, right ?
07:55 kados also, somewhere in rel_2_2 code, 090 fields are being deleted or are never added for some records
07:55 NPL has several thousand!! missing 090 fields
07:56 paul wow ! strange, I never had this problem in France !
07:56 kados have you run missing090.pl before? :-)
07:56 you may be surprised :-)
07:56 paul I'll run & let you know if there is the problem
07:57 kados paul: also, we spoke briefly about acquisitions bugs before
07:57 http://wiki.liblime.com/doku.php?id=koha226bugs
07:57 a client has explained the bugs
07:57 and I have submitted bug reports for each confirmed bug
07:57 (welcome back :-))
07:58 paul ToinS will start code cleaning on head in the afternoon
07:58 mason hiya guys
07:58 kados excellent
07:58 hey mason
07:58 mason: kinda late, eh? :-)
07:58 paul: I hear your new home is very beautiful
07:59 mason i have some acqui. changes done in that last couple of weeks that ill commit to head in the next hour, too
07:59 tis only 1am :)
07:59 paul great mason, we will wait for them then
07:59 mason cheers paul
08:00 kados paul: it's good to have you back :-)
08:01 paul: been very lonely in #koha in the morning for me :-)
08:02 paul: http://liblime.com/public/roundtrip.pl
08:02 paul: there is a sample of a preprocess script that only converts to UTF-8
08:02 paul: for MARC21 only
08:03 paul: it also keeps track of problem records and saves them in XML and iso2709 form in separate dump files
08:06 paul2 ok kados, i'll investigate in the next minutes, i'll let you know if I have another problem
08:41 kados paul: I just investigated whether it would be possible to keep the rel_2_2 style API for searching, and I think it could be done with some minor changes
08:41 paul: changes only to the routines in SearchMarc.pm
08:42 paul good news...
08:42 kados paul: the CCL style of searching is very similar to the old API
08:42 :-)
08:43 the only tricky part is how to integrate the results
08:43 because with zebra, we get back full MARC records
08:43 not bibids
08:44 (in fact, we don't get the whole set of bibids at all ... that is kept in zebra)
08:44 so maybe each MARC record in the result set must be processed to split it into Koha fields and MARC fields for display
08:49 paul if you have the MARC record, MARCmarc2koha sub in Biblio.pm will create the Koha field easily
08:50 kados cool, thanks
09:12 paul kados : what do you mean by "update to the latest bib framework"? do you mean "update to the latest marc21 frameworks from thomas" ?
09:13 if yes, what is specific with them (as I can't do it for unimarc)
09:15 other question : I think convert_to_utf8.pl is redundant with updater/updatedatabase (see updatedatabase line 1404+ : it's the same alter table)
09:22 kados : another problem/question : i try to run missing090field.pl, but it fails, as it requires zebra working. are you OK if I move this part AFTER Starting zebra ?
09:25 kados : another one : biblio_framework.sql is partially already in updatedatabase. Are you OK if I put everything in this script ? (should be easy)
09:25 same for phrase_log.sql
09:25 hello tumer/
09:25 tumer hi paul sorry about france
09:26 paul the priest of my church is italian, so we all had a very large problem on sunday : could we have been happy with a victory from anyone.
09:27 in fact, this end was the worst possible, but also the best possible : it means nothing to win with penalties.
09:27 so it also means nothing to loose with penalties ;-)
09:27 tumer not if you ask italians
09:28 paul not all italians : our priest was happy, but only half happy.
09:28 and in 2 or 3 days, their joy will end with the justice decision, probably.
09:28 did you hear of this scandal in cyprus as well ?
09:28 tumer paul i am almost finishing a complete new api for record handling. 1 question?
09:29 do you think we shouldmanage itemtype at biblio level or item level?
09:29 paul mmm... this question should be asked to koha-devel. In UNIMARC, itemtype is a biblio level information.
09:30 the best being to have something like FRBR, that is incompatible with unimarc.
09:30 (and maybe with marc21 as well)
09:30 tumer so you cannot hve a CD version of a book under same biblio
09:30 paul no you can't, because it's a different intellectual object.
09:31 otherwise, we could, for example, put all books from the same author in the same biblio.
09:31 tumer a book with a cd causing us problems-- CD gets loaned out for shorrter
09:31 and sometimes separately
09:31 but they are in sme biblio
09:32 well may be we should change library policy tehn
09:33 paul note that we could have itemtype at item level & still have the same behaviour as previously, the library just would have the same itemtype for each item.
09:34 but I think it must be asked to koha & koha-devel ml
09:34 tumer i'll ask it there
09:34 here is what i have changed:
09:34 biblio table has only marc,biblionumber and itemtype
09:35 items has itemnumber,biblionumber,marc,barcode
09:35 kados paul: just make sure you have two conf files
09:35 tumer no biblioitems
09:35 biblio also has frameworkcode
09:35 kados paul: and you are using rel_2_2 bases when running missing090
09:35 hi tumer
09:35 tumer hi kados
09:36 paul ah, ok , it means you must have 2 DB during migrations.
09:36 kados tumer: I read your conversation with thd yesterda
09:36 y
09:36 paul: not quite
09:36 paul: you run missing090 in the database before you mysqldump it
09:36 paul: then you must run it again when you have the MARC data
09:37 paul: (because sometimes there are still missing 090 fields and zebra indexing will crash if they are missing)
09:37 tumer: please proceed with your plan and feel free to commit to HEAD
09:38 tumer kados:it will break everything itsa a complete new api
09:38 kados tumer: that's the point
09:38 tumer: there is no official HEAD api yet
09:38 tumer: what you are doing is closest to my vision of it
09:39 tumer ok but head has lots of junk old script in it, i have cleaned mine
09:39 how can i delete from head
09:39 kados good question
09:39 I wonder if savannah supports subversion yet
09:39 that would allow this
09:39 you can also do:
09:39 cvs delete file.pl
09:40 tumer does that put them in archive?
09:40 paul tumer: yes
09:40 kados yes, you can't actually delete them
09:40 paul (in Attic directory)
09:41 tumer so  what i will do is submit new biblio which will break all record handling ok?
09:41 paul you plan to break everything ? sounds cool to me :D
09:42 kados tumer: ok
09:42 tumer i think thats the only way to actually get good clean code
09:43 kados tumer: if you commit it I will take a look immediately
09:43 tumer: and tell you if I don't like something :-)
09:43 (note that HEAD is already completely broken)
09:43 (so it won't change anything :-))
09:47 tumer i am currently working on it hope to get it fully functional by this weekend and put it to production
09:48 then i will commit
09:49 btw it was not zebra problem zebra was crashing cuase this new M:F:X was not giving me xml_as_record
09:49 i did not understand why
09:58 kados weird
09:58 what new M:F:X?
09:58 is it the newest from SF?
09:58 tumer yep
10:00 i write $record->as_xml_record() and still get <colection> wrapper
10:00 paul kados : I can't get missing090.pl work correctly.
10:00 it calls MARCgetbiblio with a biblionumber as parameter.
10:00 in rel_2_2, the parameter must be a bibid.
10:01 and if I try with PERL5LIB pointing to dev_week, it fails, because the KOHA_CONF is not xml, but the old .conf file
10:02 so, I have to run it from dev_week 100% :
10:02 - copy rel_2_2 DB
10:02 - run updater/updatedatabase
10:02 - run missing090.pl
10:03 the good news being that i don't have any missing 090
10:03 kados excellent
10:03 paul oups, no, I have a few.
10:03 kados ahh...good for me :-)
10:04 paul 10 for a 14000 biblio DB
10:04 tumer but should be 0
10:05 paul right tumer
10:05 it's really a lot
10:06 kados : you've missed some of my questions it seems :
10:06  - update to the latest bib framework
10:07 means "update to marc21 from thomas"  ?if yes what is interesting for me to know for unimarc ?
10:07 (hello owen)
10:07 owen Hi paul
10:08 tumer paul i dont think you need it and infact should not otherwise you will loose your mappings
10:08 paul - biblio_framework.sql, phrase_log.sql are already partially in updatedatabase. Is it OK if I put everything there ?
10:08 kados yes
10:08 everything should be in dev_week updatabase
10:09 eventually I would have put it in but didn't get to it
10:09 paul ok, i take care of it & update the wiki
10:09 kados thx
10:09 tumer biblio_framework update is not an essential part of this upgrade is it?
10:09 kados yes
10:09 it's poorly named
10:09 tumer it merely adds more field definitions to what we already have and which we will not use
10:09 kados biblio_framework.sql is what alters biblio and moves the frameworkcode as well as adding some columns
10:10 tumer ahhh
10:10 paul things that are already in udpatedabatase (like utf-8 conversion)
10:10 kados utf-8 conversion should not be in updatedatabase
10:10 paul why ?
10:10 kados the wiki is not up to date with my latest tests
10:11 because depending on the version of mysql you are migrating from, converting to utf-8 could mangle all your data
10:11 if you are running rel_2_2 on 4.0
10:11 there is no character set support
10:11 paul right. but we require 4.1 isn't it ?
10:11 kados but you table and database definitions are probably set to latin1
10:11 I speak of migration
10:11 for new installs the procedure is different
10:12 paul so we should add a test to check for 4.1 when starting updatedatabase ?
10:12 kados you can't
10:12 paul I can't what ?
10:12 kados you'd have to test the mysqldump to see if the data was coming from 4.0 or 4.1
10:12 paul add a test or require 4.1 ?
10:12 kados 4.1 is required for dev_week
10:12 but most libraries will be migrating from 4.0
10:13 if you migrate from 4.0 you must do special things to preserve your character sets
10:13 paul but I thought we have said previously that 4.1 will be required for Koha 3
10:13 kados yes
10:13 4.1 _is_ required for 2.4 and 3.0
10:14 paul se a library migrating from Koha 2.2 will have to deal with mysql upgrade if needed.
10:14 kados but most libraries are running 2.2 on mysql 4.0
10:14 paul before upgrading.
10:14 kados yes
10:14 but that is a complicated process
10:14 paul and we could check this in updater.
10:14 kados I doubt it
10:14 there are so many cases
10:14 what encoding they started on, what they want to end up with, etc.
10:14 paul so, in updater, if mysql 4.0 => stop immediatly, if 4.1 => continue
10:15 kados if 4.1, make sure the mysqldump is from 4.1 or stop immediately
10:15 paul but everybody & everything will be in utf8 in 3.0
10:15 kados yes, but you need to convert it to utf-8 _and_ tell mysql that it is utf-8
10:15 paul and mysql alter table know where it comes from isn't it ?
10:16 kados http://wiki.koha.org/doku.php?[…]ncodingscratchpad
10:16 ok
10:16 I will give you NPL as an example
10:16 paul yes, i've read, but that's not enough for me
10:16 ok, listening
10:16 kados before Koha NPL had MARC_8 encoded records
10:16 they imported them into a mysql 3.23 db
10:16 the database was set up for latin1 defaults
10:16 so ...
10:17 when NPL migrated from 1.9 to 2.0 using mysqldump
10:17 all of the data was mangled by mylsql
10:17 so now NPL has a database that thinks it has latin1 data
10:17 but actually has marc8, mangled once in a conversion
10:18 to upgrade, NPL must:
10:18 paul what does 'mangled' means ?
10:18 kados alter the mysql tables and convert to binary or blob
10:18 (so now mysql doesn't know the encoding)
10:18 (mangled means the characters have been re-encoded)
10:18 (as was common when moving from 3.23 to 4.0 (which started having some character set support))
10:19 (so now mysql doesn't know the encoding because the data is of type blob, etc.)
10:19 so now we can run mysqldump without mangling the data
10:19 (again)
10:20 now we need to convert everything to utf8
10:20 then we need to tell mysql that the tables are utf8
10:20 and in the case of the MARC data, we need to update all the leaders
10:21 but every Koha migration will be different
10:21 depending on the mysql version and encoding defaults they are using
10:21 and the type of MARC
10:22 paul: make better sense?
10:22 paul: for a new install it's much simpler
10:22 paul yes partially make sense now.
10:22 kados paul: a library must simply make sure that mysql 4.1 is set up with the correct encoding
10:23 paul: and that all their data is in utf8 before importing
10:23 paul to rewrite it : depending on what you really have and what mysql think you have, you will be in a big pain ;-)
10:23 kados yep :-)
10:23 esp for french libraries
10:23 who have many non-ascii characters
10:24 paul to transform from one to another encoding, is iconv enough (on the dump) ?
10:24 kados you can transform within mysql itself
10:24 I don't know about iconv
10:24 paul how do you do to know what is the real encoding ?
10:24 kados hehe
10:24 there is no way to know
10:24 unless you know beforehand :-)
10:25 paul really nice...
10:25 kados you can examine the hex :-)
10:25 the reason I know all of this
10:25 paul but we don't have any hex in mysql
10:26 kados is because with WIPO, I was losing hair trying to get mysqldump to export utf-8 data to their db
10:26 because I didn't know that mysql thought it had latin1, not utf-8
10:26 very frustrating
10:26 no hex in mysql
10:26 you need to export to a file
10:26 paul ah, I understand now why you don't have your long hairs anymore...
10:26 kados well ... even that could change it
10:26 some tests will need to be done
10:27 mysqlhotcopy will take a snapshot of the db
10:27 without touching the encoding
10:27 so you can set up a test environment
10:27 on another server
10:28 it's a really big problem, unfortunately, maybe too big a job for updatedatabase :(
10:28 but it's also unreleated to zebra :-)
10:28 it's a problem we created ourselves :-)
10:28 paul do you know how we created it ?
10:28 kados yes
10:29 because we said 'koha can run perfectly on any version of mysql with any settings'
10:29 and not 'make sure you are running mysql 4.1 with encoding set to the same as your data'
10:29 paul mmm... I never said that... but I agree that I never checked ;-)
10:30 kados (we of course, didn't say it, it was a sin of omission :-))
10:30 paul my problem is that I think I alway had iso8859 datas, but I was probably wrong, and I'll discover it soon
10:30 another question :
10:30 if the datas where not iso8859, how is it possible to have correct MARCdetail ?
10:30 (with proper accented chars)
10:30 kados hehe
10:30 that's just the best part
10:31 mysql will let you store any encoding
10:31 it doesn't care what you put in
10:31 except when you try to mysqldump or convert to another encoding
10:32 so you may have correctly encoded values
10:32 but to get them out you must trick mysql
10:32 paul but when you put it on a web page, if it's not 8859, the page should be wrong in the browser isn't it ?
10:33 kados isn't 8859 eq latin1?
10:33 paul yep
10:33 kados so if your encoding is 8859, and your db is 8859, and your meta tag is 8859, it's all good
10:34 paul but you said that I could not be sure of my real encoding. So, if mysql = latin1, meta=latin1 and the pages are OK, then I have real latin1 datas ?
10:34 kados sounds like it
10:34 paul if yes, then all my libraries are ok !
10:35 that's what is nice with a language that uses accents : any problem is easy to find ;-)
10:35 kados :)
10:35 so you can probably convert to utf8 before mysqldump
10:35 (use a test db first of course)
10:36 paul of course.
10:37 bon appetit !
10:45 kados : how do you export your datas ?
10:46 because export/export.pl is buggy (compilation failure)
11:07 kados paul: in rel22 it should work
11:10 paul forget this, my copy was wrong. i had updated from something locally modified, so I got some cvs errors. restarting from a fresh copy
11:11 thd kados: did you understand from reading the logs what tumer had done for holdings
11:11 ?
11:11 paul hello thd.
11:11 thd hello paul
11:16 kados thd: yes, and I approved it
11:16 ToinS paul : updatedatabase has not been merged between rel_2_2 & head
11:17 kados thd: it will be in head as soon as tumer deems it stabler :-)
11:17 ToinS: I did it yesterday
11:17 ToinS kados ah ok
11:17 thd kados: he is not using it in production yet?
11:18 kados: did you see my message about how there are only about 3 fields for the librarian to worry about in standard MARC 21 holdings?
11:18 kados thd: no
11:18 thd: tell me
11:18 thd kados: or 3 at a time
11:19 kados: acquisitions would need 541, 583, and 876 that is just 3 fields with 877-8 for very special cases
11:19 dewey i already had it that way, thd.
11:20 kados mainly dev_week and rel_2_2 are merged
11:20 thd kados: cataloguing would need 852 or 856, and sometimes 863-868
11:20 kados there are a few that need to be manually merged
11:20 like biblio.pm, if there was anything in there
11:20 thd: if they are defined in tab 10 they will show up I think
11:21 even in the current scheme
11:21 thd kados: only 952 is defined in tab 10
11:22 kados: would you not use the MARC editor to load a holdings record?
11:23 kados: that would give the librarian access to whatever is needed
11:24 kados: a holdings framework would in the case of MARC 21 be a very trimmed down bibliographic framework
11:25 kados ahh ...
11:25 right
11:25 thd kados: the fields are all there it is just a question of unhiding them
11:25 kados so the regular MARC editor would be used
11:26 thd kados: although, tumer has spotted an editor bug for filling a field from an authority field
11:26 s/field/record/
11:27 kados: tumer reports that if you add a repeated field the authorised heading fills the wrong field
11:29 kados: in his case he found that an attempt to add an authorised heading was filling 690 instead of 700 after a repeatable field had been added
11:29 kados thd: I'll take a look
11:29 paul kados/tumer/thd : which templates are OK for dev_week ? npl ?
11:30 thd kados: will there be a meeting today?
11:30 now that paul is back
11:30 kados paul: only npl are tested
11:30 paul i'm not back thd
11:30 thd welcome back paul
11:30 no
11:30 kados paul: and don't expect searching to work except at opac-zoomsearch.pl
11:30 paul: :-)
11:30 paul i'm at ToinS home, so I will not be here everytime
11:30 thd paul: you are still moving?
11:31 kados thd: no time for a meeting today
11:31 paul my move is done. but still no DSL
11:31 thd paul: do you have dial-up
11:31 ?
11:32 paul i've DSL at ToinS home. I may be able to have a dial up, but it's very expensive
11:33 thd paul: I have cheap dial-up because my building has the wrong too old equipment for cheaper DSL and the telephone company will not replace it.
11:35 paul: I will have optical fibre or a hole in a foundation wall before the telephone company will replace a circuit box from the 60s.
11:36 monopolies in action
11:39 kados: why was it so difficult to think of the simplest most efficient solution for standard holdings?
11:40 kados thd: sorry, got a lot on my plate right now
11:40 thd: I really want to resolve the standard holdings issues
11:40 thd: and I think we're very close
11:40 thd: but don't have the time today to discuss deeply
11:41 thd kados: tumer has it by not needing repeated fields just repeated holdings records
11:42 kados: OK I have to go now in any case
11:51 paul kados ?
11:51 dewey kados is probably becoming a true Perl Monger...
11:52 paul zebraidx -g iso2709 -c /koha/etc/zebra-biblios.cfg -d kohaplugin update /path/to/records => /path/to/records is the path to all records, right ?
11:52 so we have to export all of them in 1 big file (using export/export.pl) or 1 for each biblio ?
11:53 kados all in one file
11:53 tumer[A] paul one big chunck
11:53 kados file must be named *.iso2709
11:53 and put in /path/to/records
11:53 paul the /path/to/record being a directory with only this file, or can contains other things ?
11:53 kados it can contain other things
11:54 but they will be ignored
11:54 tumer[A] only with marc records
11:54 sometimes does not ignore them
11:54 kados only files with an excension of .iso2709 will be noticed
11:54 ahh ... tumer is probably right, i have not tested this extensively
11:55 tumer kados:it tries to read every file and sometimes goes crazy saying they dont have id's so best to have marc records only
11:55 kados :-)

← Previous day | Today | Next day → | Search | Index

koha1