Time |
S |
Nick |
Message |
14:50 |
|
kados |
OK, goodie, now we're making progress |
14:52 |
|
kados |
fbcit: how can I reproduce the issue, which bibs is it happening with? |
14:56 |
|
fbcit |
that's the problem |
14:56 |
|
fbcit |
one of my data entry people has the problem now |
14:57 |
|
fbcit |
the other does not |
14:57 |
|
fbcit |
grrrr |
14:57 |
|
kados |
weird |
14:57 |
|
kados |
they are using Koha's built-in MARC editor with Z39.50? |
14:57 |
|
kados |
or some other process? |
14:57 |
|
fbcit |
right |
14:58 |
|
kados |
can you hook us up with the specific target info you have set up and which records specifically they are trying to import and subsequently add items too? |
15:01 |
|
fbcit |
yep |
15:02 |
|
fbcit |
btw: zebraqueue daemon is running and the missing records are begin processed by it, contrary to my previous observation |
15:02 |
|
fbcit |
but they do not show in a search |
15:03 |
|
fbcit |
most marc records are coming from loc here |
15:03 |
|
kados |
lets try this: turn off zebraqueue daemon, I don't trust it |
15:03 |
|
kados |
and add a cron task with rebuild_zebra.pl and the -z option |
15:03 |
|
kados |
for bibs and authorities |
15:04 |
|
kados |
so use -z -a -b |
15:06 |
|
rhcl |
For what it's worth, we had (have?) the _exact_ same problem here. Even though we still have the zebra daemon running, we either do a manual rebuild or wait for the cron job to rebuild zebra. |
15:07 |
|
kados |
yea, I pretty much have given up on the zebraqueue daemon |
15:07 |
|
rhcl |
we're using the flags "-w -b -a" for the cron rebuild |
15:07 |
|
fbcit |
k |
15:07 |
|
kados |
I'll make sure that's clear in the install docs |
15:07 |
|
fbcit |
cron task is in place |
15:07 |
|
kados |
rhcl: why not -z ? |
15:08 |
|
fbcit |
kados: so do we are thinking this is a script problem rather than some weird record problem, right? |
15:08 |
|
rhcl |
huh, just because I don't know? |
15:08 |
|
kados |
rhcl: I'd recommend -z, it will use the zebraqueue table, so you can run it every 5 minutes or so |
15:09 |
|
kados |
rhcl: ie, rather than a complete index re-build |
15:09 |
|
kados |
fbcit: if you are adding records that aren't making it into zebraqueue table, that sounds like abug, but I need specific examples |
15:09 |
|
kados |
so i can reproduce it |
15:09 |
|
kados |
fbcit: I think the ebraqueue daemon issues are separate |
15:09 |
|
kados |
fbcit: and running rebuild_zebra.pl with -z option should clear those issues up |
15:10 |
|
fbcit |
no, they appear to be making it there, I was mistaken earlier due to zebraqueue daemon running |
15:10 |
|
kados |
ahh |
15:10 |
|
kados |
ok, so then it's probably entirely the zebraqueue daemon |
15:10 |
|
fbcit |
it was grabbing them before I looked :-) |
15:10 |
|
rhcl |
the man page for zebra doesn't show a "-z" flag. |
15:11 |
|
kados |
rhcl: the -z flag is for the reubild_zebra.pl script |
15:11 |
|
kados |
rhcl: do misc/migration_tools/rebuild_zebra.pl --help |
15:11 |
|
rhcl |
OK, tnx |
15:12 |
|
kados |
fbcit: that's a huge relief, esp since I was hoping to get 3.0-stable out this week ;-) |
15:12 |
|
fbcit |
kados: about mysql utf-8 |
15:12 |
|
kados |
fbcit: a bug where new items weren't getting added to zebraqueue would have thrown a wrench in that plan |
15:13 |
|
fbcit |
the koha db is utf-8 and db/table/column level |
15:13 |
|
fbcit |
does it really matter what the mysql server is at that point? |
15:13 |
|
kados |
yes, it really does |
15:14 |
|
kados |
especially important is the encoding of the connection |
15:14 |
|
kados |
maybe not so much the server though ... |
15:14 |
|
kados |
all I know is, I've seen some weird encoding issues without following things carefully |
15:14 |
|
fbcit |
so after setting up mysql server for utf-8, I need to export my bibs and re-import them to correct encoding? |
15:15 |
|
kados |
are you certain that's the cuprit? |
15:15 |
|
fbcit |
it does appear to be an encoding issue as it is occurring with every book in Spanish |
15:15 |
|
kados |
ok, that's a good sign |
15:15 |
|
fbcit |
diacriticals seem to be the issue |
15:15 |
|
kados |
yep |
15:15 |
|
fbcit |
so, fix config; export; import? |
15:16 |
|
kados |
if you could give me some specific examples, I'd like to make sure a properly encoded system handles those records correctly |
15:16 |
|
fbcit |
k |
15:16 |
|
kados |
but I hvae to eat breakfast first, so if you could send me a list of ISBNs or titles to search for on LOC that trigger a problem for you, I'll check them out when I get back |
15:17 |
|
fbcit |
Diccionario De La Lengua Española |
15:17 |
|
kados |
(you could also teston koha.liblime.com, though the indexing wont' updat there, but you could see if the encodings work) |
15:17 |
|
fbcit |
ISBN 8423968146 |
15:19 |
|
fbcit |
that record is being pulled from UNC @ Chapel Hill |
15:19 |
|
fbcit |
afton.lib.unc.edu:210 |
15:19 |
|
fbcit |
innopac db |
15:19 |
|
fbcit |
utf8 encoding |
16:14 |
|
kados |
fbcit: hack |
16:14 |
|
kados |
back I mean |
16:14 |
|
kados |
fbcit: testing now |
16:15 |
|
fbcit |
kados: it is definitely utf-8 afaict |
16:15 |
|
kados |
Ok, the title's showing up with a question mark, so it doesn't bode well |
16:15 |
|
fbcit |
I also added bug 2327 |
16:16 |
|
kados |
I suspect that the encoding isn't utf8 |
16:16 |
|
kados |
while claiming to be utf8 |
16:16 |
|
kados |
have you tried marc8? |
16:16 |
|
fbcit |
no |
16:16 |
|
kados |
fbcit: got another isbn for me so I can test something? |
16:17 |
|
fbcit |
hold on |
16:19 |
|
fbcit |
kados: do a z3950 search on 8476456700 with all servers selected |
16:20 |
|
kados |
k |
16:21 |
|
kados |
is that at the chapel hill target? |
16:21 |
|
kados |
fbcit: i wanna test marc8 |
16:21 |
|
fbcit |
no |
16:21 |
|
fbcit |
I'm trying to locate where they pulled it |
16:21 |
|
kados |
I need another example from chapel hill if you have one |
16:23 |
|
kados |
fbcit: I changed the chapel hill target to marc-8 and it's working now |
16:24 |
|
kados |
fbcit: if you change it to marc8, Koha will convert it to utf8 for you automagically |
16:25 |
|
kados |
fbcit: i've also had terrible problems iwth the LOC's claimed UTF-8 encoding, use MARC8 there too |
16:27 |
|
fbcit |
kados: works fine now |
16:27 |
|
kados |
fbcit: OK, I'll update the bug |
16:27 |
|
kados |
galen may have time next week to investigate what the specif problem with the III systems' UTF8 is |
16:27 |
|
kados |
but for now, setting to MARC8 is a decent alternative |
16:27 |
|
fbcit |
z3950 searches still blow chunks with isbn's on certian targets |
16:28 |
|
kados |
fbcit: can you give me some examples? |
16:28 |
|
fbcit |
see bug 2327 for starters |
16:29 |
|
fbcit |
but also 083793950X with the UNC target |
16:29 |
|
kados |
another innopac system |
16:29 |
|
kados |
III-- |
16:30 |
|
fbcit |
even w/UNC set to MARC8 the error occurs |
16:30 |
|
kados |
intersting |
16:30 |
|
fbcit |
I also notice that none of the z3950 targets installed by the webinstaller have a default Encoding set |
16:31 |
|
kados |
ahh, I wonder if that's the prob |
16:31 |
|
fbcit |
that column should probably be set NOT NULL |
16:31 |
|
kados |
from the display it looks like the all have marc-8 |
16:31 |
|
kados |
they I mean |
16:32 |
|
fbcit |
here they show nothing except where I set them |
16:32 |
|
kados |
yea, they have MARC-8 |
16:32 |
|
kados |
at least for me they do |
16:32 |
|
kados |
and checking the sample data, it's in there |
16:32 |
|
fbcit |
hrmm |
16:35 |
|
fbcit |
well, that does not fix the can't call method raw error |
16:37 |
|
nengard |
owen (at least I think it was you) didn't we make it so that this preference 'OPACBaseURL' wasn't necessary ... or was that someone else I was talking with? |
16:38 |
|
kados |
nengard: it still is necessary for some stuff |
16:38 |
|
kados |
nengard: but there's a bug that we will fix in 3.2 to finally remove it |
16:38 |
|
nengard |
thanks kados - just checking as I browse through |
16:38 |
|
nengard |
my documentation |
16:40 |
|
nengard |
what is GranularPermissions - this is something new to me |
16:41 |
|
kados |
nengard: it turns on the little + button for some permission groups, like 'tools' |
16:41 |
|
acmoore |
OMG. ask gmcharlt. prepare for about 4 hours of explaining. |
16:42 |
|
nengard |
acmoore :) hehe |
16:42 |
|
nengard |
I like kados's explanation - I'll take that nice short one |
16:42 |
|
kados |
nengard: turn it ON and then edit a patron's permission, you'll see it for yourself |
16:42 |
|
gmcharlt |
nengard: also see http://git.koha.org/cgi-bin/gi[…]658533d95912b5d6f |
16:42 |
|
kados |
it's the start of further granularization of permissions for Koha |
16:43 |
|
gmcharlt |
nengard: and http://git.koha.org/cgi-bin/gi[…]96cc5ad4fea545a9d |
16:43 |
|
nengard |
gmcharlt you mention a system preference: CheckSpecificUserPermissions - but i don't see it |
16:43 |
|
gmcharlt |
was renamed to GranularPermissions |
16:45 |
|
nengard |
k |
16:45 |
|
kados |
my $rec = $oResult[$k]->record($i); |
16:45 |
|
kados |
if ($rec) { |
16:45 |
|
kados |
my $marcrecord; |
16:45 |
|
kados |
$marcdata = $rec->raw(); |
16:45 |
|
kados |
fbcit: oddly, the error is claiming that $rec is undefined |
16:45 |
|
kados |
fbcit: but right above it, we test for that |
16:46 |
|
kados |
strange |
16:47 |
|
fbcit |
very |
16:47 |
|
nengard |
gmcharlt - i may have missed this - but what if this is on and then gets turned off later - does it change the user's permissions from the granular form to the original? or do they keep their permissions until their record is edited? |
16:48 |
|
gmcharlt |
nengard: it reverts to the original behavior, although the specific permissions are retained |
16:48 |
|
nengard |
k |
16:49 |
|
gmcharlt |
practically, though, the syspref should never be changed from on to off |
16:49 |
|
kados |
fbcit: [Wed Jul 09 11:49:04 2008] [error] [client 166.129.4.61] ZOOM error 1 "Permanent system error" (addinfo: "Permanent system error") from diag-set 'Bib-1', referer: http://staff-jmf.dev.kohalibra[…]span%CC%83ola%20/ |
16:49 |
|
kados |
that's the error Im getting |
16:51 |
|
kados |
|
16:51 |
|
kados |
[Wed Jul 09 11:50:45 2008] [error] [client 166.129.4.61] ZOOM error 1 "Permanent system error" (addinfo: "Permanent system error") from diag-set 'Bib-1', referer: http://staff-jmf.dev.kohalibra[…]pl?frameworkcode= |
16:51 |
|
kados |
[Wed Jul 09 11:50:45 2008] [error] [client 166.129.4.61] Premature end of script headers: z3950_search.pl, referer: http://staff-jmf.dev.kohalibra[…]pl?frameworkcode= |
16:51 |
|
kados |
|
16:51 |
|
kados |
fbcit: where are you seeing the other, more useful error? |
16:52 |
|
kados |
fbcit: did you set DEBUG or something? |
16:53 |
|
fbcit |
weird |
16:53 |
|
fbcit |
no on DEBUG |
16:53 |
|
fbcit |
are you searching on 8423968146 @ UNC? |
16:54 |
|
fbcit |
which error are you referring to? |
16:55 |
|
kados |
no, searcing catnyp, I'm talking about the error about raw() as documented in your bug report |
16:55 |
|
fbcit |
try 083793950X on the UNC target as that gives "Can't call method "raw" on an undefined value at /usr/share/koha/intranet/cgi-bin/cataloguing/z3950_search.pl line 216. |
16:55 |
|
fbcit |
" |
16:56 |
|
kados |
huh |
16:56 |
|
kados |
if I search it in cattnyp with yaz-client it returns no results |
16:56 |
|
fbcit |
it also produce that error on catnyp |
16:56 |
|
kados |
I don't get that error for some reason, i get the one above |
16:56 |
|
kados |
maybe we have different deubg levels or something |
16:57 |
|
kados |
fbcit: I'll try searching unc for that isbn using yaz-client |
16:57 |
|
fbcit |
so if no results are returned I wonder why "if ($rec) {" fails? |
16:57 |
|
kados |
not sure |
16:58 |
|
kados |
interstingly, I get failyure with default settings in yaz-client for both cattnyp and unc |
16:58 |
|
kados |
f @attr 1=7 083793950X |
16:58 |
|
kados |
returns no hits |
16:59 |
|
fbcit |
kados: when was that check added to z3950_search.pl? my version does not have it |
16:59 |
|
kados |
something screwy going on here :/ |
17:00 |
|
kados |
fbcit: ? what check? |
17:00 |
|
fbcit |
if... |
17:00 |
|
kados |
fbcit: the check for $rec? |
17:00 |
|
fbcit |
right |
17:00 |
|
kados |
might have been yesterday, MJ added a couple things |
17:00 |
|
fbcit |
my $rec = $oResult[$k]->record($i); |
17:00 |
|
fbcit |
my $marcrecord; |
17:00 |
|
fbcit |
$marcdata = $rec->raw(); |
17:00 |
|
fbcit |
that might explain it |
17:01 |
|
kados |
but I still get an error |
17:01 |
|
kados |
just not the same one |
17:01 |
|
fbcit |
this install was updated two weeks ago |
17:01 |
|
kados |
so that explains our difference :-) |
17:01 |
|
kados |
the bib-1 error is somewhat telling |
17:01 |
|
kados |
I suspect III is expecting a different set of arguments for queries than we're providing |
17:02 |
|
fbcit |
brb |
17:02 |
|
kados |
fbcit: are any queries on those targets working? |
17:02 |
|
kados |
any ISBN queries in particular? |
17:02 |
|
kados |
and if we try to find the same records via another mechanism does it fail? |
17:04 |
|
fbcit |
bak |
17:04 |
|
fbcit |
back even |
17:05 |
|
fbcit |
kados: it does not appear that any isbn searches work against those targets via z3960_search.pl |
17:05 |
|
kados |
yea |
17:05 |
|
kados |
I'm trying 'Who's Who in the Media and Communications 1998-9' |
17:05 |
|
kados |
as title now |
17:05 |
|
kados |
nothing found |
17:05 |
|
kados |
but no failures |
17:06 |
|
fbcit |
yea, titles do not cause failures here either |
17:08 |
|
kados |
OK, so there is something III catalogs are expecting that we're not providing |
17:09 |
|
kados |
fbcit: http://irspy.indexdata.com/fin[…]_count=10&_skip=0 |
17:09 |
|
kados |
http://irspy.indexdata.com/raw[…]g%3A210%2FINNOPAC |
17:10 |
|
fbcit |
cool |
17:12 |
|
kados |
oh, you're kidding me ... |
17:12 |
|
kados |
Innopac Z39.50 server does not always use the. standard Bib-1 attributes. For example, the Any. Field search (use attribute = 1016) is actually a. title search |
17:14 |
|
kados |
fbcit: can we be blamed for conforming to the standard ? |
17:14 |
|
kados |
this is why I get silly mad |
17:14 |
|
fbcit |
ok, code here is in sync now |
17:14 |
|
kados |
this is an instance where Koha gets blamed |
17:14 |
|
kados |
but we're blamed for following the standard |
17:14 |
|
kados |
arrrg |
17:15 |
|
kados |
fbcit: this is great: |
17:15 |
|
kados |
f @attr 1=1016 "Who's Who in the Media and Communications 1998-99" |
17:15 |
|
kados |
Sent searchRequest. |
17:15 |
|
kados |
Received SearchResponse. |
17:15 |
|
kados |
Search was a bloomin' failure. |
17:15 |
|
kados |
Number of hits: 0, setno 1 |
17:15 |
|
kados |
Result Set Status: none |
17:15 |
|
kados |
records returned: 1 |
17:15 |
|
kados |
Diagnostic message(s) from database: [100] Unspecified error -- v2 addinfo 'Search taking too much time. Server is disconnected.' |
17:16 |
|
kados |
so basically, I try a 1=1016 (actually keyword, but apparantly title in III), and it can't respond fast enough |
17:16 |
|
kados |
fbcit: do you think you could explain this problem to your catalogers? |
17:16 |
|
fbcit |
looks like a 5 pound spider rather than a simple bug |
17:17 |
|
kados |
fbcit: in a way that they would feel warm and fuzzy about Koha ? |
17:17 |
|
kados |
yea |
17:17 |
|
kados |
5-lb-spiders-- |
17:17 |
|
kados |
fbcit: Ok, I"ll add this additional info to the bug report |
17:18 |
|
fbcit |
sounds like we will have to have code to handle the various exceptions |
17:19 |
|
kados |
yep |
17:19 |
|
kados |
this would be better handle with pazpar2 |
17:20 |
|
kados |
you can pass info about each target config separately before doing the federated search |
17:20 |
|
kados |
fbcit: I'm afraid this won't be fixed for 3.0 |
17:20 |
|
kados |
but I'm confident we can work on a solution for 3.2 using pazpar2 |
17:21 |
|
fbcit |
np, we'll work around it here |
17:21 |
|
kados |
fbcit: biblios already uses pazpar2 |
17:21 |
|
kados |
ccatalfo: around? |
17:21 |
|
ccatalfo |
sure am |
17:22 |
|
ccatalfo |
smth about using pazpar2 with different bib attributes per target? |
17:23 |
|
kados |
ccatalfo: yea |
17:23 |
|
kados |
ccatalfo: something to bear in mind for biblios |
17:23 |
|
kados |
ccatalfo: each type of target is going to have different expectations for what a 'title' search is for example |
17:24 |
|
ccatalfo |
kados: yup |
17:24 |
|
ccatalfo |
kados: as it happens, at some point over the last month i put a hack in place to let us do that in the biblios.conf file, but fallback on biblios' defaults if not specified |
17:24 |
|
kados |
ccatalfo: and I have some good news from Index Data about how to manage a database of target information too |
17:24 |
|
kados |
oh, cool |
17:24 |
|
kados |
you rock |
17:24 |
|
ccatalfo |
kados: it's not in the main git repo yet, though |
17:24 |
|
kados |
ccatalfo: I'll fill you in on the ID info when I have some time |
17:24 |
|
ccatalfo |
kados: ah, that sounds great |
17:25 |
|
kados |
it will allow us to pull from dbs like IRSPY and have local overrides on select values of fields, as well as add our own targets, per user |
17:25 |
|
kados |
should be pretty swank actually |
17:25 |
|
kados |
more on that later :-) |
17:25 |
|
ccatalfo |
cool, can't wait to get details and try out... |
17:25 |
|
kados |
fbcit: I will figure out a way to fix this completely broken instance, but as to getting III to work, that'll have to wait |
17:27 |
|
fbcit |
so not only are we expected to fix koha, but other systems too, heh? |
17:27 |
|
kados |
apparantly |
17:50 |
|
kados |
fbcit: it appears from furthe tests that the actual connections to innopac are failing for isbn searches |
17:50 |
|
kados |
fbcit: I'm adding some user errors to make it clear where the problem is |
17:50 |
|
kados |
to the actual cataloger |
17:59 |
|
fbcit |
tnx |
18:16 |
|
Kyle |
Hey all, I submitted some Koha 3 patches. I followed the git_usage guide on the koha wiki. I haven't seen them show up on the patches mailing list. Is there any way I can find out if they went through? |
18:18 |
|
kados |
Kyle: it's possible they are in moderation, are you subscribed to the koha-patches list on lists.koha.orjg? |
18:18 |
|
kados |
Kyle: if you want, you can also cc me, jmf AT liblime DOT com and I will confirm your outgoing mail is working |
18:19 |
|
Kyle |
Yes, however, I think it's a problem with mail email configuration. I'll cc them to you as well. |
18:20 |
|
Kyle |
I used the command 'git send-email filename' |
18:20 |
|
Kyle |
Is there something else I need to do? |
18:21 |
|
kados |
you may need to properly configure your outgling mail server |
18:21 |
|
kados |
exim perhaps? |
18:21 |
|
kados |
or postfix? |
18:22 |
|
Kyle |
From what I'm reading, it sounds like I can just send them to patcheskoha.org as attachments from my gmail account. Is this correct? |
18:28 |
|
acmoore |
Kyle, they'll probably work OK like that, though some mailers are known to goof up attachments. give it a try, though. |
18:28 |
|
acmoore |
kados, who is the moderator for the patches@ list, anyway? |
18:29 |
|
acmoore |
Kyle, they'll get held up for moderation before they make it to that list if you're not subscribed. |
18:30 |
|
acmoore |
Kyle, have you been working on making your PHP enamcements work with koha 3? |
18:30 |
|
kados |
acmoore: hdl is the moderator for that list |
18:31 |
|
kados |
Kyle: gmail will definitely goof up the attachments |
18:31 |
|
kados |
Kyle: you could just point to them on a web server |
18:31 |
|
acmoore |
kados, thanks. It's dinnertime in France, so we might not get them approved today, I guess. |
18:31 |
|
kados |
and I can grab then from there |
18:31 |
|
kados |
acmoore: *nod* |
18:38 |
|
kados |
wow, you gotta love III, their errors always come back as "No error" |
18:38 |
|
kados |
brilliant! |
18:39 |
|
sawariwap |
any tentative date for the final release? |
18:40 |
|
kados |
sawariwap: today, tomorrow? |
18:41 |
|
kados |
this week for certain |
18:44 |
|
sawariwap |
oh ok |
18:44 |
|
sawariwap |
cool |
18:44 |
|
sawariwap |
:) |
18:56 |
|
Kyle |
acmoore: I probably won't be porting the koha-tools stuff until we get closer to our switchover. I would like to rewrite as much as possible in perl and integrate it into Koha 3.0. That way it benefits more people and is easier to maintain. |
18:56 |
|
acmoore |
Kyle, yeah, that would be great! It looks like you've been doing some cool stuff, and we could always use the help. |
18:59 |
|
Kyle |
Thanks. I really want to move away from 'doing my own thing' to contributing more directly to Koha. I've been moving stuff from koha-tools into dev_week. Recently, I rewrote our fines system ( which creates fines on an item's return, instead of nightly ) as part of Fines.pm in dev_week. It's been much more stable since. |
20:39 |
|
acmoore |
anyone know why C4::Output::pagination_bar makes links like http://example.com/cgi-bin/koh[…]lio.pl?q=a?page=2 when you pass it a URL that already has some query_string n it. it seems like it doesn't realize it's supposed to be using &'s after there's already a ? in there. |
20:39 |
|
acmoore |
I'm presuming I'm using it wrong, although I'm using it just like other calls. |
20:41 |
|
acmoore |
coinsidering that it's been around for so long, nearly unmolested, I have to presume I'm using it wrong, but I can't figure out how to do it right. |
20:44 |
|
kados |
acmoore: I never presume anything with code taht's been around a log time in Koha:-) |
20:49 |
|
chris |
it was written by plg .. april 2006, so its relatively recent :-) |
20:49 |
|
chris |
improved: C4::Output::pagination_bar builds an HTML pagination bar with no |
20:49 |
|
chris |
language dependency. This function hugely simplifies templates and offers a |
20:49 |
|
chris |
standard pagination method. This function also improves preformances. |
20:49 |
|
chris |
apparently its awesome :-) |
20:50 |
|
paul |
was written a few weeks before pierrick leaved Ineo-ms... |
20:50 |
|
paul |
probably "unfinished" code... |
20:50 |
|
chris |
yep |
20:50 |
|
chris |
knowing pierrick it would have been great once it was finished |
20:50 |
|
chris |
he's a very smart guy |
20:51 |
|
chris |
you must be on your way to bed paul? |
20:51 |
|
paul |
yep. |
20:51 |
|
paul |
although alone those weeks, so I work late ;-) |
20:51 |
|
chris |
ahh :) |
20:51 |
|
paul |
mmm... kados... |
20:52 |
|
paul |
the patch about Context.pm let a line 252 with "$context", which is useless & result in zillions of warnings in http conf |
20:52 |
|
paul |
I'll submit a patch for that immediatly |
20:53 |
|
paul |
patch sent |
20:55 |
|
acmoore |
well, I hacked around the part of it that looked like a bug to me. If I'm using it wrong, we can correct my calls to it later. I can't figure out for the life of me how to use it right. |
20:56 |
|
acmoore |
so, patch for 1980 sent. that's my last blocker. |
20:59 |
|
acmoore |
Looks like we have 7 remaining. |
20:59 |
|
chris |
nice work |
21:00 |
|
paul |
4 of them being related to serials edition... |
21:01 |
|
paul |
mmm... I get 8 in my bugzilla list. |
21:01 |
|
paul |
3 of them having a "patch sent", and 4 related to serials edit |
21:02 |
|
paul |
the last one being "warn staff about resource hogging scripts" |
21:03 |
|
paul |
ok, time to leave for me. |
21:03 |
|
paul |
have a good day (end of wed of start of thurs...) |
21:03 |
|
paul |
i'll be here tomorrow (except for 2hours, meeting with my bank) |
21:05 |
|
acmoore |
paul, I limited out one that was set against 3.2. that left me with 7. |
21:05 |
|
chris |
cya paul |
21:05 |
|
acmoore |
bye, paul. |
21:05 |
|
cnighs |
bye paul |
06:27 |
|
mc |
hello |
06:59 |
|
chris |
hi mc |
09:28 |
|
masonj |
anyone aboot? |
09:28 |
|
masonj |
i wonder if someone with a recent koha3-zeb can confirm something quickly for me.. |
09:30 |
|
masonj |
can anyone successfuly do a ' ' search , with 2 or more itypes, and get results? |
09:31 |
|
paul |
hi masonj |
09:31 |
|
masonj |
hi paul |
09:32 |
|
masonj |
lemme explain... |
09:32 |
|
paul |
hey... you're right |
09:32 |
|
paul |
it doesn't work |
09:32 |
|
paul |
anymore |
09:32 |
|
masonj |
so i can do a search on books, and get 100 results... |
09:32 |
|
masonj |
and a search on magazines , and get 20 results |
09:33 |
|
masonj |
but if i do a search on mags and books, i get 0 results not 120 |
09:33 |
|
masonj |
. |
09:35 |
|
chris |
i concur |
09:35 |
|
chris |
same for me |
09:36 |
|
masonj |
ok, good to know |
09:38 |
|
masonj |
hey paul, could i ask you some little questions about the 'fr/sort-string-utf.chr' file |
09:38 |
|
paul |
yep |
09:39 |
|
masonj |
ive been working with some french data, and experimenting with the zebra search behaviour |
09:41 |
|
masonj |
so, the Q is - do you get any interesting output from zebrasrv , when zebrasrv is doing the character substitution? |
09:41 |
|
masonj |
im trying to debug it |
09:42 |
|
masonj |
hmm, perhaps i should sentd you an email with some log output from my zebrasrv 1st |
09:43 |
|
paul |
yep, as I don't understand what you're speaking of... |
09:45 |
|
masonj |
if i have a title 'des moutons' - and i search for 'Dés Moutons' i should get a result |
09:45 |
|
masonj |
because sort-string-utf.chr is doing a ' map êèéëÊÈÉË e' |
09:46 |
|
paul |
right |
09:46 |
|
masonj |
yet that doesnt seem to be working for me :( |
09:46 |
|
paul |
mmm... bad choice, as Des is also an empty word, so if you have french empty words, it will be ignored |
09:46 |
|
paul |
try "moûtons" |
09:46 |
|
paul |
or "moùtons" |
09:47 |
|
paul |
is your file correctly encoded (utf-8) on your server ? I had some problems with that |
09:47 |
|
masonj |
hmm, my sort-string-utf.chr file? |
09:47 |
|
paul |
yep. |
09:48 |
|
paul |
is it correctly encoded on your server ? |
09:48 |
|
paul |
(utf-8) |
09:48 |
|
masonj |
ahh, yes i did remember an error vim? gave me about my sort file too, some months ago.. |
09:49 |
|
paul |
it's sometimes a pain to be sure, as you may have it latin1 encoded, and, if your console is latin1 too, you won't see the problem |
09:50 |
|
masonj |
right, let me send you this log ...., perhaps you can spot a difference in behaviour |
09:56 |
|
masonj |
$ file sort-string-utf.chr sort-string-utf.chr: UTF-8 Unicode English text |
09:56 |
|
masonj |
oops, missing a \n there |
09:59 |
|
masonj |
so , on a zebra that is doing accented character mapping correctly - is there any extra stuff happening in the... |
10:00 |
|
paul |
masonj: did you adapt default.idx accordingly to thisnew .chr file ? |
10:01 |
|
paul |
charmap ... |
10:06 |
|
masonj |
zebrasrv(18) [request] Search biblios OK 0 1 1+0 RPN @attrset Bib-1 @or @or @or @or @or @attr 1= |
10:06 |
|
masonj |
line ? |
10:06 |
|
masonj |
or the ' zebrasrv(18) [log] dict_lookup_grep:XXXX lines too? |
10:06 |
|
masonj |
the zebrasrv [request] line doesnt seem to be doing the a search for 'moutons' anywhere, just lots of 'moùtons'.. |
10:06 |
|
masonj |
zebrasrv(21) [request] Search biblios OK 0 1 1+0 RPN @attrset Bib-1 @or @or @or @or @or @attr 1=36 @attr 4=1 @attr 6=3 @attr 9=32 @attr 2=102 moùtons @attr 1=4 @attr 4=1 @attr 6=3 @attr 9=28 @attr 2=102 moùtons @attr 1=4 @attr 4=1 @attr 9=26 @attr 2=102 moùtons @attr 4=6 @attr 5=103 @attr 9=16 @attr 2=102 moùtons @attr 4=6 @attr 5=1 @attr 9=14 @attr 2=102 "moùtons? " @attr 4=6 @attr 9=14 @attr 2=102 moùtons |
10:06 |
|
masonj |
. |
10:06 |
|
masonj |
so im guessing that my zeb isnt doing the mapping correctly, as i would expect to see it also search for 'moutons' in that query |
10:07 |
|
masonj |
but i need someone else to confirm that |
10:07 |
|
masonj |
no, i havent edited any of the zeb config files yet |
10:09 |
|
masonj |
i looked about in the zebra-config dirs - to see if there was something i needed to update |
10:09 |
|
masonj |
but i couldnt find anything |
10:10 |
|
masonj |
looking at the default.idx, what would i need to change in there?? |
10:13 |
|
chris |
the charmap bits presumably |
10:14 |
|
chris |
# Sort register |
10:14 |
|
chris |
sort s |
10:14 |
|
chris |
completeness 1 |
10:14 |
|
chris |
charmap sort-string-utf.chr |
10:14 |
|
masonj |
sure |
10:15 |
|
masonj |
the only import thing i could find was the profilePath value in ./zebra-biblios.cfg |
10:15 |
|
chris |
i think what default.idx is doing there is using it for the sort |
10:15 |
|
chris |
which isnt what you want it to do is it? |
10:16 |
|
masonj |
:/home/mason/koha/af-rc1/etc/zebradb/lang_defs/fr |
10:16 |
|
masonj |
the profilePath points to either the 'fr' or 'en' dir, to determine which 'sort-string-utf.chr' file to use |
10:17 |
|
chris |
yep, but how do you tell it to use it for substitution, not just sorting? |
10:18 |
|
masonj |
aaah, click... |
10:19 |
|
chris |
|
10:20 |
|
masonj |
yeah, i think youre right there chris |
10:20 |
|
chris |
im just guessing |
10:20 |
|
chris |
but it seems plausible :) |
10:23 |
|
masonj |
so it looks like 'word-phrase-utf.chr' is the real magical file for doing the subst. |
10:24 |
|
masonj |
it has a similar contents to 'sort-string-utf.chr', i thought it may have been a legacy file |
10:25 |
|
chris |
right |
10:26 |
|
chris |
the sort i think is just for sorting |
10:26 |
|
chris |
so that they order correctly |
10:26 |
|
masonj |
... as all of the mapping stuff in it was commented out |
10:26 |
|
masonj |
yeah, i got it now ;) |
10:26 |
|
chris |
so whatever is doing the :w or :p |
10:26 |
|
chris |
is the one that u need for the search |
10:27 |
|
chris |
so i guess we need an fr one of those? |
10:27 |
|
chris |
or we try changin |
10:28 |
|
chris |
charmap word-phrase-utf.chr |
10:28 |
|
chris |
to the sort-string one |
10:28 |
|
chris |
but now i must sleep |
10:29 |
|
masonj |
ok hunny |