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