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