| Time |
Nick |
Message |
| 01:40 |
|
dickreckard joined #evergreen |
| 04:08 |
|
dickreckard joined #evergreen |
| 05:31 |
|
dickreckard joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:23 |
|
rjackson_isl_hom joined #evergreen |
| 08:17 |
|
tlittle joined #evergreen |
| 08:24 |
|
dickreckard joined #evergreen |
| 08:34 |
|
mmorgan joined #evergreen |
| 08:39 |
|
alynn26 joined #evergreen |
| 08:47 |
|
alynn26_away joined #evergreen |
| 09:01 |
|
collum joined #evergreen |
| 09:15 |
|
Keith-isl joined #evergreen |
| 09:19 |
|
rfrasur joined #evergreen |
| 09:32 |
|
cmalm joined #evergreen |
| 09:35 |
|
jvwoolf joined #evergreen |
| 09:39 |
|
dguarrac joined #evergreen |
| 10:22 |
|
Dyrcona joined #evergreen |
| 10:41 |
|
mantis joined #evergreen |
| 10:41 |
mantis |
Had a question regarding the Change Operator function. Was the time out feature intentional for security reasons when the Temporary setting is chosen/defaulted? |
| 10:42 |
|
jvwoolf joined #evergreen |
| 10:45 |
|
jihpringle joined #evergreen |
| 10:56 |
Dyrcona |
mantis: Yes. Change Operator is typically used to get higher permissions, so having a shorter timeout is intentional. |
| 10:58 |
* csharp_ |
hears Sade signing "Change Operator" in his head |
| 10:58 |
|
sandbergja joined #evergreen |
| 10:58 |
csharp_ |
also singing |
| 10:59 |
csharp_ |
mantis: yeah, it's not meant as a substitute for actually logging out and letting the next staff member log in |
| 10:59 |
sandbergja |
Anybody up for point releases today? Or should we postpone? |
| 11:01 |
mantis |
Thank you both. I'm assuming the log out of Evergreen entirely instead of just the original staff login is also the intentional part? It's just a specific question we have from library staff. |
| 11:08 |
mmorgan |
mantis: Using the persistent option under change operator is essentially logging out and in as the new user. |
| 11:09 |
csharp_ |
but that's confusing enough that it's easier to tell staff to just log out at the end of their shift (IMHO) |
| 11:13 |
jeff |
for some reason I parsed (CHR) in this conversation and wondered why we were takling about standing penalty types/blocks. |
| 11:15 |
mantis |
mmorgan: thank you! |
| 11:40 |
Dyrcona |
sandbergja: I'm inclined to postpone, unless others show up and say let's do releases. |
| 11:42 |
Dyrcona |
sandbergja: Also, we have #evergreen-release here on Libera for discussing releases. Anyone is free to join the channel if they want to help out or to see how the sausage is made. |
| 11:46 |
sandbergja |
Dyrcona++ |
| 11:48 |
sandbergja |
Dyrcona: postpone by a week? June 23rd? |
| 11:51 |
sandbergja |
ulterior motive: we will be upgrading next month, and it would be nice to upgrade to a fresh release. :-) |
| 11:52 |
mmorgan |
There's lots of good stuff waiting to be released! |
| 11:53 |
sandbergja |
mmorgan: agreed! |
| 12:17 |
|
sandbergja_ joined #evergreen |
| 12:18 |
|
sandbergja left #evergreen |
| 12:18 |
|
sandbergja joined #evergreen |
| 12:19 |
|
sandbergja joined #evergreen |
| 12:57 |
mmorgan |
Acquisitions woes, we have an invoice that can't be closed via the client. It times out. Does anyone have a script or process to close an invoice to get around this? |
| 13:01 |
mmorgan |
We're seeing this in the logs whenever we try to close it: 2021-06-16 09:48:17 brick2 osrf_http_translator: [WARN:5095:transport_session.c:874:162385126750950] Text of error message received from Jabber: XML stanza is too big |
| 13:07 |
jeffdavis |
mmorgan: what is your max_stanza_size setting in /etc/ejabberd/ejabberd.yml ? |
| 13:08 |
jeffdavis |
Increasing it might get around the problem. |
| 13:08 |
jeffdavis |
Looks like there's a brief mention of the same problem in bug 1725317 |
| 13:08 |
pinesol |
Launchpad bug 1725317 in OpenSRF ""XML stanza is too big" still possible with chunking and bundling" [Undecided,New] https://launchpad.net/bugs/1725317 - Assigned to Galen Charlton (gmc) |
| 13:17 |
mmorgan |
jeffdavis: Not too familiar with the ejabberd config, but I see 3 entries for max_stanza_size, 262144, 262144, 524288 |
| 13:19 |
Dyrcona |
mmorgan: There should only be 1 entry. |
| 13:21 |
* mmorgan |
will need to defer to sysadmin :) Guidelines for what the max_stanza_size should be? |
| 13:21 |
jeffdavis |
We have it set to 2000000 |
| 13:21 |
Dyrcona |
I set ours to 10485760. |
| 13:22 |
mmorgan |
Ok, thanks! That's helpful! |
| 13:22 |
mmorgan |
jeffdavis++ |
| 13:22 |
mmorgan |
Dyrcona++ |
| 13:22 |
Dyrcona |
Note that ours is 10MB.... I did that after going through smaller setting sizes and having some email notices still blow up. |
| 13:23 |
Dyrcona |
We probably have a different setting on the bricks. |
| 13:24 |
jeffdavis |
mmorgan: can I ask what version of EG you are on? Just going to update that bug with a note that the issue still exists. |
| 13:24 |
Dyrcona |
Yeah, we have 2097152 (2MB) on the brick heads. |
| 13:24 |
mmorgan |
jeffdavis: 3.6.1 |
| 13:24 |
jeffdavis |
Thanks! |
| 13:25 |
Dyrcona |
jeffdavis++ |
| 13:29 |
jeffdavis |
Not sure if we should just update the install docs with a bigger setting, or take the time to fix the underlying problem (which is beyond me). |
| 13:30 |
Dyrcona |
Well, the docs used to say 2000000 for the longest time. I think it was removed at some point because chunking and bundling was supposed to eliminate the need, but chunking and bundling is incomplete, at least on the Evergreen side. |
| 13:30 |
Dyrcona |
So....Maybe we should add it back to the installation docs for now. |
| 13:35 |
|
tlittle joined #evergreen |
| 13:37 |
|
tlittle joined #evergreen |
| 13:38 |
|
terranm joined #evergreen |
| 13:41 |
|
jihpringle joined #evergreen |
| 14:04 |
|
tlittle joined #evergreen |
| 14:38 |
|
jihpringle joined #evergreen |
| 15:00 |
|
jamesrf joined #evergreen |
| 15:04 |
|
Stompro joined #evergreen |
| 15:04 |
|
jvwoolf joined #evergreen |
| 15:07 |
Stompro |
Is the new dev meeting starting now? Or do I have my timezones off? |
| 15:07 |
alynn26_away |
It was suppose to start at 3 pm, but nothing. |
| 15:08 |
* mmorgan |
is waiting at the door as well, maybe terranm is having technical issues? |
| 15:08 |
tlittle |
No, the room was being weird and wouldn't let anyone in |
| 15:08 |
tlittle |
@terran just created a new room and just sent out the info to the listserv |
| 15:08 |
pinesol |
tlittle: Can't locate Snark.pm in @INC |
| 15:08 |
|
nfBurton joined #evergreen |
| 15:10 |
* mmorgan |
is in! |
| 15:10 |
mmorgan |
terranm++ |
| 15:10 |
Stompro |
New link is https://meet.google.com/sej-dtxm-pab |
| 15:46 |
Dyrcona |
@INC |
| 15:46 |
pinesol |
Dyrcona: WORKSFORME WONTFIX |
| 15:52 |
mmorgan |
Dyrcona++ jeffdavis++ |
| 15:52 |
mmorgan |
Increasing the max_stanza_size allowed us to close the invoice! |
| 15:52 |
jeffdavis |
:D |
| 15:55 |
Dyrcona |
mmorgan: Glad to hear it. It might be useful to mention that on bug 1725317 if it isn't already. |
| 15:55 |
pinesol |
Launchpad bug 1725317 in OpenSRF ""XML stanza is too big" still possible with chunking and bundling" [Undecided,New] https://launchpad.net/bugs/1725317 - Assigned to Galen Charlton (gmc) |
| 15:56 |
mmorgan |
Ok, will do! |
| 16:28 |
Stompro |
terranm, I think your function get_tcn is in scope.. but it doesn't return the TCN, it sets the TCN to $scope.local_overlay_target_tcn. |
| 16:32 |
|
terranm joined #evergreen |
| 16:39 |
|
jvwoolf joined #evergreen |
| 17:15 |
|
mmorgan left #evergreen |
| 17:22 |
|
jvwoolf left #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:28 |
|
jihpringle joined #evergreen |
| 20:06 |
|
jamesrf joined #evergreen |
| 21:37 |
|
StomproJ joined #evergreen |
| 22:42 |
|
finnx joined #evergreen |
