IRC log for #koha, 2008-04-30

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

All times shown according to UTC.

Time Nick Message
12:27 owen Hi #koha
12:27 paul hi owen
12:29 owen paul, all in all I agree with you with regard to a Koha 3 feature freeze
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 paul thanks to read it. I was surprised to have no reaction this morning.
12:30 owen, pls, drop a mail to koha-dev to express your opinion
12:30 owen I will
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 (hello nengard)
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:31 Hmm... but he was talking about 3.0, hunh?
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:32 owen this page? koha/labels/label-home.pl
12:32 paul yes, but no. We can (& should imo) "branch" a stable version & continue on the next one.
12:32 on another branch.
12:32 owen nengard: I assume so
12:32 nengard paul - that makes sense - but i see the documentation as an ever growing being
12:34 owen in the email chris nighswonger says "There are currently four different label styles available: 1. Bib
12:34 info/Barcode, 2. Barcode/Bib info, 3. Barcode, 4. Spine." but I don't see where this is
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:39 nengard owen - thanks!!! looks like you're right!
12:57 acmoore paul++ # encouraging planning
12:57 paul acmoore: thx. pls write your opinion on koha-dev ;-)
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.
13:04 I can't quite figure it out. Do you have a second?
13:04 owen You bet
13:04 The sets differ now?
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:05 but, I thought I saw JNF.gif removed in both patches.
13:06 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:07 owen Hmmm... the directories are identical in my repo, even after a fresh fetch and rebase
13:08 I'm not sure what that means
13:08 acmoore grr. I'm sure this is just something I'm overlooking or something.
13:08 owen http://git.koha.org/cgi-bin/gi[…]5e322afec869ecfdf
13:09 According to that JNF.gif was removed
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 paul owen : thx for your humour :D
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:19 owen So, which is preferable as a heading/link/description: "MARC Authorities framework" or "Authority types"
13:20 (admin/authtypes.pl)
13:21 gmcharlt owen: I vote for "authority types"
13:46 kados Authority types++
13:46 hdl 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:48 authority types++
13:49 owen nengard: you caught me at just the right time for these small fixes
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:50 owen If only we were out of big bugs to fix ;)
13:50 nengard owen i know :(
13:51 kados paul: response to your email forthcoming
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:52 owen tinaburger?
13:53 kados nengard: the general rule of thumb is that the person who opened it should close it when it's fixed
13:53 nengard owen she's reporting bugs right now ;) hehe
14:03 owen she asked if you can get on gmail chat
14:11 kados paul: response sent
14:11 paul thx
14:39 owen nengard: regarding Bug 2069...
14:40 nengard owen - let me open that up
14:40 ahh
14:40 yeah
14:41 owen are you thinking of a single image which labels the various aspects  that can be entered in the form?
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 let me see if i can find one
14:42 owen - not quite this - but this is a sample: http://mineralsprings.com/Cata[…]elTemplate_20.jpg
14:49 owen kados, I have a question about the redesigned OPAC results screen when you get a moment
14:49 kados owen: sure ... go for it
14:50 owen What should be displaying under "Call Number:" ?
14:50 kados that's atually up for discussion
14:50 I had thought cn_class and cn_item, but I think gmcharlt disagrees with me
14:50 some libraries seem to maintain a bib-levl call number along with an item-level
14:51 but is that what koha should do by default?
14:51 gmcharlt: thoughts?
14:51 hdl, paul?
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 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:52 and library cataloging practice varies a lot
14:52 some libraries update bib with their call number
14:52 hdl her
14:52 gmcharlt others just have it be an attribute of item, and don't update bib
14:53 paul yes, and that's why we have the field items.itemcallnumber ;-)
14:53 gmcharlt paul: right :)
14:54 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:54 hdl gmcharlt: I agree with you.
14:54 kados so do we remove cn_* from biblioitems?
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:55 kados I think a decision needs to be made on this before 3.0 stable is released
14:56 hdl sure.
14:56 and going back and forth is not quite reassuring for ppl.
14:57 imho, classification or callnumber is important at both biblioitem and item levels.
14:57 paul hdl++
14:58 if I don't mind, nobody here (BibLibre) uses biblioitems.cn_*
14:58 gmcharlt hdl: I can see classification at biblio level, and call number at item level
14:58 paul so we could remove them harmlessly
14:58 hdl mmm...
14:58 gmcharlt but why an intermediate level?
14:58 hdl wouldn't really bet on thet.
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:59 owen: NPL does biblevel classification too, right?
14:59 owen We have in the past
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
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:01 and using bib field(s) as a default call number
15:01 wouldn't actually require a separate biblio.classifcation or biblioitems.cn*
15:01 of course, fly in ointment is that XSLT for OPAC is still experimental
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 because of the overhead managing those
15:02 but maybe that's unrealistic
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:04 kados yea, I know
15:04 I don't like this problem :-)
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: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:05 mc kados ?
15:05 kados gmcharlt: I think OCLC puts call numbers in 092
15:05 and we have some special/academic libraries (Faith for instance) that expect that to be LC
15:05 hi mc
15:05 mc hi kados
15:06 in fact, i have a message for all debian users:
15:06 kados it's a tricky issue
15:06 mc http://hyperion.u-strasbg.fr/koha/
15:06 gmcharlt kados: yeah, but they're doing it wrong ;-) OCLC says 090 for locally-assign LC number
15:06 mc can you tell me about this koha installation script ?
15:06 is it a good thing to se it appears in the git repo
15:07 kados gmcharlt: so maybe the way to approach this is to make some rules about how Koha works
15:07 and to not deviate from those rules?
15:08 gmcharlt kados: well, pick defaults wisely
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: and rely on git to help manage customer-specific mods
15:08 kados also, another issue that comes up, is that people sometimes have more than one class scheme
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 so imagine a mixture of 090 and 092 and 082
15:08 depending on the record
15:08 gmcharlt kados: multi-class scheme use is one of the big arguments for focusing on item-level call numbers
15:09 ryan medical libraries are a common example
15:09 kados thats where cn_* comes in handy
15:09 ryan lots of 060's but also use 050s or 090s
15:09 kados gmcharlt: *nod* good example
15:09 gmcharlt ryan: yup; but you can implement that by looking at the MARC record
15:09 kados yea, XSL gives us that for free
15:09 (almost)
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: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 (directly from the MARC)
15:11 otherwise, item-level call numbers are in items.itemcallnumber and don't display on results pages
15:11 gmcharlt mc: install script looks intereseting
15:11 kados I can live with that
15:11 ryan: how would that work on the data migration front?
15:11 paul, hdl: do you guys agree?
15:11 paul (on phone)
15:11 gmcharlt mc: but why isn't it using  install_misc/debian.packages ?
15:12 mc gmcharlt, because the debian.packages
15:12 gmcharlt mc: some way of setting LENNY_REPO automagically would be nice for those not in France
15:12 mc - list a lot of packages that are in dependancies
15:13 hdl kados : "XSL gives us that for free" not quite since you donot have sorting by element.
15:13 mc - i experienced weird conflicts with them
15:13 kados hdl: yes, we'd have to abandon search and sort by call number/class at bib level
15:14 hdl: that should be an item browse feature anyway
15:14 afaict
15:15 mc gmcharlt, for lenny_repo : it uses apt-spy if you don't set it
15:15 ( i set it in the script for test only, it will be removed before commit)
15:15 hdl if we tell them it is not possible to sort by callnumber anymore
15:15 gmcharlt hdl: sorting by item callnumber should still be possible, as itemcallnumber is indexed
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: and nothing precludes still maintaining index defs for classification from the bib record
15:16 mc and i use lenny ones when possible
15:16 gmcharlt mc: sounds reasonable, although script should then warn user that a mixed Etch/Lenny setup will result
15:17 mc: which should be fine for most users, I expect, but not necessarily all
15:17 mc hmm ... readme does (or will)
15:17 sure
15:17 as said in readme :
15:18 it's for those who don't want to struggle with debian problems
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 so i asume that they aren't really aware of the result if it works
15:18 gmcharlt mc: personally, I've never had any particular problems using debian.packages on a fresh Etch
15:19 mc gmcharlt, this was my first attenpt to install koha so i don't know what changes
15:20 fbcit hello #koha
15:20 mc btw: find the packages that koha really requires will help us to build a future koha package
15:20 (there is an itp on it)
15:21 gmcharlt mc: yep
15:21 mc: fyi, slef (MJ Ray) is the one currently/most recently involved in efforts to build a Debian package
15:23 mc well ... i had words with libyaz debian maintainer
15:23 he told me that
15:23 - his goal is to provide a koha package
15:23 - indexdata is happy about that and will co-maintain their own packages
15:24 - vincent (the maintainer still contacted slef)
15:51 atz not sure on that one... card size printouts, I'm guessing
15:51 er... ignore that
15:53 fbcit atz++ on window changing
15:53 ;-)
16:26 nengard hi brooke
16:27 Brooke yo!
17:18 cait hello #koha
17:19 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:19 can somebody help me?
17:20 database is unimarc and version newest snapshot from git
17:24 running away? ;)
18:42 owen How do you create a gitignore file?
18:43 gmcharlt owen: it's just a file called '.gitignore' in the top level of your reposistory (or any subdirectory)
18:43 should contain names or patterns (e.g., *.temp) of files to ignore
18:44 cait: what output did you get when you ran rebuild_zebra?
18:45 owen Just a plain file with a separate line for each name or pattern?
18:45 gmcharlt owen: yes
18:48 cait ah hi
18:48 gmcharlt: its working now it seems
18:48 gmcharlt cait: great
18:48 cait ive got two installations-- one at work and one at home
18:49 at home is working now, missing daemon, problem at work must be different :( but one working installation is great for me atm
18:51 here its i/u/d 40307/0/0 at work its 0/4/0
18:51 configuration, version and import the same... ok, cant be the same, but should
18:52 owen gitignore doesn't ignore itself?
18:52 gmcharlt owen: hehe; no, it doesn't.  sometimes you want to check a .gitignore into git
18:53 owen ...hence the recent discussion.
18:53 gmcharlt yep
18:53 cait gmcharlt: some ideas, what i can try to find the mistake?
18:54 gmcharlt cait: one idea is to add -k to the option list - that keeps the temporary directory around
18:55 it will tell you the name of the directory, and you can inspect it to make sure that the records were extracted OK
18:55 also, zebraidx (which is run by rebuild_zebra) will usually give some explanation, albeit often a cryptic one
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:59 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?
20:23 chris morning
20:24 owen Hi chris, how's it going?
20:29 chris heh

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

koha1