IRC log for #koha, 2008-07-10

← Previous day | Today | Next day → | Search | Index

All times shown according to UTC.

Time Nick Message
14:50 kados OK, goodie, now we're making progress
14:52 fbcit: how can I reproduce the issue, which bibs is it happening with?
14:56 fbcit that's the problem
14:56 one of my data entry people has the problem now
14:57 the other does not
14:57 grrrr
14:57 kados weird
14:57 they are using Koha's built-in MARC editor with Z39.50?
14:57 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 btw: zebraqueue daemon is running and the missing records are begin processed by it, contrary to my previous observation
15:02 but they do not show in a search
15:03 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 and add a cron task with rebuild_zebra.pl and the -z option
15:03 for bibs and authorities
15:04 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 rhcl: ie, rather than a complete index re-build
15:09 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 so i can reproduce it
15:09 fbcit: I think the ebraqueue daemon issues are separate
15:09 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 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 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 does it really matter what the mysql server is at that point?
15:13 kados yes, it really does
15:14 especially important is the encoding of the connection
15:14 maybe not so much the server though ...
15:14 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 that record is being pulled from UNC @ Chapel Hill
15:19 afton.lib.unc.edu:210
15:19 innopac db
15:19 utf8 encoding
16:14 kados fbcit: hack
16:14 back I mean
16:14 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 while claiming to be utf8
16:16 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 kados: do a z3950 search on 8476456700 with all servers selected
16:20 kados k
16:21 is that at the chapel hill target?
16:21 fbcit: i wanna test marc8
16:21 fbcit no
16:21 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 fbcit: I changed the chapel hill target to marc-8 and it's working now
16:24 fbcit: if you change it to marc8, Koha will convert it to utf8 for you automagically
16:25 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 galen may have time next week to investigate what the specif problem with the III systems' UTF8 is
16:27 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 but also 083793950X with the UNC target
16:29 kados another innopac system
16:29 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 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 at least for me they do
16:32 and checking the sample data, it's in there
16:32 fbcit hrmm
16:35 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 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 my documentation
16:40 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 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                    if ($rec) {
16:45                        my $marcrecord;
16:45                        $marcdata   = $rec->raw();
16:45 fbcit: oddly, the error is claiming that $rec is undefined
16:45 fbcit: but right above it, we test for that
16:46 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 that's the error Im getting
16:51
16:51 [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 [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
16:51 fbcit: where are you seeing the other, more useful error?
16:52 fbcit: did you set DEBUG or something?
16:53 fbcit weird
16:53 no on DEBUG
16:53 are you searching on 8423968146 @ UNC?
16:54 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-b​in/cataloguing/z3950_search.pl line 216.
16:55 "
16:56 kados huh
16:56 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 maybe we have different deubg levels or something
16:57 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 interstingly, I get failyure with default settings in yaz-client for both cattnyp and unc
16:58 f @attr 1=7 083793950X
16:58 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 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                    my $marcrecord;
17:00                    $marcdata   = $rec->raw();
17:00 that might explain it
17:01 kados but I still get an error
17:01 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 the bib-1 error is somewhat telling
17:01 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 any ISBN queries in particular?
17:02 and if we try to find the same records via another mechanism does it fail?
17:04 fbcit bak
17:04 back even
17:05 kados: it does not appear that any isbn searches work against those targets via z3960_search.pl
17:05 kados yea
17:05 I'm trying 'Who's Who in the Media and Communications 1998-9'
17:05 as title now
17:05 nothing found
17:05 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 fbcit: http://irspy.indexdata.com/fin[…]_count=10&_skip=0
17:09 http://irspy.indexdata.com/raw[…]g%3A210%2FINNOPAC
17:10 fbcit cool
17:12 kados oh, you're kidding me ...
17:12 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 fbcit: can we be blamed for conforming to the standard ?
17:14 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 but we're blamed for following the standard
17:14 arrrg
17:15 fbcit: this is great:
17:15 f @attr 1=1016 "Who's Who in the Media and Communications 1998-99"
17:15 Sent searchRequest.
17:15 Received SearchResponse.
17:15 Search was a bloomin' failure.
17:15 Number of hits: 0, setno 1
17:15 Result Set Status: none
17:15 records returned: 1
17:15 Diagnostic message(s) from database: [100] Unspecified error -- v2 addinfo 'Search taking too much time.  Server is disconnected.'
17:16 so basically, I try a 1=1016 (actually keyword, but apparantly title in III), and it can't respond fast enough
17:16 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 yea
17:17 5-lb-spiders--
17:17 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 this would be better handle with pazpar2
17:20 you can pass info about each target config separately before doing the federated search
17:20 fbcit: I'm afraid this won't be fixed for 3.0
17:20 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 ccatalfo: around?
17:21 ccatalfo sure am
17:22 smth about using pazpar2 with different bib attributes per target?
17:23 kados ccatalfo: yea
17:23 ccatalfo: something to bear in mind for biblios
17:23 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 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 oh, cool
17:24 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 should be pretty swank actually
17:25 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 fbcit: it appears from furthe tests that the actual connections to innopac are failing for isbn searches
17:50 fbcit: I'm adding some user errors to make it clear where the problem is
17:50 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 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 I used the command 'git send-email filename'
18:20 Is there something else I need to do?
18:21 kados you may need to properly configure your outgling mail server
18:21 exim perhaps?
18:21 or postfix?
18:22 Kyle From what I'm reading, it sounds like I can just send them to patches@koha.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 kados, who is the moderator for the patches@ list, anyway?
18:29 Kyle, they'll get held up for moderation before they make it to that list if you're not subscribed.
18:30 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 Kyle: gmail will definitely goof up the attachments
18:31 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 acmoore: *nod*
18:38 wow, you gotta love III, their errors always come back as "No error"
18:38 brilliant!
18:39 sawariwap any tentative date for the final release?
18:40 kados sawariwap: today, tomorrow?
18:41 this week for certain
18:44 sawariwap oh ok
18:44 cool
18:44 :)
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 I'm presuming I'm using it wrong, although I'm using it just like other calls.
20:41 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 improved: C4::Output::pagination_bar builds an HTML pagination bar with no
20:49    language dependency. This function hugely simplifies templates and offers a
20:49    standard pagination method. This function also improves preformances.
20:49 apparently its awesome :-)
20:50 paul was written a few weeks before pierrick leaved Ineo-ms...
20:50 probably "unfinished" code...
20:50 chris yep
20:50 knowing pierrick it would have been great once it was finished
20:50 he's a very smart guy
20:51 you must be on your way to bed paul?
20:51 paul yep.
20:51 although alone those weeks, so I work late ;-)
20:51 chris ahh :)
20:51 paul mmm... kados...
20:52 the patch about Context.pm let a line 252 with "$context", which is useless & result in zillions of warnings in http conf
20:52 I'll submit a patch for that immediatly
20:53 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 so, patch for 1980 sent. that's my last blocker.
20:59 Looks like we have 7 remaining.
20:59 chris nice work
21:00 paul 4 of them being related to serials edition...
21:01 mmm... I get 8 in my bugzilla list.
21:01 3 of them having a "patch sent", and 4 related to serials edit
21:02 the last one being "warn staff about resource hogging scripts"
21:03 ok, time to leave for me.
21:03 have a good day (end of wed of start of thurs...)
21:03 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 i wonder if someone with a recent koha3-zeb can confirm something quickly for me..
09:30 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 lemme explain...
09:32 paul hey... you're right
09:32 it doesn't work
09:32 anymore
09:32 masonj so i can do a search on books, and get 100 results...
09:32 and a search on magazines , and get 20 results
09:33 but if i do a search on mags and books, i get 0 results not 120
09:33 .
09:35 chris i concur
09:35 same for me
09:36 masonj ok, good to know
09:38 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 so, the Q is - do  you get any interesting output from zebrasrv , when zebrasrv is doing the character substitution?
09:41 im trying to debug it
09:42 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 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 try "moûtons"
09:46 or "moùtons"
09:47 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 is it correctly encoded on your server ?
09:48 (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 $ file  sort-string-utf.chr sort-string-utf.chr: UTF-8 Unicode English text
09:56 oops, missing a \n there
09:59 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 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 line ?
10:06 or the ' zebrasrv(18) [log] dict_lookup_grep:XXXX lines too?
10:06 the zebrasrv [request] line doesnt seem to be doing the a search for 'moutons' anywhere, just lots of 'moùtons'..
10:06 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 .
10:06 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 but i need someone else to confirm that
10:07 no, i havent edited any of the zeb config files yet
10:09 i looked about in the zebra-config dirs - to see if there was something i needed to update
10:09 but i couldnt find anything
10:10 looking at the default.idx, what would i need to change in there??
10:13 chris the charmap bits presumably
10:14 # Sort register
10:14 sort s
10:14 completeness 1
10:14 charmap sort-string-utf.chr
10:14 masonj sure
10:15 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 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 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 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 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 the sort i think is just for sorting
10:26 so that they order correctly
10:26 masonj ... as all of the mapping stuff in it was commented out
10:26 yeah, i got it now ;)
10:26 chris so whatever is doing the :w or :p
10:26 is the one that u need for the search
10:27 so i guess we need an fr one of those?
10:27 or we try changin
10:28 charmap word-phrase-utf.chr
10:28 to the sort-string one
10:28 but now i must sleep
10:29 masonj ok hunny

← Previous day | Today | Next day → | Search | Index

koha1