![http://mineralsprings.com/Cata[…]elTemplate_20.jpg](http://mineralsprings.com/Catalog/LabelTemplate_20.jpg){kind=link}
← 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