| Time |
Nick |
Message |
| 02:11 |
|
Mark__T joined #evergreen |
| 03:45 |
|
stevenyvr2 joined #evergreen |
| 03:45 |
|
stevenyvr2 left #evergreen |
| 05:23 |
|
natschil joined #evergreen |
| 06:19 |
bshum |
@roulette |
| 06:19 |
pinesol_green |
bshum: *click* |
| 06:47 |
paxed |
mornin |
| 06:57 |
|
natschil_ joined #evergreen |
| 07:40 |
|
rjackson-isl joined #evergreen |
| 07:40 |
csharp |
question for when everyone is awake: is it possible to retrieve holdings information via Evergreen SRU alone, or would that require us to set up z39.50 on our end? |
| 07:41 |
bshum |
Hmm |
| 07:41 |
bshum |
I suspect that SRU alone would work. Since z39.50 just points at the SRU |
| 07:42 |
csharp |
the context is that we're sharing our data with an EBSCO EDS instance (run by GALILEO) and they'd prefer real time results (because otherwise the results will be updated weekly) |
| 07:44 |
* csharp |
wonders if/how Dyrcona is dealing with it |
| 07:44 |
csharp |
we're wary of setting up z39.50 access because we don't want the extra load on our system for a neglible benefit |
| 07:44 |
bshum |
csharp: SRU will work |
| 07:45 |
csharp |
bshum: I was hunting documentation on SRU usage - do you know of a link? |
| 07:45 |
bshum |
csharp: Based on what I gleaned from http://evergreen-ils.org/dokuwiki/doku.php?id=evergreen-admin:sru_and_z39.50 |
| 07:45 |
bshum |
http://acorn.biblio.org/opac/extras/sru/CONS/holdings?version=1.1&operation=searchRetrieve&query=reeves-stevens&maximumRecords=0 |
| 07:45 |
bshum |
For example, is an SRU search against our system directly |
| 07:46 |
bshum |
Adding the CONS/holdings to the URL scoped it against holdings for the consortium |
| 07:46 |
csharp |
ah yes |
| 07:46 |
bshum |
And I can see the 852 tag data represented |
| 07:46 |
csharp |
yeah that works |
| 07:47 |
bshum |
Hope that helps. |
| 07:47 |
csharp |
bshum: it does - thanks! |
| 07:48 |
|
jboyer-isl joined #evergreen |
| 08:03 |
jcamins |
dbs++ |
| 08:15 |
|
akilsdonk_ joined #evergreen |
| 08:16 |
csharp |
bshum: do you know where I can find docs on SRU usage? or did you dig through SuperCat.pm? |
| 08:17 |
bshum |
csharp: Oh I just based the above on what was on the wiki already. I don't really know how the query use works ;) |
| 08:17 |
csharp |
ok |
| 08:21 |
bshum |
I have a feeling http://www.loc.gov/standards/sru/sru1-1archive/search-retrieve-operation.html might be informative. |
| 08:22 |
csharp |
ah - excellent |
| 08:22 |
csharp |
bshum: thanks as always |
| 08:25 |
bshum |
And http://www.loc.gov/standards/sru/specs/cql.html |
| 08:25 |
bshum |
csharp: That's linked to in the SuperCat.pm file itself. |
| 08:25 |
bshum |
So I assume that means it's related :) |
| 08:25 |
csharp |
great |
| 08:26 |
csharp |
well, what I'm looking for right now is a way to return a single record with holdings based on id (901c) |
| 08:26 |
csharp |
I guess tcn would work too in a pinch |
| 08:26 |
_bott_ |
There should not be an Ontario California. ...living in Michigan, Ontario, CA means something totally different to me. |
| 08:27 |
csharp |
heh - I never know there was an Ontario California |
| 08:28 |
graced |
_bott_ agreed - I once was on a plane going to Los Angeles and after we pushed back they said, Flight 555 to Ontario. I almost had a heart attack. Turns out that was a layover then we went to LA. |
| 08:29 |
* csharp |
has to fly back via Orlando from the hackaway |
| 08:29 |
paxed |
at least it's not Arlanda ... |
| 08:29 |
csharp |
seems like I could just parachute down en route ;-) |
| 08:32 |
|
kbeswick joined #evergreen |
| 08:34 |
bshum |
csharp: Well there's always stuff like http://acorn.biblio.org/opac/extras/unapi?id=tag:open-ils.org,2013-08-22:biblio-record_entry/606077/CONS&format=holdings_xml-full |
| 08:35 |
bshum |
The various format types are listed out around line 500 or so in SuperCat.pm |
| 08:35 |
csharp |
ah - that |
| 08:35 |
csharp |
's probably more what I'm after |
| 08:35 |
csharp |
glad I barked up the SRU tree though since I'm learning a lot ;-) |
| 08:35 |
bshum |
Yeah I'm sure there's a way to search the SRU for bib record ID though. |
| 08:35 |
bshum |
I imagine it's an identifier index |
| 08:36 |
csharp |
this is probably more straightforward given my current problem |
| 08:37 |
bshum |
yep, there's an identifier:bibid indexed |
| 08:37 |
bshum |
So there's probably a way to create an SRU search to match against that index. |
| 08:37 |
bshum |
But I'm glad you have options :) |
| 08:38 |
csharp |
yeah me too |
| 08:38 |
* bshum |
wanders off to the office (early today!) |
| 08:40 |
|
rfrasur joined #evergreen |
| 08:42 |
|
mmorgan joined #evergreen |
| 08:42 |
|
ericar joined #evergreen |
| 08:45 |
|
mrpeters joined #evergreen |
| 09:00 |
dbs |
csharp: just use the eg.id index |
| 09:00 |
dbs |
http://zed.concat.ca/opac/extras/sru/OSUL/holdings?version=1.1&operation=searchRetrieve&query=eg.id=123456 |
| 09:01 |
dbs |
if you just do http://zed.concat.ca/opac/extras/sru/ you'll see the list of supported indexes (although the names may look a little wonky) |
| 09:01 |
dbs |
(adjust zed for your hostname of choice, of course) |
| 09:02 |
dbs |
jcamins: koha-related karma? |
| 09:03 |
jcamins |
dbs: yup. |
| 09:03 |
jcamins |
I haven't looked at the branch yet, but the fact that it exists deserves karma. |
| 09:06 |
dbs |
It's a pretty small branch, in the end. rangi pointed me at the right place to start, and a couple of hours later huzzah |
| 09:22 |
csharp |
dbs++ # exactly what I was after |
| 09:24 |
|
kmlussier joined #evergreen |
| 09:25 |
bshum |
Close. |
| 09:27 |
|
yboston joined #evergreen |
| 09:30 |
dbs |
bshum++ |
| 09:35 |
pinesol_green |
[evergreen|Jason Etheridge] silence some unitialized warnings - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b7f13bf> |
| 09:35 |
rfrasur |
tabletop gaming resources are expensive |
| 09:35 |
* rfrasur |
didn't know |
| 09:42 |
|
mllewellyn joined #evergreen |
| 09:45 |
pinesol_green |
[evergreen|Lebbeous Fogle-Weekley] Acq: Honor new dist forumula fields in old method of applying formulae - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=baca6d3> |
| 09:46 |
|
jboyer-isl joined #evergreen |
| 09:47 |
* bshum |
apologizes for the incoming bug churn as we remove all targets for 2.2 (now that it's outside support window) |
| 09:54 |
|
pmurray_away joined #evergreen |
| 09:54 |
|
pmurray joined #evergreen |
| 09:54 |
rfrasur |
bshum++ |
| 09:59 |
kmlussier |
bshum++ |
| 09:59 |
kmlussier |
bug_churn-- |
| 10:00 |
csharp |
progress++ |
| 10:00 |
rfrasur |
progress++ |
| 10:19 |
|
mcooper joined #evergreen |
| 10:24 |
pinesol_green |
[evergreen|Dan Scott] Remove JSPAC-oriented PasswordReset.pm interface - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=eda67ed> |
| 10:28 |
pinesol_green |
[evergreen|Bill Erickson] Propagating 2.3.10 DB upgrade script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=170e5c8> |
| 10:33 |
|
ericar_ joined #evergreen |
| 10:35 |
|
RoganH joined #evergreen |
| 10:37 |
jboyer-isl |
Has anyone ever seen a single legacy script that fails to run? We've got issues with circ_permit_renew.js not getting a proper environment set up and dieing with a ReferenceError because log_vars isn't defined. |
| 10:39 |
jboyer-isl |
But not every time, seemingly only when the "COPY IS NEEDED FOR A HOLD" status is returned. |
| 10:39 |
dbs |
jboyer-isl: yeah, that sounds very familiar. |
| 10:39 |
dbs |
one sec... |
| 10:40 |
jcamins |
dbs: I like the InStoreOnly. |
| 10:40 |
|
mrpeters joined #evergreen |
| 10:41 |
dbs |
b3905c80d9bbfd13c2b5316ee34980b301e1c3f8 maybe? |
| 10:41 |
jboyer-isl |
dbs: even better, it seems to be limited to a specific location. |
| 10:41 |
* dbs |
will look for the equivalent non-conifer commit :) |
| 10:41 |
jboyer-isl |
I'll check that out. |
| 10:42 |
dbs |
d273da4d53d1b I think |
| 10:42 |
pinesol_green |
[evergreen|Dan Scott] Support script-based circ in nearest_hold() - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d273da4> |
| 10:42 |
dbs |
That was for 2.4, but depending on your backports etc it might affect you too |
| 10:44 |
dbs |
jcamins: yeah, I was pretty brief in the description, but the goal is to match as closely as possible the http://schema.org/Offer ontology so that library holdings could show up next to abebooks.com sales offers in enriched search results |
| 10:44 |
jboyer-isl |
dbs: thanks. we'll take a look. |
| 10:44 |
|
mrpeters joined #evergreen |
| 10:45 |
jcamins |
dbs++ # Google understands the schema.org markup! |
| 10:45 |
dbs |
Longer term we'd like to get schema.org to offer some more granular options in their ItemAvailability enumerations, but short term it seems like a reasonable compromise |
| 10:46 |
jcamins |
Agreed. I think I may have to borrow your markup for Biblionarrator. |
| 10:46 |
dbs |
jcamins: good, I'm getting better at this now that it's the third UI I've tackled :) |
| 10:46 |
|
mrpeters joined #evergreen |
| 10:46 |
dbs |
jcamins++ # please do! |
| 10:48 |
jcamins |
dbs: the non-XSLT details are kind of iffy. I'm comfortable signing off as-is, since the XSLT and "normal" modes have been diverging for a long time, with the XSLT consistently better in every way. But if you want to do a "normal" mode schema.org markup thing, I can hold off on signing off. |
| 10:50 |
dbs |
jcamins: huh, rangi didn't evenmention the "normal" mode, so let's avoid that. Let me add a commit to that to improve the subject markup, now that I've stared at it a little longer... |
| 10:51 |
jcamins |
Thanks. I was actually just about to ask about the subject markup. I initially didn't notice it because I was looking for basic bibligoraphic data. |
| 10:57 |
* dbs |
should go join #koha and stop spamming #evergreen - but I pushed another commit to improve the subject/keywords markup to my branch |
| 10:57 |
* jcamins |
will take a look. |
| 10:58 |
jboyer-isl |
Curses! it's starting to look like our problem is possibly autogen related. (problem at a single location, not everywhere, it was last run 3 days ago, etc.) |
| 11:00 |
jcamins |
dbs: looks a lot better, thanks. |
| 11:01 |
|
zerick joined #evergreen |
| 11:01 |
dbs |
jcamins: fwiw, there's some weird disconnect between the RDFa validators and Google Rich Snippets that gives me a little whiplash on issues like this. Trying to sort it out with the RDFa folks. |
| 11:08 |
rfrasur |
RoganH++ |
| 11:08 |
RoganH |
eh? |
| 11:08 |
rfrasur |
your email |
| 11:09 |
RoganH |
Sorry, that was 30 seconds ago, my head was on new stuff, lol. |
| 11:09 |
rfrasur |
no worries. same. |
| 11:10 |
rfrasur |
it still deserved good karma |
| 11:10 |
RoganH |
Thank you. |
| 11:14 |
|
Rish joined #evergreen |
| 11:17 |
bshum |
cupcakes++ |
| 11:18 |
* bshum |
could not allow it to be neutral karma |
| 11:18 |
pinesol_green |
[evergreen|Mike Rylander] Repair remaining Authority Fixed Field editor entries - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=43fd9c1> |
| 11:18 |
rfrasur |
Did Mary bring more experiments in? |
| 11:18 |
kmlussier |
I prefer cookies. Or ice cream. |
| 11:18 |
bshum |
rfrasur: I don't think so. I just happened to be toying with the @karma counting. |
| 11:19 |
rfrasur |
oh...I saw some of mllewellyn's cupcakes on FB and have nearly decided to move closer to her. |
| 11:19 |
rfrasur |
which is creepy and doesn't account for family/job/etc |
| 11:21 |
rfrasur |
kmlussier: ice cream, for sure |
| 11:24 |
eeevil |
grabbing 0820 |
| 11:25 |
mrpeters |
anyone know if there is a simple single server syslog-ng example config floating around anywhere? |
| 11:29 |
bshum |
Uh, sort of. |
| 11:29 |
bshum |
mrpeters: There's an example for rsyslog |
| 11:29 |
mrpeters |
i can live with that |
| 11:29 |
bshum |
syslog-ng is kind of dead beyond version 2 or 3 I think |
| 11:29 |
mrpeters |
right, i was just used to syslog-ng from ISL |
| 11:29 |
mrpeters |
im a blank slate here, i can use rsyslog |
| 11:30 |
bshum |
Yeah, in newer versions of Ubuntu and Debian, it got weird with the syntax |
| 11:30 |
bshum |
So I've been happy to make the switch to rsyslog |
| 11:30 |
bshum |
If you look for Open-ILS/examples/evergreen-rsyslog.conf that should help. |
| 11:32 |
pinesol_green |
[evergreen|Steven Callender] Remove [ and ] characters from seriestitle index LP#1187521 - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d8422ab> |
| 11:32 |
pinesol_green |
[evergreen|Mike Rylander] Stamping upgrade script for series title normalizer improvement - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4309de3> |
| 11:33 |
bshum |
mrpeters: You should just drop that into /etc/rsyslog.d/evergreen-rsyslog.conf and it should work once you restart rsyslog. |
| 11:34 |
bshum |
I haven't toyed with the logrotate one yet. |
| 11:34 |
mrpeters |
thanks bshum |
| 11:34 |
pinesol_green |
[evergreen|Bill Erickson] LP1183467 ACQ view funding source list permissions - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3df6b00> |
| 11:35 |
eeevil |
grabbing 0821 |
| 11:36 |
pinesol_green |
[evergreen|Thomas Berezansky] Fix A/T object cache - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=fb37e15> |
| 11:37 |
eeevil |
nevermind. giving back 0821. it'd be great if someone would look at https://bugs.launchpad.net/evergreen/+bug/1214560 ... master has the exact analog to that fix already, due to new features, and it's working in production. I can just keep applying it to productions sites until someone cares to look at it for commit. |
| 11:37 |
pinesol_green |
Launchpad bug 1214560 in Evergreen 2.4 "Browse normalization timing is incorrect" (affected: 1, heat: 6) [Undecided,New] |
| 11:39 |
|
dboyle joined #evergreen |
| 11:39 |
rfrasur |
hmm, is there a bug for breaking search in the staff client? |
| 11:40 |
bshum |
rfrasur: Depends on which kind of search you're talking about. (there's quite a few kinds) |
| 11:41 |
rfrasur |
bshum: well, I was shortcutting and just doing keyword searches sometimes w/ audience or w/o, but it seems like it got sick of me and just stopped returning results. I ended up having to go back to a "new search" and maybe refreshing it? |
| 11:42 |
rfrasur |
I dunno what kind of search it'd be...a little bit of everything? |
| 11:42 |
bshum |
That's an "advanced search" I suspect. |
| 11:42 |
pinesol_green |
[evergreen|Mike Rylander] Correctly mark nested INNER joins as such - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=80e3f6f> |
| 11:42 |
bshum |
vs. a basic search (the one public uses mostly) and "expert search" which has MARC stuff |
| 11:43 |
rfrasur |
well, it wasn't an expert search although I do tend to try and game it a little at times. |
| 11:43 |
rfrasur |
it wasn't a well organized search, so I guess I'll have to plan better next time, so I can see what's falling down. |
| 11:43 |
* rfrasur |
pushed a lot of buttons |
| 11:44 |
bshum |
eeevil: For that bug you'd like extra eyes on |
| 11:44 |
bshum |
eeevil: I'm trying to figure out how to replicate the issue/resolve it with testing :) |
| 11:44 |
bshum |
eeevil: And as I'm reading the upgrade script, it replaces a reingest function |
| 11:44 |
bshum |
Does that mean we need to reingest some bibs to see a change? |
| 11:45 |
eeevil |
no |
| 11:45 |
eeevil |
so, say you have a browse normalizer to push everything to upper case |
| 11:45 |
eeevil |
it's doing that well |
| 11:45 |
eeevil |
you have a field in marc that you type "BOOK" into |
| 11:46 |
eeevil |
it's stored as "BOOK" |
| 11:46 |
eeevil |
you type "magazine" into another record |
| 11:46 |
eeevil |
it's stored as "MAGAZINE" post-normalize |
| 11:46 |
eeevil |
in a third record, you put "book" |
| 11:47 |
eeevil |
well, because the current ingest function performs the normalization /AFTER/ it looks for a duplicate, it checks for a duplicate on "book" but tries to store "BOOK" |
| 11:47 |
eeevil |
queue explody record |
| 11:47 |
eeevil |
cue |
| 11:48 |
bshum |
Hmm |
| 11:48 |
eeevil |
IOW, we need to normalize the string we want to store /BEFORE/ we check the browse entry table for an existing, duplicate version |
| 11:48 |
eeevil |
we don't, before my patch is applied |
| 11:48 |
eeevil |
and the ingest fails |
| 11:48 |
eeevil |
after, we check for the right string and everything just works as intended |
| 11:49 |
eeevil |
see: same code in master, look for "prepped_value" |
| 11:53 |
|
jdouma joined #evergreen |
| 11:57 |
bshum |
Ah okay, value_prepped, I see it now :) |
| 11:58 |
bshum |
eeevil: Seems logical. How should we handle the number code in master? (tag it as a placeholder entry and note that it was a fix for 2.3/2.4 only?) |
| 12:03 |
eeevil |
bshum: I was going to create an empty placeholder for master |
| 12:03 |
eeevil |
that's what I've done in the past for (what amounts to) out-of-order fixes in back branches |
| 12:04 |
bshum |
Makes sense. |
| 12:04 |
bshum |
Should we make a 2.3.11 target to move that bug to though? Since berick already put 2.3.10 everywhere? |
| 12:04 |
bshum |
(that's just details) |
| 12:05 |
eeevil |
bshum: I think yes. I've been un-milestoning the ones that are committed today but were still pointing at 2.3.10 |
| 12:06 |
|
sseng joined #evergreen |
| 12:06 |
bshum |
I'll fix LP up real quick and then I'll go backport that fix for 2.3 and 2.4 for you. |
| 12:10 |
bshum |
Calling 0821 then. |
| 12:13 |
|
fparks joined #evergreen |
| 12:22 |
bshum |
eeevil: Should be set. |
| 12:22 |
pinesol_green |
[evergreen|Ben Shum] Add placeholder file for 0821 upgrade script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=347e376> |
| 12:28 |
berick |
senator++ bug 1215516 |
| 12:28 |
pinesol_green |
Launchpad bug 1215516 in Evergreen ".gitignore updates" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1215516 |
| 12:28 |
berick |
been meaning to do that |
| 12:29 |
eeevil |
bshum: awesome, thanks |
| 12:29 |
bshum |
senator++ indeed |
| 12:32 |
bshum |
eeevil: I went back and added milestone targets to 2.3.11 for the bugs you committed earlier today. |
| 12:32 |
bshum |
I'll do some more reshuffling of bug targets after I go warm up some lunch. |
| 12:33 |
eeevil |
bshum: thanks |
| 12:47 |
|
smyers_ joined #evergreen |
| 12:55 |
|
fparks_ joined #evergreen |
| 12:59 |
rfrasur |
@hates |
| 12:59 |
pinesol_green |
rfrasur hates MARC; mouthy teens; State of Indiana Department of Workforce Development online interface; stupid state bureaucracy; incessant adult responsibility; Internet Explorer; IE; little blue e; void; Microsoft; Adobe; Disney; Disney a lot; oxford university press hardcovers; and facets |
| 12:59 |
rfrasur |
@hate reports |
| 12:59 |
pinesol_green |
rfrasur: The operation succeeded. rfrasur hates reports. |
| 12:59 |
bshum |
@love Star Trek |
| 12:59 |
pinesol_green |
bshum: The operation succeeded. bshum loves Star Trek. |
| 12:59 |
rfrasur |
oh yes |
| 12:59 |
rfrasur |
@love phasers |
| 12:59 |
pinesol_green |
rfrasur: The operation succeeded. rfrasur loves phasers. |
| 12:59 |
rfrasur |
@love sonic screwdrivers |
| 12:59 |
pinesol_green |
rfrasur: The operation succeeded. rfrasur loves sonic screwdrivers. |
| 13:00 |
rfrasur |
@love quantum physics |
| 13:00 |
pinesol_green |
rfrasur: The operation succeeded. rfrasur loves quantum physics. |
| 13:04 |
|
dboyle_ joined #evergreen |
| 13:04 |
_bott_ |
Can anyone give me a quick thought on aged_circulation vs. circ history opt-in? ...seems they won't play nicely, but maybe I'm missing something. |
| 13:05 |
* dbs |
will be amused if his koha branch for schema.org bib+holdings gets merged before his evergreen branch :) |
| 13:05 |
jeff |
_bott_: i believe they will work okay together. |
| 13:05 |
jeff |
_bott_: iirc, circ history opt-in is implemented as a bucket. |
| 13:05 |
_bott_ |
oh? |
| 13:05 |
jeff |
_bott_: of course, my iirc might be inaccurate. looking. |
| 13:07 |
jeff |
nope. it changed from a bucket. it was, but is no longer. |
| 13:08 |
_bott_ |
I assumed it went action.circulation direct |
| 13:11 |
jeff |
yeah, it used to be a biblio bucket, now it's using action.usr_visible_holds in the db. |
| 13:12 |
jeff |
er, s/holds/circs/ :-) |
| 13:13 |
_bott_ |
right. hmm... so aging any circs newer than the oldest retention_start would be bad |
| 13:14 |
jeff |
there might be a stop for that already. have you looked at the code that ages circs to see if it avoids aging circs on users with retention turned on? |
| 13:14 |
jeff |
that would be my next step. |
| 13:14 |
jeff |
then a wishlist / bugfix to have the aging pay attention to the user circ retention settings. |
| 13:14 |
jeff |
(if not already handled) |
| 13:16 |
_bott_ |
was looking at doing some manual initial aging (i.e. deleting from action.circulation and relying on trigger), just trying not to break anything in the process |
| 13:19 |
csharp |
_bott_: we just did a large manual "aging" back in the spring |
| 13:19 |
csharp |
we aren't using automatic aging at this poing |
| 13:19 |
csharp |
point |
| 13:20 |
csharp |
@blame poing |
| 13:20 |
pinesol_green |
csharp: poing stole csharp's ice cream! |
| 13:20 |
_bott_ |
...a day for ice cream, apparently |
| 13:20 |
rfrasur |
csharp:what's the reasoning behind now using automatic aging? |
| 13:20 |
rfrasur |
s/now/not |
| 13:21 |
_bott_ |
no reasoning on my end, just something that's never been done |
| 13:21 |
csharp |
rfrasur: doing it manually allows us to preserve a full copy of what's getting deleted in production in case we need to load it into an archival DB |
| 13:21 |
csharp |
(which we have had to do from time to time) |
| 13:22 |
rfrasur |
I see. |
| 13:35 |
|
fparks joined #evergreen |
| 13:38 |
|
asimon joined #evergreen |
| 13:39 |
asimon |
We have a new Evergreen system with two bricks pointing to a database server. The bricks stop responding after a while, and the logs seem to indicate that it is a problem with the cstore process hitting a (too-low) limit. Does anyone know where I might find that parameter? |
| 13:41 |
bshum |
asimon: cstore max_children is defined in opensrf.xml configuration. |
| 13:41 |
jboyer-isl |
asimon: /openils/conf/opensrf.conf is where most of them are. There are separate entries for different services. |
| 13:41 |
bshum |
A general warning, increasing that number beyond a certain point means having to increase the number of connections for postgresql. Or using some sort of postgresql pooling technique. |
| 13:42 |
bshum |
"that number" being the number of children defined for each opensrf.xml service. |
| 13:44 |
jboyer-isl |
Yeah, just picking something like oh, 300, without checking around to make sure it's ok will make you have a bad day. |
| 13:44 |
* jboyer-isl |
might have had a bad day |
| 13:44 |
* bshum |
definitely did. |
| 13:45 |
bshum |
It was the first thing we noticed to go wrong during real production use with our 1st generation bricks and DB server. |
| 13:46 |
bshum |
berick: senator: Should .gitignore ignore also products of various things? |
| 13:47 |
bshum |
For example: Open-ILS/xul/staff_client/external/libmar/tool/mbsdiff |
| 13:47 |
bshum |
Which I think is created when you actually build the clients out. |
| 13:47 |
bshum |
I've often wondered that for the xulrunners and JS stuff too. |
| 13:48 |
berick |
bshum: yeah, anything we don't push into the repo |
| 13:48 |
senator |
agreed |
| 13:50 |
bshum |
I can try my hand at adding a few more things to .gitignore then. And sign off on what you two have started. |
| 13:51 |
berick |
bshum++ |
| 13:51 |
|
kitteh joined #evergreen |
| 13:58 |
asimon |
bshum: The cstore settings in opensrf.xml in our new Evergreen system match the settings in our old Evergreen system. Are you saying that the max_children in the other services also relate to cstore? |
| 14:00 |
|
smyers__ joined #evergreen |
| 14:02 |
phasefx |
dbs: berick: re: live_t/ and Cronscript.pm, do we only want to move subs to Cronscript when they are actually re-used across tests, or simply if they might get re-used? I'm thinking about create_closed_date and delete_closed_date in 04-overdue_with_closed_dates.t |
| 14:03 |
berick |
phasefx: i think no on those 2 |
| 14:03 |
berick |
those 2 examples, i mean |
| 14:03 |
bshum |
asimon: Can you share a snippet of your logging that made you look for these settings? |
| 14:03 |
bshum |
Maybe it's a postgres config issue and not an Evergreen one. |
| 14:03 |
phasefx |
roger that. If someone does make another test, maybe those should go into a new library altogether |
| 14:06 |
|
fparks joined #evergreen |
| 14:10 |
dbs |
phasefx: agreed with you and berick on that. Cronscript is meant for stuff that would often be used in real scripts; if there are test-specific methods that won't be used in production but will be reusable in test scripts, then a TestUtils.pm or the likes would make sense as a home for those |
| 14:13 |
phasefx |
so far I have put register_workstation, do_checkin, and do_checkout into Cronscript |
| 14:13 |
phasefx |
those seem like they could stay there |
| 14:14 |
berick |
hmm, if a TestUtils.pm is made, that would be a better place for those, imo |
| 14:15 |
phasefx |
I'll go ahead and make a TestUtils.pm then; the idea is that it would be an installed perl module? not something that gets loaded out of the source tree? |
| 14:16 |
berick |
not sure what dbs had in mind, exactly, but I don't think it would hurt to install it. but it would be loaded from source (for make check), i assume |
| 14:18 |
phasefx |
these particular tests assume a running instance of EG as it is |
| 14:18 |
berick |
ah, right |
| 14:18 |
phasefx |
and don't get called during make check |
| 14:18 |
berick |
in which case, scratch my load-from-source comment |
| 14:18 |
berick |
installing it along w/ the rest makes sense to me |
| 14:19 |
phasefx |
my problem with load-from-source (and I'm definitely doing something wrong when I try it) is that I could get it to work with either make livecheck, or from invoking the scripts directly out of live_t/, but not both. Some path/working-dir issue |
| 14:21 |
phasefx |
that's when I was trying to use oils_header.pl |
| 14:26 |
phasefx |
objections to me making TestUtils a subclass of Cronscript? |
| 14:30 |
pastebot |
"asimon" at 204.193.129.146 pasted "bshum: Here are two lines from early this morning." (2 lines) at http://paste.evergreen-ils.org/24 |
| 14:40 |
|
dbs joined #evergreen |
| 14:40 |
|
stevenyvr2 joined #evergreen |
| 14:44 |
rfrasur |
Offhand, has there been any wishlisting for clone/edit MARC records? |
| 14:46 |
phasefx |
I'd like to see the merge UI let you cherry-pick tabs from subordinate records to merge into the lead record, but not sure if I launchpadded that. No tuits for actually doing it |
| 14:46 |
RoganH |
I'd like to wishlist an artificial intelligence to edit our MARC records |
| 14:46 |
phasefx |
originally, PINES wanted to make it difficult to "clone" records |
| 14:46 |
RoganH |
But with my luck I'd end up with Microsoft's Clippy doing it. |
| 14:46 |
phasefx |
it's easy to work around these days with the flat text editor |
| 14:46 |
rfrasur |
RoganH++ |
| 14:47 |
rfrasur |
phasefx: yeah, and I like the flat text editor. asking for others. |
| 14:47 |
* rfrasur |
can imagine a happy cloner completely undoing deduping |
| 14:47 |
phasefx |
I think better MARC template management would be cool, moving it out of the config files and filesystem and into the database |
| 14:47 |
rfrasur |
In which case, bshum's phaser could prove particularly handy |
| 14:48 |
mrpeters |
bshum++ for fixing my rsyslog stupidity |
| 14:48 |
phasefx |
just put a permission in front of easy cloning |
| 14:48 |
mrpeters |
love this little guy ;) |
| 14:48 |
rfrasur |
phasefx: that's a good idea |
| 14:48 |
* phasefx |
is about 50/50 on good ideas |
| 14:48 |
rfrasur |
well, just throwing it out there. Not sure if it's a big enough deal to make a big deal about it. |
| 14:49 |
* rfrasur |
likes it the way it is. |
| 14:51 |
bshum |
asimon: Hmm, that looks more like some sort of disconnect. Are you sure Evergreen services are still running on your bricks? and/or some weird reboot or disconnect in your server/network architecture. |
| 14:51 |
bshum |
I've seen that sort of error when a box of mine rebooted spontaneously and I didn't go restarting open-ils services properly. |
| 15:11 |
asimon |
bshum: No, my VMs have not rebooted. I do have to restart the Evergreen services to get the system to respond. |
| 15:11 |
bshum |
asimon: What kind of virtualization is being used? |
| 15:11 |
bshum |
(just curious, shouldn't be related) |
| 15:12 |
asimon |
bshum: XenServer 6.2 |
| 15:13 |
|
stevenyvr2 joined #evergreen |
| 15:17 |
bshum |
Hmm |
| 15:18 |
bshum |
I wonder if there's anything in your logs if you backtrace further to right before the problems begin. |
| 15:18 |
asimon |
bshum: I'll take another look. |
| 15:18 |
bshum |
Cause this all just seems like something is not in sync, either the VMs or the database being reset. |
| 15:24 |
rangi |
dbs++ |
| 15:44 |
|
Joe_L joined #evergreen |
| 15:47 |
bshum |
But of course, the first sample bib I pick doesn't work correctly |
| 15:48 |
|
ericar joined #evergreen |
| 15:48 |
bshum |
dbs: So I installed the commits from bug 1214012 to test the schema.org stuff and then went to that google.com page to test site pages directly to see. |
| 15:48 |
pinesol_green |
Launchpad bug 1214012 in Evergreen "Schema.org enhancements: holdings and RDFa Lite" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1214012 |
| 15:49 |
bshum |
The first bib I tried, which was 27 in the concerto fed me a "Error: Incomplete rdfa with schema.org." at the end of the entries. |
| 15:49 |
bshum |
Though I'm still reading up to figure out what that means exactly. |
| 15:50 |
bshum |
Going to go do some more reading now. |
| 15:57 |
Joe_L |
Question: I'm working on configuring action-trigger events and responses, specifically sending an email when an item is one day overdue. The action_trigger.event database table shows events marked as 'complete', but no emails were sent. |
| 15:57 |
Joe_L |
Is there a log somewhere I can check? |
| 16:00 |
paxed |
perhaps /var/log/mail.err etc |
| 16:01 |
paxed |
also, test if you send mail manually from the server command line |
| 16:04 |
Joe_L |
That's where things get hairy. I'm using an SMTP server which, for IPs within the private LAN doesn't need authentication. So I'll enter, for example, mail.orgx.com as the SMTP server name in /openils/conf/opensrf.xml but there aren't any spaces for port or encryption. None is necessary for this test, but the config options are very spartan. |
| 16:06 |
jeff_ |
my suggestion at this point would be that if you need to authenticate to an SMTP server, you use a local SMTP server to perform that authentication -- have your local MTA listen on localhost only, accept everything, and relay it to a remote relay/smarthost using the credentials/etc required. |
| 16:08 |
Joe_L |
The oddity is that for servers on this particular LAN there isn't authentication or even encryption required. I suppose my question is whether there's a documented function-call-stack visible anywhere for what happens during the "sendEmail" reactor execution. |
| 16:09 |
Joe_L |
at least something I can trace along and see where the failure is appearing. |
| 16:10 |
phasefx |
Joe_L: still useful to have a local MTA, if you don't have transparency/log access to the remote SMTP server |
| 16:11 |
Joe_L |
Fair advice. What's the best configuration for opensrf.xml when using a local MTA? "localhost" for the smtp server, or something like "localhost:25"? |
| 16:12 |
phasefx |
default is localhost |
| 16:13 |
Joe_L |
phasefx: alrightie, I'll give it a shot and see what happens. Thanks! |
| 16:13 |
Joe_L |
phasefx: certainly couldn't hurt at this point. :-) |
| 16:26 |
Joe_L |
phasefx: *facepalm* thanks for being the voice of reason and settling my frustration. Turns out that in my haze of trial-and-error I'd forgotten to reset opensrf. It's always the small things. :) |
| 16:28 |
phasefx |
Joe_L: oy |
| 16:30 |
Joe_L |
Although that does beg a question.... if action_trigger_runner.pl is running on a cron job and, for some reason, opensrf isn't running for some reason at the time of cron execution, will ATR check for the opensrf process and gracefully abort or will it... die in a burst of flames, sparks, and error log messages? |
| 16:33 |
bshum |
If opensrf isn't running, it'll usually say so when trying to kick off the cron. (which is super fun when it's scripted to run every 15 minutes like it is in our utility server). |
| 16:33 |
bshum |
And it doesn't actually do anything as far as I'm aware. |
| 16:33 |
phasefx |
Exception: OpenSRF::EX::Session 2013-08-22T17:30:42 main /openils/bin/action_trigger_runner.pl:240 Session Error: router private.localhost/opensrf.settings IS NOT CONNECTED TO THE NETWORK!!! |
| 16:33 |
bshum |
^-- yeah, that thing. |
| 16:33 |
bshum |
:( |
| 16:33 |
phasefx |
you'd likely get that in your mail spool |
| 16:35 |
Joe_L |
Ah, well at least it's not as ugly as when the server crashes while opensrf is running. That took a bit of research to get osrf up again. At least this can be solved by a wrapper script. Thanks! |
| 16:36 |
Joe_L |
Kudos for cron jobs that don't spawn lock files then crash before clean-up. :D |
| 16:37 |
bshum |
Well |
| 16:37 |
bshum |
If services die mid run |
| 16:37 |
bshum |
Wouldn't that require going into the a/t event table and resetting things so that the process can complete. |
| 16:37 |
bshum |
Otherwise, it might stay stuck on those events waiting for a process that's gone. |
| 16:39 |
Joe_L |
touche. Are there state flags for each event besides "pending" and "complete"? |
| 16:39 |
bshum |
Yeah, there's a few. |
| 16:40 |
bshum |
They're listed in the definition constraint |
| 16:40 |
bshum |
But basically:, pending, invalid |
| 16:40 |
bshum |
found, collecting, collected, validating, valid, reacting, reacted, cleaning, complete |
| 16:41 |
bshum |
And error. |
| 16:42 |
Joe_L |
Well that would simplify troubleshooting, at least, and make it simpler to reset the failed jobs to 'pending' if worse came to worse. Is there developer documentation anywhere on where in the process workflow each flag is set? |
| 16:43 |
* bshum |
doesn't know off hand, but doubts it. |
| 16:47 |
Joe_L |
Fair enough. Still, this is a huge step forward. Thanks again! |
| 16:57 |
jeff_ |
phasefx++ |
| 16:57 |
jeff_ |
bshum++ |
| 16:57 |
jeff_ |
Joe_L++ |
| 16:57 |
jeff_ |
:-) |
| 17:03 |
|
mmorgan left #evergreen |
| 17:09 |
Joe_L |
bshum: I was doing some testing and managed to force every event in the series into an ' |
| 17:09 |
Joe_L |
'error' state, but the emails still sent. Where are errors logged? |
| 17:32 |
dbs |
bshum: how did you test with the rich snippets tool - copy and paste, or pointing at a bib via a URI? |
| 17:39 |
Joe_L |
I'll continue testing tomorrow and see what scenarios break this script. Thanks again for the debugging help and have a great night! |
| 17:41 |
dbs |
bshum: as far as I can tell, it's an undocumented expectation that the Offer type will always have a given property that I haven't given. quite possibly a bug in the rich snippets tool. |
| 17:42 |
dbs |
(not just saying that defensively; the RDFa folk have complained about the quality of the rich snippets tool parsing a number of times before) |
| 17:59 |
* dbs |
figures out what el Goog wants: it wants a "price" attribute, and "your soul" isn't good enough, it wants at least one integer; but "your s0ul" works just fine. but two integers separated by any non-integer other than a "." or "," is RIGHT OUT |
| 17:59 |
dbs |
stupid google |
| 18:01 |
eby |
@blame metadata |
| 18:01 |
pinesol_green |
eby: metadata stole eby's ice cream! |
| 18:01 |
dbs |
since I can't just put in "$0.00", I guess sorting out asset.copy.deposit / asset.copy.deposit_amount comes into play |
| 18:03 |
hopkinsju |
Can anyone tell me where the default hold notification phone number is stored in the db? We have a library that's reporting the wrong number printing on pickup slips and I"m trying to track it down. |
| 18:03 |
hopkinsju |
I don't suppose anyone else has seen that problem? |
| 18:04 |
bshum |
dbs: I used the URL you provided and then submitted my test server URL and record page. |
| 18:04 |
bshum |
Err, test server's record page URL |
| 18:05 |
bshum |
dbs++ for showing us the way |
| 18:05 |
bshum |
hopkinsju: Hold notification phone number for the patron? |
| 18:06 |
hopkinsju |
bshum: yessir |
| 18:06 |
bshum |
hopkinsju: If so, that's a per hold deal |
| 18:06 |
hopkinsju |
But the default is stored in their preferences. |
| 18:06 |
bshum |
Ah, gotcha. |
| 18:06 |
hopkinsju |
The library reports that it's "happening more and more" which makes me think it has to do with the stored default |
| 18:06 |
bshum |
That's probably a string in actor.usr_setting |
| 18:06 |
hopkinsju |
Since the users are becoming more used to the ability. |
| 18:06 |
bshum |
I don't remember the type off the top of my head |
| 18:07 |
hopkinsju |
Ok, that's what I thought too. Maybe I need to look at more/different users then. |
| 18:07 |
bshum |
Hmm |
| 18:08 |
bshum |
Yep |
| 18:08 |
bshum |
The name of the setting is "opac.default_phone" |
| 18:09 |
hopkinsju |
Yeah, I was just about to say the same thing. |
| 18:09 |
bshum |
You could grab the user ID for that patron, and then do a quick scan like "SELECT * FROM actor.usr_setting WHERE usr = XXX; " and see if they have that setting. |
| 18:09 |
hopkinsju |
Unfortunately I'm not seeing the suspect phone numbers anywhere in there. |
| 18:09 |
bshum |
Then it sounds like user error to me. |
| 18:09 |
bshum |
:) |
| 18:10 |
bshum |
Or possibly some weird browser thing |
| 18:10 |
hopkinsju |
*could* be, but the phone numbers actually do belong to other users in the same OU |
| 18:10 |
bshum |
Though I don't think we allow saved values for that field. Haven't checked lately. |
| 18:10 |
bshum |
Maybe some staff member is toying with you :) |
| 18:10 |
bshum |
And putting down holds with the wrong numbers. |
| 18:10 |
* dbs |
writes a mini-novel on bug 1214012 |
| 18:10 |
pinesol_green |
Launchpad bug 1214012 in Evergreen "Schema.org enhancements: holdings and RDFa Lite" (affected: 1, heat: 6) [Wishlist,Triaged] https://launchpad.net/bugs/1214012 - Assigned to Ben Shum (bshum) |
| 18:11 |
bshum |
dbs: Heh, it's a good explanation. |
| 18:11 |
hopkinsju |
bshum: Well, thanks man, I'm going to call it day and revisit this. |
| 18:11 |
bshum |
I'll commit the changes after dinner. |
| 18:11 |
hopkinsju |
Yes, people love playing with me :) |
| 18:11 |
bshum |
hopkinsju: Good luck over there. |
| 18:12 |
hopkinsju |
bshum: You to! Holla! |
| 18:12 |
* hopkinsju |
toos |
| 18:12 |
dbs |
bshum: good eyes though. I honestly never noticed that little red message at the bottom. Guess I'm used to the W3 validators throwing HUGE H1 RED BACKGROUND ERROR messages when things go awry |
| 18:12 |
dbs |
bshum++ |
| 18:12 |
bshum |
dbs: It's just my luck that the first 5 records I tried gave me that error |
| 18:13 |
bshum |
Before I went back and found the bib example you referenced in yours to verify that it didn't do that *every* time |
| 18:13 |
bshum |
But yes, right after dinner :D |
| 18:13 |
dbs |
bshum: huh, weird. maybe it's something that switched over today, then. There was a brief period of time that the Rich SNippets tool wasn't working today... |
| 18:14 |
dbs |
bshum: yes, me too :) |
| 18:18 |
|
zerick joined #evergreen |
| 19:23 |
bshum |
dbs: Last commit looks good to me. Happy to sign off and commit unless you're still tweaking things. |
| 19:26 |
jcamins |
bshum: watch out. dbs said he was done, and then sent me another three commits. |
| 19:26 |
jcamins |
:) |
| 19:27 |
bshum |
jcamins: Heh, I've done my fair share of that too. |
