Time |
Nick |
Message |
05:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
07:06 |
|
rjackson_isl joined #evergreen |
07:26 |
|
collum joined #evergreen |
08:17 |
|
bos20k joined #evergreen |
08:38 |
|
mmorgan joined #evergreen |
08:50 |
|
Dyrcona joined #evergreen |
08:58 |
|
bos20k_ joined #evergreen |
09:08 |
|
sandbergja joined #evergreen |
09:09 |
|
aabbee joined #evergreen |
09:32 |
|
jvwoolf joined #evergreen |
10:00 |
|
sandbergja joined #evergreen |
10:44 |
dbs |
Circulation policies, hmm. I want to be able to block users from borrowing once they've accumulated a certain threshold of fines within our consortium |
10:45 |
dbs |
Is that where standing penalties come into play? |
10:47 |
Dyrcona |
Indeed it is. |
10:48 |
dbs |
Having a tough time finding a writeup about how system-generated penalties get applied in the docs. Lots about staff-generated penalties though |
10:49 |
mmorgan |
Group Penalty Thresholds is where to set thresholds |
10:50 |
mmorgan |
... under Local Administration |
10:52 |
dbs |
mmorgan++ # thanks |
10:52 |
dbs |
now to figure out why the "Penalty" dropdown in the "New penalty threshold" dialogue is empty :( |
10:56 |
dbs |
Ah well, back to plain old SQL. Much better. |
10:58 |
mmorgan |
Well, if you want to take the easy way out... ;-) |
11:01 |
* mmorgan |
has not tried getting to Group Penalty Thresholds in the web client before. Appears broken. |
11:09 |
mmorgan |
Ah. Ok. bug 1812389 |
11:09 |
pinesol |
Launchpad bug 1812389 in Evergreen "Group Penalty Threshold link does not work" [Medium,Fix released] https://launchpad.net/bugs/1812389 |
11:11 |
dbs |
weirdly we're on 3.1.2 and it is broken for us, but... we're weird |
11:11 |
dbs |
thank you! |
11:12 |
dbs |
wait, different bug, we get to the right page but the "Penalty" dropdown when you go to add a penalty is empty |
11:12 |
* dbs |
shrughs |
11:12 |
dbs |
(that's a shrug and a sigh I guess) |
11:13 |
Dyrcona |
:) |
11:13 |
* Dyrcona |
goes back to poking logs for information about segfaults. |
11:16 |
Dyrcona |
Hmm... Someone used operator change just before midnight last night? |
11:16 |
Dyrcona |
I guess some of the community colleges were open. |
11:28 |
dbs |
We don't have 3.3 docs yet eh? |
11:29 |
dbs |
(well, we have them, just not generated on docs.evergreen-ils.org...) |
11:29 |
rhamby |
looks like it |
11:30 |
rhamby |
docs are overrated anyway .... who wants to actually know the outcome of their actions .... |
11:34 |
Dyrcona |
JBoyer: I have found a segfault that looks like it happened after a regular staff login timed out. Same pgt search that triggered the segfault. |
11:34 |
Dyrcona |
The authtoken appears in the logs for several hours before it was deleted and then the crash. |
11:36 |
Dyrcona |
Yeahp: Session retrieve at 21:44, then nothing until 00:44 when the session was deleted, followed by crash. |
11:42 |
dbs |
So just restart the server every 10 minutes or so to avoid that segfault? |
11:43 |
dbs |
(Seriously though - that's a great find between you and JBoyer) |
11:51 |
dbs |
Oh yeah and none of the existing Group Penalty Thresholds are being displayed in that interface, which is also weird. Weird on weird |
11:51 |
dbs |
I guess I'll revisit it once we upgrade from 3.1.2 to 3.3.x |
11:59 |
|
BAMkubasa joined #evergreen |
12:03 |
|
jihpringle joined #evergreen |
12:10 |
jihpringle |
gmcharlt: for the second of the new patches on LP 1777207 is the "previous sort order" in bullet 3 the original check in order or the order after the patron sorted? |
12:10 |
pinesol |
Launchpad bug 1777207 in Evergreen "Web Client - Check In List Refreshes After Every Scan and Gets Progressively Slower" [Medium,Confirmed] https://launchpad.net/bugs/1777207 - Assigned to Galen Charlton (gmc) |
12:11 |
jihpringle |
just want to make sure I know what I should be seeing when I test |
12:15 |
|
Christineb joined #evergreen |
12:22 |
miker |
jihpringle: donning gmcharlt mask, the user-applied sort |
12:23 |
miker |
IIUC |
12:23 |
|
Dyrcona joined #evergreen |
12:24 |
jihpringle |
miker: thanks :) |
12:26 |
|
sandbergja joined #evergreen |
12:48 |
Dyrcona |
And, now, I think I've seen multiple of the pgt searches with null authtoken from the same session delete. |
12:49 |
Dyrcona |
Either that, or log messages are being duplicated. |
12:51 |
Dyrcona |
Well, it definitely came in twice, because I have two different traces, with four total messages from the gateway. All with the same source IP and only 1 session deleted from that IP at that time. |
12:53 |
Dyrcona |
OK... I see why the duplication: 1 is ACT and the other INFO |
12:53 |
|
collum joined #evergreen |
12:54 |
|
collum_ joined #evergreen |
12:55 |
Dyrcona |
So, I've got 4 from 1 session delete, 2 from another, and 1 from a third. The third does not coincide with a segmentation fault. |
13:04 |
|
collum joined #evergreen |
13:08 |
Dyrcona |
Nope. Miscounted, the numbers are 5, 1, and 1. |
13:13 |
Dyrcona |
Oh! Other drone crashes correspond on the second drone server. |
13:14 |
Dyrcona |
So, that last one did cause a drone segfault. |
13:14 |
Bmagic |
I love it |
13:15 |
Bmagic |
(finding the answers) |
13:42 |
csharp |
dbs: not sure if it's the same problem, but some of our dojo weirdness ended up being caused by our nginx proxy not being properly configured to forward the origin IP - might be useful :-) |
13:42 |
csharp |
"kinda working" is always hard to diagnose |
13:51 |
* Dyrcona |
is reminded that there are branches and commits that he should review but has been bogged down in log files.... |
13:52 |
dbs |
csharp: always worth keeping in mind! |
13:53 |
* dbs |
currently wondering how to turn a yaz-client query for pubdate that works ("find @attr 1=31 @attr 4=4 2010") into something that works in Z39.50 search |
13:54 |
|
HomerPublic joined #evergreen |
13:54 |
dbs |
ah there we go, set config.z3950_attr code=31, format=4, truncation=100 |
13:55 |
dbs |
kinda wish we had aligned the column names in that table to the Bath Profile names at http://www.ukoln.ac.uk/interop-focus/activities/z3950/int_profile/bath/draft/stable1.html but ah well |
14:06 |
gmcharlt |
jihpringle: I confirm that the person wearing my mask earlier is correct ;) |
14:06 |
jeffdavis |
I still want to know why miker had that mask handy. |
14:07 |
gmcharlt |
dbs: that strikes me as something we could fix up almost completely transparently (assuming that few if any folks have been writing clark kent reports on the config.z3950_source table) |
14:07 |
csharp |
jeffdavis: we all have gmcharlt masks - do you not? |
14:07 |
jeffdavis |
csharp: I guess I need to start attending the conferences. |
14:07 |
csharp |
jeffdavis: or the hackaway! |
14:08 |
csharp |
fwiw, I've never made a report with that source |
14:08 |
jihpringle |
thanks gmcharlt |
14:09 |
jihpringle |
I've tested both new patches on our test server and so far it looks good |
14:11 |
gmcharlt |
cool |
14:17 |
dbs |
gmcharlt: those would be some weird reports indeed! |
14:18 |
gmcharlt |
dbs: "but whatever is wrong with me using Evergreen as my platform for hosting an IRSpy clone?" ;) |
14:23 |
dbs |
csharp: are you using "proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;" or "proxy_set_header X-Forwarded-For $remote_addr;" |
14:23 |
|
Moggers1986 joined #evergreen |
14:35 |
Dyrcona |
So, now, I've found a segfault that does not appear to correspond to an auth timeout, unless the session delete happened on another brick... Is that possible? |
14:35 |
* Dyrcona |
double checks. |
14:37 |
Dyrcona |
Indeed. My first cross-brick crash. |
14:38 |
Dyrcona |
This was a different search, too, asc, not pgt. |
14:38 |
|
nfBurton joined #evergreen |
15:06 |
csharp |
dbs: proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for |
15:06 |
Dyrcona |
So, I have found two so far that don't seem to correspond to open-ils.auth.session.delete calls, but 1 has two session retrieves right before it: 1 with an authtoken and 1 with null for the authtoken. |
15:07 |
Dyrcona |
Two segfaults, that is. |
15:07 |
dbs |
csharp: okay, that matches what we're doing. thanks though! |
15:07 |
Dyrcona |
dbs | csharp: I'm using the same on my test systems with nginx. I will likely use haproxy in production to replace ldirectord, IF I ever get the time. |
15:08 |
dbs |
Some of the Dojo UIs were replaced with Angular UIs in the last couple of releases, or am I dreaming? |
15:09 |
berick |
dbs: they were |
15:09 |
Dyrcona |
They have to be enabled, though, don't they? |
15:09 |
Dyrcona |
I mean, explicitly, by the admin. |
15:10 |
berick |
no, there's no enabling |
15:10 |
berick |
they're just swapped |
15:11 |
dbs |
berick: sweet! |
15:12 |
dbs |
Was there a noticeable speed (or at least perception of speed) increase? |
15:12 |
berick |
oh no doubt |
15:12 |
dbs |
awwwwwesome |
15:20 |
berick |
dbs: just did an exaggerated experiment on evdemo.kcls.org (cross country) -- Angular page DOMContentLoaded at 646ms. Dojo page at 21 seconds. |
15:20 |
berick |
the latency really impacts the dojo stuff a lot more, of course. disparity wouldn't be that bad on a nearby server |
15:33 |
dbs |
oh that's going to make so many people happy here |
15:33 |
* dbs |
eyes acquisitions |
16:03 |
jeffdavis |
Our most distant library is over 2000 miles from the data centre. |
16:04 |
jeffdavis |
(Speaking of cross-country latency experiments.) |
16:08 |
Dyrcona |
Chasing NULL pointers is worse than chasing rabbits. |
16:09 |
Dyrcona |
And, speaking of Canadia [sic], my wife and daughter are in Quebec province at the moment. |
16:13 |
Dyrcona |
@later tell JBoyer I believe I have found the crashing bit in oils_pcrud, though its actually in oils_sql.c. |
16:13 |
pinesol |
Dyrcona: The operation succeeded. |
16:17 |
|
jvwoolf left #evergreen |
16:38 |
csharp |
@quote add <Dyrcona> Chasing NULL pointers is worse than chasing rabbits. |
16:38 |
pinesol |
csharp: The operation succeeded. Quote #200 added. |
16:40 |
gmcharlt |
those wascally nullits |
16:41 |
Dyrcona |
"But, if you go...chasing pointers..." |
16:46 |
Dyrcona |
"And you know it's gonna null...." |
16:46 |
Dyrcona |
:) |
16:50 |
Dyrcona |
"Tell 'em a bearded, older programmer has given you a patch..." |
16:50 |
Dyrcona |
"poor pcrud...when it has a segfault..." |
16:51 |
* Dyrcona |
hopes he never runs into Grace Slick. |
16:52 |
Dyrcona |
Although, that would be cool... |
17:00 |
|
finnx joined #evergreen |
17:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
17:02 |
|
finnx left #evergreen |
17:08 |
|
mmorgan left #evergreen |
17:12 |
Dyrcona |
So, I'm partly wrong and partly right about where the segfault occurs, and the partly wrong could make a better fix easier.... |
17:12 |
Dyrcona |
Even though I'm technically done for the day, I think I'll play around with this some more. |
17:23 |
Dyrcona |
libosrf_json could probably stand to be its own library. |
18:10 |
Dyrcona |
So, i'm trying to write a client in C and I'm having trouble with the contextnode argument to the bootstrap functions. Nothing I've tried so far works. |
18:38 |
Dyrcona |
OIC.... took me long enough. |
18:40 |
Dyrcona |
Eh.. no. It still fails to bootstrap when I claim to srfsh. |
18:48 |
* Dyrcona |
shakes his head in shame.... |
18:49 |
Dyrcona |
Returns 1 on success, zero on failure... |
18:51 |
Dyrcona |
THAT took WAY too long... |
18:51 |
* Dyrcona |
signs out and gives it a rest for tonight. |
19:36 |
|
RyanMcg joined #evergreen |
19:37 |
RyanMcg |
Quick query for the Great brain! Is there a way to force the evergreen webclient (Server says 3-1-11) to default to the maximum number of horizontal rows on data displays such as bills, items out, items checked out? Our current default is only 25 rows, and we don't want to have to remember to reset that every time we start the web client. |
19:38 |
RyanMcg |
I'm looking for a workstation/local administration method, not a server-side solution for the issue |
19:43 |
RyanMcg |
Or is it not possible aside from as a server side change, or not at all? |
19:47 |
|
sandbergja joined #evergreen |
20:37 |
|
book` joined #evergreen |
21:54 |
|
sandbergja joined #evergreen |