| # | Time | Nick | Message |
|---|
| # | 00:37:09 | dbs has quit IRC |
| # | 00:37:22 | mck9 has left #evergreen |
| # | 01:28:56 | pmplett has quit IRC |
| # | 02:59:03 | artunit_ has joined #evergreen |
| # | 03:00:44 | finnx has quit IRC |
| # | 03:00:44 | twirlip-afk has quit IRC |
| # | 03:00:44 | artunit has quit IRC |
| # | 03:00:44 | phasefx has quit IRC |
| # | 03:00:55 | artunit_ is now known as artunit |
| # | 03:02:50 | phasefx has joined #evergreen |
| # | 03:02:53 | twirlip-afk has joined #evergreen |
| # | 03:06:54 | artunit has quit IRC |
| # | 03:07:02 | artunit has joined #evergreen |
| # | 03:07:02 | finnx has joined #evergreen |
| # | 03:07:27 | artunit_ has joined #evergreen |
| # | 03:07:32 | artunit has quit IRC |
| # | 03:07:37 | artunit_ is now known as artunit |
| # | 03:08:59 | artunit has quit IRC |
| # | 03:09:30 | artunit has joined #evergreen |
| # | 03:34:48 | jamesrf has quit IRC |
| # | 03:34:54 | jamesrf_ has joined #evergreen |
| # | 03:38:18 | jamesrf_ has quit IRC |
| # | 03:39:59 | jamesrf has joined #evergreen |
| # | 03:43:20 | jamesrf has quit IRC |
| # | 03:45:28 | jamesrf has joined #evergreen |
| # | 03:48:54 | jamesrf has quit IRC |
| # | 03:50:13 | jamesrf has joined #evergreen |
| # | 03:53:40 | jamesrf has quit IRC |
| # | 03:55:22 | jamesrf has joined #evergreen |
| # | 03:57:25 | jmeeuwen has joined #evergreen |
| # | 03:57:27 | jamesrf has quit IRC |
| # | 03:57:33 | jmeeuwen | good morning |
| # | 04:00:21 | jamesrf has joined #evergreen |
| # | 04:00:21 | jeff | good morning |
| # | 04:00:35 | jeff | phasefx_: g'nite ;-) |
| # | 04:02:47 | jmeeuwen | is this also the channel for OpenSRF? |
| # | 04:03:13 | jeff | pretty much, yes. |
| # | 04:03:31 | jeff | are you interested in opensrf outside of evergreen? |
| # | 04:03:53 | jeff | if so, that's great! |
| # | 04:03:55 | jmeeuwen | no, it's part of or a dependency of evergreen, right? |
| # | 04:04:50 | jmeeuwen | allow me to introduce myself; my name is Jeroen van Meeuwen and I am a Fedora / Red Hat developer; i'm interested in getting Evergreen/OpenSRF into Fedora and Extra Packages for Enterprise Linux |
| # | 04:05:37 | jeff | aha! |
| # | 04:06:07 | jeff | yes, opensrf is required by evergreen. opensrf also has potential to be used for other things besides evergreen, but its most common use at this time is to support evergreen. |
| # | 04:06:43 | lisppaste3 | jmeeuwen pasted "untitled" at http://paste.lisp.org/display/90567 |
| # | 04:06:59 | jmeeuwen | as it stands, I'm having problems with memcache in libopensrf; it doesn't compile because of mc_free and some others (see paste) |
| # | 04:08:58 | jmeeuwen | i was wondering whether opensrf needs libmemcached (the client lib) or memcached (the server side of things)? |
| # | 04:10:10 | jeff | to compile, i believe it needs the client libraries/headers, and to run it requires the server. |
| # | 04:10:38 | jeff | jmeeuwen: are you following the instructions in the wiki for compiling opensrf, including installing dependencies using Makefile.install? |
| # | 04:11:55 | jmeeuwen | euh, gheghe, no |
| # | 04:12:22 | jmeeuwen | libmemcache is packaged for fedora and rhel/centos, it's in Extra Packages for Enterprise Linux (EPEL) |
| # | 04:12:27 | jeff | jmeeuwen: on debian, you'd install libmemcache-dev package, but CentOS/RHEL doesn't seem to package it -- or didn't at the time that Makefile.install was last updated for RHEL |
| # | 04:12:31 | jmeeuwen | http://fedoraproject.org/wiki/EPEL fwiw |
| # | 04:13:15 | jmeeuwen | as is ejabberd, but more importantly |
| # | 04:13:39 | jmeeuwen | i think i might be able to help get the centos/rhel/fedora side of things straightened out and i would be glad to do so ;-) |
| # | 04:14:35 | jmeeuwen | would that be appreciated? |
| # | 04:14:43 | jeff | great! http://evergreen-ils.org/dokuwiki/doku.php?id=opensrf:1.2:install is the latest instructions for a "release" of opensrf, and should point you at Makefile.install, which you can parse through and see what's trying to be done. |
| # | 04:15:20 | jeff | jmeeuwen: there's no fedora target in Makefile.install, just RHEL and CentOS, so that's something you could probably add. I'm sure people who prefer Fedora would appreciate it. |
| # | 04:16:17 | jmeeuwen | i doubt fedora would be the most excellent platform to run the library system on, but it is what is closest to the next generation of enterprise linux so it'd be more of a development platform maybe |
| # | 04:16:19 | jeff | jmeeuwen: it's often a good idea to drop a note to the open-ils-dev list stating what you intend to do, then go ahead and do it and submit patches |
| # | 04:16:34 | jmeeuwen | jeff, excellent, that's exactly what i'm used to ;-) |
| # | 04:33:07 | pinesol has joined #evergreen |
| # | 04:33:14 | gmcharlt has quit IRC |
| # | 04:33:14 | eby has quit IRC |
| # | 04:33:14 | wjr has quit IRC |
| # | 04:33:15 | r123 has quit IRC |
| # | 04:33:15 | rickd_ has quit IRC |
| # | 04:33:15 | kbeswick has quit IRC |
| # | 04:33:15 | pinesol` has quit IRC |
| # | 04:33:51 | jmeeuwen | hmm, the "About US" page on evergreen-ils.org mentions another IRC channel #openils-evergreen? |
| # | 04:33:52 | rickd has joined #evergreen |
| # | 04:36:09 | kbeswick has joined #evergreen |
| # | 04:39:37 | gmcharlt has joined #evergreen |
| # | 04:40:44 | eby has joined #evergreen |
| # | 04:41:44 | wjr has joined #evergreen |
| # | 04:58:23 | jeff | jmeeuwen: "legacy". we're using this channel now. |
| # | 04:58:32 | jmeeuwen | good ;-) |
| # | 04:58:49 | jmeeuwen | i can not join any more channels, i had to close #debian to get in here ;-) |
| # | 04:59:40 | jeff | @later tell phasefx_ http://evergreen-ils.org/about.php still references the old #OpenILS-Evergreen -- can you fix, if someone else hasn't noticed by the time you get this? |
| # | 04:59:40 | pinesol | jeff: The operation succeeded. |
| # | 05:01:49 | jmeeuwen | maybe this is a stupid question, but what's xmpp (or ejabberd) got to do with a library system? |
| # | 05:02:28 | jeff | evergreen's built on top of opensrf, and opensrf uses xmpp to pass messages |
| # | 05:02:42 | jmeeuwen | so xmpp is used as a messaging queue? |
| # | 05:03:48 | jmeeuwen | like one node dispatches a job and some other node listening on a specific channel or listening to specific types of messages picks up the job and executes whatever is necessary? |
| # | 05:03:52 | jeff | i believe that's an accurate statement, yes. see the various documents linked under "Project OpenSRF, the framework underlying Evergreen" here: http://evergreen-ils.org/dokuwiki/doku.php |
| # | 05:04:08 | jeff | jmeeuwen: pretty close, yes. |
| # | 05:04:23 | jmeeuwen | right |
| # | 05:04:49 | jmeeuwen | i failed to recognize that from my brief bird's view just now browsing through the docs a little |
| # | 05:05:20 | jmeeuwen | i can't help but thinking aqmp would be an awesome message bus but it's much too soon for me to say anything useful about it at this point ;-) |
| # | 05:05:40 | eguest309_ has joined #Evergreen |
| # | 05:05:53 | jeff | jmeeuwen: applications register a listener with the opensrf router, clients make requests to a well known jabber address (with the xmpp "resource" being significant)... |
| # | 05:06:29 | jmeeuwen | right |
| # | 05:07:15 | eguest309_ has quit IRC |
| # | 05:07:29 | jeff | amqp, you mean? |
| # | 05:08:47 | jmeeuwen | ohw, i'm sorry |
| # | 05:09:10 | jmeeuwen | yes, amqp |
| # | 05:10:09 | jeff | i don't think amqp was done being developed when opensrf was born. i've seen others ask the hypothetical "would opensrf use amqp if it was built today?", but that's just a hypothetical at this point. |
| # | 05:10:43 | jmeeuwen | right, amqp has been in development for quite some time |
| # | 05:11:11 | jmeeuwen | i'm not sure it's done even today, but it's just a premature thought anyway ;-) |
| # | 05:11:30 | jeff | ``developed from mid-2004 to mid-2006'' according to wikipedia, and "The birth of OpenSRF" blog post is from early 2005. |
| # | 05:11:41 | jeff | oof. i must sleep! |
| # | 05:11:55 | jeff | jmeeuwen: g'nite! welcome to #evergreen! |
| # | 05:12:05 | jmeeuwen | goodnight jeff, and thanks! |
| # | 06:20:58 | User1__ has joined #evergreen |
| # | 06:21:40 | User1__ | Anyone know where I can get a hold of a 1.6 Windows staff client? i just spent the day building the Evergreen server with the RC for 1.6 and now notice the client is no longer available for download!! |
| # | 06:44:34 | User1__ | Anyone? |
| # | 06:45:28 | wlayton has joined #evergreen |
| # | 06:46:10 | wlayton | User1__: Still around? |
| # | 06:46:41 | User1__ | Yeop |
| # | 06:46:42 | User1__ | yep |
| # | 06:46:52 | wlayton | Here: http://evergreen-ils.org/downloads/evergreen-setup-rel_1_6_0_0.exe |
| # | 06:47:10 | User1__ | Thank you kindly!! |
| # | 06:47:20 | wlayton | Though I'm not sure if that's the new 1.6 staff client for the final release, or the leftover -rc1 client. Should work either way, though. |
| # | 06:47:50 | User1__ | It'll get me starte, anyway. |
| # | 06:48:42 | wlayton | gotta run off to work - have a good day! |
| # | 06:48:45 | wlayton has quit IRC |
| # | 06:59:01 | User1__ has quit IRC |
| # | 07:50:12 | rickd has quit IRC |
| # | 07:54:38 | mck9 has joined #evergreen |
| # | 08:06:57 | eby has quit IRC |
| # | 08:10:28 | eby has joined #evergreen |
| # | 08:16:20 | phase_bb has joined #evergreen |
| # | 08:54:23 | dbs has joined #evergreen |
| # | 08:58:13 | dbs | phasefx++ # coding, cleaning up machine |
| # | 09:02:31 | Meliss has joined #Evergreen |
| # | 09:06:58 | jeff | uurgh. |
| # | 09:10:10 | bshum has joined #Evergreen |
| # | 09:12:50 | jenny has joined #evergreen |
| # | 09:14:30 | dbs | jeff awakes? |
| # | 09:16:27 | phasefx_ | brainz |
| # | 09:20:15 | StephenGWills has joined #evergreen |
| # | 09:24:09 | User1__ has joined #evergreen |
| # | 09:24:59 | User1__ | So, finally have Evergreen 1.6 running and it looks good. However, I can't seem to find any sys admin manuals. Although there are some on the doc wiki I can't seem to find anything regarding indexing etc? |
| # | 09:25:11 | User1__ | Any new bibs I have added are not showing on the OPAC results |
| # | 09:25:56 | mrpeters-isl has joined #evergreen |
| # | 09:26:09 | mrpeters-isl | all, has an OpenSRF release been cut that is compatible with Evergreen-ILS-1.6.0.0 or do you still need to use one from svn? |
| # | 09:27:33 | phasefx_ | User1__: are you searching the OPAC within the client or from a web browser? If the latter, do you have holdings associated with your bibs? |
| # | 09:28:10 | User1__ | both |
| # | 09:28:22 | sboyette has joined #evergreen |
| # | 09:30:02 | phasefx_ | mrpeters-isl: download page in progress: http://evergreen-ils.org/downloads2.php |
| # | 09:31:23 | phasefx_ | User1__: any errors in the logs? grep \\[ERR /openils/var/log/* If you load a record in the marc editor and re-save it, does it make a difference? |
| # | 09:31:45 | phasefx_ | and how have you loaded the records? |
| # | 09:32:16 | dbs | mrpeters-isl: or http://evergreen-ils.org/downloads3b.php |
| # | 09:32:56 | dbs | User1__: https://answers.launchpad.net/evergreen/+question/86623 |
| # | 09:33:05 | mrpeters-isl | dbs thanks! |
| # | 09:33:16 | User1__ | Thanks - I'll take a look |
| # | 09:33:50 | dbs | mrpeters-isl: actually, downloads2.php is better |
| # | 09:34:00 | phase_bb has quit IRC |
| # | 09:34:08 | dbs | phasefx: maybe we should just make the new downloads page live |
| # | 09:35:19 | mrpeters-isl | dbs: 10-4 |
| # | 09:36:33 | dbs | atz: I'm curious about why you suggested trac instead of launchpad for Jeroen |
| # | 09:37:19 | r1231 has left #evergreen |
| # | 09:37:40 | dbs | It kind of cuts the whole public bug database experiment off at the knees, don't you think? |
| # | 09:38:04 | atz | dbs: oh, i guess because i linked him to the trac bug |
| # | 09:39:15 | dbs | Okay. I just worry that other people will wonder why this guy got suggested for having trac privs immediately, when everyone else who has been around a lot longer is directed towards launchpad |
| # | 09:39:36 | dbs | I might be being over-concerned though. |
| # | 09:39:37 | atz | i don't care, i'd give everybody access to trac. |
| # | 09:40:12 | atz | but, in short, he has cred. |
| # | 09:41:12 | dbs wanders away for a little bit |
| # | 09:41:14 | atz | dbs: was it you that was working on auto tools stuff just yesterday? |
| # | 09:44:34 | User1__ | Can anyone tell me how difficult (or even if it can be done) it is to change the locale of Evergreen to non US. Example: We are in Europe and don't use $ for currency or the same date format, we use DD/MM/YYYY. Is this do-able? |
| # | 09:44:54 | atz | date format is a wide problem |
| # | 09:45:58 | atz | it will require touching a lot of code. (i had to do date internationalization on the Koha project as my first assignment.) |
| # | 09:46:14 | User1__ | Really? eek. What about currency? |
| # | 09:46:31 | User1__ | Koha, if I remember correctly, was much easier to change. |
| # | 09:46:48 | atz | i have not checked out the currency handling in EG at all. |
| # | 09:47:49 | atz | User1__: you will be using MARC21 though, right? |
| # | 09:47:57 | User1__ | Yep. |
| # | 09:51:46 | User1__ | Is this there any documentation on what code needs to be change *holds his breath* |
| # | 09:52:30 | jenny has quit IRC |
| # | 09:55:36 | r123 has joined #evergreen |
| # | 10:15:48 | moodaepo | wlayton++ |
| # | 10:20:21 | phasefx_ | fwiw, I plan to move all dates in xul to dojo sometime soon |
| # | 10:47:24 | StephenGWills | yo! shout-out to "my friendly Evergreen developers" in lieu of an IT/ILS Helpdesk. *g* what's happenin boys and girls? |
| # | 10:47:43 | jeff | User1__: breathe! |
| # | 10:48:43 | phasefx_ | that was a typo, should be fiendly |
| # | 10:49:50 | dbwells | Hello all. In order to help garner some acceptance of my serials code additions, I intend to create a more formal proposal document in the wiki. Before I do that, however, I want to be totally sure I understand the goals of the current pieces. |
| # | 10:50:12 | dbs | dbwells: sounds good! |
| # | 10:50:32 | dbs | You could also use blueprints.launchpad.net as a test bed |
| # | 10:50:44 | dbwells | First, looking at the serial schema, what is the intended function of serial.binding_unit? |
| # | 10:51:04 | dbs | phasefx: huh, the XUL date/time pickers don't do it for you? |
| # | 10:51:32 | dbs | dbwells: the intention is that a binding unit can contain one or more bound issues, associated with a barcode |
| # | 10:51:33 | phasefx_ | dbs: I'm thinking for display, not input |
| # | 10:51:42 | dbs | phasefx: ahh, makes sense |
| # | 10:52:47 | dbs | User1__: there are some hits on internationalization at http://evergreen-ils.org/dokuwiki/doku.php?do=search&id=i18n |
| # | 10:53:11 | dbs | but, currency display-wise, right now the dollar sign is still hard-coded in many places |
| # | 10:53:43 | StephenGWills | Evergreen just threw a shoe. a requested config-rules_circ_duration was not found. Obviously there is a bit of config that needs to be setup but wouldn't there be a default in play? |
| # | 10:54:29 | dbwells | Well, this may be a crazy way to ask, but where would binding_unit fit here: http://www.open-ils.org/dokuwiki/doku.php?id=acq:serials:model ? |
| # | 10:54:39 | StephenGWills | All I know so far is that member encountered the error... I am not sure yet what he did to trigger it. Any suggestions about what to be looking for when i call him? |
| # | 10:54:53 | phasefx_ | StephenGWills: what's the specific rule identified, and does it exist in config.rule_circ_duration? |
| # | 10:56:05 | miker_ | dbwells: somewhere between issuance and [CP] |
| # | 10:56:07 | dbwells | Is it a 1-to-1 with copy (CP)? |
| # | 10:56:15 | dbwells | ok |
| # | 10:56:33 | dbs | 1-to-1 with copy, but *-to-1 from issuance to binding unit |
| # | 10:57:28 | dbs finally wrote up some plperl functions to generate summary statements last night |
| # | 10:58:37 | StephenGWills has quit IRC |
| # | 10:59:39 | dbwells | dbs: can you elaborate on that (the plperl stuff). Are you talking about populating serial.bib_summary, or something else? |
| # | 11:01:51 | dbs | dbwells: yep, that's the idea |
| # | 11:04:05 | dbwells | hmmm, part of my proposal was going to be getting rid of the *_summary tables :( |
| # | 11:04:19 | dbs | dbwells: okay, then it's definitely good to talk about plans :) |
| # | 11:05:31 | dbs | I was working (slowly, as is my style) towards having INSERT/UPDATE/DELETE triggers on serial.record_entry doing the "right things" with the *_summary tables, to avoid having to generate the summaries at run-time for every request |
| # | 11:06:01 | dbs | but, by all means, given the lack of progress I've made over the past two years, I'm certainly open to new ideas! |
| # | 11:06:47 | dbwells | the biggest variable in my mind is the role the actual MFHD record will take. Should it be central or secondary to the day-to-day workings of serials? I can see it both ways, but ultimately concluded it should be central if possible. |
| # | 11:08:05 | dbwells | I should say 'concluded at the moment' :) |
| # | 11:10:07 | dbwells | Along those lines, the interface layer in some ways becomes a glorified MFHD editor. |
| # | 11:12:20 | dbwells | When possible, holdings in the MFHD record will be expressed in their compressed form, and received issues will merely expand the range. Unbound issues may or may not get their own 863 depending on library preference. |
| # | 11:14:21 | twirlip-afk is now known as twirlip |
| # | 11:14:55 | dbwells | Libraries who wish to keep 863 as a per-volume could be accommodated by generating an 866 summary statement. |
| # | 11:15:13 | miker_ | dbwells: in my mind, the MFHD in combination with the surrounding tables constitute the authoritative data set ... |
| # | 11:17:26 | brendan_ga has quit IRC |
| # | 11:18:42 | dbwells | miker_: a big factor is that the MFHD standard is very flexible at what it intends to do, store holdings data |
| # | 11:19:29 | dbwells | miker_: it provides a fair number of options for doing roughly the same thing is slightly different ways. |
| # | 11:20:39 | dbwells | miker_: I am just currently thinking along the lines that if we can store it in the record, we should, and not duplicate that information in another table. |
| # | 11:21:02 | dbs | dbwells: fwiw, using triggers to populate the *_summary tables doesn't supplant the MFHD record as the central source |
| # | 11:21:33 | dbs | it's just a convenient view of some of the data as stored in the MFHD record |
| # | 11:21:51 | miker_ | dbwells: well, the problem is display generation speed. using the summary tables as a caching mechanism makes things easier, and triggers to keep them updated makes the MFHD central while facilitating speedier display ... |
| # | 11:21:57 | miker_ | so, I think we're in violent agreement |
| # | 11:22:39 | dbs | dbwells++ # "the interface layer in some ways becomes a glorified MFHD editor" - that's the holy grail, right? |
| # | 11:23:05 | dbwells | miker_: ok, just trying to be totally sure :) |
| # | 11:23:20 | miker_ | however |
| # | 11:23:22 | dbwells | dbs: right, I think so |
| # | 11:23:37 | miker_ | that's just the summary tables, IMO |
| # | 11:23:52 | dbwells | miker_: right |
| # | 11:24:02 | miker_ | I'm not sure binding units fall into that category |
| # | 11:24:13 | miker_ | we need ... something ... to link to the copy to give it a barcode |
| # | 11:24:34 | miker_ | the initial thought is issuance -->> binding_unit --> copy |
| # | 11:24:40 | miker_ | er |
| # | 11:24:45 | miker_ | the initial thought is issuance <<-- binding_unit --> copy |
| # | 11:24:52 | dbwells | yes, I follow |
| # | 11:25:02 | miker_ | where a binding unit can be one or more issuacne |
| # | 11:25:09 | miker_ | haha |
| # | 11:25:11 | miker_ | issue acne |
| # | 11:26:01 | miker_ | so, you'd create a binding unit (the row), and as you add issuances to it the MFHD would be appropriately modified |
| # | 11:26:16 | miker_ | and, as that happens, the summaries would be regenerated |
| # | 11:26:48 | dbwells | one last comment about the summary tables, I suppose I am mostly wondering if their function as a caching mechanism will be largely negated if multi-volume compressed holdings were the norm in the MFHD |
| # | 11:27:58 | miker_ | dbwells: I don't agree ... the layer of XML parsing and the larger payloads would still benefit from the tables |
| # | 11:27:58 | dbs | dbwells: well, you would still need to reach into the MFHD via XPATH or regexes to extract the compressed holdings |
| # | 11:28:41 | dbs and miker_ are of one mind, although miker_ has 95% of the grey matter and I'm the reptilian brain stem |
| # | 11:28:42 | miker_ | now, bibtemplate is rad, and would be more flexible than generated summary text, but we've seen a big benefit from context-trimming on the bib side |
| # | 11:29:04 | dbwells | Ok, my wondering has officially ceased :) |
| # | 11:29:10 | miker_ | heh |
| # | 11:29:55 | miker_ | dbwells: IMO, we can do both ... srsly, I'd much rather use the XML directly at display time ... but, I really do fear transmission time and render speed |
| # | 11:33:12 | dbwells | I would like to ask a few more questions about the level of statement compression we will use in the records. Do we definitely want an 863 per bound volume, or should be consider multivolume compression when possible? |
| # | 11:34:11 | brendan_ga has joined #evergreen |
| # | 11:35:40 | dbs | dbwells: you have now gone beyond the depth of my off-the-top-of-my-head mfhd knowledge. like most of my knowledge, it dwells in the shallow end of the pool |
| # | 11:38:18 | dbwells | well, partial compression would look something like this: |
| # | 11:38:25 | dbwells | 863 40 $8 1.1 $a 3 $b 1-12 $i 1999 |
| # | 11:38:30 | dbwells | 863 40 $8 1.2 $a 4 $b 1-12 $i 2000 |
| # | 11:39:07 | dbwells | while a full compression would turn both of those lines into: |
| # | 11:39:09 | dbwells | 863 40 $8 1.1 $a 3-4 $b 1-12 $i 1999-2000 |
| # | 11:39:21 | miker_ | dbwells: well, my preference would be for a statement poer bound volume (to tie a binding unit to an 863) ... but, I suppose if we separate binding units (make them physically-authoritative) from MFHD (and, the statement compression should be un-doable, right) then it's just admin choice |
| # | 11:39:34 | miker_ | a "compression level" setting ... somewhere |
| # | 11:39:43 | miker_ | s/poer/per/ |
| # | 11:41:20 | dbwells | miker_: I am in agreement that it should be an option, but only if you feel that separating the binding units from the MFHD is doable. |
| # | 11:42:09 | miker_ | dbwells: I think it's preferable, as long as one could reasonably expect there to be a "generate 863 per binding unit" button, which uncompresses, as needed, the compressed statements |
| # | 11:42:31 | jenny has joined #evergreen |
| # | 11:42:34 | miker_ | and I don't know if that's a reasonable (code- and MARC-wise) expectation |
| # | 11:43:06 | dbwells | or, perhaps it makes it makes sense that those who want full compression will also generally not want binding units |
| # | 11:43:30 | dbwells | both or nothing, at least as a start |
| # | 11:44:25 | miker_ | the more I think about it, the more I think they're different things, really |
| # | 11:45:08 | miker_ | the binding unit is "here's a set of physical items that share one barcode", and that's a separate table, managed by folks that know nothing of MFHD, but know all about copies and issuances |
| # | 11:45:37 | miker_ | and /that/ is authoritative insofar as the physical items are concerned |
| # | 11:46:09 | miker_ | the holdings statements in the MFHD say "I know I have these ranges of stuff, somewhere" |
| # | 11:46:23 | dbwells | makes sense to me |
| # | 11:46:25 | miker_ | which is driven by issuance (primarily) |
| # | 11:48:02 | miker_ | so, I'd say we start with complete ("we have it") issuances driving the creation of holdings statements, fully compressed, and later add the option of relaxing the compression to the "per barcode" level, effectively binding units |
| # | 11:48:10 | StephenGWills has joined #evergreen |
| # | 11:48:22 | dbwells | one wrinkle, though, is that the MFHD standard does allow for a $p in the 863, 'piece designation', which some systems use to store the barcode. |
| # | 11:49:52 | miker_ | dbwells: sure, and if you've set the "per barcode" flag to true then we'd shove that in --- remember, these would be regenerated by triggers each time the issuance table changes, eh? |
| # | 11:50:07 | miker_ | based on the prediction entries |
| # | 11:50:15 | dbwells | I agree completely with what you said. I think that using 863s to link directly to binding units is an option that comes "later" |
| # | 11:50:26 | miker_ | whee |
| # | 11:51:25 | dbwells | ok, one last group of questions about the 'issuance' table. |
| # | 11:53:20 | dbwells | I think it makes sense to use it to store prediction "instance" information as well, since it is 1-to-1 with an issuance. Thought? |
| # | 11:54:23 | dbwells | fields like 'date_expected', 'date_received', etc. |
| # | 11:54:28 | miker_ | dbwells: the plan has been to use an issuance to track that state and status of an instance |
| # | 11:54:40 | miker_ | so, one table, several states through its lifetime |
| # | 11:54:55 | miker_ | so, yeah, fields like you're talking about |
| # | 11:55:05 | dbwells | great |
| # | 11:55:56 | miker_ | basically, you'd have: MFHD -> issuance <- subscription |
| # | 11:57:22 | dbwells | Do does the MFHD record largely supplant the call number in the diagram? http://www.open-ils.org/dokuwiki/doku.php?id=acq:serials:model |
| # | 11:58:37 | miker_ | dbwells: actually, that's another reason for the summary statements in tables |
| # | 11:59:21 | miker_ | call number -> subscription -> summaries |
| # | 11:59:55 | miker_ | that's not directly represented in the image |
| # | 12:00:00 | miker_ | obviously |
| # | 12:01:07 | dbwells | hmmm, interesting |
| # | 12:02:06 | miker_ | but, the idea would be similar to the Located URI stuff ... there's a magical callnumber row (label = ##URI##, hidden from all UIs (or should be)) that says "there are online-only versions of this" |
| # | 12:02:35 | miker_ | we can do a very similar thing with serials stuff... |
| # | 12:03:09 | miker_ | a redirection to some other tables in order to inject (display-oriented) layers between callnumber and copy |
| # | 12:03:23 | miker_ | replacing callnumber, of course |
| # | 12:03:28 | miker_ | as we do with the URI junk |
| # | 12:03:55 | miker_ | it's not entirely internally self-consistent, but then neither is MARC ;) |
| # | 12:04:21 | dbs | miker_: doesn't even need to be online-only, as we currently use dummy barcodes for making our non-circulating print periodical collection retrievable |
| # | 12:05:04 | dbs | (although they have real call numbers that need to be displayed, so maybe that doesn't really hold) |
| # | 12:06:09 | dbwells | I must admit that I am not entirely following, but I have a feeling this conversation will be totally clear three to six months from now. |
| # | 12:07:40 | miker_ | dbs: right ... "unbarcoded resources" would be a better way to describe what Located URIs supports, I guess |
| # | 12:12:09 | dbwells | so, if I understand, the intention is that the serial.record_entry will exist more or less in parallel with the structures in the diagram, informing one another as needed but not actually existing in the structure? |
| # | 12:12:31 | mrpeters-isl | any idea why autogen gives No Response from settings server...going to sleep but settings is running fine? |
| # | 12:15:56 | dbwells | hmmm, still thinking :) |
| # | 12:16:20 | dbwells | talking about myself... |
| # | 12:16:48 | dbwells | Anyway, the nature of the linking can wait for now. |
| # | 12:19:23 | dbwells | My last question about the issuance table has to do with multi-copy subscriptions. Should an issuance represent all expected copies, or should each copy get a separate issuance? |
| # | 12:20:34 | miker_ | issuances, in my mind, represent something that can be received, so one per physical copy |
| # | 12:20:59 | miker_ | also supports creating multiple binding units with different barcodes that have the same issues in them |
| # | 12:21:07 | miker_ | but ... I could be crazy |
| # | 12:23:47 | mrpeters-isl | die fieldmapper!!! quit going to sleep! |
| # | 12:23:59 | dbwells | I have thought about it a fair amount and not reached a firm conclusion. It seems most natural to say an issuance is one copy only, as you suggest. |
| # | 12:24:08 | dbwells | But... |
| # | 12:24:59 | dbwells | I am not convinced of how it will actually affect the workflow logic. |
| # | 12:25:03 | User1__ has quit IRC |
| # | 12:26:13 | dbwells | We often receive multiple copies, but only bind one. I would guess that is normal, but maybe not? |
| # | 12:29:40 | dbs | dbwells: multiple copies of the same issue? |
| # | 12:29:52 | dbwells | right |
| # | 12:30:05 | dbs | I'm not sure that I've run across that use case before, so haven't thought about it at all. |
| # | 12:30:32 | dbwells | yeah, the more I think about it, the more it goes into the 'maybe later' bin. |
| # | 12:30:37 | dbs | That would complicate things, I think, if you want to indicate somehow that multiple copies were received. Multiple subscriptions, perhaps? |
| # | 12:31:32 | dbwells | exactly. It is really one subscription, but is it *really* one subscription? |
| # | 12:32:08 | dbwells | from the business side of things yes, but in the real world, no |
| # | 12:33:46 | natschil has joined #evergreen |
| # | 12:34:19 | dbs | dbwells: btw, I just posted a new entry at http://coffeecode.net describing my current Evergreen serials project which might be of interest to you |
| # | 12:38:27 | dbwells | dbs: looks like a good read. We also use SFX here at Calvin. We have done a fair amount with it, including a nightly sync of e-journal 'short records' into our current catalog and a quarterly sync of our print holdings into SFX. |
| # | 12:39:15 | dbwells | We will lose both things when we switch to EG, so hopefully your work will give us a head start on duplicating some of that funcitonality. |
| # | 12:39:38 | dbs | dbwells: ah, cool! I'd like to move towards a nightly sync, all of our records have been added manually over the past 5 years or something insane like that |
| # | 12:40:10 | dbs | (actually, the truly insane part was that all of the electronic holdings were added manually as 856 entries to those records - NOT MY IDEA!) |
| # | 12:40:43 | dbwells | :o |
| # | 12:41:13 | dbs | dbwells: we're running the open-ils.resolver service now to generate links + coverage statements dynamically from SFX based on the ISSN in a given record, so that will probably be of interest to you |
| # | 12:41:30 | mrpeters-isl | Updating fieldmapper |
| # | 12:41:30 | mrpeters-isl | No Response from settings server...going to sleep |
| # | 12:41:33 | mrpeters-isl | no errors in logs |
| # | 12:41:39 | mrpeters-isl | wtf |
| # | 12:41:53 | dbs | opensrf.settings is running? |
| # | 12:41:59 | mrpeters-isl | yep! |
| # | 12:42:03 | mrpeters-isl | thus why i am so puzzled |
| # | 12:42:17 | mrpeters-isl | lots of settings drones |
| # | 12:43:05 | mrpeters-isl | and the master/listener of course |
| # | 12:47:13 | berick | atz: lemme grab some food and think on it some more |
| # | 12:51:20 | dbwells | dbs: about the blueprints.launchpad.net suggestion, I am not familiar with the service. Do you think it would be better to draft something there rather than in the wiki, or was it more an off-the-cuff suggestion? |
| # | 12:52:36 | dbs | dbwells: where-ever you feel comfortable. we're starting month #2 of trying out launchpad, so I thought it would be a good experiment, but I don't want to get in the way of your real work |
| # | 12:52:50 | branflakes has joined #Evergreen |
| # | 12:53:26 | dbwells | dbs: ok, I'll give it a whirl, why not :) |
| # | 13:02:58 | dbs | dbwells++ |
| # | 13:05:28 | dbs | gdunbar_ berick phasefx miker_ et al: what are the remaining items on the critical path for turning http://evergreen-ils.org/downloads2.php into http://evergreen-ils.org/downloads.php ? |
| # | 13:06:17 | dbs | i.e. should we just "release" 1.6.0.0 and 1.4.0.7 now and tackle the release notes etc concurrently? |
| # | 13:06:33 | gdunbar_ | dbs: I need to tweak the 1.4.0.6 release notes into 1.4.0.7 release notes.... The 1.6.0.0 notes are done |
| # | 13:07:03 | dbwells | well, I created the blueprint, but it seems to primarily handle management type details with a field for adding a URL to the actual spec. I think that is a good thing, overall. |
| # | 13:07:36 | gdunbar_ | dbs but 1.4.0.7 is mainly bug fixes so I see no reason to let that hold up the new page |
| # | 13:08:01 | dbs | gdunbar_: cool. the horse keeps leaving the barn, but maybe we could see if there are volunteers to maintain release notes as commits occur (or at least periodically), rather than the release-time crunch |
| # | 13:08:18 | gdunbar_ | dbs: It has been a dream of mine... :-) |
| # | 13:09:01 | dbs | heh |
| # | 13:09:17 | dbs | so http://evergreen-ils.org/dokuwiki/doku.php?id=release_notes_1_6_0_0_rc1 is the 1.6.0.0 release notes location? |
| # | 13:09:59 | dbs | and http://evergreen-ils.org/dokuwiki/doku.php?id=feature_list_1_6_0 is the feature list |
| # | 13:11:02 | dbs | ? or the latter is the authoritative one for 1.6.0, and the former one is just for rc1? |
| # | 13:14:06 | natschil has quit IRC |
| # | 13:20:51 | miker_ | dbs: "the latter is the authoritative one for 1.6.0, and the former one is just for rc1" |
| # | 13:21:48 | dbs | miker_: okay |
| # | 13:24:09 | dbs | it is done |
| # | 13:24:45 | miker_ | dbs++ |
| # | 13:25:11 | mrpeters-isl | anyone else with any thoughts on autogen fieldmapper "going to sleep" |
| # | 13:25:14 | phasefx_ | I should probably package a new client |
| # | 13:25:23 | mrpeters-isl | no errors in logs, listener running, etc. |
| # | 13:25:56 | dbs | phasefx: that is why I asked about the client last week, heh |
| # | 13:26:58 | dbs replaces the link to the staff client with "SOON" |
| # | 13:27:06 | phasefx_ | would it be safe to install whatever OpenSRF goes with 1.6 over top of a trunk OpenSRF, for the purpose of building the client from the 1.6 tarball? |
| # | 13:28:06 | dbs | OpenSRF 1.2.0? Should be safe. You just want the /openils/lib/javascript bits right? |
| # | 13:28:21 | miker_ | phasefx_: please use 1.2.0 |
| # | 13:28:30 | miker_ | there are changes in trunk js |
| # | 13:28:54 | phasefx_ | right, I'm asking if I need to wipe out trunk OpenSRF completely or if I could safely just install over it with 1.2.0 |
| # | 13:29:12 | miker_ | you could just install over it, but you may need to then rebuild EG |
| # | 13:29:23 | phasefx_ | I suppose I could ./configure things to point to an alternate OpenSRF path |
| # | 13:29:35 | dbs | he needs to do that anyway to build the new staff client, I think |
| # | 13:29:47 | dbs | ooh, good test of autotools ... heh |
| # | 13:30:14 | phasefx_ | my plan is snapshot my vm image so I can restore it after I'm done, install OpenSRF 1.2.0, compile EG 1.6 with some minimal options, then package the build/ directory for the staff client |
| # | 13:34:21 | jeff | feature_list_1_6_0 needs some completion of this half-finished thought: ``# |
| # | 13:34:21 | jeff | * |
| # | 13:34:21 | jeff | Please note that this represents a change from previous versions of Evergreen and for new clients it is recommended to use this interface, for |
| # | 13:34:24 | jeff | # |
| # | 13:35:05 | finnx has quit IRC |
| # | 13:35:22 | jeff | (i'm not sure what the exact intention is, or i'd edit myself) |
| # | 13:36:06 | phasefx_ | I'll be doing the steps here, after installing the right OpenSRF: http://evergreen-ils.org/dokuwiki/doku.php?id=scratchpad:packaging_the_staff_client_for_windows |
| # | 13:36:08 | dbs | ... "script-based circulation ain't where it's at" |
| # | 13:36:59 | jeff | mrpeters-isl: is EI using script-based or db-based circ rules? |
| # | 13:42:09 | phasefx_ | now, this client will have the same target server (build) id as the one that is up there now. Should we do anything to distinguish it from that previous version? If we want to leave the source code untouched, I could put some extra wording in the text the installer displays |
| # | 13:43:16 | finnx has joined #evergreen |
| # | 13:50:38 | phasefx_ | another question is the xulrunner to use.. the previous 1.6.0.0 was using XR 1.9.0.13.. there's a stable 1.9.1 series out now |
| # | 13:52:19 | phasefx_ | not that I can download any of them (redirection problems with their site) |
| # | 13:52:37 | eby_ has joined #evergreen |
| # | 13:53:08 | phasefx_ | https to the rescue |
| # | 13:53:40 | dbs | phasefx: have you been testing 1.6.0.0 with 1.9.0 or 1.9.1? |
| # | 13:54:12 | phasefx_ | I've used 1.9.1 with trunk, but the only 1.6 client I've been using has been with 1.9.0 |
| # | 13:54:21 | dbs | so, that's probably your answer |
| # | 13:54:30 | phasefx_ | testing.. ha ha :) |
| # | 13:54:48 | phasefx_ | I'm sure there's also a newer 1.9.0 too |
| # | 13:55:22 | phasefx_ | 1.9.0.15 |
| # | 13:55:40 | phasefx_ will go with .15 |
| # | 13:55:58 | dbs | i would leave the build ID at 1_6_0_0, it can be a learning opportunity for the future to make RC build ID's reflect the RC |
| # | 13:56:14 | dbs | .15 sounds like a good decision |
| # | 13:56:38 | phasefx_ 's method was to use the tag/ as the build id, didn't expect for the tag to turn into a branch |
| # | 13:58:39 | phasefx_ | want any new installer languages beside French and Czech? |
| # | 13:59:49 | phasefx_ | don't think any of the options they have we support yet |
| # | 13:59:50 | jenny has quit IRC |
| # | 13:59:55 | dbs | did cs-CZ actually get into 1.6.0.0? |
| # | 14:00:47 | dbs | I thought it was hy-AM (Armenian), en-CA (Canuck), fr-CA (Canuck francais) and en-US (Cowboy) |
| # | 14:00:57 | phasefx_ | you are right |
| # | 14:01:07 | phasefx_ | so I'll remove czech from the installer |
| # | 14:01:20 | dbs | cool. czech can go in for 1.6.0.1 |
| # | 14:01:29 | dbs | and russian |
| # | 14:01:40 | dbs | but they missed the 1.6.0.0 boat (due to me) |
| # | 14:01:48 | phasefx_ | innosetup does have russian |
| # | 14:04:51 | jenny has joined #evergreen |
| # | 14:07:01 | B_Bonner has joined #evergreen |
| # | 14:07:54 | mrpeters-isl | all, in what directory are the marc templates stored? |
| # | 14:08:23 | mrpeters-isl | openils/var/templates/marc/ or am i off? |
| # | 14:10:42 | dbs | mrpeters-isl: if memory serves, that's the place |
| # | 14:14:15 | mrpeters-isl | thanks! |
| # | 14:14:46 | mrpeters-isl goes back to drawing board on this "sleeping" issue |
| # | 14:15:18 | phasefx_ | http://evergreen-ils.org/downloads/evergreen-setup-rel_1_6_0_0.exe.md5 (in case someone gets a cached copy) and http://evergreen-ils.org/downloads/evergreen-setup-rel_1_6_0_0.exe |
| # | 14:17:08 | lisppaste3 | mrpeters-isl pasted "fieldmapper "Sleeping"" at http://paste.lisp.org/display/90598 |
| # | 14:17:14 | dbs | yay md5 for staff_client |
| # | 14:17:34 | dbs | phasefx: do you want to update the downloads page, or shall i? |
| # | 14:18:33 | phasefx_ | dbs: please go ahead, and I'm in a phone meeting. dbs++ |
| # | 14:18:34 | dbs will do it |
| # | 14:18:38 | dbs | jinx |
| # | 14:19:44 | phasefx_ | dbs: we should start hosting md5's on another server |
| # | 14:21:01 | dbs | phasefx++ |
| # | 14:21:34 | mrpeters-isl | phasefx_ how does this differ from what we had been using in Indiana? Do we need to have everyone upgrade? |
| # | 14:22:55 | phasefx_ | more recent version of xulrunner, so bugfixes (and possibly bugs) that you may or may not notice. The code changes that could affect the local client are very minor I think. You shouldn't need to upgrade. Especially if you want to keep your 1.8 xulrunner build for those printers |
| # | 14:24:46 | mrpeters-isl | ok |
| # | 14:26:14 | phasefx_ | mrpeters-isl: so that printer warning could be displayed with offline printing with the new client, but wouldn't with the older cut |
| # | 14:26:21 | phasefx_ | I think that's it |
| # | 14:27:58 | mrpeters-isl | cool |
| # | 14:29:23 | mrpeters-isl | is there some other switch needed beyond "./autogen.sh -c /openils/conf/opensrf_core.xml -u" that I am missing? |
| # | 14:29:27 | mrpeters-isl | i have never had this issue! |
| # | 14:30:03 | phasefx_ | you shouldn't even need to specify -c for the default path, at least in trunk. Not sure about 1.6 |
| # | 14:30:28 | phasefx_ | ./autogen.sh -u |
| # | 14:31:19 | mrpeters-isl | yeah, just hangs on Updating fieldmapper then says "No Response from settings server...going to sleep" |
| # | 14:33:09 | phasefx_ | mrpeters-isl: what version of OpenSRF? |
| # | 14:33:42 | mrpeters-isl | 1.2.0 |
| # | 14:39:37 | jenny1 has joined #evergreen |
| # | 14:47:00 | dbs | Hmm, esilibrary.com/feed seems dead? |
| # | 14:47:48 | dbs | yup, blog is dead |
| # | 14:47:52 | dbwells | mrpeters-isl: shot in the dark, but I have had problems with the setting service due to OpenSRF incombatibility with ejabberd 2.0.3 and higher. See here: http://list.georgialibraries.org/pipermail/open-ils-dev/2009-July/004888.html |
| # | 14:47:52 | dbs | Error establishing a database connection |
| # | 14:48:17 | dbs | dbwells: hmm, i certainly _hope_ that the fix for that is in 1.2.0 |
| # | 14:48:32 | dbwells | dbs: I don't think they are :( |
| # | 14:48:50 | dbs | argh. arghity argh argh |
| # | 14:49:49 | dbs | we're looking for this: http://svn.open-ils.org/trac/OpenSRF/changeset/1731 |
| # | 14:50:40 | dbs | and nope: http://svn.open-ils.org/trac/OpenSRF/browser/tags/rel_1_2_0/src/libopensrf/transport_client.c |
| # | 14:51:02 | dbwells | Yeah, rel_1.2.0 ends at 1728 |
| # | 14:51:03 | dbs | miker_: so, add that to the list of things to backport to 1.2.1, eh? |
| # | 14:52:19 | dbs | 4 months of code updates to OpenSRF trunk with no new OpenSRF releases is probably sub-optimal |
| # | 14:53:20 | mrpeters-isl | dbwells: yeah, i dont think that will do it :) |
| # | 14:53:40 | dbs | mrpeters-isl: what distro are you running on? |
| # | 14:53:42 | mrpeters-isl | crap, actually, you may be right i will try the upgrade |
| # | 14:53:44 | mrpeters-isl | debian lenny |
| # | 14:54:11 | dbs | hmm, lenny should be okay, unless they backported that "from" requirement |
| # | 14:54:17 | mrpeters-isl | hmm |
| # | 14:54:39 | mrpeters-isl | i dunno, ive had 1.6 (the RC1) running fine on another lenny system |
| # | 14:54:46 | mrpeters-isl | with trunk OpenSRF |
| # | 14:55:17 | mrpeters-isl | and that was trunk from probably, September? so would that be newer or older than 1.2.0? |
| # | 14:55:35 | dbwells | mrpeters-isl: newer |
| # | 14:55:42 | mrpeters-isl | crap |
| # | 14:55:57 | mrpeters-isl | was hoping to not use anything non "offically" released on this box |
| # | 14:56:39 | mrpeters-isl | so do i need to roll back jabber, or upgrade? |
| # | 14:57:04 | jenny has quit IRC |
| # | 14:57:05 | mrpeters-isl | i imagine im on 2.0.5-1.1 |
| # | 14:57:47 | phasefx_ | dbs: http://blog.esilibrary.com/feed/ ? |
| # | 14:58:13 | dbs | http://blog.esilibrary.com/ is dead |
| # | 14:58:20 | dbs | oh, and now it's back. weird |
| # | 14:58:37 | dbs | ahh, http://blog.esilibrary.com/feed/atom/ is bad |
| # | 14:58:52 | dbs | http://blog.esilibrary.com/feed/ is okay |
| # | 14:59:11 | dbs | phasefx: something's been weird with it in the last hour or so |
| # | 14:59:15 | dbs | mrpeters-isl: 2.0.5? |
| # | 14:59:28 | mrpeters-isl | ejabberd version, sorry |
| # | 14:59:28 | dbs | that's stock lenny? |
| # | 14:59:34 | phasefx_ | I'll let folks know, thanks. I think that's outsourced |
| # | 14:59:57 | mrpeters-isl | er, sorry dbs---2.0.1-6+lenny1 |
| # | 15:00:42 | dbs | that sounds better :) |
| # | 15:00:54 | dbs | mrpeters-isl: can you run any srfsh commands? |
| # | 15:01:26 | mrpeters-isl | yep! |
| # | 15:01:27 | dbs | ejabberd 2.0.1 should be okay |
| # | 15:01:29 | mrpeters-isl | math, login, etc. |
| # | 15:01:39 | dbs | introspect opensrf.settings ? |
| # | 15:01:50 | mrpeters-isl | sure, have an example of a command to run against it? |
| # | 15:02:00 | dbs | well, exactly that (minus the ?) |
| # | 15:02:14 | mrpeters-isl | srfsh# introspect opensrf.settings |
| # | 15:02:14 | mrpeters-isl | --> opensrf.settings |
| # | 15:02:27 | mrpeters-isl | then lots of data |
| # | 15:02:49 | lisppaste3 | mrpeters-isl pasted "introspect" at http://paste.lisp.org/display/90602 |
| # | 15:03:21 | dbwells | mrpeters-isl: I think it is probably safe to say you have some other problem, sorry |
| # | 15:03:36 | mrpeters-isl | dbs: thats just a sampling of it, there is more i can paste if needed |
| # | 15:04:10 | dbs | mrpeters-isl: so, if srfsh can instrospect opensrf.settings, then everything is working fine :) |
| # | 15:04:32 | mrpeters-isl | but autogen still fails haha |
| # | 15:04:41 | mrpeters-isl | so i have no consortium settings in the OPAC |
| # | 15:04:41 | dbs | it makes me wonder if the srfsh credentials (user/pass/host) are different than what autogen.sh is picking |
| # | 15:04:52 | mrpeters-isl | admin open-ils still |
| # | 15:04:57 | dbs | no no |
| # | 15:04:58 | phasefx_ | or maybe it's the contents of the xml file? |
| # | 15:05:12 | dbs | .srfsh.xml vs. opensrf_core.xml |
| # | 15:05:38 | mrpeters-isl | let me check |
| # | 15:06:25 | mrpeters-isl | we're concerned with private.localhost users/pw's right? |
| # | 15:07:55 | mrpeters-isl | in which case, hosts, username, pw match from both xmls |
| # | 15:08:15 | dbs | umm, does your opensrf_core.xml point to opensrf.xml? |
| # | 15:08:28 | dbs | i guess it must, to have started those up |
| # | 15:09:09 | mrpeters-isl | yep |
| # | 15:09:33 | dbs | how about IDL |
| # | 15:09:42 | dbs | does opensrf.xml point to fm_IDL.xml? |
| # | 15:09:47 | mrpeters-isl | let me check |
| # | 15:10:24 | mrpeters-isl | <IDL>/openils/conf/fm_IDL.xml</IDL> <!-- top level IDL file --> |
| # | 15:10:41 | dbs | okay |
| # | 15:10:43 | mrpeters-isl | and fm_IDL.xml exists |
| # | 15:10:59 | dbs | what if you type "perl /openils/bin/fieldmapper.pl /openils/conf/opensrf_core.xml" ? |
| # | 15:11:06 | mrpeters-isl | sure, 1 sec |
| # | 15:11:48 | mrpeters-isl | Can't locate OpenILS/Utils/Fieldmapper.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.10.0 /usr/local/share/perl/5.10.0 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl .) at /openils/bin/fieldmapper.pl line 4. |
| # | 15:11:48 | mrpeters-isl | BEGIN failed--compilation aborted at /openils/bin/fieldmapper.pl line 4. |
| # | 15:12:17 | dbs | Interesting |
| # | 15:12:23 | dbs | this is as opensrf? |
| # | 15:12:59 | dbs | Try ". ~/.bashrc" and then run that command again to see if PERL5LIB is set up in .bashrc like it's supposed to |
| # | 15:15:15 | mrpeters-isl | sorry that was as root |
| # | 15:15:30 | dbs | okay, try it as opensrf |
| # | 15:15:35 | mrpeters-isl | yep, doing so now |
| # | 15:15:41 | mrpeters-isl | r |
| # | 15:15:41 | mrpeters-isl | No Response from settings server...going to sleep |
| # | 15:16:29 | dbs | well, at least we know that autogen.sh isn't doing anything funky to the argument that fieldmapper.pl is receiving |
| # | 15:17:17 | dbs | mrpeters-isl: hmm, is this a fresh install on a clean server? |
| # | 15:18:03 | dbs | I was wondering if the old OpenSRF perl modules might have been left behind in /openils/lib/perl/ - but I thought that went away between Evergreen 1.2 and 1.4 |
| # | 15:18:22 | dbs | (and again... osrf_ctl.sh should have tripped over that) |
| # | 15:20:12 | mrpeters-isl | dbs: it sure is |
| # | 15:20:20 | mrpeters-isl | totally brand new install of Debian lenny just this morning |
| # | 15:20:36 | dbs | I'm tapped out |
| # | 15:21:06 | mrpeters-isl | haha yeah, me too |
| # | 15:21:07 | dbs | it doesn't make any sense to me that srfsh (C) can talk to opensrf.settings but Perl can't |
| # | 15:21:10 | mrpeters-isl | its pretty damn strange |
| # | 15:21:24 | mrpeters-isl | none of my normal stupid mistakes! |
| # | 15:27:34 | branflakes has quit IRC |
| # | 15:27:48 | pmplett has joined #evergreen |
| # | 15:34:25 | jamesrf_ has joined #evergreen |
| # | 15:34:46 | jamesrf has quit IRC |
| # | 15:34:51 | jamesrf_ is now known as jamesrf |
| # | 15:49:05 | StephenGWills | i'm reading the circ_mod stuff.... can I set different circ_mods for each library system in a consortium? |
| # | 15:49:19 | mrpeters-isl | StephenGWills: in theory, i dont't see why not |
| # | 15:49:27 | StephenGWills | ok |
| # | 15:49:36 | mrpeters-isl | though I have to say, having standardized circ mods across the whole consortium is great for patrons |
| # | 15:49:48 | mrpeters-isl | dont have to worry about different rules at each library, makes for a happier patron |
| # | 15:49:51 | phasefx_ | we're missing http://evergreen-ils.org/downloads/ChangeLog-1.4.0.7-1.6.0.0 |
| # | 15:50:36 | phasefx_ | StephenGWills: the list of circ mods is global, but the behavior associated with any given circ modifier doesn't have to be global |
| # | 15:51:08 | mrpeters-isl | phasefx_: though, you could get crazy and create a circ mod for each branch |
| # | 15:51:14 | phasefx_ | yeah |
| # | 15:51:24 | mrpeters-isl | like, book_isl that is one, and book_gpl that is another type of book |
| # | 15:51:31 | mrpeters-isl | would get to be one heck of a mess, but hey, you could do it :) |
| # | 15:51:39 | phasefx_ | wouldn't be too bad with templates, if those were easier to distribute/share |
| # | 15:51:49 | mrpeters-isl | another thing we do is use the 3 loan durations |
| # | 15:51:57 | mrpeters-isl | so there are 3 options for the consortium members to chose from, for a particular circ mod |
| # | 15:52:15 | mrpeters-isl | for example - "book new" from which they can have a 7, 14, or 21 day circ period |
| # | 15:52:20 | phasefx_ wishes more folks would base behavior off of the data in the bib record, rather than something item level |
| # | 15:52:40 | mrpeters-isl | phasefx_: example? |
| # | 15:52:44 | phasefx_ | record type |
| # | 15:53:02 | mrpeters-isl | i see, rather than using circ modifiers all together? |
| # | 15:53:12 | phasefx_ | same sort of values you see in the Circulate As Type drop-down |
| # | 15:53:21 | mrpeters-isl | ok i get you |
| # | 15:53:26 | phasefx_ | circ mods could compliment such logic |
| # | 15:53:49 | phasefx_ | if (record type = projected medium && circ mod = high demand) then rule A |
| # | 15:54:20 | mrpeters-isl | interesting |
| # | 15:55:16 | phasefx_ | if (record type == projected medium) { rule = defaultVidRule; if ( circ mod == high demand ) { rule = highDemandVidRule; } } |
| # | 15:55:47 | jenny1 has quit IRC |
| # | 15:59:41 | Meliss has quit IRC |
| # | 16:02:25 | bshum has quit IRC |
| # | 16:17:10 | jenny has joined #evergreen |
| # | 16:45:33 | twirlip is now known as twirlip-afk |
| # | 16:50:51 | dbwells_ has joined #Evergreen |
| # | 17:00:11 | dbwells__ has joined #Evergreen |
| # | 17:01:03 | dbwells__ has left #Evergreen |
| # | 17:04:08 | dbwells_ has quit IRC |
| # | 17:06:55 | dbwells has quit IRC |
| # | 17:10:24 | jenny1 has joined #evergreen |
| # | 17:16:55 | jenny has quit IRC |
| # | 17:35:47 | dbwells has joined #Evergreen |
| # | 17:40:24 | dbs has quit IRC |
| # | 17:41:22 | atz has quit IRC |
| # | 17:42:03 | atz has joined #evergreen |
| # | 17:47:07 | [1]atz has joined #evergreen |
| # | 17:48:07 | [1]atz has quit IRC |
| # | 17:48:51 | [1]atz has joined #evergreen |
| # | 17:56:03 | atz has quit IRC |
| # | 17:56:04 | [1]atz is now known as atz |
| # | 17:58:31 | B_Bonner | Hi, I'm trying to log onto the DIG 1.6 test server, but am experiencing a "login failed" error. I am using staff client rel_1_6_0_0. Is it simply a problem with login credentials or is it something more involved? (thanks) |
| # | 18:08:13 | brendan_ga has quit IRC |
| # | 18:11:33 | moodaepo | B_Bonner The password needs to be reset I think |
| # | 18:13:38 | B_Bonner | Who should I contact to reset the DIG password? |
| # | 18:22:46 | jenny1 has left #evergreen |
| # | 18:23:27 | moodaepo | B_Bonner mrpeters-isl set that server up so I think he would be the person to harass |
| # | 18:31:53 | eby_ has quit IRC |
| # | 19:03:54 | [1]atz has joined #evergreen |
| # | 19:07:05 | atz has quit IRC |
| # | 19:07:05 | [1]atz is now known as atz |
| # | 19:27:52 | twirlip-afk is now known as twirlip |
| # | 19:44:01 | pmplett has quit IRC |
| # | 19:50:03 | B_Bonner has quit IRC |
| # | 20:02:50 | brendan_ga has joined #evergreen |
| # | 20:04:48 | twirlip is now known as twirlip-afk |
| # | 20:24:42 | pmplett has joined #evergreen |
| # | 20:33:48 | r123 has quit IRC |
| # | 20:48:46 | wlayton has joined #evergreen |
| # | 20:59:05 | brendan_ga_ has joined #evergreen |
| # | 21:00:36 | brendan_ga has quit IRC |
| # | 21:04:38 | dbs has joined #evergreen |
| # | 21:11:33 | dbs | @later tell jmeeuwen http://evergreen-ils.org/~denials/ may be useful for a developer-oriented intro to OpenSRF and Evergreen |
| # | 21:11:33 | pinesol | dbs: The operation succeeded. |
| # | 21:12:15 | dbs | @later tell jmeeuwen "The HTML edition" is the tutorial, "the tarball edition" includes the code samples and a presentation to follow along with |
| # | 21:12:15 | pinesol | dbs: The operation succeeded. |
| # | 21:19:04 | atz has quit IRC |
| # | 21:19:45 | atz has joined #evergreen |
| # | 21:26:12 | wlayton | dbs: If I want to update some fr-CA translations for 1.6, should I work from from branch_1_6_0? |
| # | 21:26:54 | dbs | wlayton: I think that makes the most sense; one sec |
| # | 21:28:21 | dbs | yep, that's the right place |
| # | 21:28:37 | wlayton | great |
| # | 21:28:44 | dbs | in /build, make newpot; make LOCALE=fr-CA updatepo |
| # | 21:29:32 | dbs | (following http://evergreen-ils.org/dokuwiki/doku.php?id=evergreen-admin:customizations:i18n) |
| # | 21:30:11 | dbs | we really need to get this stuff onto translations.launchpad.net/evergreen, but it means flipping the file/directory conventions to conform to GNU gettext standards |
| # | 21:31:20 | dbs | that is, from po/fr-CA/db-seed.po & po/ru-RU/db-seed.po to po/db-seed/fr-CA.po & po/db-seed/ru-RU.po |
| # | 21:33:14 | phasefx_ | how would someone best do l10n I wonder.. just maintain patches to those po files, or make up "locales"? |
| # | 21:35:14 | dbs | making up locales is a terrible idea |
| # | 21:35:46 | dbs | patching the PO files is only slightly better, just because it's pretty complex |
| # | 21:36:34 | dbs | I've documented before how to overlay entity files, so that you just pick up the overrides for your site (works on a skin-by-skin basis). which is fine for the entity-ized stuff. |
| # | 21:37:09 | phasefx_ | hrm |
| # | 21:37:13 | dbs | by l10n I assume you mean "local customizations" not localization |
| # | 21:37:26 | phasefx_ | I really don't know the difference, then |
| # | 21:38:48 | dbs | localization is adapting a product for a specific language / region / culture - e.g. french-speaking quebec |
| # | 21:39:30 | dbs | "local customization" would be changing some strings to include email addresses for your site's sysadmin, or the name of your library |
| # | 21:39:35 | phasefx_ | so i18n is just the framework/capability of doing l10n? |
| # | 21:40:08 | dbs | right-o |
| # | 21:40:50 | phasefx_ had it all wrong, haha |
| # | 21:42:58 | jeff | it took a while, but this exists now: http://en.wikipedia.org/wiki/Category:Numeronyms |
| # | 21:43:57 | jeff | (took a while as in it didn't exist until just recently. i had nothing to do with its creation.) |
| # | 21:44:52 | phasefx_ | wow, I wonder which one started the meme |
| # | 21:44:56 | dbs | huh |
| # | 21:45:10 | dbs | i18n and g11n were the two that I first had hammered into me at IBM |
| # | 21:45:52 | phasefx_ | S12n |
| # | 21:46:18 | phasefx_ | i18n is dated from 1985 |
| # | 21:55:58 | wlayton | dbs: One question for your francophone cataloguers: do they refer to "a record" (as in MARC records) as "une notice" ? |
| # | 21:56:34 | wlayton | I'd like to change the current "compte" to "notice" in fr-CA but don't want to do it unilaterally ;-) |
| # | 22:14:57 | brendan_ga_ has quit IRC |
| # | 22:15:11 | dbs | wlayton: yep. "une notice" dans mon bureau |
| # | 22:15:40 | dbs | they're all francophones. None of them use the fr-CA interfaces |
| # | 22:18:43 | dbs | which would make me feel like we wasted about a year of effort on enabling what i18n support there is, if it weren't for Tigran & Armenia |
| # | 22:19:20 | dbs | I'd love to see an Anishnabek localization of the OPAC, at least |
| # | 22:20:58 | wlayton | dbs: If it makes you feel better, our Quebec staff use the fr-CA interface (they're the ones that complained about "compte" vs "notice") |
| # | 22:21:17 | dbs | yay :) |
| # | 22:22:29 | wlayton | Although I notice that they didn't report the BIG typo on the staff client login window ("Fermeer" instead of "Fermer") |
| # | 22:23:50 | dbs | hah, maybe that's the nl-NL influence :) |
| # | 22:25:08 | wlayton | ha! |
| # | 22:26:20 | dbs pokes around http://github.com/senator/OpenILS-Evergreen/commits/patron_data |
| # | 22:40:31 | brendan_ga has joined #evergreen |
| # | 23:03:14 | eguest309 has joined #Evergreen |
| # | 23:06:15 | wlayton has quit IRC |
| # | 23:09:05 | dbs | for x in `ls -d po/*-* | sed -e 's/^po\///' | grep -v en-US`; do for y in `ls -1 po/$x/*po | sed -e 's/^po\/..-..\///' -e 's/.po$//'`; do svn mv po/$x/$y.po po/$y/$x.po; done; done; |
| # | 23:09:07 | dbs | whee! |
| # | 23:15:16 | miker_ | dbs: just thinking of doing that to trunk for now? |
| # | 23:15:46 | dbs | miker_: working on it |
| # | 23:16:43 | phasefx_ | that's one heck of a one-liner |
| # | 23:16:55 | phasefx_ | and no perl to be found :) |
| # | 23:22:37 | eguest309 has quit IRC |
| # | 23:25:30 | pmplett has quit IRC |
| # | 23:28:23 | error_23 has joined #Evergreen |
April 10-13