← Previous day | Today | Next day → | Search | Index
All times shown according to UTC.
Time | Nick | Message |
---|---|---|
12:03 | slef | ok np |
12:06 | kados | mailman will do it automatically |
12:24 | slef | no it won't, as it's bouncing to the From not the envelope |
12:24 | (buggy RFC-ignorant mailserver) | |
12:30 | kados | ahh |
13:19 | owen | Hi GrahamDoel |
13:19 | GrahamDoel | Hi owen |
13:20 | I have a fresh install of koha and am strugglind with the z39.5 searches, do you think you might be able to point me in the right direction | |
13:20 | ? | |
13:20 | owen | I can try |
13:20 | GrahamDoel | thanks |
13:21 | owen | What are the symptoms of your problem? Are the searches not returning any results? |
13:22 | thd | kados: are you back? |
13:22 | GrahamDoel | when I do an add biblio enter the isbn and click the z3950 search it just returns z3950 Still ?? requests to go |
13:22 | kados | thd: yep |
13:22 | GrahamDoel | I have run the start daemon script, but don't know how to check |
13:23 | thd | /msg kados kados: I am still finishing the Afognak job |
13:23 | kados | :-) |
13:23 | owen | Hmmm... that's one I /don't/ know. |
13:24 | kados: can you assume the daemon is running properly if the script doesn't generate any errors? | |
13:24 | kados | GrahamDoel: check the logs |
13:24 | you need to see what the log says to be sure | |
13:24 | GrahamDoel | ok... could you remind me where they are? |
13:25 | kados | GrahamDoel: whereever you specified in the z3950-daemon-options file |
13:25 | GrahamDoel | ok, thanks... I'll look now |
13:27 | owen | GrahamDoel: you filled in a search term, right? An ISBN or title? |
13:28 | GrahamDoel | yes, I found that on a list somewhere and did check that I had done. |
13:32 | ahh.. I see. No connection at... | |
13:42 | thd | kados: there is a bug in the 008 plugin |
13:42 | kados | thd: do tell |
13:45 | thd | kados: if the first 6 positions for record creation date are blank then using the plugin does not set them automatically but eliminates the first six positions moving everything over by 6 positions |
13:45 | kados: is that clear? | |
13:45 | kados | yes |
13:46 | should be a simple fix | |
13:46 | thd | kados: maybe this happens for the 008 plugin under other conditions but this was the condition where I noticed it. |
13:51 | GrahamDoel | thank you kados and owen, problem solved. Thanks again |
13:55 | kados | thd: could you file a bug in bugzilla ... mark it as 'blocker' since it prevents creation of valid MARC21 records |
13:56 | thd | kados: is that what blocker means? |
13:56 | kados | blocker means that you can't release the software until it's fixed |
13:57 | IMO anything that prevents us from creating valid MARC21 is a blocker :-) | |
13:57 | thd | kados: you do not have to use the plugin and so there is a workaround |
13:58 | kados: editing fixed fields without some extra aid is crazy though | |
13:58 | kados | yep |
14:59 | thd | kados: bug filed but I have not been able to assign it to you |
15:01 | kados: when I have tried assigning or CC a bug to you it tells me that jmfliblime.com is not a recognised email address for that purpose. | |
15:03 | kados: how can I assign a bug to you | |
15:03 | ? | |
15:10 | kados | thd: I'm here |
15:10 | thd: jmfkados.org is the right address I think | |
15:10 | thd | ahh |
15:11 | kados: I remembered an important question | |
15:11 | kados | thd: I'm all ears :-) |
15:12 | thd | kados: we are using MARC instead of MARC-XML in Zebra for performance reasons? |
15:12 | kados | not quite |
15:12 | we are using binary MARC for the initial import | |
15:12 | and MARCXML after that | |
15:12 | internally it's stored in Zebra's internal format | |
15:13 | thd | kados: importation is much slower if it were in XML? |
15:15 | kados | yes |
15:15 | about 1000 times slower :-) | |
15:16 | thd | kados: does the record editor add a new record in MARC-XML or MARC? |
15:17 | kados: does the record editor also submit the resulting record from edits int the same format? | |
15:19 | kados: can we break the MARC record size limit without problem using MARC-XML once the record has been added or newly created? | |
15:19 | kados | I think so |
15:19 | though I haven't tested | |
15:20 | thd | kados: what format does the record editor save to the database for Zebra? |
15:23 | kados: is importation 1000 times slower if the records have already been converted to UTF-8? | |
15:23 | kados | yes |
15:23 | thd | kados: what format does the record editor save to the database for Zebra? |
15:24 | kados | there is code to do both |
15:24 | but currently, I'm using xml | |
15:25 | thd | kados: is there any performance difference for Zebra presenting one format or other for search results? |
15:26 | kados | not that I know if |
15:26 | of course, XML is much more verbose :-) | |
15:26 | a 10K MARC21 file could easily be 100K in MARCXML | |
15:27 | thd | kados: yet the browser only has to manage the browser view |
15:29 | kados: have you bookmarked MARC::Record relative to MARC::File::XML? | |
15:30 | kados | bookmarked? |
15:31 | thd | s/bookmarked/benchmarked add field, and other transformations/ |
15:33 | kados: my spell checker sometimes gives my strange transformations that I do not always catch | |
15:33 | s/my/me/ | |
15:35 | kados | I haven't benchmarked anything yet |
15:35 | officially :-) | |
15:38 | thd | kados: I guess that a benchmark is not needed in instances when you have a 1000 times difference. No one cares if it is 998 or 1002 times too long for that particular case. |
15:44 | kados | :-) |
17:15 | thd | kados: are you still there? |
21:13 | russ | dewey seen thd? |
21:13 | dewey | thd was last seen on #koha 3 hours, 57 minutes and 37 seconds ago, saying: kados: are you still there? [Fri Jun 30 10:15:30 2006] |
21:13 | russ | thd are you about? |
21:13 | thd | yes russ |
21:15 | russ | hiya |
21:15 | i have a marc question for you if you have a minute | |
21:15 | thd | yes |
21:15 | russ | the 300 b subfield, is that repeatable? |
21:16 | or should it be repeatable? | |
21:16 | thd | yes, I believe |
21:18 | russ: apparently, I was wrong | |
21:19 | russ: 300 is repeatable even 300 $a is repeatable and $a is seldom repeatable | |
21:20 | russ: 300 $b is not repeatable | |
21:20 | russ | right ok |
21:20 | thanks | |
21:20 | what resource do you use to find this out? | |
21:22 | thd | russ: http://www.loc.gov/marc has the most up to date information for the concise format information |
21:22 | russ: I may guess at what you want to know for encoding 300 | |
21:24 | russ: If you were wanting to use a repeated $b to add additional information about accompanying material in $e, which is not allowed then .. | |
21:24 | put all the information in $e itself for the accompanying material | |
21:26 | russ | ok cool thanks |
21:26 | thd | russ: consider the example of the atlas in http://www.loc.gov/marc/biblio[…]phys.html#mrcb300 |
21:27 | russ: 300 ##$a271 p. :$bill. ;$c21 cm. +$eatlas (37 p., 19 leaves of plates : 19 col. maps ; 37 cm.) | |
21:28 | russ: $e contains everything for the accompanying atlas which might have been in a repeated $b were it allowed. | |
21:29 | russ: $e also contains what might have been in a repeated $c which is allowed but I have not noticed it used. | |
21:31 | russ: $e, itself, is not repeatable | |
21:41 | russ | thanks for all of that, that link to the loc was helpful, i have found what i need. |
02:11 | osmoze | hello |
02:16 | btoumi | hi all |
02:16 | ToinS | hello |
02:29 | btoumi | hi toin's |
02:34 | ToinS | salut bruno |
02:35 | btoumi | ca va |
02:35 | ? | |
02:36 | hdl | hello world |
02:36 | ToinS | très bien |
02:36 | salut hdl | |
02:36 | btoumi | hello hdl |
03:39 | slef | hii |
04:00 | ToinS | hi slef |
06:40 | tumer | hdl:are you around? |
07:20 | hdl | tumer[A]: I'm here. |
07:20 | I was having lunch and overlooked your beep | |
07:20 | tumer ??? | |
07:20 | dewey | tumer is here for a few seconds ;-) |
07:21 | tumer | hi hdl? |
07:21 | hdl | hi |
07:21 | how are you ? | |
07:21 | tumer | i am having probleems with authorities |
07:21 | btoumi | hi all |
07:22 | hdl | If I can help. |
07:22 | Can you tell me ? | |
07:22 | tumer | hdl: on the editor when you get an authority with all these repeatable fields.. |
07:22 | the biblio-blind-search.pl gets confused | |
07:23 | hdl | an url ? |
07:23 | tumer | if the cataloger plays with cloning subfields or changing their order.. |
07:24 | and then tries to field the field from the authorities.. | |
07:24 | hdl | Oh Yes. |
07:24 | tumer | they get filled into differnt tags .. |
07:24 | hdl | OUPPS. |
07:24 | tumer | or if you try to delete tem.. |
07:24 | it deletes a different tag | |
07:25 | hdl:did you get this? | |
07:25 | hdl | No, but I have VERY simple authorized forms. |
07:26 | tumer | hdl: do you understand the problem? |
07:26 | hdl | Yes. |
07:26 | Should be a problem of dupping the authtagtoreport using the good order. | |
07:26 | tumer | so authorities is now btoken with this new editor and i had to stop using authorities |
07:27 | hdl | Is this only because of the latest changes in MARC editor ? |
07:27 | tumer | i think so because we never had it before |
07:28 | we are in the middle of cataloguing 10,000 books and the system is now broken | |
07:28 | hdl | BEST is the fiend of good. :( |
07:29 | which version are you working on ? | |
07:29 | devweek ? | |
07:29 | tumer | if you want to reproduce the problem.. |
07:30 | juts have a page where there are more than one field that uses authorities in te same page | |
07:30 | thd: i am using dev_week merged to rel_2_ | |
07:31 | thd | tumer: yes |
07:31 | tumer | i am using npl templates though |
07:32 | hdl | wow, what a mess. |
07:32 | tumer | hdl:also i think there is a missing code |
07:33 | hdl | Is there an official branch for devweek merged with rel_2_2 or is it that You did a merge ? |
07:33 | tumer | when you clean a field of authority the authority number does not get cleaned.. |
07:34 | the blind-biblio-search.pl only cleans subfields a..z | |
07:34 | thd | tumer: I had thought that there had been no changes to the authorities editor in a very long time |
07:35 | tumer | thd:i am talking about using authorities in normal marc editor |
07:35 | hdl | tumer: It is not so easy to understand but with default templates, you have to open the popup and clear entry. |
07:35 | tumer | thd: thats exacly the what i am talking about |
07:35 | thd | yes, I was about to guess that |
07:36 | tumer | oh hi thd |
07:36 | thd | hello tumer |
07:36 | tumer | hdl:the previous line was supposed to be for you not to thd |
07:37 | thd | I realise you pinged me by mistake |
07:37 | tumer | its just that i write to td more so used to write ths automatically |
07:38 | the last line is a mess of mistakes.sorry | |
07:38 | hdl | It's ok. |
07:38 | tumer | hdl:its the same way with npl templates. You use a popup for athorities |
07:39 | thd | tumer: so the problem is that $3 is not being cleared when the popup is opened? |
07:39 | hdl | But on my devweek version, which is quite old, the "clearing" of authorities seems to work. |
07:40 | (thd: $9 kohaauth number) | |
07:40 | tumer | hdl:yes on the screen buth the marc record could be left with $9 authid filled |
07:40 | thd | oops $9 I mean |
07:41 | tumer: are you using a recent version from CVS? | |
07:41 | tumer | hdl:the main problem is not cleaning |
07:41 | the problem occurs if you use this cloning of subfieds and then use yhe authorities | |
07:42 | thd | tumer: which version are you using? |
07:42 | tumer | my marc editor is version the one just before paul broke |
07:43 | i am afraid to upgrade now | |
07:43 | thd | tumer: that version has a problem when cloning fields and certainly you should not upgrade the addbiblio.pl |
07:44 | tumer: kados made a fix which he has not posted yet but which he described the needed changes | |
07:45 | tumer | well thats not so easy of not upgrading as the system is now half-breed |
07:46 | hdl | Yes, I understand. |
07:47 | tumer | hdl:say a subject authority has 150$a 150$x and another 150$x does it get transferred to the marc editor correctly? |
07:48 | hdl | I have not tested. But paul told me that there could possibly be a problem. |
07:49 | tumer | hdl:well there is. It does not |
07:49 | hdl | I could investigate but not before next week. |
07:50 | tumer | even if you prepare multiple x's on the editor they get filled with same data allover. |
07:50 | hdl | It should be a problem of PERL context. |
07:51 | tumer | hdl:the problem i am having is not of multiple subfields but of completely wrong fields getting cleared or even sometimes filled |
07:51 | thd | tumer: I have found the fix kados suggested on #koha |
07:52 | hdl | you know : when using $field->subfield('a') it returns either a string OR a list depending on the variable on the right of your = |
07:52 | thd | 25/06/06 12:09:00+-5<kados:#koha>for a temporary fix |
07:52 | tumer | hdl:the changes in marc editor breaks authorities |
07:52 | thd | 25/06/06 12:09:11+-5<kados:#koha>look for all instances of 'new_from_xml' in addbiblio.pl |
07:52 | 25/06/06 12:09:17+-5<kados:#koha>and make sure they look like this: | |
07:52 | 25/06/06 12:09:18+-5<kados:#koha>my $record=MARC::Record->new_from_xml($xml, 'UTF-8'); | |
07:52 | tumer | thd:i already have that |
07:53 | thd | oh, I suspected that all the bugs would not be gone |
07:54 | tumer: I have seen more examples of double encoding UTF-8 to UTF-8 | |
07:54 | tumer | kados have been silent about encoding problems i reported anyone knows why? |
07:55 | thd | tumer: kados is extremely fatigued by encoding problems |
07:56 | tumer | thd:well at least that releives me some of mine |
07:56 | slef | Is there any easy way to debug a z39.50 connection that I think is being blocked by a firewall, or do we need to wait for the administrator to interrogate the firewall? |
07:58 | thd | tumer: there is still also a problem with the fonts used in the CSS for every template which will obscure the actual character content for some UTF-8 multibyte characters. |
07:59 | tumer | thd:yes i know but not for internet explorer which i use |
07:59 | thd | tumer: this problem is browser independent |
08:00 | tumer | thd:as long as i keep with true type (unicode) characters of windows i do not et that problem |
08:02 | thd | tumer: my problem of posting UTF-8 content is gone now with Firefox 1.5.04. What I am identifying is a problem for character display that may not affect Turkish characters but certainly exists for French character display in both Firefox and the Opera post from Windows. |
08:02 | s/post/port/ | |
08:03 | slef: what problems does you Z39.50 connection report | |
08:03 | ? | |
08:06 | tumer: I am observing this character display problem especially in the uncommon cases where a fixed width font is used but maybe it is my GNU/Linux system | |
08:08 | slef | thd: none, as far as I can tell. |
08:09 | thd | tumer: kados did say that he would hunt down the double encoding problem that you reported |
08:09 | tumer: he has only been back from ALA yesterday | |
08:10 | slef: do you mean the connection is working fine or that you have no error messages? :) | |
08:11 | slef: can you determine that the daemon is running with the ps command? | |
08:15 | tumer we could test whether you can see the same problem when you are off phone | |
08:20 | tumer | thd: i am back now |
08:21 | thd: what do you want me to do? | |
08:25 | thd: the page looks normal with french accented characters | |
08:27 | thd | tumer: do you see a difference between the representation of the accented character in the results for search sting and author results column? |
08:27 | tumer | thd:no it looks perfectly fine |
08:27 | thd | tumer: what accented characters do you see? |
08:28 | tumer | thd:i see accented e that is é |
08:28 | slef | thd: yes, and I can run it through the debugger. It forks but never changes from Still ?? requests to go. |
08:29 | thd | tumer: so the problem is with X-windows or fonts on my GNU/Linux system then. |
08:29 | tumer | thd: only in name Valérie there is an accent |
08:30 | thd: by the way this is what i am trying to achieve | |
08:30 | thd | tumer: thank you now I know that I suffer deeply for my freedom I see some very strange out of order accent on this page |
08:31 | tumer: yet, because different fonts are use on the page with an individual record instead of multiple search results the individual record looks fine | |
08:32 | tumer | thd:yes the problem is how did you mabage to get this page display correctly like this and not have the double utf8 problem? |
08:33 | doing the same search on my system will give the double encoding problem | |
08:33 | thd | tumer: my X-windows may also be partly misconfigured like everyone's |
08:34 | tumer | thd:so you mean you know the solution or this? |
08:34 | thd | tumer: I have not seen the double encoding problem on the installation on my system at home but I have seen it on a production system that I have been working on for kados |
08:35 | tumer: I do not know the solution for double encoding other than finding where it is happening and stopping it. | |
08:36 | tumer | thd:now this is serious. What you are saying is that its not a double encding problem but a problem of X-windows or Windows? |
08:37 | thd: by the way is your serach results coming from ZEBRA or mysql? | |
08:38 | thd | tumer: i expect that the double encoding I see on the production system where I have been editing records is from some part of the system not recognising that the record was already converted from MARC-8 to UTF-8. There had somewhat recently been a problem for MARC::File ::XML doing that. |
08:38 | tumer | thd: are you using zebra? |
08:38 | thd | tumer: my search results are coming from SQL |
08:39 | tumer: I have not taken the time actually to set up Zebra yet. | |
08:40 | tumer: I have s[pent most days recently too busy to advance my installation of Koha | |
08:40 | tumer | thd:we may be sitting on another problem that this thing actually happens with ZEBRA only and not with SQL? |
08:41 | thd | tumer: I expect that the production system where I have seen double encoding is not using Zebra but I am not certain |
08:42 | kados: are you awake yet? | |
08:42 | tumer | thd:the same record with the same search will yield the double encoding on my system and kados's which both use zebra |
08:43 | thd | tumer: do you mean that you added it to your system? |
08:43 | tumer | thd: no but i have the same authorname i mean |
08:44 | thd | tumer: that is very bad |
08:44 | tumer: has your record been saved with the record editor or only imported? | |
08:45 | tumer | thd:unfortunately i have to go to a reception now, but at least we are starting to all see the same problem which is good |
08:45 | thd | :) |
08:46 | tumer | thd:if you catch kados can you please mention him this coversation? |
08:47 | thd | tumer: I have been trying to show him this problem since late yesterday |
08:47 | tumer: I hope that he has not gone away | |
08:48 | tumer: you also have the other problem with not clearing $9. | |
08:50 | slef: do you have a valid reliable Z39.50 target configured and are you searching for a record that can certainly be found? | |
08:50 | kados | thd: I will be soon :-) |
08:51 | thd: I've got to head out for a couple hours | |
08:51 | thd: I'll be back later | |
08:51 | thd | kados:OK tumer and I have found something |
08:52 | kados | thd: can't wait to hear about it ;-) |
08:53 | (btw: entity encoding the utf8 may be the answer to our previous encoding probs, I thought of that last night ...) | |
09:30 | thd | paul: are you there? |
09:51 | paul: are you still here? | |
10:41 | slef | thd: no and no |
10:41 | thd: :) | |
10:41 | thd: I'm 99% sure the firewall is blocking z39.50 to all other servers :-/ | |
10:43 | thd | slef: z39.50 servers are only good. You should let them all in. My firewall does not block z39.50 responses over port 80 but my security is low :) |
← Previous day | Today | Next day → | Search | Index