IRC log for #koha, 2006-04-19

Time	Nick	Message
12:29	kados	thd: you around?
12:29	kados	thd: wondering if the scripts I sent you last night worked for you
12:32	thd	kados: yes I am here
12:35	thd	kados: I have no XML parser error from bulkmarcimport.pl now. That error had moved to afognak2koha.pl.
12:36	thd	kados: Have you used Python much?
12:36	kados	thd: no never
12:37	kados	thd: so now you have an xml parser error from afognak2kokha.pl?
12:37	kados	thd: I'm betting that's because I changed my version of MARC::File::XML :-)
12:37	kados	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	thd	kados: your indentation is now readable :)
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: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	kados	yep, standard
12:43	kados	thd: you sure you're using a editor with 4 character tabs?
12:43	kados	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	kados	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	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:45	kados	in Field.pm
12:45	kados	line 64-65
12:45	kados	($tagno =~ /^[0-9A-Za-z]{3}$/)
12:45	kados	or croak( "Tag \"$tagno\" is not a valid tag." );
12:46	kados	i experimented with changing 'croak' to 'warn'
12:46	kados	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	kados	thd: croak means die ... which was the problem I was facing with the early versions of the script -- it was just dieing
12:48	kados	but I think the latest versions use eval{}; to check for success before executing
12:48	kados	so you probably dont' need to update Field.pm anymore
12:48	kados	I would like to figure out why so many record fail on bulkmarcimport
12:48	kados	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	thd	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	kados	but only 398 ...
12:51	kados	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	thd	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	kados	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	kados	thd: does it fix those as well? :-)
12:57	kados	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	thd	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	kados	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	thd	s/died/die/
13:03	kados	right
13:04	kados	I've got to head out for about half an hour
13:04	kados	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	thd	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	kados	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	kados	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	kados	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	kados	cm: i usually create a hash in my import script
15:01	kados	something like this:
15:01	kados	my %branches;
15:02	kados	oops
15:02	kados	my %branches = (
15:02	kados	MEADVILLE => MDV,
15:02	kados	ATHENS => APL,
15:02	kados	NELSONVILLE => NPL,
15:02	kados	);
15:02	kados	then, when you're parsing your record
15:03	kados	you can use the existing code as the hash key
15:03	kados	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	kados	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	kados	cm: that parses all the marc data from the originating system to what Koha expects
15:06	kados	cm: shuffles around the holdings, does validity checks to make sure all the fixed fields are correct
15:06	kados	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	kados	cm: right ... I've heard good things about MarcEdit
15:09	kados	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	kados	holiday in EU
15:17	kados	go have fun! :-)
15:18	pierrick	OK :-) read you tomorrow
15:18	kados	ciao :-)
15:20	kados	slef: the funny part of that post is that the word 'Easter' is derived from a pagan goddess's name :-)
15:20	kados	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	kados	thd: acquired via sourceforge as described at the debian install guide on kohadocs.org?
21:16	kados	(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	thd	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	kados	update XML::Parser
21:26	kados	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	kados	the upgrade should be seamless
21:27	kados	no need to uninstall the old one
21:28	kados	(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	thd	?
21:30	kados	thd: type:
21:31	kados	echo $PERL5LIB
21:32	kados	(I think)
21:32	kados	thd: I'm pretty sure CPAN already takes precedence
21:32	kados	thd: you can easily find out by simply installing the CPAN version
21:32	kados	thd: then re-running the script ;-)
21:33	kados	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	kados	thd: perl -MCPAN -e 'install XML::Parser'
21:39	kados	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	thd	kados: It is always more than 45 seconds on my machine
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: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: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
22:01	kados	thd: try commenting out 'MARC::Charset->assume_unicode(1);
22:01	kados	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	thd	kados: commenting out assume_unicode did not affect the error.
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:31	kados	thd: try uncommenting them out
22:31	kados	thd: I'm gonna head to bed
22:31	kados	thd: have fun :-)
22:32	thd	good night kados
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.
23:01	thd	maybe that is a 399 record limit
23:04	thd	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	hdl	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	thd	paul: why is bulkmarcmarcimport.pl limited to importing 399 records at a time?
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: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	kados	paul: good news on the encoding probs: we've identified the problem
06:52	kados	paul: shoul dbe able to fix it this week
06:52	paul	kudos kados.
06:52	paul	(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	kados	yes, I leave on the 25th
06:52	paul	2 quick questions :
06:53	paul	1- is there a rss for wiki.koha.org
06:53	paul	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	kados	paul: no, haven't had a chance to do the devweek page yet
06:55	kados	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	paul	about feed.php : I added a bookmark on firefox ( a rss bookmark), but always get an error...
06:59	kados	hmmm
06:59	kados	what error?
06:59	kados	ahh, the feed is not working
06:59	kados	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	kados	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	kados	thd: :-)
07:05	kados	hmmm, feeds really aren't working ... very strange
07:06	kados	I get:
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	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	kados	thd: maybe you could contact your friend at LOC and find out ?
07:07	kados	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	kados	$userInfo = $auth->getUserData($user)
07:08	kados	is line 153
07:12	kados	hmmm, it seems the latest version of dokuwiki has the problem
07:12	kados	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	thd	there is no more use of $marcrecord apart from the commented out statement meant for use with eval.
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:21	kados	thd: ?
07:22	thd	kados: After my $marcrecord = $onerecord[16];
07:22	thd	$marcrecord is not really used.
07:23	kados	thd: do you have this line:
07:23	kados	$record = MARC::File::USMARC->decode($marcrecord);
07:23	kados	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	kados	it's not commented out in my version
07:24	kados	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	kados	pierrick: can you confirm that the feed is working on your local copy of dokuwiki?
07:27	kados	pierrick: it's failing for me with:
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	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	kados	line 153 is:
07:28	kados	$userInfo = $auth->getUserData($user);
07:30	kados	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	paul	that's a lot of ppl.
07:34	paul	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	paul	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	kados	and how large are they?
07:36	kados	ahh
07:36	paul	I phone anna
07:36	paul	only 1 for instance is reserved.
07:36	thd	paul: I understand your concern perfectly well
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: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	paul	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	kados	slef: in about 15 minutes
07:51	slef	T Topic for #koha: no meeting today
07:51	slef	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	kados	yes
07:55	kados	the sorting is completely random I think
07:55	kados	IIRC we ran into this problem before
07:55	kados	and decided that whoever is leading the mtg decides the order of bugs to address
07:56	pierrick	OK
07:57	pierrick	who is "webmastering" bugzilla?
07:57	kados	pierrick: you of course :-)
07:57	kados	pierrick: I'll grant you access
07:57	pierrick	No
07:57	pierrick	I mean, "who can upgrade to 2.20?"
07:58	kados	pierrick: what's your username?
07:58	pierrick	:-)
07:58	pierrick	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	pierrick	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	pierrick	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	kados	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	pierrick	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	kados	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	kados	hmmm ... you could be right though
08:15	kados	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	pierrick	bug 997: No MARC subfield sequence specification or subfield repeatability
08:16	kados	we're close to a fix on this
08:17	kados	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	kados	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	thd	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	kados	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	thd	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	pierrick	searching is broken in HEAD
08:24	pierrick	zebra problem it seems
08:24	pierrick	(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	kados	paul: yep, agreed
08:25	paul	we should create bugs on head only when we are close to releasing something.
08:25	paul	that's not the case for instance !
08:25	pierrick	do we all agree on this? (I do)
08:25	pierrick	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	thd	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	pierrick	next is 1048
08:32	kados	I think 1048 is fixed
08:32	kados	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	paul	I plan to work on it this week
08:36	kados	great
08:36	kados	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	pierrick	?
08:37	kados	pierrick: is there a rel_2_2 version?
08:37	kados	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	kados	pierrick: some bugs are introduced _in_ cvs
08:38	kados	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	kados	(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	kados	Koha's never had correct encoding for MARC21
08:39	kados	because it's always been saved as MARC8
08:39	kados	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	kados	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	kados	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	pierrick	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	kados	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	kados	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	kados	:-)
08:49	kados	paul: probably the cleanup will be unnecessary
08:50	kados	paul: the fix to MARC::File::XMl will allow continued use of invalid encodings
08:50	kados	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	pierrick	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	paul	+ Net::z3950 won't be used anymore with Perl-ZOOM
08:53	kados	right
08:53	kados	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	paul	module for building IR applications in Perl, using the standard
08:54	paul	protocols Z39.50, SRU and SRW.
08:54	paul	The big change in release 1.05 is the inclusion of support for
08:54	paul	asynchronous multiplexing - that is, the ability to build
08:54	paul	metasearching applications in Perl. This functionality has been in the
08:54	paul	underlying ZOOM-C code all along, but is now wired out to the Perl
08:54	paul	level for the first time. The 1.05 distribution includes example
08:54	paul	programs using the new facilities, and for the very first time the
08:54	paul	ZOOM metasearching facilities are documented, albeit briefly.
08:54	paul	*************
08:55	kados	w00t!
08:55	kados	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	thd	kados: quality documentation solves problems before they are created
08:57	kados	pierrick: what's the next bug?
08:58	pierrick	#72
08:58	pierrick	"can't receive an order" in 1.2.2
08:58	kados	I'll close it
08:58	kados	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	kados	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	paul	which one ? 111 ?
09:00	kados	but haven't contributed the fix back to rel_2_2
09:01	kados	not related to 111, but to #72
09:01	kados	so about 111
09:01	kados	sorry :-)
09:01	paul	#72 is fixed by katipo, but not in CVS ?
09:02	paul	while #111 is still to examine.
09:02	paul	(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	kados	paul: katipo has fixed full acquisitions for their clients
09:03	kados	paul: but haven't committed the fix to cvs
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:04	kados	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	paul	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	paul	#111 : seems rachel thinks it's not a bug
09:05	paul	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	thd	?
09:06	kados	thd: lets discuss that after the mtg
09:06	paul	mmm... 2 years at least.
09:06	paul	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	paul	so, let's close
09:07	kados	pierrick: I'll close 11
09:07	kados	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	paul	and not a varchar.
09:08	paul	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	kados	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	pierrick	I suppos #159 is closed, invalid
09:11	pierrick	anybody can confirm?
09:12	kados	pierrick: it's 1.2.3 so probably
09:12	kados	(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	paul	;-)
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	paul	thd: yes
09:17	kados	thd: resolved in cvs
09:17	kados	thd: I have tested it myself
09:17	paul	kados: you mean in rel_2_2 isn't it ?
09:17	paul	(as it should be fixed in 2.2.3/4 )
09:17	paul	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	kados	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	kados	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	paul	ok
09:19	paul	fixed or wontfix ?
09:20	paul	(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	kados	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	kados	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	paul	that can be closed too
09:22	paul	(as issuing system deeply modified. this bug means nothing now)
09:22	kados	I agree
09:23	kados	though there is another bug in issuingrules
09:23	kados	that should be a blocker for 2.4 IMO
09:23	pierrick	I close #239, wontfix ?
09:23	kados	pierrick: yes
09:23	kados	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	kados	I'll assign it to myself and look into it
09:26	kados	done
09:27	kados	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	kados	next?
09:28	pierrick	281
09:28	pierrick	(diabolical one)
09:28	kados	is Mike at katipo?
09:29	kados	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	kados	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	kados	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	kados	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	kados	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	kados	pierrick: not a biblio or an item
09:34	pierrick	kados, that's make sense
09:34	paul	... which is useless
09:34	paul	(reserving on a biblioitem is useless I mean)
09:34	kados	right
09:34	kados	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	paul	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	kados	pierrick: biblio, biblioitem, item
09:36	kados	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	kados	in fact we need a multi-tiered hierarchy to have full MARC holdings support
09:37	kados	that includes more than three levels
09:37	kados	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	paul	but I'm not 100% sure.
09:39	paul	it's a classic database management problem.
09:39	paul	the basket number is defined when the 1st line is saved, not when you clic on "create order".
09:39	paul	thus, librarians can't be 2 with the same basket #
09:39	paul	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	paul	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	paul	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	kados	but we should check to be sure it works
09:42	kados	I'll have NPL check on this
09:42	pierrick	should I reassign to tumer?
09:43	kados	wait ... I missread it
09:43	kados	Tumer didn't fix this bug
09:43	kados	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	pierrick	I take #285
09:46	kados	pierrick: you should ask chris about it
09:46	kados	pierrick: I bet katipo has a fix
09:46	kados	morning owen
09:46	owen	Hi
09:46	pierrick	OK kados, I'll bug chris on this
09:47	pierrick	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	kados	they are often charged a small fee
09:48	kados	I think this is fixed
09:48	kados	but I'm not 100% sure
09:48	kados	I know that borrower categories includes a fee option
09:48	kados	but I"m not sure it generates an invoice
09:48	kados	on their account
09:49	kados	someone needs to investigate this
09:50	kados	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	pierrick	next is #287
09:51	kados	287 is also for katipo/chris
09:51	pierrick	OK
09:52	pierrick	#322 ow
09:52	pierrick	now
09:53	kados	I will take 322
09:53	kados	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	kados	379 is for chris
09:55	kados	next?
09:55	pierrick	390
09:55	pierrick	(paul's one)
09:56	kados	390 is about statuses in general I think
09:56	kados	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	kados	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	paul	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	pierrick	newt is #426
10:01	pierrick	s/newt/next/
10:01	pierrick	(HEAD of 2003)
10:01	pierrick	was it before rel_2_2 start?
10:01	paul	yep
10:01	paul	it was rel_2_0
10:02	paul	a quite old.
10:02	paul	& 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	pierrick	next is #484
10:05	kados	:-)
10:05	pierrick	I'll bug chris
10:05	pierrick	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	pierrick	paul?
10:07	owen	Sorry paul -- I was referring to bug 484 being a template bug
10:08	owen	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	paul	#551 now ?
10:09	paul	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	pierrick	next is 555
10:11	paul	#555 is irrelevant I think.
10:12	paul	ok, next is 559
10:12	paul	do we want to work on #559 ?
10:12	kados	we need sample data for 2.4 I think
10:12	kados	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	paul	although we should be able to give a sample DB to anyone requesting.
10:13	paul	as I have for french unimarc libraries (EMN DB)
10:13	kados	ok ... so it should be in CVS
10:13	kados	but not in the release
10:13	pierrick	we should provide samples on koha.org but not in releases
10:14	pierrick	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	paul	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	paul	(at least, I tried to fix them when I see them)
10:16	paul	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	pierrick	next is 604
10:18	pierrick	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	paul	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	kados	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	kados	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	paul	(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	kados	so maybe mark 629 as fixed and refer to ISBD as the solution?
10:25	kados	(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	pierrick	next is 642
10:28	kados	is websitesearch.pl even used anymore?
10:29	kados	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	kados	it's just the display that's different
10:30	kados	but it woudl be nice to have a website search
10:30	kados	IMO
10:30	kados	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	paul	show nothing interesting
10:31	kados	pierrick: some libraries catalog websites
10:31	kados	pierrick: in MARC even :-)
10:31	owen	kados: I think yes to the itemtype
10:31	pierrick	next is 645
10:32	pierrick	an encoding bug :-)
10:32	paul	I think it can be closed (#645)
10:32	kados	I'll take that one
10:32	kados	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	paul	#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	kados	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	kados	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	kados	pierrick++
10:39	pierrick	kados, why do you say that?
10:39	pierrick	(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	paul	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	paul	bug still here.
10:43	kados	for 668, I have noticed that problem in rel_2_2
10:43	kados	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	kados	we had a mtg at NPL yesterday
10:45	kados	about 'in transit' status
10:45	kados	I will take bug 670
10:45	kados	684?
10:46	kados	684 is fixed, new marc editor doesn't create blank fields anymore
10:46	pierrick	you missed 682
10:46	kados	woops :-)
10:47	kados	682 is wontfix
10:47	kados	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	kados	in rel_2_2
10:48	pierrick	paul?
10:48	kados	in HEAD it's NA
10:48	paul	why kados ?
10:48	paul	(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	kados	so what is this prob?
10:49	paul	in MARC-editor, suppose 200$a is mandatory.
10:50	paul	you duplicate 200$A and enter 2 values.
10:50	paul	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	paul	you can't, as 200$a is mandatory.
10:50	kados	heh
10:50	paul	so both $a must contain something !
10:50	paul	(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	kados	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	pierrick	paul and I are scared by Javascript, it seems ;-)
10:52	pierrick	next is 687
10:52	paul	right. a shame there is no really useable doc in french to learn javascript
10:52	paul	and 686 ?
10:52	paul	Only first ISBN used
10:52	paul	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	paul	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	pierrick	then I said "next is 686")
10:55	kados	(paul, did you fix problem of repeated subfields leaving blank subfieldcodes?)
10:55	kados	(or should I file a new bug report for that also?)
10:55	paul	pierrick: right. but I spoke of 684 hereafter.
10:55	paul	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	kados	:-)
10:57	paul	slef says that only the 1st ISBN in the retrieved biblio (from the z3950 server) can be searched.
10:57	paul	I think it's a really minor problem.
10:57	paul	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	paul	ok
10:58	paul	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	paul	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	paul	(I think it is for MARC=OFF libraries)
10:59	paul	(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	paul	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	hdl	But I can cope with it.
11:02	hdl	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	kados	wait ... 707 I'm not sure
11:03	hdl	pierrick: of course :) But will have to ask katipians :)
11:05	hdl	kados: is it still a prob ?
11:06	kados	not sure about 707
11:06	kados	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	paul	(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	kados	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	kados	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	pierrick	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	kados	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	kados	ahh dates
11:15	kados	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	kados	if there is a quote in the name of the server
11:16	kados	it's impossible to delete it
11:16	kados	like:
11:16	kados	NPL's Server
11:16	paul	hdl => you take care of it too ?
11:16	hdl	yep
11:16	hdl	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	paul	(owen comment)
11:17	paul	(see owen comment I mean)
11:17	kados	right
11:17	kados	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	pierrick	that's not the case her
11:20	pierrick	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	kados	it's not fixed I think
11:20	paul	s/maybe//g => there is "keyword", even in french.
11:20	paul	(in result list header)
11:20	pierrick	so it's wontfix
11:21	paul	but that's really a pain to fix...
11:21	paul	yep.
11:21	kados	in fact, I ahve a fix for NPL already
11:21	kados	I removed searchdesc completely
11:21	pierrick	great workaround ;-)
11:21	hdl	:D
11:21	kados	and gave the template the vars
11:21	kados	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	paul	hdl take care
11:22	kados	good
11:23	paul	#735 thus ?
11:23	kados	it's a katipo one?
11:23	kados	need to bug chris I htink
11:23	kados	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	paul	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	paul	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	kados	for their clients
11:25	kados	that they haven't committed
11:25	kados	pierrick: can you ask chris about this?
11:25	paul	so #735 => wontfix
11:25	paul	(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	pierrick	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	kados	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	kados	(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	paul	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	kados	paul: maybe we should have two default frameworks
11:30	kados	paul: because the standard marc framework is quite huge
11:30	kados	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	paul	so= kados is working on a framework
11:31	paul	that is also the marc21 semantic definition
11:31	kados	paul: in fact, thd is the one that did it
11:31	kados	paul: the marc21 framework I mean
11:31	kados	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	kados	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	paul	(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	pierrick	on friday?
11:33	kados	pierrick: works for me
11:34	paul	(I mean : away on friday)
11:34	paul	(at SAn-OP=
11:34	paul	(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	paul	or during devWeek !
11:35	kados	paul: good idea
11:35	kados	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	paul	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	pierrick	paul, the evening
11:37	paul	kados: ok, my wife happy to meet you, although a little bit afraid to speak english ;-)
11:37	paul	pierrick: we will be in Paris, probably not on the net, but IRL !
11:37	paul	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	pierrick	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	kados	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	kados	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	paul	but i can confirm you mail has arrived.
11:44	paul	so you can come ;-)
11:44	slef	paul: can you send me any extra info email, please?
11:44	slef	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	paul	2 => Programme is on wiki.koha.org
11:48	paul	3=> yes
11:48	slef	eek, must go
11:48	slef	sorry
11:52	thd	paul: tell me about the new UNIMARC framework

← Previous day | Channels | #koha index | Today | Next day → | Search | Google Search | Plain-Text | plain, newest first | summary