| Time |
Nick |
Message |
| 06:02 |
pinesol |
News from qatests: Failed Log Output: osrfsys.log <http://testing.evergreen-ils.org/~live//archive/2020-09/2020-09-28_04:00:10/test.78.html> |
| 06:37 |
|
agoben joined #evergreen |
| 07:23 |
|
rjackson_isl_hom joined #evergreen |
| 08:07 |
|
Dyrcona joined #evergreen |
| 08:16 |
|
mantis1 joined #evergreen |
| 08:30 |
|
mmorgan joined #evergreen |
| 08:37 |
|
rfrasur joined #evergreen |
| 08:51 |
Dyrcona |
Bleh. Chrome-- |
| 08:53 |
Dyrcona |
When Chrome restored the previous session this morning, it used a cached copy of the Lp bug from before my previous update to the bug, so I didn't see my update from last week. I knew that I'd updated that bug, but just assumed that I was mistaken after looking at it in Chrome. |
| 08:53 |
Dyrcona |
cache-- |
| 09:16 |
|
dbwells joined #evergreen |
| 09:50 |
|
jvwoolf joined #evergreen |
| 11:21 |
|
jtm-lis joined #evergreen |
| 12:34 |
|
drigney joined #evergreen |
| 12:49 |
|
sandbergja joined #evergreen |
| 13:05 |
Dyrcona |
Interesting: A record that took 237.8 seconds to update on Pg 9.6, took 326.8 seconds on Pg 10 with the branch from Lp 1482757. |
| 13:06 |
pinesol |
Launchpad bug 1482757 in Evergreen 3.4 "Loading records with located URIs should not delete and recreate call_numbers" [Low,Confirmed] https://launchpad.net/bugs/1482757 |
| 13:06 |
Dyrcona |
I suppose that indicates some consistency in the results, and it not being down to odd vagaries on the server. |
| 13:08 |
Dyrcona |
It will be interesting to see if that is also the record that takes the longest to update on Pg 10. (The Pg 10 run isn't finished, yet.) |
| 13:39 |
|
sandbergja joined #evergreen |
| 14:03 |
jeff |
Dyrcona: That seems quite slow on 9.6, even. Are there an exceptionally large number of located URIs in the record, and/or associated rows in asset.call_number due to the churn that bug deals with? |
| 14:10 |
Dyrcona |
jeff: Most records are finishing around 2 seconds. Not sure why that particular record takes so long. I haven't looked at it, yet. |
| 14:15 |
Dyrcona |
Does this mean anything to anyone? [ERR :16008:osrf-websocket-stdio.c:671:] WS received XMPP error message in response to thread=0.469669984780122451601316787885 and recipient=router public.localhost/open-ils.curbside. Likely the recipient is not accessible/available. |
| 14:16 |
Dyrcona |
The open-ils.curbside service is running. |
| 14:37 |
|
collum joined #evergreen |
| 14:37 |
Dyrcona |
Y'know, it's often not as easy to see if a branch is missing commits as it should be with git, particularly when the branches you're trying to compare have different bases. |
| 14:38 |
jeff |
yeah, in theory it would be easier with less cherry-picking, but I'm not sure how well that would work for us. |
| 14:44 |
Dyrcona |
I'm also not getting anything useful in the logs about a 500 error with a backport of curbside to 3.2. It happens in the OPAC. Things seem to be OK in the web staff client. |
| 14:45 |
Dyrcona |
I did manage to check the commits by dumping the results of git log --grep 1879983 on each branch to a file. That's assuming that all of the commits have the bug number in them, which they may not. |
| 14:46 |
Dyrcona |
It looks like they do. |
| 14:48 |
Dyrcona |
Ah.. Found something useful: egweb: template error: file error - opac/parts/hold_notify.tt2: not found |
| 14:54 |
Dyrcona |
So, curbside appears to depend on a "new" feature that doesn't exist in 3.2. I can either try backporting that feature, or removing the reference to the template, but I fear the latter will lead to different breakage. |
| 14:59 |
JBoyer |
Dyrcona, a couple things: 1, you can absolutely take that reference out and curbside will be fine. And 2, since this bit me just this week, did you add curbside the the list of services available in opensrf_core.xml? |
| 15:05 |
Dyrcona |
JBoyer++ # I have not done the latter. |
| 15:07 |
rfrasur |
Bmagic - do you still have 3.3.3 on your community demo server or is it leftover from Bug Squash Week? |
| 15:37 |
|
collum_ joined #evergreen |
| 15:37 |
|
mantis1 left #evergreen |
| 16:03 |
|
dbwells_ joined #evergreen |
| 16:25 |
Bmagic |
rfrasur: it's master |
| 16:54 |
|
nfBurton joined #evergreen |
| 17:13 |
|
mmorgan left #evergreen |
| 17:52 |
|
sandbergja joined #evergreen |
| 18:00 |
pinesol |
News from qatests: Failed Log Output: osrfsys.log <http://testing.evergreen-ils.org/~live//archive/2020-09/2020-09-28_16:00:02/test.78.html> |
