Time Nick Message
11:52 thd paul: tell me about the new UNIMARC framework
11:48 slef sorry
11:48 slef eek, must go
11:48 paul 3=> yes
11:48 paul 2 => Programme is on wiki.koha.org
11:47 paul 1 => there is no KohaCon Hotel, the Con will take place in ENSMP
11:47 slef Where is kohacon hotel? When will programme be published? Are submissions still open?
11:45 thd paul: what is the new UNIMARC framework about which you had posted comment for 95% correct?
11:44 paul everything is on wiki.koha.org
11:44 slef about kohacon
11:44 paul about what ?
11:44 slef I'll be back from next meeting around 20:00+0100
11:44 slef paul: can you send me any extra info email, please?
11:44 paul so you can come ;-)
11:43 paul but i can confirm you mail has arrived.
11:43 paul slef: I don't know why you did not get a confirmation.
11:43 pierrick_away thank you Joshua
11:42 slef paul: I completed the registration form twice now. It says I'll get email. I've not had email AFAICT. I have not booked travel tickets and now they're going to be more expensive... if I leave it more, they may not be available.
11:42 kados pierrick: very productive meeting
11:42 kados pierrick: excellent ... thanks for your work on the BSM!
11:41 pierrick kados, OK. I'll bug him tomorrow morning (11h GMT) about bugs and bugzilla :-)
11:41 slef sorry, I have meetings all over the show today
11:41 paul slef: I don't understand your question about KohaCon, could you pls explain ?
11:41 kados pierrick: i don't have access to that machine
11:41 kados pierrick: you'll have to ask chris about that
11:40 pierrick kados, do you have the keys to bko server? Could we plan an upgrade to a recent version of Bugzilla?
11:40 slef when should I get kohacon info? I really could do with booking confirmation so I can get tickets etc
11:39 pierrick so, next BSP during devWeek
11:38 pierrick OK... speaking of the devWeek in a restaurant on May 2nd, 2006 in the evening :-)
11:38 paul to a restaurant (I mean if we speak of the devWeek, not if we do a BSP, of course)
11:38 pierrick paul, I'm OK but where will we go to work?
11:37 paul so, you can join us in ENSMP, for evening ;-)
11:37 paul pierrick: we will be in Paris, probably not on the net, but IRL !
11:37 paul kados: ok, my wife happy to meet you, although a little bit afraid to speak english ;-)
11:37 pierrick paul, the evening
11:37 pierrick paul, may 2nd
11:36 paul pierrick: OK from home for what ?
11:36 kados paul: yes of course :-)
11:36 pierrick OK for me I'll work from home
11:36 paul I can count you as my guest on May, 7th in Marseille ?
11:36 paul why not...
11:36 kados paul: sure
11:36 paul on may 2nd evening ?
11:35 kados paul: or we could do it in Paris
11:35 kados paul: good idea
11:35 paul or during devWeek !
11:35 paul I think we should organise a very quick meetingto organize the devWeek
11:35 pierrick it's tomorrow or after devWeek :-)
11:35 paul thd : (katipans will be here in 4 hours)
11:34 pierrick tomorrow???
11:34 kados paul: is port 80 open? you could join us via cgi::irc
11:34 thd paul: what do you mean about 4 hours?
11:34 paul same thing : i'm away
11:34 pierrick thursday?
11:34 paul (and they have a strong firewall, so no 6667 port open :-( )
11:34 paul (at SAn-OP=
11:34 paul (I mean : away on friday)
11:33 kados pierrick: works for me
11:33 pierrick on friday?
11:33 pierrick Do we plan another BSP at the end of the current week?
11:33 kados thd: of course
11:33 thd and accuracy
11:33 kados pierrick: then we have them after that
11:33 thd kados: I like my commits to reflect my high standards of completeness
11:33 kados pierrick: finish up remaining bugs
11:33 paul in 4 hours...
11:33 kados pierrick: i think we should have one more without NZ present
11:32 pierrick When would it be possible to have russ & chris?
11:32 paul (this week)
11:32 paul (+ away thursday&friday)
11:32 hdl pierrick: thx
11:32 paul when will be the next bsm ?
11:32 thd kados: of course it should be committed but we should still discuss finishing it for the little that remains undone
11:32 kados hehe
11:32 paul for sure : the 80 remaining bugs will be fixed automatically ;-)
11:32 kados pierrick: great job, thanks for organizing this!
11:32 pierrick (for today)
11:32 kados thd: commit early commit often :-)
11:32 pierrick kados, yes
11:31 kados pierrick: are we finished? :-)
11:31 kados thd: it may not be perfect, but probably shouhld still be committed
11:31 pierrick folks... thank you for your participation to Bug Squashing Party :-)
11:31 paul you fund many many things ;-)
11:31 kados paul: (though it was funded by LibLime)
11:31 kados paul: the marc21 framework I mean
11:31 kados paul: in fact, thd is the one that did it
11:31 paul that is also the marc21 semantic definition
11:30 paul so= kados is working on a framework
11:30 paul pierrick: ok, I misunderstood what you were speaking of
11:30 thd kados: however that framework is not perfectly finished or (I would have committed it.
11:30 pierrick paul, no, MARC data are isoXXXX files while frameworks are a definition, in what I understand
11:30 kados paul: 3X the size of previous default
11:30 kados paul: because the standard marc framework is quite huge
11:30 kados paul: maybe we should have two default frameworks
11:29 kados pierrick: framework
11:29 paul pierrick: it's the same thing => the default framework is the marc21 structure !
11:29 kados paul: thx
11:29 paul kados: "structure_def.sql"
11:29 pierrick kados, are you commiting data or framework?
11:29 thd paul: the UNIMARC framework has also not been committed?
11:28 kados filename?
11:28 paul in misc/marc_datas/marc21_english directory
11:28 paul it's 95% correct for unimarc
11:28 kados paul: where should the framework be committed?
11:28 pierrick will it be commited for 2.2.6?
11:28 kados (just needs error checking I believe)
11:27 kados it's 95% finished
11:27 paul as well as for unimarc.
11:27 thd kados: yes I know sorry for the interjection :)
11:27 kados there is a new standard marc framework for marc21
11:27 paul we should, but I don't think we do.
11:27 pierrick did we update frameworks ?
11:27 kados thd: we're in a bug fix meeting, we can discuss that afterwards :-)
11:27 kados I'll mark it as fixed
11:27 thd kados: I could not receive an order properly in 2.2.4 when I tested full acquisitions.
11:27 kados 736 will be fixed in rel_2_2 with new frameworks
11:26 pierrick next is 736
11:26 pierrick kados, I note paul votes for wontfix and I bug chris about this
11:25 kados I vote we ask chris if katipo has a better fix
11:25 paul (I vote)
11:25 paul so #735 => wontfix
11:25 kados pierrick: can you ask chris about this?
11:25 kados that they haven't committed
11:25 kados for their clients
11:25 kados so I wonder if katipo has an even better fix
11:25 paul It may be considered as a dirty fix, but at least, it's stable now !
11:25 kados right
11:25 paul (that a library of mine showed me)
11:24 kados yep
11:24 paul in this case, I'm able to explain why I did this : to avoid a larger larger problem !
11:24 paul + it could caus problems if the library has modified the catalogue entry.
11:24 kados maybe this is what katipo calls 'breaking full acquisitions'? :-)
11:24 paul and it's a real big stuff to report the modif to the catalogue
11:24 paul as the change is done only in order, not in catalogue.
11:23 kados so it's a feature :-)
11:23 paul however, if you enable the change, then it won't work correctly
11:23 kados ahh
11:23 paul #725 : I changed the behaviour : you can't modify biblio informations once you've saved an order.
11:23 kados think even
11:23 kados need to bug chris I htink
11:23 kados it's a katipo one?
11:23 paul #735 thus ?
11:22 kados good
11:22 paul hdl take care
11:22 paul ok, #733 then
11:22 kados paul: yep
11:22 paul as it may require a lot of work to adapt this to french & default
11:22 hdl Great
11:22 kados so mark as wontfix
11:22 pierrick since we can't use localized strings in Perl code, you had no choice
11:22 kados ok, to head
11:22 paul but commit this to head pls.
11:22 kados not been committed
11:21 paul kados +++
11:21 owen Has that been committed?
11:21 pierrick separately... I suppose
11:21 kados so the template designer could label them
11:21 kados and gave the template the vars
11:21 hdl :D
11:21 pierrick great workaround ;-)
11:21 kados I removed searchdesc completely
11:21 kados in fact, I ahve a fix for NPL already
11:21 paul yep.
11:21 paul but that's really a pain to fix...
11:20 pierrick so it's wontfix
11:20 paul (in result list header)
11:20 paul s/maybe//g => there is "keyword", even in french.
11:20 kados it's not fixed I think
11:20 kados pierrick: so wontfix would be better?
11:20 pierrick next is #733 as sai paul
11:20 paul mmm... owen is maybe right...
11:20 pierrick here
11:20 pierrick that's not the case her
11:20 pierrick as slef said earlier, invalid means ""you are a moron, submitter"
11:19 owen 730 is fixed?
11:19 kados ok
11:19 paul #730 : I marked it as fixed
11:19 pierrick #730 is fixed but not invalid
11:19 kados pierrick: 730 is not invalid?
11:19 hdl I take it.
11:18 pierrick it's not invalid
11:18 paul #733 then
11:18 kados (though head will not have searchdesc as it's too restricted)
11:17 paul #730 now irrelevant
11:17 pierrick nxt is 730
11:17 kados I'll mark fixed then
11:17 kados right
11:17 paul (see owen comment I mean)
11:17 paul (owen comment)
11:17 paul irrelevant
11:17 kados I don't know if this specific bug still exists
11:16 pierrick so 723...
11:16 hdl reassgning
11:16 hdl yep
11:16 paul hdl => you take care of it too ?
11:16 kados NPL's Server
11:16 kados like:
11:16 kados it's impossible to delete it
11:16 kados if there is a quote in the name of the server
11:16 kados I confirm it's a problem
11:15 paul deletion of a z39.50 doesn't work
11:15 kados ok
11:15 paul 722 before
11:15 kados we need a unified method for dealing with all dates
11:15 kados ahh dates
11:15 kados 723 next?
11:15 paul I let kados mark it as fixed
11:14 kados fixed in rel_2_2
11:14 paul it's fixed I think
11:14 pierrick next is 717
11:13 kados 716 is invalid I think
11:13 pierrick next is 716
11:13 kados yea
11:13 owen I assume this is with the old subject search
11:12 kados owen: ?
11:12 kados bug 715 must be fixed I think
11:12 hdl thx.
11:12 pierrick hdl, http://fr3.php.net/magic_quotes
11:11 kados 20 minutes good for me too
11:11 pierrick I'll bug chris on #714
11:11 paul that's OK to me
11:11 pierrick paul, but I should, I would like to leave office in 20 minutes
11:10 pierrick paul, I didn't set any limit
11:10 paul i vote katipo too for #714
11:10 kados so 714 is for katipo
11:10 kados hdl: if a z3950 server is created with a single quote, it cannot be deleted
11:09 paul I think some of katipans may use them.
11:09 kados hdl: or a similar one at least
11:09 kados hdl: while you're fixing that, the same problem occurs with Z3950 servers list
11:09 paul kados: ++ => I haven't
11:09 hdl None of our clients, as far as I know.
11:09 paul (or the prepare(?) execute($x))
11:09 paul hdl : $dbh->quote() is enough I bet
11:09 kados does _anyone_ use printers in Koha?
11:09 hdl (pierrick: would you mind sending me links for PHP magic quote ?)
11:09 paul pierrick: do you have a time for closing this BSM ?
11:08 pierrick 714 now
11:08 paul hdl++
11:08 pierrick thanks hdl
11:08 kados hdl++
11:08 pierrick in PHP, this problem is known as "magic quote" and I painfully remember how to handle it
11:08 thd kados: you have to turn normal acquisitions on :)
11:07 hdl still a problem.
11:06 kados I can't find supplier page :-)
11:06 kados not sure about 707
11:05 hdl kados: is it still a prob ?
11:03 hdl pierrick: of course :) But will have to ask katipians :)
11:03 kados wait ... 707 I'm not sure
11:03 kados 707 I can confirm it's a prob
11:03 pierrick hdl, make sure newbasket2.pl can still be reached before fixing it :-)
11:03 paul #707 then ? I think it's fixed.
11:02 hdl I take it
11:02 hdl But I can cope with it.
11:02 hdl newbasket2 was not known of me.
11:01 paul ;-)
11:01 pierrick a pagination problem ;-)
11:01 paul hdl ? an idea ?
11:01 kados owen: any comments?
11:01 pierrick 706?
11:01 paul done
11:00 paul #705 : wontfix
10:59 kados thx
10:59 pierrick OK, I take the bug and I'll ask Katipo
10:59 paul (but not sure)
10:59 paul (I think it is for MARC=OFF libraries)
10:59 paul (I did not remove it because I think katipo want it. but we should ask them to see i fit's still usefull)
10:59 pierrick shouldn't we remove it from HEAD?
10:59 paul yep.
10:59 pierrick paul, it can, but not with menu
10:58 paul so, I vote "wontfix" ;-)
10:58 paul catmaintenance can't be reached anymore
10:58 pierrick but is maint/catmaintain.pl still relevant?
10:58 paul yes, and very outdated.
10:58 pierrick #687 seems very simple
10:58 paul pierrick: no.
10:58 pierrick does Perl-zoom automaticaly fixes #686?
10:58 paul next is 687, this time, we agree
10:57 paul ok
10:57 paul yep.
10:57 kados and perl-zoom for head :-)
10:57 paul So I don't think I can't find time to fix it.
10:57 kados right, maybe wontfix for rel_2_2
10:57 paul but a very complex fix.
10:57 paul I think it's a really minor problem.
10:57 paul slef says that only the 1st ISBN in the retrieved biblio (from the z3950 server) can be searched.
10:57 kados :-)
10:57 kados paul takes it then?
10:56 paul 686 is related to breeding farm => reservoir.
10:56 kados so what bug is next? 686 finally>
10:56 paul (but as you ignore blank subfields, that should not be a problem)
10:56 kados paul: I'll make a note to myself to check that also
10:55 paul kados: i don't remember
10:55 paul pierrick: right. but I spoke of 684 hereafter.
10:55 kados (or should I file a new bug report for that also?)
10:55 kados (paul, did you fix problem of repeated subfields leaving blank subfieldcodes?)
10:55 pierrick then I said "next is 686")
10:54 pierrick at 17:46 (french hour) kados said: "684 is fixed, new marc editor doesn't create blank fields anymore"
10:54 paul sorry, I was speaking of 684 previously
10:54 kados ok, I take 684
10:54 paul kados: and 684 : Cannot remove an added field from biblio
10:53 paul ??? I see "bug 686 : only 1st ISBN used"
10:53 kados paul: which one do we need javascript to fix?
10:53 pierrick kados++
10:52 paul did he disappear in a black hole ?
10:52 paul Only first ISBN used
10:52 paul and 686 ?
10:52 paul right. a shame there is no really useable doc in french to learn javascript
10:52 pierrick next is 687
10:51 pierrick paul and I are scared by Javascript, it seems ;-)
10:51 pierrick thank you kados
10:51 paul ok, thanks
10:51 kados I'll take it
10:51 paul yep. but i'm still a stupid javascript guy ;-)
10:51 kados in clonesubfield
10:50 kados but easy to solve with javascript
10:50 thd wow
10:50 paul yep
10:50 kados so still a problem then
10:50 paul (stupid, I admit)
10:50 paul so both $a must contain something !
10:50 kados heh
10:50 paul you can't, as 200$a is mandatory.
10:50 paul a few days after, you want to edit and delete the 2nd value, as it's stupid
10:50 kados right
10:50 paul then you save.
10:50 paul you duplicate 200$A and enter 2 values.
10:49 paul in MARC-editor, suppose 200$a is mandatory.
10:49 kados so what is this prob?
10:49 kados ahh
10:49 paul that's not this.
10:49 kados unless I misunderstand, in head we will not have koha2marc links anymore
10:48 paul (NA in head)
10:48 paul why kados ?
10:48 kados in HEAD it's NA
10:48 pierrick paul?
10:48 kados in rel_2_2
10:48 kados 686 still a problem
10:48 pierrick next is 686
10:47 paul which bug are we working on now then ?
10:47 kados I'll change it
10:47 kados 682 is wontfix
10:46 kados woops :-)
10:46 pierrick you missed 682
10:46 kados 684 is fixed, new marc editor doesn't create blank fields anymore
10:45 kados 684?
10:45 kados I will take bug 670
10:45 kados about 'in transit' status
10:45 kados we had a mtg at NPL yesterday
10:45 kados this is the status thing again
10:44 pierrick I take it, next is 670
10:44 kados pierrick++
10:44 pierrick I can take it if you want
10:44 kados I'll hire chris to fix it :-)
10:43 owen That one just won't die.
10:43 kados it seems noone wants it :-)
10:43 kados for 668, I have noticed that problem in rel_2_2
10:43 paul bug still here.
10:42 paul pfff... only 38 on 134
10:42 kados pierrick++ :-)
10:42 pierrick so 668 :-)
10:42 paul (that was the largest table with silly fields I think)
10:41 kados cool
10:41 paul (borrowers has been cleaned on HEAD I think. Thx to SAN-OP)
10:41 owen A case of planning optimistically for future functionality
10:41 kados right
10:41 pierrick weird :-/
10:41 paul and some fields that appear, can be filled but do nothing
10:41 kados paul: that too :-)
10:41 paul in fact kados I think that there are many fields in DB that are useless & appear nowhere
10:41 kados pierrick: no, not that specifically
10:40 owen Input fields in the template and/or columns in the database
10:40 paul so you can set whatever you want here.
10:40 paul no, but this "min age required" does nothing at all.
10:40 pierrick kados, you mean template button with no effect in Perl code?
10:40 paul "many" is maybe too pessimistic. but "some" is OK
10:39 kados pierrick: we have many bugs that have never been fixed, many of them are features that claim to do something, but don't do anything
10:39 pierrick (next is 668)
10:39 pierrick kados, why do you say that?
10:39 kados pierrick++
10:38 kados as it seems like a typical Koha problem :-)
10:38 pierrick I take it
10:38 kados I assume this is still a problem
10:38 pierrick 659
10:38 kados next?
10:37 pierrick I'll bug him on 2.0, please confirm it's closed on 2.2 and HEAD :-)
10:37 owen Judging from my comments I think so. Since I can't remember it I'll have to trust myself :)
10:37 kados owen: is it fixed in rel_2_2?
10:37 owen Unless MJR wants to leave open for 2.0, I assume this can be closed.
10:36 kados owen: any comments?
10:36 kados hmmm
10:35 thd s/required/correct/
10:35 paul #657
10:35 kados next?
10:35 paul done
10:35 kados ok paul will
10:35 thd exactly I think pierrick is required code should be ASCII unless there is a very good reason for something else
10:35 kados I'l close it
10:35 kados yep, fixed
10:35 paul (it's fixed, so it will be a quick bug ;-) )
10:35 pierrick yep
10:35 paul #652 then ?
10:34 paul kados: ok
10:34 kados I'll investigate as I already must deal with related issues
10:34 pierrick I would say we should not have utf8 in Perl code, why is it required?
10:34 kados I don't use 'use utf8' in Biblio.pm
10:34 paul it's related to char_encode sub I bet ?
10:33 kados if Biblio.pm has use utf8 it's fixed, otherwise it's not
10:33 pierrick shouldn't it be forbidden?
10:33 kados right ... and now Biblio.pm has 'use utf8' in it?
10:33 paul yep.
10:33 pierrick kados, does slef mean there are non ASCII characters inside Perl code?
10:32 paul except it's encoding of the file itself, not of MARC records
10:32 kados it's not fixed yet
10:32 kados I'll take that one
10:32 paul I think it can be closed (#645)
10:32 pierrick an encoding bug :-)
10:31 pierrick next is 645
10:31 owen kados: I think yes to the itemtype
10:31 kados pierrick: in MARC even :-)
10:31 kados pierrick: some libraries catalog websites
10:30 paul show nothing interesting
10:30 paul grep -R "websitesearch.pl" *
10:30 pierrick kados, what is a "website search" in Koha context?
10:30 kados unless websites should be defined as an itemtype
10:30 kados IMO
10:30 kados but it woudl be nice to have a website search
10:30 kados it's just the display that's different
10:30 kados non-MARC koha these days is still MARC in the background
10:29 paul I think no
10:29 owen But is it still used in non-MARC Koha?
10:29 paul owen: ++
10:29 owen Not useful in a MARC situation, I think
10:29 kados is it useful even? should we revive it?
10:28 kados is websitesearch.pl even used anymore?
10:28 pierrick next is 642
10:27 pierrick kados, ok
10:27 kados pierrick: maybe bug self about it?
10:27 paul right, & it's a slef one
10:26 pierrick next is 636
10:26 paul kados: ++
10:25 kados (because for instance, any field mapped in 'searchalso' is searched on but will not always display in normal view
10:24 kados so maybe mark 629 as fixed and refer to ISBD as the solution?
10:24 kados right ... I meant to say that someone must create an ISBD display that actually fulfills all the fields needed
10:23 paul (it's just tricky, but you can)
10:23 paul kados: you can insert links into ISBD...
10:23 kados IMO there's no solution unless ISBD display could be expanded to include links, etc.
10:23 kados yea, 629 is a tricky one
10:22 pierrick we move to 629
10:21 kados but it's assigned to me so I'll look into it
10:21 owen 612 is still a problem
10:21 pierrick it seems ou hav all worked on this #612
10:21 kados 612 might still be a prob?
10:20 kados pierrick++
10:19 paul good news !
10:19 pierrick paul, OK for the redesign, I'll work on it this week
10:19 paul ok for me. #612 now
10:19 kados (right)
10:19 paul (as it's somewhat related to myt suggestion to separate technical install& library install)
10:19 kados I'll mark 604 as wontfix
10:19 pierrick it needs to be chunked
10:19 kados paul: I agree
10:19 paul I think we should close this bug & work on installation re-design for koha 3.0
10:19 pierrick IMO, this kind of bug report can't be accepted as such
10:18 paul that happends during install.
10:18 paul more a long list of problematic things.
10:18 kados ahh, right
10:18 paul #604 is not really a bug...
10:18 pierrick next is 612
10:18 kados slef: still here?
10:18 pierrick I'll but slef on it
10:17 pierrick next is 604
10:17 pierrick owen takes care of it
10:17 kados pierrick: I'll reassign it to owen
10:17 kyle heh heh...
10:16 paul pierrick: what do we do with #585 then ?
10:16 kados kyle: you've stumbled into a bug squash meeting :-)
10:16 kyle hey.
10:16 pierrick hi kyle
10:16 kados hey kyle
10:16 paul hello kyle
10:16 paul (at least, I tried to fix them when I see them)
10:16 paul owen: ++
10:15 owen I think most of these issues have been taken care of. I'll double check and close the bug if I can
10:15 paul maybe not in rel_2_2
10:15 paul should be fixed in prog templates.
10:15 kados owen: any updates on this one?
10:14 pierrick so we move to #585
10:14 kados ok, I"ll mark as wontfix
10:14 paul pierrick: ++
10:14 kados ahh, good point
10:14 pierrick I would say I would like this to be in the extension manager
10:13 pierrick we should provide samples on koha.org but not in releases
10:13 kados but not in the release
10:13 kados ok ... so it should be in CVS
10:13 paul as I have for french unimarc libraries (EMN DB)
10:13 paul although we should be able to give a sample DB to anyone requesting.
10:13 paul pierrick: I agree.
10:12 kados I can provide MARC21 data
10:12 pierrick do we keep sample data inside official releases? (I think we should not)
10:12 kados yes
10:12 kados we need sample data for 2.4 I think
10:12 paul do we want to work on #559 ?
10:12 paul ok, next is 559
10:11 paul #555 is irrelevant I think.
10:11 pierrick next is 555
10:10 pierrick OK, I'll bug slef on 551 and I confirm that this is completely redesigned in HEAD
10:09 paul fixed too I think.
10:09 paul #551 now ?
10:09 paul so I mark#504 as fixed
10:08 pierrick I confirm that bookshelves work correctly on 2.2
10:08 owen But you're right about 492
10:07 owen Sorry paul -- I was referring to bug 484 being a template bug
10:07 pierrick paul?
10:07 pierrick next is #504
10:06 paul owen: right. bookshelves work correctly.
10:06 pierrick I close
10:06 kados I think 492 is probably fixed
10:06 owen Sounds like a template bug that's probably out of date
10:05 pierrick next is #492
10:05 pierrick I'll bug chris
10:05 kados :-)
10:03 pierrick next is #484
10:03 pierrick Owen, tell me if you want me to bug chris on #426
10:03 owen I'll try
10:02 kados owen: can you check?
10:02 paul & ingrid was our previous QA manager.
10:02 paul a quite old.
10:01 paul it was rel_2_0
10:01 paul yep
10:01 pierrick was it before rel_2_2 start?
10:01 pierrick (HEAD of 2003)
10:01 pierrick s/newt/next/
10:01 pierrick newt is #426
10:01 pierrick paul, I let you close your assigned bug :-)
10:00 paul however, #390 is fixed I think
10:00 kados I will search for it
10:00 paul kados: can you get it (the mail) ?
10:00 pierrick url
10:00 kados or else forgot how it works again :-)
10:00 paul I wrote a mail on koha-devel some months ago, just for kados
09:59 kados pierrick: paul is the best source :-)
09:59 paul (same thing for "ordered", although an ordered book has no item, so it can't have a status)
09:59 pierrick where can I find information about "how statuses work in Koha"?
09:59 paul so, whatever the "manual" status, a book "on issue" or "reserved" is "on issue" or "reserved"
09:59 kados ahh ...
09:58 paul as well as "on issue".
09:58 paul this kind of status overwrite authorized values.
09:58 owen If it's really about statuses, I think we should close 390 and enter a new bug
09:58 kados how does the status get updated when authorized values are used for statuses?
09:57 paul no, I don't
09:57 kados paul: can you confirm this is still a problem if a library uses authorized values for statuses?
09:57 kados owen: ok ... but that's only if you use the hardcoded statuses
09:57 pierrick thank you, not familiar enough with bugzilla
09:56 paul (Priority 5)
09:56 kados pierrick: priority 5 maybe?
09:56 pierrick what is P5?
09:56 owen circulation.pl /does/ now show whether a book has been consigned for a borrower.
09:56 kados in rel_2_2
09:56 paul #390 : heavily rewirtten by SAN-OP
09:56 kados even I am confused about how statuses are supposed to work
09:56 kados 390 is about statuses in general I think
09:55 pierrick (paul's one)
09:55 pierrick 390
09:55 kados next?
09:54 kados 379 is for chris
09:53 kados owen: cool, thanks for checking on that
09:53 owen item type=> borrower category
09:53 pierrick OK, next is #379
09:53 kados next?
09:53 owen I just tried adding a borrower using an item type with a fee attached, and it did /not/ generate an invoice (no fee was attached to the borrower's account). FWIW.
09:53 kados I believe it is fixed but I will confirm
09:53 kados I will take 322
09:52 pierrick now
09:52 pierrick #322 ow
09:51 pierrick OK
09:51 kados 287 is also for katipo/chris
09:51 pierrick next is #287
09:50 pierrick I'll bug chris
09:50 paul I think Koha can handle some of what is wanted already.
09:50 kados pierrick: can you bug chris?
09:49 kados someone needs to investigate this
09:48 kados on their account
09:48 kados but I"m not sure it generates an invoice
09:48 kados I know that borrower categories includes a fee option
09:48 kados but I'm not 100% sure
09:48 kados I think this is fixed
09:48 kados they are often charged a small fee
09:48 kados when a out-of-town person joins the library
09:47 thd what is a borrower subscription?
09:47 pierrick next is #286
09:46 pierrick OK kados, I'll bug chris on this
09:46 owen Hi
09:46 kados morning owen
09:46 kados pierrick: I bet katipo has a fix
09:46 kados pierrick: you should ask chris about it
09:46 pierrick I take #285
09:44 pierrick next is 285
09:44 hdl yes, reassigning to myself.
09:44 pierrick hdl, I let you change the assignement
09:43 kados ok
09:43 hdl I can handle this.
09:43 kados I don't know whether it's fixed
09:43 kados Tumer didn't fix this bug
09:43 kados wait ... I missread it
09:42 pierrick should I reassign to tumer?
09:42 kados I'll have NPL check on this
09:42 kados but we should check to be sure it works
09:42 kados I think Tumer committed a fix
09:42 pierrick 284
09:41 kados ok, next bug? :-)
09:41 paul I agree it's still not perfect, but it's highly better !!!
09:41 paul now, the only case where we could get 2 basket with the same # would be if they clic on "save" on their 1st line at the same milli-second.
09:40 pierrick (comes close to the point I wanted to discuss on koha-devel about numeric identifiers)
09:40 paul thus the problem...
09:40 paul thus, 2 librarians creating a basket in the same minut, got the same basket #
09:40 pierrick I take it
09:39 paul previously, the basket# was defined BEFORE the 1st line was created (with a max() )
09:39 paul thus, librarians can't be 2 with the same basket #
09:39 paul the basket number is defined when the 1st line is saved, not when you clic on "create order".
09:39 paul it's a classic database management problem.
09:38 paul but I'm not 100% sure.
09:38 paul I think #283 is fixed now
09:38 pierrick next is 283
09:37 kados I close bug 282
09:37 pierrick kados, thanks for the quick clarification
09:37 kados but we digress again
09:37 kados that includes more than three levels
09:36 kados in fact we need a multi-tiered hierarchy to have full MARC holdings support
09:36 kados well, as implemented it's useless
09:36 pierrick (and I understood, reading the database model, that biblioitem is useless)
09:36 kados pierrick: reserves happen at the biblioitem level only in current Koha
09:35 kados pierrick: biblio, biblioitem, item
09:35 kados pierrick: in old Koha tables we have a three-level hierarchy:
09:35 paul pierrick: we should be able reserve on a biblio or on an item.
09:35 paul so maybe we won't have to maintain MARC=OFF anymore soon !
09:35 pierrick kados says something and the contrary two lines after :-/
09:35 paul + I showed chris hide_marc=ON systempref & he will show it to them.
09:34 pierrick excuse me... what can you reserve?
09:34 kados right
09:34 paul and katipo only has 2 libraries with MARC=OFF.
09:34 kados in MARC koha it is
09:34 kados right
09:34 paul (reserving on a biblioitem is useless I mean)
09:34 paul ... which is useless
09:34 pierrick kados, that's make sense
09:34 kados pierrick: not a biblio or an item
09:33 kados pierrick: in Koha you can only reserve a biblioitem
09:33 paul just have to integrate it & commit the code
09:33 pierrick kados, you mean in Koha you can reserve a biblio or an item?
09:33 paul I have the fix from SAN-OP
09:33 kados paul++
09:33 paul kados: it will be fixed soon in cvs-head
09:33 kados since a serial is linked to an item now, the problem still exists :-)
09:33 kados this is related to the problem of not being able to reserve specific items
09:33 pierrick paul, has the magazines management been redesigned?
09:32 kados this is a problem but not as originally reported
09:32 kados hmmm ...
09:31 pierrick next is... 282
09:31 kados ok
09:31 pierrick kados, of course, that's my task to bug chris
09:31 kados :-)
09:30 paul maybe, but pierrick will have to bug chris ;-)
09:30 kados I'll tell chris it's his responsibility
09:30 kados perhaps we should leave it for katipo in rel_2_2
09:30 pierrick does only Katipo clients use adult/child feature?
09:30 paul & investigate for head.
09:30 kados well ...
09:30 paul so I would close it as invalid
09:30 kados ok
09:30 paul + I have no clients with this feature.
09:30 pierrick paul, you've worked with adult/child/other borrower type
09:29 paul in head, with SAN-OP everything is rewritten (almost)
09:29 kados paul: do any of yours?
09:29 kados none if my clients use the 'child' registration feature
09:29 thd pierrick: yes it is good to know that koha is capable of diabolical behaviour :0
09:29 pierrick what is hmc.edu?
09:29 kados noone knows it seems
09:28 kados is Mike at katipo?
09:28 pierrick (diabolical one)
09:28 pierrick 281
09:28 kados next?
09:27 kados so we need to bug chris, I"ll do that
09:27 paul #280. Same note for me : no slip printed
09:27 pierrick 280
09:27 kados what is the next bug?
09:26 kados done
09:26 kados I'll assign it to myself and look into it
09:26 kados I can't confirm either as I haven't checked
09:25 paul so has no idea wether this bug is there or not anymore
09:24 pierrick next is 272
09:23 kados I will add a new bug report for issuingrules bugs I've found
09:23 kados pierrick: yes
09:23 pierrick I close #239, wontfix ?
09:23 kados that should be a blocker for 2.4 IMO
09:23 kados though there is another bug in issuingrules
09:22 kados I agree
09:22 paul (as issuing system deeply modified. this bug means nothing now)
09:22 paul that can be closed too
09:22 paul #202 closed. next is #239
09:22 kados bachelor I meant :-)
09:22 pierrick kados & paul, my free week is next week ;-)
09:22 paul batchler ???
09:22 kados pierrick: I'll add it to the list :-)
09:21 kados paul: great, so you are batchler like me this week :-)
09:21 pierrick kados++ we disgress, I hope we'll have a general branch management discussion during devWeek :-)
09:21 kados but we digress
09:21 pierrick kados, not if you report correction one by one
09:21 kados pierrick: rel_3_0 should be nearly bug free IMO and running latest code with all bugfixes from previous versions
09:20 paul (wife is away with childs for the whole week, then i've plenty of time)
09:20 kados pierrick: otherwise, HEAD will always be buggy
09:20 kados pierrick: no, we must fix HEAD I think
09:20 paul kados: yes
09:20 kados paul: (after BSM can we discuss the best way to merge rel_2_2 and HEAD?)
09:20 thd pierrick: HEAD will be insufficiently well specified as compared with rel_2_2 if the next release is 2.4
09:20 pierrick kados, will you create a rel_3_0 and a 3.0.0RC1 before squashing all bugs?
09:20 paul (what have we decided ?)
09:19 paul fixed or wontfix ?
09:19 paul ok
09:19 paul (i've created a tag)
09:19 pierrick paul, you close #202?
09:19 kados until then, there are no bugs in HEAD :-)
09:19 paul you can begin from 2.2.5
09:18 kados after that, we can start bug reports on HEAD
09:18 pierrick very painful, obviously
09:18 paul it's a really boring stuff I already made 3 times.
09:18 kados but it must be done
09:18 kados it will be quite a painful process
09:18 paul ah, ok, i let you done then.
09:18 kados later this week
09:18 kados I will personally be merging rel_2_2 code into HEAD
09:18 paul pierrick: yes, we agree.
09:18 pierrick (so that bug won't reappear on 3.0
09:18 kados paul: yes, might not be resolved in HEAD but that's not a problem
09:18 thd kados: I thought that you had. I did not check the date on the bug report.
09:18 pierrick are we OK every correction made on rel_2_2 is reported on HEAD?
09:17 paul s/in/since/
09:17 paul (as it should be fixed in 2.2.3/4 )
09:17 paul kados: you mean in rel_2_2 isn't it ?
09:17 kados thd: I have tested it myself
09:17 kados thd: resolved in cvs
09:17 paul thd: yes
09:17 paul (look at last owen comment)
09:17 thd kados: I missed something is 185 resolved, when?
09:16 paul #202 should be closed too.
09:16 kados pierrick: suggestion: you keep track of where we are, we will close/edit bugs
09:16 pierrick next is 202
09:16 kados 185 closed
09:16 paul ;-)
09:16 paul but it works fine now
09:16 pierrick next is #185... he guys... you're too fast for me ;-)
09:16 paul (i've fixed something in 2.2.3/4 iirc)
09:15 thd I belieive that Katipo still has 1.X customers.
09:15 paul #185 : I confirm too
09:15 pierrick paul, I've added a not on the bug resolution explaining...
09:15 kados I can confirm that autobarcode is working in CVS
09:14 thd kados: I have never seen the auto barcode feature working correctly form CVS or releases since I have observed form 2.2.2 onward.
09:14 paul we probably should say "fixed" in fact, as it's fixed for a long time.
09:13 slef I hate it when my bugs get bounced as invalid, can you tell? ;-)
09:13 pierrick slef, I close #159, wontfix :-)
09:13 kados heh
09:13 slef invalid = "you are a moron, submitter" ; wontfix = "we don't care about this (any more)"
09:13 pierrick slef, good question
09:12 kados ok
09:12 pierrick I close #159
09:12 slef why invalid not wontfix?
09:12 paul ???
09:12 kados (though it is full acquisitions which none of us use)
09:12 kados pierrick: it's 1.2.3 so probably
09:11 pierrick anybody can confirm?
09:11 pierrick I suppos #159 is closed, invalid
09:10 pierrick next is #159, "Item search during full acquisitions doesn't display results properly" on 1.2.3
09:09 kados I'll assign 111 to me and find out if katipo has a fix
09:09 paul OK
09:09 kados back to bug 111
09:09 pierrick paul, #119 reassigned to you
09:09 kados the bug is in fact that remaining requests are disappearing after the first is fulfilled
09:09 kados thd's right
09:08 thd kados: look at the last line of rachel's comment for 111.
09:08 paul I'll take care of it asap.
09:08 paul and not a varchar.
09:08 paul mmm... this problem is still here it seems : dewey still a double.
09:08 thd kados: rachel does identify one issue for which 111 is still a bug
09:08 kados 111 marked invalid with a comment explaining
09:07 pierrick next is #119 "Dewey Numbers like 000 or 581.0 aren't handled properly" in 1.2.3
09:07 kados 1
09:07 kados pierrick: I'll close 11
09:07 paul so, let's close
09:06 paul I have the same opinion too.
09:06 pierrick kados, you close #111?
09:06 kados pierrick: I'll confirm it
09:06 pierrick can someone confirm rachel's note: "not a bug"
09:06 paul kados: ++
09:06 paul mmm... 2 years at least.
09:06 kados thd: lets discuss that after the mtg
09:05 thd ?
09:05 thd paul: how long have they been using normal acquisitions in France/
09:05 pierrick but she didn't close the bug
09:05 paul so we could mark it invalid I thikn
09:05 kados right
09:05 paul but a feature
09:05 paul #111 : seems rachel thinks it's not a bug
09:05 paul thus my feeling
09:05 kados so bug 111
09:05 paul at least 5 libraries in france are using acqu system, without reporting a problem.
09:05 kados of course :-)
09:04 paul I can look at the problem if I know that there is a problem !
09:04 paul kados: ++
09:04 kados I'll tell chris to try to explain the probs
09:04 paul pierrick: acqui simple => it's a useless option now I think.
09:04 thd kados: yet they do not have a general fix they hard coded the fix for New Zealand
09:04 paul maybe they could explain the problem & the fix. Maybe there's something I don't understand
09:04 kados so we should file a new bug report and have katipo comment on it
09:03 kados paul: (perhaps because they are afraid it will just be broken again (this is the 3rd time it has been broken)
09:03 kados paul: but haven't committed the fix to cvs
09:03 kados paul: katipo has fixed full acquisitions for their clients
09:02 kados paul: #72 is probably fixed in CVS, but is also related to another major bug in rel_2_2: full acquisitions is broken
09:02 paul (now, by us)
09:02 paul while #111 is still to examine.
09:01 paul #72 is fixed by katipo, but not in CVS ?
09:01 kados sorry :-)
09:01 kados so about 111
09:01 kados not related to 111, but to #72
09:00 kados but haven't contributed the fix back to rel_2_2
09:00 paul which one ? 111 ?
09:00 paul kados: ++ I was afraid to miss something. I did not understand where 111 was related to acq !
09:00 kados katipo has fixed it for their clients
09:00 kados full acquisitions is busted in rel_2_2
09:00 thd :)
09:00 kados thd: that's a completely separate bug :-)
08:59 thd kados: that is still a bug in 2.X where normal acquisitions is broken
08:59 pierrick next is #111, "Client can request item multiple times" in 1.2.3
08:58 kados that's definitely not valid anymore
08:58 kados I'll close it
08:58 pierrick "can't receive an order" in 1.2.2
08:58 pierrick #72
08:57 kados pierrick: what's the next bug?
08:57 thd kados: quality documentation solves problems before they are created
08:56 thd kados: and we need better than brief documentation
08:55 kados hehe
08:55 thd kados: I do have some much greater wishes but that is happy to know
08:55 kados thd: your greatest wish is now realized :-)
08:55 kados w00t!
08:54 paul *************
08:54 paul ZOOM metasearching facilities are documented, albeit briefly.
08:54 paul programs using the new facilities, and for the very first time the
08:54 paul level for the first time. The 1.05 distribution includes example
08:54 paul underlying ZOOM-C code all along, but is now wired out to the Perl
08:54 paul metasearching applications in Perl. This functionality has been in the
08:54 paul asynchronous multiplexing - that is, the ability to build
08:54 paul The big change in release 1.05 is the inclusion of support for
08:54 paul protocols Z39.50, SRU and SRW.
08:54 paul module for building IR applications in Perl, using the standard
08:54 paul We are delighted to announce the new release 1.5 of the ZOOM-Perl
08:54 kados paul: no! what was the diff?
08:54 slef why not note it will be invalid once Perl-ZOOM transition is complete?
08:54 paul (however => did everydoby see that Perl-ZOOM 1.05 has been released by mike ?)
08:54 slef erm
08:53 pierrick I close #50
08:53 kados I agree to close it
08:53 kados right
08:53 paul + Net::z3950 won't be used anymore with Perl-ZOOM
08:53 paul (I never saw it, as I look only at 2.0 & 2.2 bugs. Otherwise, I would have closed it)
08:53 thd kados: I will give them an incentive
08:52 paul so, I would say close as invalid
08:52 kados thd: there is little incentive for them to use valid MARC
08:52 paul I think it refer to something that is no more in Koha now.
08:52 kados thd: the solution for many of pauls clients will be to continue to use invalid MARC records
08:52 paul #50 : reporter & assigned to have disappeared.
08:52 slef kados: welcome to my world. Esperanto forced me here a while back.
08:52 thd paul: the future will always fix everything but you will still need the supporting code for record exchange to copy catalogue from non-Unicode systems
08:51 slef brb, buying water sealant
08:51 kados slef: yep, I've learned a lot about encoding over the last week ...
08:51 pierrick we start with grand father bug 50
08:51 pierrick from oldest to youngest
08:51 paul pierrick: ++
08:51 pierrick hum... bug list
08:51 slef ;-)
08:50 kados heh
08:50 thd paul: For Western European languages in ISO 5426 there is a simple Perl module solution.
08:50 kados paul: ie, it will work for invalid MARC records
08:50 kados paul: the fix to MARC::File::XMl will allow continued use of invalid encodings
08:49 kados paul: probably the cleanup will be unnecessary
08:49 kados :-)
08:49 kados paul: and we already know your libraries don't have valid MARC because they can use the Koha MARC editor in 2.2.x which can only create severely invalid MARC
08:48 paul mmm... too bad...
08:48 kados paul: that specifies the encoding of the record
08:48 kados paul: for instance, EMN doesn't have 100$a in their records
08:48 thd paul: that is because you use invalid ISO 8859 encoding when the records specify ISO 5426.
08:48 kados paul: your libraries don't have valid MARC either :-)
08:47 paul thd: I never had problems reported by any library.
08:46 thd kados: with so many different valid UNIMARC encodings but not ISO 8859 the encoding problems are potentially worse for UNIMARC.
08:45 kados bug 1053 posted
08:45 kados pierrick: sure
08:43 thd kados: ISO 8859 was never a valid UNIMARC encoding even if you could obtain invalid records from BNF.
08:43 pierrick can we move to the "less sever" bugs list?
08:41 pierrick the notes are required to understand when the bug appeared
08:41 thd kados: that is only because records could be obtained in a non-library encoding. That was not really a solution o the problem for correct records in UNIMARC.
08:41 kados well, there are only a few of us developers, I think we can manage it :-)
08:41 kados ahh
08:41 pierrick kados, 1052 moved to "branch 2.2". The problem is you don't see when it appears (ie, after 2.2.5)
08:40 kados thd: Koha encoding has worked fine for UNIMARC
08:40 kados which is why NPL has always had problems with special chars outside the normal ascii range
08:40 thd kados: Koha never had correct encoding except for non-library encodings :)
08:39 kados which no browser can understand
08:39 kados because it's always been saved as MARC8
08:39 kados Koha's never had correct encoding for MARC21
08:39 kados thd: good point :-)
08:39 thd kados: although encoding was completely buggy when it was absent
08:39 kados (though it fixes many many bugs in 2.2.5's MARC editor)
08:38 kados pierrick: it does not exist in 2.2.5
08:38 pierrick OK kados, I add a 2.2, wait a second
08:38 kados pierrick: such as the encoding one I have
08:38 kados pierrick: some bugs are introduced _in_ cvs
08:38 kados pierrick: there are two CVSes
08:38 pierrick no, my opinion is that you use the last 2.2.x version where the bug remain
08:37 kados pierrick: how do I specify rel_2_2 for the bug version?
08:37 kados pierrick: is there a rel_2_2 version?
08:37 pierrick ?
08:37 pierrick about 1052, why is it "HEAD" in description and "rel_2_2" in JMF note
08:36 kados I"ll add it now
08:36 paul I accept the bug & change it's status
08:36 kados there is an undocumented bug related to encoding for UNIMARC data
08:36 kados great
08:36 paul I plan to work on it this week
08:36 paul this one is for me.
08:36 pierrick 1049 closed, next is 1052
08:35 thd pierrick: solving a problem once is usually better than needing solve it twice
08:35 hdl pierrick talking about 1049.
08:35 kados which bug are we on?
08:34 pierrick paul, I close 1049
08:34 thd pierrick: that is distinguished from solving a problem for 2.X and having a completely different model in 3.0 so that the underlying code has to be completely rewritten for 3.0 with some loss of the advantage from the 2.X work.
08:33 paul pierrick: I close or you close the bug ?
08:33 hdl 1048 I could close very shortly.
08:33 pierrick paul, too bad we can't say on which version the bug is corrected... too old version of bugzilla
08:33 kados good
08:32 paul 1049 is closed also, since 2.2.5
08:32 thd pierrick: there is more value in working on something that will solve problems in 2.X where the same code can be kept for 3.0
08:32 kados ok, pierrick can do it
08:32 pierrick OK, I close
08:32 kados I can confirm it
08:32 kados I think 1048 is fixed
08:31 pierrick next is 1048
08:31 pierrick thd, OK, I don't see the point but I understand what you mean
08:30 thd pierrick: I have tried to concentrate my attention to issues where much underlying code is liable to persist between 2.X and 3.0
08:29 pierrick thd, what do you mean "strongly related code"?
08:29 thd pierrick: I have tried to give attention where strongly related code would be making the transition to 3.0
08:28 thd pierrick: It is obvious even without working on head but I can make the best contribution to something that is mostly working already.
08:28 paul yes it is.
08:28 pierrick paul, I mean "branches" is a sub of C4::Koha
08:27 paul pierrick: you mean in general or for 1038 ?
08:27 pierrick thd, if you work a bit with HEAD, it should be obvious release 3.0.0 is not very near
08:27 hdl pierrick: may be there.
08:26 thd paul: yes, as I said
08:26 paul thd: I mean we are not close to release Koha 3.0 !
08:26 pierrick is C4::Koha used?
08:26 hdl main::branches pb on this bug was the last problem.
08:26 pierrick When chris & kados will tell koha-devel that zebra is *stable* on HEAD, bug reports will be welcomed
08:26 thd paul: what do you mean is not the case? Do you mean no release soon for 3.0 is not the case?
08:25 pierrick Zebra integration is not *stable* yet
08:25 pierrick do we all agree on this? (I do)
08:25 paul that's not the case for instance !
08:25 paul we should create bugs on head only when we are close to releasing something.
08:24 kados paul: yep, agreed
08:24 kados as it's about 3am in NZ?
08:24 paul I think it should be closed, as everybody know there are many problems on head ;-)
08:24 kados chris is very asleep I hope
08:24 pierrick (where is chris?)
08:24 pierrick zebra problem it seems
08:24 pierrick searching is broken in HEAD
08:23 pierrick next is bug 1038
08:23 kados thd: great, we'll await your update to the bug report
08:22 thd kados: template problems would merely require work to match paul's solution for subdivided subjects
08:21 thd kados: yes I can do that but the most important issue is no way to order repeatable fields in the editor.
08:20 kados thd: or could you update 997 with what's left?
08:20 kados thd: could we close out 997 and you can enter a new report for what's left?
08:19 thd kados: I will try again ...
08:19 thd kados: templates still order data incorrectly and some of my fixes no longer work because of other code changes.
08:19 kados thd: that sentence is incomprehensible :-)
08:18 thd kados: the most important thing missing is importing non-editor subfields into the editor and related field as distinct from subfield ordering for repeated fields.subfields
08:17 kados thd: is bug 997 satisfactorily resolved?
08:17 kados thd: after the Bug mtg we can discuss specifics of bug 824
08:17 thd kados: There is an issue for the limitation of existing date management code when only copyright date appears in the templates but is usually empty for limited date management code.
08:17 kados thd: what's missing?
08:16 kados we're close to a fix on this
08:16 pierrick bug 997: No MARC subfield sequence specification or subfield repeatability
08:16 pierrick thank you kados
08:16 kados bug assigned to me
08:16 pierrick I strongly suppose operator has found a workaround
08:15 kados heh
08:15 kados hmmm ... you could be right though
08:15 kados thd: I doubt it's anything more than operator error :-)
08:14 thd kados: I suspect that is the poor support for distinguishing copyright from publication date in MARC21
08:13 kados pierrick: I'll assign it to myself and I will investigate
08:13 kados seems unlikely that bug 824 is a real bug
08:13 paul (still on phone...)
08:13 pierrick OK Paul, so bug 824: Copyright Date not transfering with Record from breeding farm
08:12 paul I would do from oldest to youngest
08:12 pierrick bug 1052: Major Bug in MARC tables Sync
08:11 pierrick I go from the youngest to the oldest
08:11 kados sounds good
08:10 pierrick I propose we start by listing blocker/critical bugs and divide work
08:09 kados they might be! :-)
08:09 pierrick but as these bugs remains in bko, I suppose they are still present in Koha
08:09 kados those should probably be cleaned up at some point
08:09 kados right
08:09 pierrick I didn't filter on versions, so on the second list, many bugs are are very old, reported on 1.x
08:09 kados ok
08:08 pierrick and major to trivial on http://tinyurl.com/lgrnb
08:07 pierrick I've divided bugs in 2 groups of severity : blocker/critical http://tinyurl.com/l9hwj
08:07 kados sounds good
08:06 pierrick I think it's a good way to go, is there any objection to this?
08:06 kados yep
08:06 pierrick I've read the IRC log of a previous BSP and you had listed bugs by severity
08:05 kados great!
08:05 pierrick thanks to Kados and my new powers on bugs.koha.org, I've just added versions 2.2.x (1<=x<=5) and renamed version CVS to HEAD which is more appropriate
08:04 hdl hi
08:04 thd thd is here
08:03 pierrick (hi paul :-)
08:03 paul (although on phone)
08:03 pierrick who is around?
08:03 pierrick BSP can start?
07:59 kados np
07:59 pierrick thank you kados
07:58 kados pierrick: you should have full privs now
07:58 slef I've got to grab lunch, so I'll be missing at first
07:58 pierrick pierrick@koha-fr.org
07:58 pierrick :-)
07:58 kados pierrick: what's your username?
07:57 pierrick I mean, "who can upgrade to 2.20?"
07:57 pierrick No
07:57 kados pierrick: I'll grant you access
07:57 kados pierrick: you of course :-)
07:57 pierrick who is "webmastering" bugzilla?
07:56 pierrick OK
07:55 kados and decided that whoever is leading the mtg decides the order of bugs to address
07:55 kados IIRC we ran into this problem before
07:55 kados the sorting is completely random I think
07:54 kados yes
07:54 kados hmmm
07:54 pierrick can someone confirm that Bugzilla sorting is bugged?
07:52 kados :-)
07:52 slef yay, now mere mortals can keep the topic updated
07:51 kados sorry, that was a layover from yesterday
07:51 slef kados: /mode #koha -t
07:51 slef *T* Topic for #koha: no meeting today
07:51 kados slef: in about 15 minutes
07:51 kados slef: we've got a bug squash mtg
07:51 slef no meeting? oh ok
07:50 kados paul: that sounds like a good format
07:42 thd paul: I am sure you will manage things perfectly well
07:42 paul we agree
07:40 thd paul: so my point is that it ought not to be exclusively all the time small groups with a small scope
07:39 paul a group working 1 day, with 1 hour at the end of the day to present other what he did.
07:39 paul for sure. I think we should have 1 group speaking of zebra, 1 group speaking of design, 1 group speaking of ...
07:38 thd paul: well every small group may not be looking at every issue
07:38 paul narrow focus ???
07:38 pierrick Bug Squashing Party in 20 minutes :-)
07:38 thd paul: I agree that dividing into small groups with specific tasks would be useful as long as it is not exclusively small groups with a narrow focus
07:36 thd paul: I understand your concern perfectly well
07:36 paul only 1 for instance is reserved.
07:36 paul I phone anna
07:36 kados ahh
07:36 kados and how large are they?
07:36 kados what rooms are available at the meeting place?
07:36 paul thd : I agree. But my concern here is only the devWeek & it's efficiency.
07:35 paul I agree. I'll have to ask Anna W. to see if we can have more than 1 grop.
07:35 kados the good news is we have people with different skills attending
07:35 thd paul kados: koha needs more people not fewer even though a group of one might act the most :)
07:35 kados right, in fact, I often find groups of 3-4 are best
07:35 paul I think groups larger than 7/8 persons usually speak a lot & don't act a lot
07:34 kados paul: agreed
07:34 paul we will have to organize small groups if we want to do usefull things.
07:34 paul that's a lot of ppl.
07:34 paul 16 ppl in Marseille...
07:33 kados maybe I should change to rss2?
07:33 paul mmm... maybe i made something wrong
07:33 kados I see a date in firefox
07:33 paul not for me
07:33 kados does it not have the date?
07:30 paul it would be better with the date of the entries.
07:30 thd kados: the odd thing is that the log file had MARC records that I was able to use for import
07:30 paul right.
07:30 kados paul: I uncommented line 153 and now it works :-)
07:28 kados $userInfo = $auth->getUserData($user);
07:28 kados line 153 is:
07:28 kados paul: maybe ... but which?
07:27 paul kados: maybe a missing php library ?
07:27 thd kados: yes,. especially odd that chomp was commented out because the the second argument gives you MARC records delimited by the newline.
07:27 kados [client 70.106.188.191] PHP Fatal error: Call to a member function on a non-object in /var/www/koha.org/dokuwiki/feed.php on line 153, referer: http://wiki.koha.org/doku.php
07:27 kados pierrick: it's failing for me with:
07:27 kados pierrick: can you confirm that the feed is working on your local copy of dokuwiki?
07:25 kados huh
07:25 thd kados: you sent me the commented out version where chomp etc are all commented out :)
07:24 kados and I haven't worked on this since I sent it to you
07:24 kados it's not commented out in my version
07:24 kados you sure?
07:24 thd kados: you had commented it pout :)
07:24 kados loop?
07:24 thd s/statement/loop/
07:24 kados um ... well that's your problem then :-)
07:23 thd kados: yes but that is only in the commented out eval statement.
07:23 kados thd: or did you delete it? :-)
07:23 kados $record = MARC::File::USMARC->decode($marcrecord);
07:23 kados thd: do you have this line:
07:22 thd $marcrecord is not really used.
07:22 thd kados: After my $marcrecord = $onerecord[16];
07:21 kados thd: ?
07:21 thd kados: would you explain to me how afognak2koha.pl has access to the preexisting MARC record when it is not using the assigned variable?
07:15 thd there is no more use of $marcrecord apart from the commented out statement meant for use with eval.
07:15 thd kados: I am confused about how afognak2koha.pl does anything with the preexisting MARC record. After my $marcrecord = $onerecord[16];
07:12 kados http://bugs.splitbrain.org/?do=details&id=453
07:12 kados hmmm, it seems the latest version of dokuwiki has the problem
07:08 kados is line 153
07:08 kados $userInfo = $auth->getUserData($user)
07:08 kados interesting ...
07:08 thd kados: I know of someone at LC. This may be his department.
07:07 kados thd: if they could keep their mapping up to date?
07:07 kados thd: maybe you could contact your friend at LOC and find out ?
07:07 kados thd: probably not :(
07:07 thd kados: I saw the discussion you had with miker on #code4lib but that did not seem to me that a solution for every native language was coming this week :)
07:06 kados in the log
07:06 kados [client 213.41.184.186] PHP Fatal error: Call to a member function on a non-object in /var/www/koha.org/dokuwiki/feed.php on line 153
07:06 kados I get:
07:05 kados hmmm, feeds really aren't working ... very strange
07:05 kados thd: :-)
07:05 kados thd: well, just this page: http://www.loc.gov/marc/specifications/speccharucs.html
07:04 thd kados: Do you have a secret agent in LC to map all the hidden character sets for you?
07:01 kados pierrick: did you alter anything that would prevent the feed from working?
07:01 kados strange, I have no idea why that is
07:00 paul http://wiki.koha.org/feed.php => no element found
06:59 kados I'll check quickly the config
06:59 kados ahh, the feed is not working
06:59 kados what error?
06:59 kados hmmm
06:57 paul about feed.php : I added a bookmark on firefox ( a rss bookmark), but always get an error...
06:56 paul yes, they are on rle_2_2 as well as on head if I don't mind.
06:55 kados paul: did you see Mason's commits of the new barcode system?
06:53 kados paul: no, haven't had a chance to do the devweek page yet
06:53 kados paul: rss: http://wiki.koha.org/feed.php
06:53 thd paul: the CVS version is fine in that regard except that kados modification of 5 weeks ago is incomplete.
06:53 paul 2- did you open the page for devWeek ?
06:53 paul 1- is there a rss for wiki.koha.org
06:52 paul 2 quick questions :
06:52 kados yes, I leave on the 25th
06:52 kados paul: it's related to MARC::File::XML handling non-standard records (ie, ones that don't have 100$a fields)
06:52 paul (next week you'll be in Geneva isn't it ?)
06:52 paul kudos kados.
06:52 kados paul: shoul dbe able to fix it this week
06:52 kados paul: good news on the encoding probs: we've identified the problem
06:51 kados thd: that's clumsy of me :-)
06:51 paul hello kados
06:51 kados morning all
06:50 thd paul: I see now that the 399 record limit is a modification that kados shared with me. I guess he had forgotten the limitation that he himself had introduced :)
06:46 paul thd => ????? I usually import all records, so I don't understand why you're speaking of a limit
06:12 thd hdl: do you know a practical reason why limiting the number of records imported by bulkmarcimport.pl to less than 400 records would be important? would be important?
06:06 thd paul: why is bulkmarcmarcimport.pl limited to importing 399 records at a time?
06:05 thd paul: hello
02:30 pierrick hi hdl :-)
02:26 hdl hi pierrick
02:11 chris hi hdl and toins
02:10 ToinS hi
02:10 hdl hi all
02:10 hdl hi chris.
02:09 chris :)
02:09 ToinS sorry ! it's mistake ;-)
02:08 chris friendtux ?
01:54 ToinS join #friendtux
23:04 thd perhaps that 399 record constraint is designed to avoid overwhelming system RAM with an exceptionally large number of records.
23:01 thd maybe that is a 399 record limit
23:00 thd kados: I have discovered why you only succeeded at importing less than 400 records with bulkmarcimport.pl. There is a 400 record limit hard coded and then that number would be reduced by any error producing records rejected with the eval statement.
22:32 thd good night kados
22:31 kados thd: have fun :-)
22:31 kados thd: I'm gonna head to bed
22:31 kados thd: try uncommenting them out
22:31 thd kados: it must be the eval loop; I think all the eval loops have been commented out in afognak2koha.pl but they may have been serving a different purpose.
22:07 thd kados: commenting out assume_unicode did not affect the error.
22:03 thd kados: I suspect that some UTF8 code is introducing problems that does not exist in the records themselves but that may be a mere tautology. The problems are causing problems.
22:01 kados thd: at the top of afognak2koha.pl
22:01 kados thd: try commenting out 'MARC::Charset->assume_unicode(1);
21:55 thd kados: something changed though to remove that error from bulkmarcimport.pl between the CVS version and the version you sent me last night. There must be a clue there for fixing the problem with afognak2koha.pl
21:50 thd kados: what am I thinking? I checked Saturday and CPAN told me what it tells me today that XML::Parser is up to date.
21:44 thd CPAN has to check the metadata for current versions each day on my system which takes a little time over a dialup connection
21:40 thd kados: It is always more than 45 seconds on my machine
21:39 thd kados: I also want to know if it should work not merely that it does work :)
21:39 kados thd: you'll be able to tell in literally 45 seconds ;-)
21:38 kados thd: perl -MCPAN -e 'install XML::Parser'
21:38 kados thd: dude, do it the short way :-)
21:38 thd kados: I have not installed the CPAN version yet but the CPAN path is first in the extra long multi-version set of paths that I have.
21:34 kados :-)
21:34 thd kados: yes that is true :)
21:34 kados thd: you will be able to tell either way
21:33 thd kados: that presumes that the CPAN version will fix the error :)
21:33 kados thd: trying it will save several hours of research ;-)
21:32 kados thd: then re-running the script ;-)
21:32 kados thd: you can easily find out by simply installing the CPAN version
21:32 kados thd: I'm pretty sure CPAN already takes precedence
21:32 kados (I think)
21:31 kados echo $PERL5LIB
21:30 kados thd: type:
21:30 thd ?
21:30 thd kados: how would I rearrange path precedence
21:29 kados thd: it doesn't matter so long as the CPAN path takes precedent
21:29 thd kados: Debian does not put its version in the place CPAN puts its versions unless I were to configure CPAN to use the same location.
21:28 kados (this is perl after all)
21:27 kados no need to uninstall the old one
21:27 kados the upgrade should be seamless
21:27 kados in my experience, debian is always several versions behind
21:27 thd kados: O guess I should do that although I have generally preferred Debian to manage Debian Perl packages when it can.
21:26 kados perl -MCPAN -e 'install XML::Parser'
21:25 kados update XML::Parser
21:25 kados huh
21:25 thd kados: this is my error: not well-formed (invalid token) at line 39, column 60, byte 1542 at /usr/lib/perl5/XML/Parser.pm line 187
21:25 kados hmmm
21:22 thd kados: afognak2koha.pl is working up until the 11th record with shiny new 000/06-07 based itemtype code.
21:18 thd kados: yes, the very latest since Saturday and I spent that day discovering why I still had the CPAN version installed before I looked in an earlier Perl version directory.
21:16 kados (as of two days ago?)
21:16 kados thd: acquired via sourceforge as described at the debian install guide on kohadocs.org?
21:16 kados thd: are you running the CVS versions of MARC::Charset and MARC::File::XML?
21:15 thd kados: changing croak to warn did not cure my fatal XML parser error for afognak2koha.pl.
15:20 kados slef: so replacing 'Easter' with 'Spring' is actually _more_ christian :-)
15:20 kados slef: the funny part of that post is that the word 'Easter' is derived from a pagan goddess's name :-)
15:18 kados ciao :-)
15:18 pierrick OK :-) read you tomorrow
15:17 kados go have fun! :-)
15:17 kados holiday in EU
15:17 kados no meeting today
15:13 slef http://www.deborahlipp.com/wordpress/?p=303
15:10 cm slef: me neither
15:09 kados slef: haven't heard that one, but I wouldn't be too surprised :-)
15:09 slef kados: is it true that some US xtians are complaining about calling easter "spring holiday"? ;-)
15:09 cm i'm too bad with perl to do otherwise. :)
15:09 thd slef: yes all the festivals are pagan
15:09 kados cm: I'm too attached to MARC::Record to try it out :-)
15:08 kados cm: right ... I've heard good things about MarcEdit
15:08 kados slef: i thought so ... that would explain the bunnies :-)
15:08 slef thd: isn't eostre a pagan festival too?
15:07 cm i've been doing most of that with MarcEdit.
15:06 kados cm: normalizes all the branches, locations, formats/itemtypes, etc.
15:06 kados cm: shuffles around the holdings, does validity checks to make sure all the fixed fields are correct
15:05 kados cm: that parses all the marc data from the originating system to what Koha expects
15:05 kados cm: so I usually create a script oldmarc2kohamarc.pl
15:05 cm okay. I'll talk it over with Kyle.
15:04 kados and you can do everything in batch mode
15:04 kados it's pretty simple to do if you use the MARC::Record module
15:04 cm cool. thanks!
15:04 kados yep
15:04 cm interesting. is that what nelsonville did?
15:03 kados and easily replace it with the hash value
15:03 kados you can use the existing code as the hash key
15:02 kados then, when you're parsing your record
15:02 kados );
15:02 kados NELSONVILLE => NPL,
15:02 kados ATHENS => APL,
15:02 kados MEADVILLE => MDV,
15:02 kados my %branches = (
15:02 kados oops
15:01 kados my %branches;
15:01 kados something like this:
15:01 kados cm: i usually create a hash in my import script
15:01 kados cm: but it might be easier to just map your branch codes to shorter ones
15:01 cm i realize there are lots of tables with that field, so I'd have to change it there too.
15:01 kados cm: nope, shouldn't
15:00 cm would it break anything if I increased the length of the branchcode?
14:59 kados cm: what's up?
14:59 kados cm: sure
14:53 cm Hey kados, got a moment?
14:24 kados thd: :-)
14:23 thd kados: In the pagan parts of the world there is no rest for coders and the wicked.
14:22 hdl Easter Monday in France.
14:22 kados thd: in some parts of the world :-)
14:22 hdl Yes.
14:22 thd kados: Is it still a holiday?
14:22 hdl ok.
14:21 kados hdl: don't think we're gonna have a mtg today
14:21 hdl hi
14:21 kados hi hdl
13:24 kados ok
13:22 thd kados: well I will try changing croak to warn and see what happens after I finish making some changes to afognak2koha.pl
13:20 kados thd: and I'm not sure that will fix it
13:20 kados thd: it's Field.pm, not file.pm
13:15 thd kados: my File.pm from 22 April 2005 has neither croak or warn at lines 64-65.
13:05 thd kados: so I need to change File,pm for afognak2koha.pl to work?
13:04 kados I'll be back soon and I'll take a closer look at these issues
13:04 kados I've got to head out for about half an hour
13:03 kados right
13:03 thd s/died/die/
13:03 thd kados: I actually had not checked the result from the original MARC file only the fact that bulkmarcimport.pl did not died and did in fact give informative error messages.
13:02 kados thd: one of the important functions of the afognak2koha.pl script is conversion to utf-8
13:01 kados thd: if you only use the original marc file it will be in marc-8 and will not be compatible with any known browsers :-)
13:00 thd kados: If I apply afognak2koha.pl it dies after the 10th record.
12:59 thd kados: I was able to pass by the 11th record without even running afognak2koha.pl and just using the original MARC only file that had died after the 10th record previously.
12:57 kados thd: so shall I leave the record modification and insert to you entirely? :-)
12:57 kados thd: does it fix those as well? :-)
12:57 kados thd: cool
12:57 thd kados: the verbose error messages from bulkmarcimport.pl now warn about fields without proper field terminating characters etc.
12:56 kados thd: it only writes records that dont' fail IIRC
12:56 kados thd: the reason it passes the 11th record is because the afognak2koha.pl script doesn't write that record to the file :-)
12:55 thd kados: I can tell about the problems which may be additional to character encoding problems that bulkmarcimport.pl encounters but now corrects.
12:53 thd kados: I have only been experimenting with a small subset but I noticed that bulkmarcimport.pl at least managed to pass the 11th unmodified record without giving up on the file.
12:51 kados on yours too?
12:51 kados but only 398 ...
12:51 kados thd: but on my system at least, it doesn't import all of the records (417?)
12:50 thd kados: bulkmarcimport.pl seems to work fine and displays very verbose messages about the records as it proceeds.
12:49 thd kados: so I slept some but should sleep a bit more.
12:49 kados hehe
12:48 thd kados: I have mostly fixed indentation and item types, item types, answered a long telephone call, and tried to avoid sleeping.
12:48 kados thd: did you have a chance to attempt a bulkmarcimport?
12:48 kados I would like to figure out why so many record fail on bulkmarcimport
12:48 kados so you probably dont' need to update Field.pm anymore
12:48 kados but I think the latest versions use eval{}; to check for success before executing
12:47 kados thd: croak means die ... which was the problem I was facing with the early versions of the script -- it was just dieing
12:47 kados thd: so did you have a chance to work on adding the extra item fields?
12:47 thd kados: so is croaking better than warning?
12:46 kados though on my current system it's set to 'croak'
12:46 kados i experimented with changing 'croak' to 'warn'
12:45 kados or croak( "Tag \"$tagno\" is not a valid tag." );
12:45 kados ($tagno =~ /^[0-9A-Za-z]{3}$/)
12:45 kados line 64-65
12:45 kados in Field.pm
12:45 thd kados: I know exactly whey the indentation was flat. You could not have worked as quickly and corrected the indents at the same time.
12:44 thd kados: Yes I am sure that when you finish code you have beautiful indentation. This code was not yet finished.
12:44 kados yea, I was working pretty fast when trying to resolve all the probs
12:44 kados ahh, I see now there are a few missing indents
12:43 thd kados: In Perl it was merely a readability issue so that I could easily identify what loop I was looking within.
12:43 kados thd: i use vim
12:43 kados thd: you sure you're using a editor with 4 character tabs?
12:43 kados yep, standard
12:42 kados huh ... actually, it follows standard perl practice :-)
12:42 thd kados: mostly your indentation needed indentation. There was nothing wrong with it :)
12:41 kados thd: what was wrong with my indentation?
12:40 thd kados: however, the code would have worked just fine in Perl whether I could read it our not if perhaps I had your modified MARC::File::XML.
12:38 thd kados: your indentation is now readable :)
12:38 thd kados: Python code requires careful attention to whitespace which I had to fix in afonak2koha.pl :)
12:37 kados thd: let me find the change I made
12:37 kados thd: I'm betting that's because I changed my version of MARC::File::XML :-)
12:37 kados thd: so now you have an xml parser error from afognak2kokha.pl?
12:36 kados thd: no never
12:36 thd kados: Have you used Python much?
12:35 thd kados: I have no XML parser error from bulkmarcimport.pl now. That error had moved to afognak2koha.pl.
12:32 thd kados: yes I am here
12:29 kados thd: wondering if the scripts I sent you last night worked for you
12:29 kados thd: you around?