whatever.com | NULL | | |whatever.com | NULL | | |← Previous day | Today | Search | Index
All times shown according to UTC.
| Time | Nick | Message |
|---|---|---|
| 12:07 | cnighs | g'morning #koha |
| 12:10 | paul | kados around ? |
| 12:10 | hi cnighs | |
| 12:10 | does any liblimer have a an idea of the size of a Koha setup with, say, 1 000 000 biblios, and 3 000 000 issues a year ? | |
| 12:10 | (the disk size, mySQL & zebra) | |
| 12:49 | gmcharlt | good morning #koha |
| 12:49 | paul | hi gmcharlt |
| 12:49 | gmcharlt | paul: don't have the numbers offhand - atz, ryan, or cfouts might have them |
| 12:49 | paul | cfouts ? |
| 12:52 | gmcharlt | cfouts = Clay Fouts, a new sysadmin for LL - not sure if he goes on #koha that often |
| 12:56 | slef | paul: I'd expect disk type (RAID is almost essential, but speed and layout matter too) and CPU speed/number to also come into play at that size, based on past experience with webservers. |
| 13:19 | kados | paul: with that many transactions you definitely want zebra and mysql on separate disks, probably separate servers |
| 13:19 | paul: otherwise zebra's indexing will compete with mysql for disk IO | |
| 13:35 | paul | kados : thanks for the idea. |
| 13:35 | can you tell me for the size ? | |
| 15:00 | kados | owen: you there? |
| 15:00 | owen: 'patrons have been successfuly moved to trash' | |
| 15:01 | owen | :) |
| 15:01 | kados | owen: that just doesn't quite capture what we're doing and if we're going to change that, I think we should change it 'right' :-) |
| 15:01 | owen | Doesn't sound very nice for the patrons |
| 15:01 | kados | hehe |
| 15:01 | how about patron accounts have been deleted | |
| 15:01 | or anonomyzed even | |
| 15:01 | however you spell that | |
| 15:02 | owen | Is this under clean borrowers? |
| 15:04 | I see both "deleted" and "moved to trash" in the template, based on <!-- TMPL_IF NAME="trash" --> | |
| 15:04 | What does that mean? | |
| 15:05 | kados | paul: ? |
| 15:05 | paul | mmm... no idea either. It's something written by toins |
| 15:05 | maybe it's : | |
| 15:05 | 1st step (confirm what we will clean) and 2nd step (really delete) | |
| 15:05 | ? | |
| 15:06 | owen | What does it mean when patrons are "moved to the trash?" |
| 15:06 | kados | deletedborrowers table I bet |
| 15:06 | owen | "What do you want to do for deleted patrons? Permanently delete these patrons Move these patrons to the trash" |
| 15:06 | eric_ | anybody knows where i can find a list of what type of marc is used in a country? |
| 15:07 | paul | owen: no idea, sorry |
| 15:08 | eric_ | owen: Could it mean that the patrons is "deactivated", but all its information is still in the database? |
| 15:12 | owen | CVS history says cleanborrowers.pl was added by toins |
| 15:13 | kados | owen: I bet it moves them to the deletedborroweres table |
| 15:13 | owen | Shouldn't that just be the default action? |
| 15:14 | kados | if there was one |
| 15:14 | owen | I hate to reference "the trash" when there's no mechanism from the interface for retrieving records from "the trash" |
| 15:15 | su-erin | any tips for trouble shooting this upgrade from .064 to .094 on ubuntu 7.10: Can't open blib/ZEBRA_CONF_DIR/etc/passwd for read at rewrite-config.PL line 168. |
| 15:27 | eric | su-erin, the first thing to do is to check if the file exists (I guess you check that already, right). |
| 15:27 | It should be in the directory where you untar koha | |
| 15:45 | atz | then check if you can read it :) |
| 15:47 | su-erin | rewrite-config.PL is there and I have opermission to read it; check that yesterday. I think it has something to do with the that ZEBRA_CONF_DIR. I just dont know what directory that should be |
| 15:51 | atz | usually in your koha (kohaclone, whatever) directory as ./etc |
| 15:55 | paul | kados ? about your patch UTF-8 to ASCII MAPPINGS. I don't understand why you need equivalent AND map. |
| 15:55 | atz | paul: i think map is a one-way relationship |
| 15:56 | so if I search by e, it will match on acute-e, but not vice versa | |
| 15:56 | i'm not sure why we would need both though, if there are duplicates | |
| 15:57 | paul | in french .chr, we use only map, and it work fine |
| 15:57 | head/etc/zebradb/lang_defs/fr/sort-string-utf.chr | |
| 15:57 | atz | su-erin: for example: ~/kohaclone/etc/zebradb/ |
| 15:57 | paul | (used also for word-phrase-utf.chr) |
| 16:02 | atz | paul: we also ran into differences between wide-bytes and combined characaters |
| 16:02 | but maybe we would be fine to just use the mappings you have in the french file | |
| 16:02 | su-erin | thanks, i'll dig their |
| 16:02 | *there | |
| 16:20 | kados | paul: note that only covers sorting, not searching |
| 16:21 | paul: do you have a custom word-phrase-utf.chr that you use for French libraries too? | |
| 16:21 | paul | kados : what cover sorting not searching ? |
| 16:21 | kados | sort-string.chr |
| 16:21 | it's not used for equivalance in searching, only sorting | |
| 16:21 | paul | nope, we use the same file content (although we have a word-phrase-utf) |
| 16:21 | but it's content is the same as sort-phrase-utf.chr | |
| 16:21 | kados | then only word-phrase-utf should be used for searching according to default.idx |
| 16:22 | paul | right. |
| 16:22 | kados | word phrase numeric indeces are separaet from sort indeces |
| 16:22 | paul | but the content of both files are the same |
| 16:22 | (not sure to understand what you mean...) | |
| 16:23 | kados | different rules are used for different indexes and therefore, actions |
| 16:23 | rules that apply to sorting don't apply necessarily to searching | |
| 16:24 | paul | yep, I know |
| 16:24 | kados | for instance, in English, we want to be able to search for 'The', but we don't want 'The ' to be counted for sorting purposes |
| 16:24 | paul | but for us, the same rules are OK. so the files have the same content. |
| 16:24 | mmm... the is in empty words, isn't it ? | |
| 16:24 | so it's discarded ? | |
| 16:25 | kados | paul: so you use sort-string.chr also for word-phrase-utf.chr? |
| 16:25 | because those two files in default Koha are different | |
| 16:25 | paul | yep |
| 16:25 | kados | OK, so that's a local modif you do apart from normal installation |
| 16:25 | (just trying to understand clearly) | |
| 16:25 | atz | kados: so their config references the same file in 2 places |
| 16:25 | rather than 2 separate files | |
| 16:25 | iiuc | |
| 16:25 | kados | you edit default.idx and point word and phrase indexes to sort-string.chr |
| 16:26 | ? | |
| 16:26 | paul | nope. |
| 16:26 | we refer to sort-string.chr & word-phrase.chr | |
| 16:26 | but those 2 files contains the same thing (map, equivalent...) | |
| 16:26 | kados | OK, so you copy sort-string.chr to replace word-phrase-utf.chr then? |
| 16:27 | paul: the same type of file, yes but in default Koha they have very different rules, esp the French sort-string.chr and default word-phrase-utf8.chr | |
| 16:27 | paul | I should do an install from scratch to check |
| 16:27 | kados | and your sort-string.chr has mappings for French words like Le |
| 16:27 | do you want those to be ignored in searching as well as sorting? | |
| 16:27 | (that would be surprising to me) | |
| 16:27 | atz | paul: yes, please. your familiarity w/ this issue will help out considerably |
| 16:28 | paul | kados : yes, that's what I want |
| 16:28 | (ignore Le when searching & sorting) | |
| 16:28 | + we always use empty word removal, so "Le" is not sent to zebra anyway for searching | |
| 16:28 | (so it's usefull only for sorting in fact) | |
| 16:28 | kados | k |
| 16:29 | paul: OK, so I bet that it doesn't work for you because only sort-string.chr is used and only for sorting, not searching | |
| 16:29 | all searching uses word-phrase-utf.chr | |
| 16:30 | for english and french it appears | |
| 16:30 | paul | (I didn't say it don't work for us. I just investigate the consequences of the commit for us ;-) ) |
| 16:30 | eric | (for the record, when paul talks about <empty words>, he is refering to <stop words>) |
| 16:30 | paul | eric : right |
| 16:30 | kados | maybe we should move word-phrase-utf.chr to the lang_defs/fr and lang_defs/en |
| 16:30 | paul | (empty word is a frenchism..) |
| 16:31 | kados : maybe yes. | |
| 16:31 | eric | Paul, is there a reason why you don't want to sort using the stop words? I can understand the search, but for the sort, i<m not sure... |
| 16:32 | kados | eric: 'Le ' is an article and most librarians don't want it to be used for sorting |
| 16:32 | s/it/articles/ | |
| 16:33 | paul | eric : "Le Seigneur des anneaux" must appear at "S" for sorting |
| 16:34 | kados | paul: maybe we should move word-phrase-utf.chr to the lang_defs/fr and lang_defs/en |
| 16:35 | paul: to accomodate your need to not search by articles etc | |
| 16:35 | paul | kados : didn't you write that 3mn ago already ? and I answered "maybe yes" |
| 16:36 | kados | hehe, maybe :-) |
| 16:36 | paul | kados : in fact, I don't care having map Le^ ^, for searching, as Le is already removed by Koha before sending the request to zebra |
| 16:36 | but I agree it's a good idea. | |
| 16:36 | (more flexible for the future probably) | |
| 16:38 | nicomo | yes because you (paul) speculates that the stop-words list will be correctly filled in by the librarian: not a sure bet |
| 16:38 | so having map Le for seraching might provide a safety net too | |
| 16:39 | gmcharlt | respecting nonfiling indicators would be better yet, although a 3.2/DOM-mode thing |
| 16:39 | nicomo | gmcharlt ++ |
| 16:48 | eric | anybody knows the usage of 908$a - Put Command Parameter? |
| 17:13 | cnighs | hdl about? |
| 17:44 | paul | cnighs: hdl was at a client today. should be back tomorrow |
| 17:44 | or maybe will jump in for a few minuts in 2 hours or so (although it's already 8PM here) | |
| 17:45 | cnighs | tnx paul |
| 19:31 | atz | acmoore: trying out overdues script for a client... |
| 19:31 | all the <<branches.*>> elements seem not to get populated? | |
| 19:31 | seen that before/ | |
| 19:31 | ? | |
| 19:36 | acmoore | atz, hmm. No, I haven't. In fact, I have branches.branchphone in the template I've been testing with, and it gets popualted. |
| 19:36 | I wonder what more I can look at with you. | |
| 19:37 | atz | let me check their branches table.... |
| 19:37 | acmoore | atz, do they get removed? |
| 19:37 | atz | yeah, they don't appear in the resulting messages, just an empty line |
| 19:38 | acmoore | atz, are you supplying a --library flag to the script to limit it to one branch, or running it on all branches? |
| 19:38 | atz | running it for all |
| 19:39 | acmoore | hmm.. odd. I don't knwo what might be up. I wonder if the same thing happens if you limit it to one branch. |
| 19:39 | I guess one thing to check is that the field you're looking for is actually populated in the branches table. | |
| 19:40 | atz | yep, that's why I went to check. looks normal to me |
| 19:40 | mysql> select * from branches; | |
| 19:40 | +------------+--------------+---------------------------+----------------+----------------+-------------+-----------+----------------+---------+----------+---------------+ | |
| 19:40 | | branchcode | branchname | branchaddress1 | branchaddress2 | branchaddress3 | branchphone | branchfax | branchemail | issuing | branchip | branchprinter | | |
| 19:40 | +------------+--------------+---------------------------+----------------+----------------+-------------+-----------+----------------+---------+----------+---------------+ | |
| 19:40 | | LCC | Main Library | DeFehr Building 3rd Floor | Kretingos 36 | Klaipeda, LT | | | librarywhatever.com | NULL | | | |
|
| 19:40 | | TXT | Textbooks | DeFehr Building Basement | Kretingos 36 | Klaipeda, LT | | | librarywhatever.com | NULL | | | |
|
| 19:40 | +------------+--------------+---------------------------+----------------+----------------+-------------+-----------+----------------+---------+----------+---------------+ | |
| 19:41 | (emails changed to protect the innocent) | |
| 19:41 | acmoore | are you attempting to use branchphone? ;) |
| 19:41 | atz | would that prevent branchname from displaying? |
| 19:42 | acmoore | ah, no. I just didn't know what field you were trying to use, and branchphone appears to not be populated. |
| 19:42 | atz | the odd thing is that *none* of the branches.* fields display |
| 19:44 | acmoore | atz, can you run it with the --library=LCC or --library=TXT set to see if it works? Is this a pain for you to do? |
| 19:44 | atz | probably this line: @branches = (''); |
| 19:45 | acmoore | I've noticed that some people use a branchcode of '' for a default in their databases, and perhaps leaving it off is suppoosed to be running for that default branch instead of all branches. |
| 19:45 | eric | do you know what the issuing column? |
| 19:46 | atz | acmoore: that is probably inconsistent... in rules that should be NULL, as in UNMAPPED to branches table |
| 19:46 | "" is an illegal value (foreign key violation) | |
| 19:48 | eric: i imagine that field is meant to designate whether the branch is a circulating one or an internal one (like bindery, cataloguing, etc.) | |
| 19:49 | i'd bet it isn't used (anymore) though. much like branchprinter. | |
| 19:49 | acmoore | atz, oh, I see. well, I wonder how this should work, then. I guess not specifying branchcode to this script should run for all branches, but that appears to be a bug, then? |
| 19:49 | atz | acmoore: no luck w/ --library options |
| 19:49 | acmoore | atz, when you say no luck, do you mean that it continues to fail to substitute the branches.* fields? |
| 19:49 | atz | acmoore: it still runs, and it populates w/ patron and item data. but the branches.* lines are still blank |
| 19:50 | in short, yes. | |
| 19:50 | :) | |
| 19:50 | acmoore | odd. |
| 19:51 | atz | just rebased this afternoon, btw |
| 19:51 | acmoore | the -v flag isn't too great, but if you want me to keep looking at it with you, could you run it with one library and the -v flag and send me the results, please? |
| 19:52 | I'm just not sure if they'll be useful enough for you to decypher. | |
| 19:52 | atz | acmoore: it's possible that the *borrowers* are sparsely populated and there isn't a homebranch recorded |
| 19:52 | let me check that | |
| 19:54 | nope... looks like they all belong to the main branch. | |
| 19:55 | which is odd, b/c I still get results with --library=TXT ... must be because the items that are overdue are TXT's | |
| 19:57 | well, the error message is on point: | |
| 19:57 | The following terms were not matched and replaced: | |
| 19:57 | branches.branchname | |
| 19:57 | branches.branchaddress1 | |
| 19:57 | branches.branchaddress2 | |
| 19:57 | branches.branchaddress3 | |
| 19:57 | branches.branchphone | |
| 19:57 | branches.branchemail at /home/liblime/kohaclone/misc/cronjobs/overdue_notices.pl line 383. | |
| 20:00 | also distressing, since I ran in -n (no effect mode), I see lines like : debarring 48 Irma BALCIUNAITE | |
| 20:01 | acmoore | -n is No email. |
| 20:01 | perhaps that should change, though. | |
| 20:06 | atz | hmmm. ok, i have the log from that and can un-debar the 10 or so patrons impacted |
| 20:07 | acmoore: so there is no test mode? | |
| 20:08 | acmoore | i guess not. There's just the mode that sends no emails. It seems to still debar people. |
| 20:09 | atz | we definitely need some kind of safe poke-around-but-don't-hurt-nobody mode. |
| 20:09 | acmoore | I'd think so. |
| 20:11 | There was another documentation improvement idea that came up yesterday. I put them together in this bug http://bugs.koha.org/cgi-bin/b[…]w_bug.cgi?id=2388 | |
| 20:11 | I can open one up to make a test mode of some kind, too. | |
| 20:13 | atz, opened 2389 for that. | |
| 20:14 | atz | ok, i'll leave it at that for now |
| 20:14 | i'll probably just hardcode the branch stuff for the client, since they are the almost the same | |
| 20:15 | pianohacker | (liblime or biblibre people) newbie question: how do you keep clients up to date with the latest git improvements and add their personally requested changes to just their tree? |
| 20:17 | atz | pianohacker: the clients have git repos, and you just commit their changes to them |
| 20:17 | then when you rebase, git merges everything (or gives errors you have to sort out manually) | |
| 20:17 | pianohacker | OK, thanks |
| 20:30 | atz | acmoore: how often should process_message_queue run? |
| 20:34 | acmoore | atz, I guess maybe hourly or so? Really, it only needs to be run nightly since the only things that write to it are nightly cronjobs, but perhaps we'll have more things adding to it soon. |
← Previous day | Today | Search | Index
