| Time |
Nick |
Message |
| 01:03 |
|
bmills joined #evergreen |
| 01:49 |
|
tsbere_ joined #evergreen |
| 01:51 |
|
tsbere__ joined #evergreen |
| 04:11 |
|
dbwells_ joined #evergreen |
| 06:29 |
|
dcook__ joined #evergreen |
| 07:39 |
|
collum joined #evergreen |
| 07:45 |
|
jboyer-isl joined #evergreen |
| 07:47 |
|
rjackson_isl joined #evergreen |
| 07:53 |
|
mrpeters joined #evergreen |
| 08:09 |
|
dcook joined #evergreen |
| 08:29 |
|
ericar joined #evergreen |
| 08:29 |
|
Dyrcona joined #evergreen |
| 08:42 |
|
mmorgan joined #evergreen |
| 08:56 |
|
jwoodard joined #evergreen |
| 08:56 |
Dyrcona |
Think I'll sign out. |
| 08:57 |
Dyrcona |
When I hook up the second monitor it messes with my workspaces and programs, like Pidgin, that open multiple windows sometimes get split over different work spaces. |
| 09:18 |
|
maryj joined #evergreen |
| 09:26 |
|
RoganH joined #evergreen |
| 09:48 |
|
yboston joined #evergreen |
| 09:52 |
|
Dyrcona joined #evergreen |
| 09:53 |
|
gmcharlt joined #evergreen |
| 09:54 |
csharp |
I'm noticing the action_trigger.event_params entry "max_delay_age" for the default overdue notice example, but I don't see that it ever gets consulted anywhere - I'm I correct to think that it's unused? |
| 09:56 |
csharp |
actually, I don't see that event_params are consulted anywhere, but I'm working under the assumption that I'm missing something |
| 10:06 |
berick |
csharp: hm, yeah, there's a validtor that references it in the DB, but said validator does not exist. I believe it was replaced with action_trigger.event_definition.max_delay |
| 10:16 |
csharp |
berick: cool - thanks |
| 10:42 |
Bmagic |
anyone know off hand which date the "Negative Balance Interval" the code respects? money.payment? |
| 10:43 |
Dyrcona |
Not off-hand, I'd have to look. |
| 10:44 |
Bmagic |
no problem, im looking now |
| 10:46 |
|
bmills joined #evergreen |
| 10:48 |
Bmagic |
Dyrcona: it looks like it's money.payment from this line my $last_payment = $e->search_money_payment(..... then return 1 if ($payment_ts + $interval_secs >= $now); |
| 10:50 |
Dyrcona |
I thought so, but wasn't sure any more. |
| 10:50 |
kmlussier |
That's my recollection from testing. |
| 10:56 |
|
maryj joined #evergreen |
| 11:01 |
|
Christineb joined #evergreen |
| 11:10 |
Bmagic |
Does anyone have a library that controls access to the public workstations via login? That uses SIP backend? |
| 11:10 |
jeff |
yes. |
| 11:10 |
jeff |
many, including us. |
| 11:10 |
jeff |
well, depending on what you mean by "via login" |
| 11:10 |
Bmagic |
We have more than one library complaining that it requires that you login 2 times in order for it to work. We figured out that it's because the CASSIE system doesnt wait long enough for our server to respond |
| 11:11 |
jeff |
i am not very familiar with CASSIE. |
| 11:11 |
jeff |
others here may be. |
| 11:11 |
Bmagic |
if our server doesnt respond within 1 second, it gives up! |
| 11:11 |
jeff |
how long is your SIP server taking to respond? |
| 11:11 |
jeff |
that seems... harsh. |
| 11:11 |
Bmagic |
the second login always works because by then, the server had already done the work and presumably the query results are cached in postgres |
| 11:12 |
Dyrcona |
Bmagic: We have a couple of libraries that use CASSIE and they've not complained about double logins. |
| 11:13 |
Bmagic |
I have remote controlled their CASSIE software and dug around for some settings related to timeout and found nothing. At this point, I am telling the libraries that it's CASSIE's issue and they need to fix their software |
| 11:13 |
Bmagic |
I thought perhaps I would as here in IRC, because there might be a way to speed up our server? |
| 11:13 |
jeff |
Bmagic: this appears to be the correct course of action. :-) |
| 11:14 |
Bmagic |
Does anyone have stats on number of nanoseconds for the patron lookup via SIP? |
| 11:16 |
Dyrcona |
Bmagic: No, but you might be able to figure it out from the logs. osrfsys.log does log response times for backend calls. |
| 11:16 |
Dyrcona |
Bmagic: nanoseconds is being over optimistic. |
| 11:17 |
Bmagic |
right on - I have numbers but I was wondering if I could compare them to someone else's numbers |
| 11:18 |
dbs |
3m complained about the speed (or lack thereof) of our SIP server, but that was a few years ago |
| 11:20 |
miker |
Bmagic: I suspect that CASSIE is being silly and not holding the staff-level connection open, and the timeout is because it's having to reauthenticate the CASSIE instance and /then/ the patron on the first try. SIP2 is meant to use long-term (as in, as long as the serial cable is physically connected and both client and server are powered on) connections. then comes TCP/IP and dumb clients... |
| 11:20 |
Bmagic |
in the SIP logs, I can see the time between the 63 input and the 64 output - the example I am looking at was less than a second |
| 11:20 |
Bmagic |
miker: yes! That is what I was thinking too |
| 11:21 |
Bmagic |
ok thanks everyone for helping me think this through. I think that I have decided that it's not us |
| 11:24 |
Dyrcona |
So, the websockets apache and the regular apace are orthogonal to each other, i.e. I don't have to restart the former because I restarted the latter, right? |
| 11:25 |
berick |
Dyrcona: right. generally only have to restart websockets after a code update/install |
| 11:26 |
berick |
or an ejabberd restart |
| 11:27 |
Dyrcona |
berick: Thanks! |
| 11:27 |
Dyrcona |
Oh. what about after osrf_control --restart-all? |
| 11:29 |
berick |
Dyrcona: i would not expect that to require a websocket restart, though looking back at my local scripts, I see that I do restart it, i guess just to be safe. |
| 11:29 |
Dyrcona |
OK. Thanks, again. |
| 11:29 |
berick |
WS only talks to osrf when a request is in progress. otherwise it's just setting on a jabber socket waiting. |
| 11:32 |
kmlussier |
IIRC, Sitka is using Postgres 9.4 in production. Is anyone else using 9.4? |
| 11:33 |
RoganH |
not I said the little red hen |
| 11:34 |
jboyer-isl |
We’ve only been on 9.3 for a couple of weeks. (Always the on stable branch, never on master.) |
| 11:36 |
jboyer-isl |
That bridesmaid reference made more sense before I actually typed it out… |
| 11:36 |
berick |
heh |
| 11:40 |
kmlussier |
jboyer-isl: I got the reference. :) |
| 11:41 |
Dyrcona |
We use 9.3 in production and 9.1 on development/training. |
| 11:42 |
Dyrcona |
'Cause we've been too lazy to upgrade the second db server. |
| 11:52 |
csharp |
kmlussier: we're moving to 9.4 this weekend - been testing on it for months on two test servers with no issues |
| 11:53 |
kmlussier |
csharp: Awesome! I'll be interested in hearing how things go in production. |
| 12:51 |
jeff |
_bott_: is GRPL also running 9.4 in production? |
| 12:52 |
dbwells_ |
kmlussier: We've been on 9.4 in production since 12/22. So far, so good. |
| 12:53 |
kmlussier |
dbwells: Good to hear! Any pitfalls you came across when upgrading? |
| 12:55 |
dbwells |
kmlussier: We moved to a new server at the same time, so it was a complete dump and reload. Everything went smooth, IIRC. |
| 13:08 |
berick |
jeff: how's your mobile app elastic search experiment been holding up? |
| 13:12 |
jeff |
very well so far. just getting back into some of it after some time off. |
| 13:12 |
jeff |
we've moved on to in-building catalog terminals. |
| 13:12 |
berick |
jeff: how are you managing bib updates? is it real time or in batch? |
| 13:12 |
* berick |
can't remember the details |
| 13:12 |
jeff |
incrementals every X minutes. |
| 13:12 |
berick |
gotcha |
| 13:12 |
berick |
glad it's going well |
| 13:19 |
_bott_ |
jeff: Yes, since April 2015 |
| 13:20 |
jeff |
_bott_: any gotchas or issues that you recall? |
| 13:20 |
_bott_ |
Nope, things have run well |
| 13:23 |
jeffdavis |
We've been running 9.4 for a while as well. No issues unless you count bug 1499086, which is probably not 9.4-specific. |
| 13:23 |
kmlussier |
Thanks _bott_! Good to hear! And thanks jeff for poking _bott_ with my question! |
| 13:24 |
kmlussier |
Hmmm...pinesol_green appears to be MIA |
| 13:25 |
jeffdavis |
https://bugs.launchpad.net/evergreen/+bug/1499086 - bad PG query plan causing very slow load times for bookbags |
| 13:41 |
jeffdavis |
Is webstaff.pot auto-generated, or should I add an entry to it if I add a translatable string to a web client template? |
| 13:42 |
berick |
jeffdavis: it's auto generated from the templates |
| 13:42 |
berick |
as long as you use l(...) |
| 13:42 |
jeffdavis |
thanks! |
| 13:43 |
Dyrcona |
jeffdavis: If you're doing this for your local benefit, you will need to run make newpot in build/i18n |
| 13:43 |
csharp |
kmlussier: I'm looking into the bot, FYI |
| 13:43 |
kmlussier |
csharp++ |
| 13:43 |
* Dyrcona |
has been messing with translations this week. |
| 13:43 |
kmlussier |
It almost feels as if bshum has already left us. :( |
| 13:44 |
Dyrcona |
IIRC, today is his last day with biblio. |
| 13:44 |
* kmlussier |
nods |
| 13:44 |
dbs |
:( |
| 13:44 |
kmlussier |
That's why I didn't bother him about the bot. I figured he was busy cleaning out his desk. Though, having seen his desk, I imagine there's not much cleaning to be done. |
| 13:44 |
Dyrcona |
jeffdavis: Though make install_all_locales in the same place will build newpot for you. |
| 13:45 |
Dyrcona |
Someone is leaving our office this week, too. |
| 13:45 |
Dyrcona |
Though she's not involved in the ILS part of operations. |
| 13:45 |
jeffdavis |
Dyrcona: understood, thank you. |
| 13:46 |
Dyrcona |
When we install from git for production, we install the translations as well. |
| 13:46 |
Dyrcona |
I've been preparing for our next upgrade, and I added something that caused me to have to add to build/i18n/Makefile, so it's all fresh in my mind for a change. |
| 13:47 |
|
pinesol_green joined #evergreen |
| 13:48 |
csharp |
@dunno |
| 13:48 |
pinesol_green |
csharp: I see nothing, I know nothing! |
| 13:49 |
jeffdavis |
I'm working on a new feature in the staff client. We're not using the web client locally yet, but if I am adding it there for feature parity, I guess I'd better know how to test it. :) |
| 13:49 |
csharp |
@quote random |
| 13:49 |
pinesol_green |
csharp: Quote #67: "< Rogan_Ni> Star Wars" (added by berick at 01:38 PM, September 17, 2013) |
| 13:49 |
Dyrcona |
csharp++ |
| 13:49 |
kmlussier |
Dyrcona: What? Who is leaving? |
| 13:49 |
Dyrcona |
kmlussier: Laura. |
| 13:49 |
csharp |
I upgraded limnoria |
| 13:49 |
csharp |
(fwiw) |
| 13:53 |
Dyrcona |
jeffdavis++ |
| 13:53 |
Dyrcona |
New features are nice. |
| 13:53 |
csharp |
bug 1499086 |
| 13:53 |
pinesol_green |
Launchpad bug 1499086 in Evergreen 2.9 "Slowness/timeout on loading bookbags in OPAC" [Medium,Triaged] https://launchpad.net/bugs/1499086 |
| 14:01 |
|
jlitrell joined #evergreen |
| 14:21 |
|
alynn26 joined #evergreen |
| 14:23 |
|
jihpringle joined #evergreen |
| 15:11 |
|
edoceo joined #evergreen |
| 15:30 |
|
jihpringle joined #evergreen |
| 15:35 |
|
jeff___ joined #evergreen |
| 15:48 |
bshum |
"And now his watch is ended." |
| 15:49 |
jboyer-isl |
bshum++ |
| 15:50 |
Dyrcona |
bshum++ |
| 15:51 |
dbs |
bshum++ |
| 15:52 |
dbs |
Go do (more) great things |
| 15:52 |
jeff |
bshum++ |
| 15:53 |
berick |
bshum++ |
| 15:53 |
|
ericar_ joined #evergreen |
| 15:59 |
csharp |
bshum++ |
| 15:59 |
csharp |
@karma |
| 15:59 |
pinesol_green |
csharp: Highest karma: "kmlussier" (189), "Dyrcona" (185), "bshum" (148), "berick" (134), and "jeff" (129). Lowest karma: "iii" (-12), "ie" (-7), "SIP" (-7), "typos" (-6), and "marc" (-4). You (csharp) are ranked 9 out of 273. |
| 15:59 |
bshum |
csharp++ # bot wrangling |
| 16:00 |
bshum |
Anything fun in the upgrade? |
| 16:00 |
csharp |
bshum: no fun right now :-( - I'm in the weeds with action triggers |
| 16:01 |
csharp |
basically we're pulling in all the 2.8 + 2.9 goodness |
| 16:01 |
csharp |
moving to the new multiplex-able SIP server |
| 16:01 |
bshum |
Busy busy |
| 16:04 |
kmlussier |
bshum++ bshum++ bshum++ |
| 16:04 |
|
ericar_ joined #evergreen |
| 16:05 |
mmorgan |
bshum++ |
| 16:05 |
mmorgan |
@praise bshum |
| 16:05 |
* pinesol_green |
I come to praise bshum, not to bury them. |
| 16:11 |
|
remingtron_ joined #evergreen |
| 17:09 |
|
mmorgan left #evergreen |
| 17:11 |
kmlussier |
The OU setting for "Specify search depth for the duplicate patron check in the patron editor." What is the default if no depth is set here? |
| 17:11 |
kmlussier |
And it's already after 5 p.m. I wonder if anyone's still around who knows the answer to my question. |
| 17:27 |
kmlussier |
For the logs, the depth appears to be 2. |
| 17:29 |
berick |
kmlussier: i believe it defaults to the depth of the staff login workstation org unit. |
| 17:29 |
berick |
which would be 2 in a stock EG setup |
| 17:31 |
kmlussier |
berick: Ah, ok. That makes sense. |
| 17:31 |
kmlussier |
berick: Can you guess what I'm testing right now? :) |
| 17:32 |
berick |
heh, i have a theory patron reg is involved |
| 17:34 |
kmlussier |
berick: I'm hoping to complete the testing on the latest code for the new editor tonight. |
| 17:35 |
berick |
kmlussier++ |
| 17:35 |
kmlussier |
But, first, I suppose I should feed the children. Their faces are looking a little gaunt. |
| 17:35 |
berick |
hah |
| 17:43 |
Bmagic |
bshum++ |
| 17:46 |
* berick |
ponders transient A/T event defs where output is generated then promptly deleted to avoid event_output bloat for single-use data like self checkout receipts, etc. |
| 17:57 |
miker |
berick: cleanup module, perhaps? though reprinting receipts is a use case (unfilled ATM, admittedly) |
| 17:58 |
miker |
(and just auditing, aside from reprinting) |
| 17:58 |
* miker |
disappears |
| 18:15 |
|
rlefaive joined #evergreen |
