Time Nick Message 20:29 chris heh 20:24 owen Hi chris, how's it going? 20:23 chris morning 18:59 cait hm its really slow atm, but working, can i do something to make ist faster? i read about changing configuration file of mysql, is there some documentation about it somewhere? 18:57 cait gmcharlt: i cannot chat from work :( but i will copy the results from indexing, so i can ask better questions, thx for the help so far! I will try -k 18:55 gmcharlt also, zebraidx (which is run by rebuild_zebra) will usually give some explanation, albeit often a cryptic one 18:55 gmcharlt it will tell you the name of the directory, and you can inspect it to make sure that the records were extracted OK 18:54 gmcharlt cait: one idea is to add -k to the option list - that keeps the temporary directory around 18:53 cait gmcharlt: some ideas, what i can try to find the mistake? 18:53 gmcharlt yep 18:53 owen ...hence the recent discussion. 18:52 gmcharlt owen: hehe; no, it doesn't. sometimes you want to check a .gitignore into git 18:52 owen gitignore doesn't ignore itself? 18:51 cait configuration, version and import the same... ok, cant be the same, but should 18:51 cait here its i/u/d 40307/0/0 at work its 0/4/0 18:49 cait at home is working now, missing daemon, problem at work must be different :( but one working installation is great for me atm 18:48 cait ive got two installations-- one at work and one at home 18:48 gmcharlt cait: great 18:48 cait gmcharlt: its working now it seems 18:48 cait ah hi 18:45 gmcharlt owen: yes 18:45 owen Just a plain file with a separate line for each name or pattern? 18:44 gmcharlt cait: what output did you get when you ran rebuild_zebra? 18:43 gmcharlt should contain names or patterns (e.g., *.temp) of files to ignore 18:43 gmcharlt owen: it's just a file called '.gitignore' in the top level of your reposistory (or any subdirectory) 18:42 owen How do you create a gitignore file? 17:24 cait running away? ;) 17:20 cait database is unimarc and version newest snapshot from git 17:19 cait can somebody help me? 17:19 cait i imported 50.000 titles yesterday with holdings and i can check them out... but search does not work :( used rebuild_zebra -b -w 17:18 cait hello #koha 16:27 Brooke yo! 16:26 nengard hi brooke 15:53 fbcit ;-) 15:53 fbcit atz++ on window changing 15:51 atz er... ignore that 15:51 atz not sure on that one... card size printouts, I'm guessing 15:24 mc - vincent (the maintainer still contacted slef) 15:23 mc - indexdata is happy about that and will co-maintain their own packages 15:23 mc - his goal is to provide a koha package 15:23 mc he told me that 15:23 mc well ... i had words with libyaz debian maintainer 15:21 gmcharlt mc: fyi, slef (MJ Ray) is the one currently/most recently involved in efforts to build a Debian package 15:21 gmcharlt mc: yep 15:20 mc (there is an itp on it) 15:20 mc btw: find the packages that koha really requires will help us to build a future koha package 15:20 fbcit hello #koha 15:19 mc gmcharlt, this was my first attenpt to install koha so i don't know what changes 15:18 gmcharlt mc: personally, I've never had any particular problems using debian.packages on a fresh Etch 15:18 mc so i asume that they aren't really aware of the result if it works 15:18 gmcharlt mc: unifying the Debian package deps and Perl deps would be nice - to clarify whether something is available in Etch or Lenny 15:18 mc it's for those who don't want to struggle with debian problems 15:17 mc as said in readme : 15:17 mc sure 15:17 mc hmm ... readme does (or will) 15:17 gmcharlt mc: which should be fine for most users, I expect, but not necessarily all 15:16 gmcharlt mc: sounds reasonable, although script should then warn user that a mixed Etch/Lenny setup will result 15:16 mc and i use lenny ones when possible 15:15 gmcharlt hdl: and nothing precludes still maintaining index defs for classification from the bib record 15:15 mc another difference with the kaos doc : i only use cpan when i can't install some perl packages 15:15 gmcharlt hdl: sorting by item callnumber should still be possible, as itemcallnumber is indexed 15:15 hdl if we tell them it is not possible to sort by callnumber anymore 15:15 mc ( i set it in the script for test only, it will be removed before commit) 15:15 mc gmcharlt, for lenny_repo : it uses apt-spy if you don't set it 15:14 kados afaict 15:14 kados hdl: that should be an item browse feature anyway 15:13 kados hdl: yes, we'd have to abandon search and sort by call number/class at bib level 15:13 mc - i experienced weird conflicts with them 15:13 hdl kados : "XSL gives us that for free" not quite since you donot have sorting by element. 15:12 mc - list a lot of packages that are in dependancies 15:12 gmcharlt mc: some way of setting LENNY_REPO automagically would be nice for those not in France 15:12 mc gmcharlt, because the debian.packages 15:11 gmcharlt mc: but why isn't it using install_misc/debian.packages ? 15:11 paul (on phone) 15:11 kados paul, hdl: do you guys agree? 15:11 kados ryan: how would that work on the data migration front? 15:11 kados I can live with that 15:11 gmcharlt mc: install script looks intereseting 15:11 kados otherwise, item-level call numbers are in items.itemcallnumber and don't display on results pages 15:10 kados (directly from the MARC) 15:10 kados ok, so I think what we're saying is, eliminate cn_* from biblioitems, and use XSL to display bib-level classification on results pages and that's customized per library 15:10 gmcharlt ryan: biblioitems.cn_* actually work against implementing a hierarchical lookup of bib fields for a default call number, since there's only one of them 15:09 kados (almost) 15:09 kados yea, XSL gives us that for free 15:09 gmcharlt ryan: yup; but you can implement that by looking at the MARC record 15:09 kados gmcharlt: *nod* good example 15:09 ryan lots of 060's but also use 050s or 090s 15:09 kados thats where cn_* comes in handy 15:09 ryan medical libraries are a common example 15:08 gmcharlt kados: multi-class scheme use is one of the big arguments for focusing on item-level call numbers 15:08 kados depending on the record 15:08 kados so imagine a mixture of 090 and 092 and 082 15:08 ryan a lot of people also expect a cascade : if there's an 090, use it, if not, use 050 e.g. 15:08 kados also, another issue that comes up, is that people sometimes have more than one class scheme 15:08 gmcharlt kados: and rely on git to help manage customer-specific mods 15:08 mc in a normal time (when ftp.perl.org isn't down), it can install koha by typing only one command and answer to questions 15:08 gmcharlt kados: well, pick defaults wisely 15:07 kados and to not deviate from those rules? 15:07 kados gmcharlt: so maybe the way to approach this is to make some rules about how Koha works 15:06 mc is it a good thing to se it appears in the git repo 15:06 mc can you tell me about this koha installation script ? 15:06 gmcharlt kados: yeah, but they're doing it wrong ;-) OCLC says 090 for locally-assign LC number 15:06 mc http://hyperion.u-strasbg.fr/koha/ 15:06 kados it's a tricky issue 15:06 mc in fact, i have a message for all debian users: 15:05 mc hi kados 15:05 kados hi mc 15:05 kados and we have some special/academic libraries (Faith for instance) that expect that to be LC 15:05 kados gmcharlt: I think OCLC puts call numbers in 092 15:05 mc kados ? 15:05 kados it'd be ideal if we could come up with a koha default that allowed minimal customization per library and fulfilled both options for having and not having bib-level call numbers 15:04 gmcharlt kados: perhaps some generic indexing defs would handle it: bib-dewey-class from MARC21 082/092, bib-lc-class from MARC21 050/090 15:04 kados I don't like this problem :-) 15:04 kados yea, I know 15:04 gmcharlt kados: one issue with 942 is if you change a "standard" field (050, 082), do you need to deal with repopulating 942 15:02 kados but maybe that's unrealistic 15:01 kados because of the overhead managing those 15:01 kados gmcharlt: yep ... originally I'd put it in 942 fields so we didn't have ot have per-user indexes specified and per-user frameworks 15:01 gmcharlt of course, fly in ointment is that XSLT for OPAC is still experimental 15:01 gmcharlt wouldn't actually require a separate biblio.classifcation or biblioitems.cn* 15:01 gmcharlt and using bib field(s) as a default call number 15:01 gmcharlt kados: if call number is in MARC record, OPAC can display it directly from MARC (at least, if you're using XSLT), and you can index it directly from MARC 15:00 kados I wonder if the reasoning behind that is you only have to enter it in once, at the bib level and it replicates automatically to the items 14:59 owen We have in the past 14:59 kados owen: NPL does biblevel classification too, right? 14:59 kados gmcharlt: HCL maintains both biblevel in 092 and item level ... primarily so they can display call numbers in search results and they use them to display icons for things like audience and format 14:58 hdl wouldn't really bet on thet. 14:58 gmcharlt but why an intermediate level? 14:58 hdl mmm... 14:58 paul so we could remove them harmlessly 14:58 gmcharlt hdl: I can see classification at biblio level, and call number at item level 14:58 paul if I don't mind, nobody here (BibLibre) uses biblioitems.cn_* 14:57 paul hdl++ 14:57 hdl imho, classification or callnumber is important at both biblioitem and item levels. 14:56 hdl and going back and forth is not quite reassuring for ppl. 14:56 hdl sure. 14:55 kados I think a decision needs to be made on this before 3.0 stable is released 14:55 gmcharlt I think removing cn_* from biblioitems would be a good idea, but I realize there could be Koha usage patterns that still rely on those 14:54 kados so do we remove cn_* from biblioitems? 14:54 hdl gmcharlt: I agree with you. 14:54 gmcharlt but to clarify, I'm saying that items.itemcallnumber (or rather, a dedupped view thereof) should be what goes in a Call number field in the OPAC search results by default 14:53 gmcharlt paul: right :) 14:53 paul yes, and that's why we have the field items.itemcallnumber ;-) 14:52 gmcharlt others just have it be an attribute of item, and don't update bib 14:52 hdl her 14:52 gmcharlt some libraries update bib with their call number 14:52 gmcharlt and library cataloging practice varies a lot 14:51 gmcharlt a library could choose to display the call number directly from the bib (i.e., MARC21 050, 082, 090, 092, or whatever), but bib classification is not necessarily what's on the item spine label 14:51 gmcharlt yes - my view is that it should be (a dedupped) list of item call numbers, i.e., whatever is actually on the items 14:51 kados hdl, paul? 14:51 kados gmcharlt: thoughts? 14:51 kados but is that what koha should do by default? 14:50 kados some libraries seem to maintain a bib-levl call number along with an item-level 14:50 kados I had thought cn_class and cn_item, but I think gmcharlt disagrees with me 14:50 kados that's atually up for discussion 14:50 owen What should be displaying under "Call Number:" ? 14:49 kados owen: sure ... go for it 14:49 owen kados, I have a question about the redesigned OPAC results screen when you get a moment 14:42 nengard owen - not quite this - but this is a sample: http://mineralsprings.com/Catalog/LabelTemplate_20.jpg 14:41 nengard owen let me see if i can find one 14:41 nengard it's just an enhancement request ... no i was thinking on image with a couple of labels - size doesn't matter - just to show people where each measurement comes from 14:41 owen are you thinking of a single image which labels the various aspects that can be entered in the form? 14:40 nengard yeah 14:40 nengard ahh 14:40 nengard owen - let me open that up 14:39 owen nengard: regarding Bug 2069... 14:11 paul thx 14:11 kados paul: response sent 14:03 nengard owen she asked if you can get on gmail chat 13:53 nengard owen she's reporting bugs right now ;) hehe 13:53 kados nengard: the general rule of thumb is that the person who opened it should close it when it's fixed 13:52 owen tinaburger? 13:51 nengard i have a bugzilla question - who closes the bugs? should I if you've fixed them? or should you be doing that? i have a lot of open bugs on my list that aren't really open anymore 13:51 kados paul: response to your email forthcoming 13:50 nengard owen i know :( 13:50 owen If only we were out of big bugs to fix ;) 13:49 nengard :) I was just telling tina that we have nearly run out of big bugs to report and everythng we're reporting seems pretty small now 13:49 owen nengard: you caught me at just the right time for these small fixes 13:48 nengard authority types++ 13:48 nengard owen they used to call me speedy gonzales at my first library cause i fixed things so quickly - i think you're quicker :) hehe thanks for fixing that - and sorry i'm such a stickler for consistency :) 13:46 hdl Authority types++ 13:46 kados Authority types++ 13:21 gmcharlt owen: I vote for "authority types" 13:20 owen (admin/authtypes.pl) 13:19 owen So, which is preferable as a heading/link/description: "MARC Authorities framework" or "Authority types" 13:10 acmoore yeah! I just looked in my email again too, and I think it was removed from both directories, too. maybe I have my working directory goofed up. perhaps I don't understand git as well as I should or somehting. 13:09 paul owen : thx for your humour :D 13:09 acmoore oh well. Don't worry about it. The patches look right to me, so perhaps my directory is just goofed up. I'll look into it more on my end. 13:09 owen According to that JNF.gif was removed 13:08 owen http://git.koha.org/cgi-bin/gitweb.cgi?p=Koha;a=commit;h=c0a0e885b99638a5fe021a75e322afec869ecfdf 13:08 acmoore grr. I'm sure this is just something I'm overlooking or something. 13:08 owen I'm not sure what that means 13:07 owen Hmmm... the directories are identical in my repo, even after a fresh fetch and rebase 13:06 acmoore there's a t/icondirectories.t script that I checked in that's supposed to compare the two directories, and it's complaining about that one, so that's how I noticed. 13:05 acmoore but, I thought I saw JNF.gif removed in both patches. 13:05 acmoore koha-tmpl/intranet-tmpl/prog/img/itemtypeimg/npl/JNF.gif exists, but koha-tmpl/opac-tmpl/prog/itemtypeimg/npl/JNF.gif doesn't. 13:04 owen The sets differ now? 13:04 owen You bet 13:04 acmoore I can't quite figure it out. Do you have a second? 13:04 acmoore hi owen. Thanks for helping with the itemtype icon stuff. In looking at your patches, it looks like you removed the same icons from each of the opac-tmpl and the intranet-tmpl directories, but they don't look the same to me anymore. 12:57 paul acmoore: thx. pls write your opinion on koha-dev ;-) 12:57 acmoore paul++ # encouraging planning 12:39 nengard owen - thanks!!! looks like you're right! 12:37 owen I'm not real familiar with the process, but it looks like he's talking about the "New Layout" form, where you can choose a "layout type" 12:34 nengard info/Barcode, 2. Barcode/Bib info, 3. Barcode, 4. Spine." but I don't see where this is 12:34 nengard owen in the email chris nighswonger says "There are currently four different label styles available: 1. Bib 12:32 nengard paul - that makes sense - but i see the documentation as an ever growing being 12:32 owen nengard: I assume so 12:32 paul on another branch. 12:32 paul yes, but no. We can (& should imo) "branch" a stable version & continue on the next one. 12:32 nengard owen this page? koha/labels/label-home.pl 12:31 nengard paul no problem - i figured that i'm going to be writing forever and ever :) that's the nature of open source :) 12:31 owen Hmm... but he was talking about 3.0, hunh? 12:30 owen nengard: I would think that must refer to what is "Labels" in 3.0, but was barcode generation in 2.x 12:30 paul (hello nengard) 12:30 paul nengard : in my mail about freezing Koha, sorry to have forgotten the doc part : how to write a doc for a moving software... 12:30 owen I will 12:30 paul owen, pls, drop a mail to koha-dev to express your opinion 12:29 paul thanks to read it. I was surprised to have no reaction this morning. 12:29 nengard from an email to the koha list - "there is no 'help' in the documentation on the barcode generation page." what page is this referring to? that way I can make sure we write up some documentation in the manual 12:29 owen paul, all in all I agree with you with regard to a Koha 3 feature freeze 12:27 paul hi owen 12:27 owen Hi #koha