02:51 |
|
mrisher joined #evergreen |
02:54 |
|
mrisher joined #evergreen |
05:27 |
|
rjackson_isl_hom joined #evergreen |
06:00 |
pinesol |
News from qatests: Failed configure CPAN <http://testing.evergreen-ils.org/~live//archive/2020-05/2020-05-27_04:00:07/test.3.html> |
07:18 |
|
rjackson_isl_hom joined #evergreen |
07:20 |
|
rfrasur joined #evergreen |
08:14 |
|
dbwells joined #evergreen |
08:35 |
Dyrcona |
At least, the backport to 3.2.10 seems to have done something. |
08:38 |
|
alynn26 joined #evergreen |
08:47 |
|
mmorgan joined #evergreen |
08:48 |
csharp |
Dyrcona: btw, I tested your no-Java branches on OpenSRF/Evergreen - I see no problems, but I would guess we want to be pretty coordinated about how we commit to master/release stuff |
08:52 |
Dyrcona |
csharp: It should wait until after 3.5 is released, or at least, it should not go into the 3.5 branch, not that Java works there. It hasn't worked in years. |
08:53 |
Dyrcona |
I'm looking into my earlier comment and I'm seeing strange stuff on my test VM. I'm going to have to find out what jamundson is looking at in production to see if something similar is going on. |
08:55 |
csharp |
Dyrcona: I looked on my master server and I don't have any selection lists to test but I didn't see problems with the UI loading or with PO items, etc. |
08:59 |
Dyrcona |
csharp: I reverted commits to the files in the picklist directory and it seems to be working, now. |
09:04 |
Dyrcona |
Could be a cache issue, too. It appeared fixed after I reverted changes and used the Chromium developer tools, and I have the tools set to disable cache. |
09:07 |
Dyrcona |
With or without changes, I get a bunch of these: VM1995:89 POST https://training.cwmars.org/osrf-http-translator net::ERR_INSUFFICIENT_RESOURCES |
11:54 |
bshum |
Every time we circle around to killing the target though, somebody decides to update the deps, so... :D |
11:55 |
bshum |
I think I got pretty close to figuring out how to get it working again, but got stuck on the HTTPS config parts, since it's different on Fedora vs. Ubuntu Apache |
11:58 |
bshum |
I'd only be wary against moving off of pinned Node versions because of potential dependency disruption. I think they tend to stay pretty safe along major versions, so maybe not as worrying |
11:59 |
Dyrcona |
So, reverting all of the ACQ changes from the jQuery bug fix makes no difference according to the person testing this. |
12:00 |
bshum |
This whole Node thing is so fickle :) |
12:00 |
|
mrisher joined #evergreen |
12:00 |
|
jihpringle joined #evergreen |
15:12 |
* mmorgan |
was looking at that, too. |
15:14 |
mmorgan |
So having separate event defs for different libraries would be the only way to break them up? Not a good solution for large consortia, though. |
15:17 |
Dyrcona |
mmorgan: Yes, that's where my thoughts are heading, though I'm a bit fuzzy on how to have the separate event definitions for each member library. |
15:20 |
* mmorgan |
has cloned the event owned by the consortium and changed owner to the ou for the member library. Testing this again to make sure it only creates events for the owner. |
15:21 |
Dyrcona |
mmorgan: I was about to look at that as a possibility. |
15:30 |
jeffdavis |
berick++ |
15:30 |
jeffdavis |
I can create a signoff branch but I wonder if it should be reviewed by someone more familiar with OpenSRF stuff than I am. |
17:12 |
mmorgan |
Heh. Just saw that pinesol helpfully supplied bug number seven. Obviously, that's not one I was referring, to :) |
17:13 |
|
mmorgan left #evergreen |
17:28 |
|
jihpringle joined #evergreen |
18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
18:05 |
|
rjackson_isl_hom joined #evergreen |
18:08 |
|
jvwoolf joined #evergreen |
18:54 |
|
mrisher joined #evergreen |
04:22 |
|
dbwells_ joined #evergreen |
06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
06:28 |
|
rjackson_isl_hom joined #evergreen |
07:20 |
|
rjackson_isl_hom joined #evergreen |
07:24 |
|
rfrasur joined #evergreen |
10:14 |
bshum |
Well, it sounded like dbwells had some thoughts about keeping it alive, but yeah I've been in favor of letting it die for now |
10:14 |
csharp |
didn't/doesn't Syrup use it? |
10:15 |
Dyrcona |
Reading dbwells comment, he's concerned about Syrup, and no, I don't think Syrup actually uses much (if any) of it. |
10:15 |
bshum |
20.04 definitely chokes on the existing packages and as testing goes, haven't built OpenSRF with python bindings at all forever |
10:16 |
Dyrcona |
It won't build on Ubuntu 16.04, either, but works on 18.04. |
10:16 |
Dyrcona |
Or, rather, it won't work on 16.04. |
10:17 |
Dyrcona |
Java's been dead for years.... bug 1827051 |
10:21 |
csharp |
Dyrcona: please - that sounds great |
10:22 |
csharp |
if someone gets the itch to implement Python3 later, more power to them :-) |
10:22 |
Dyrcona |
If someone wants to look at the Java bug in the meantime, that would be helpful. |
10:22 |
csharp |
if I get a moment today, I'll test both OpenSRF and EG |
10:22 |
Dyrcona |
csharp++ |
10:22 |
csharp |
lots of meetings today |
10:23 |
Dyrcona |
I think we should modernize our use of ejabberd before we try adding more language interfaces. |
16:06 |
|
jihpringle96 joined #evergreen |
17:17 |
|
mmorgan left #evergreen |
17:33 |
|
jvwoolf joined #evergreen |
18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
01:06 |
|
JBoyer joined #evergreen |
01:49 |
|
JBoyer joined #evergreen |
04:22 |
|
dbwells joined #evergreen |
06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
06:21 |
|
sandbergja joined #evergreen |
06:25 |
|
sandbergja joined #evergreen |
07:12 |
|
rfrasur joined #evergreen |
07:59 |
Dyrcona |
Pg11++ which is Pg12 and I'm trying that next. :) |
08:01 |
JBoyer |
Dyrcona++ |
08:01 |
JBoyer |
That sounds great |
08:04 |
Dyrcona |
I don't know what other surprises may await us in Pg12 or Pg11, but I think I'm going to switch my main development VM to used the Pg12 database if this test goes well. |
08:08 |
|
alynn26 joined #evergreen |
08:15 |
|
jvwoolf joined #evergreen |
08:22 |
|
mantis2 joined #evergreen |
17:01 |
|
rjackson_isl_hom joined #evergreen |
17:12 |
|
mmorgan left #evergreen |
17:33 |
|
Dyrcona joined #evergreen |
18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
18:17 |
|
rjackson_isl_hom joined #evergreen |
18:52 |
|
rjackson_isl_hom joined #evergreen |
06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
07:21 |
|
rjackson_isl_hom joined #evergreen |
07:32 |
|
Dyrcona joined #evergreen |
07:38 |
|
rfrasur joined #evergreen |
07:54 |
Dyrcona |
Been a while since I ran git pull: Your branch is behind 'origin/master' by 1764 commits, and can be fast-forwarded. |
08:30 |
|
alynn26 joined #evergreen |
08:31 |
Dyrcona |
csharp: It might interest you to know that I just got better profile numbers from a default installation of Pg10 with the same authority update on the same hardware than I got last Friday with a tuned Pg 9.6 database. I'm going to try Pg 11 and Pg 12 after restoring dumps to them. |
08:33 |
Dyrcona |
Granted, this is totally nonscientific testing. I'm just running the update, reverting it, and running the update again with plprofiler and looking at the output. I'm not doing enough trials nor averaging results. |
08:40 |
csharp |
thanks! I can do some experimentation too |
08:42 |
Dyrcona |
I'm restoring to Pg 11, now. My methodology is do the restore, then run the plprofiler as mentioned above. I'm trying not to use the db server for anything else in the meantime. |
08:42 |
Dyrcona |
The restore usually takes so long that I don't get around to running plprofiler until the next morning. |
17:14 |
jeff |
often our fallback is "your card number always works in place of your username if you've forgotten your username", but there are cases where that isn't as helpful. |
17:29 |
|
mmorgan left #evergreen |
18:00 |
|
sandbergja joined #evergreen |
18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
19:31 |
|
sandbergja joined #evergreen |
19:51 |
|
sandbergja joined #evergreen |
20:23 |
|
sandbergja joined #evergreen |
01:44 |
|
alynn26_away joined #evergreen |
05:47 |
|
agoben joined #evergreen |
06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
07:23 |
|
rjackson_isl_hom joined #evergreen |
07:25 |
|
Dyrcona joined #evergreen |
07:29 |
|
rfrasur joined #evergreen |
14:31 |
|
rfrasur joined #evergreen |
14:35 |
csharp |
Dyrcona: what version of PG? |
14:42 |
Dyrcona |
Pg 9.6 |
14:43 |
Dyrcona |
I also have 10, 11, and 12 on this server, but I'm only testing with 9.6. |
14:48 |
Dyrcona |
To install plprofile on other versions of Postgres, I'll need to checkout the source code for each version. |
15:55 |
JBoyer |
Dyrcona, In case you're interested the only package I had to remove to get Ubuntu to chill out about upgrading Postgres was postgresql-plperl-(vers). It wails about it because apparently that package must not properly work side-by-side with other versions and postgresql-* is in the "never remove these packages" list. Makes a Postgres version upgrade even more urgent once the system comes back up. :) |
15:56 |
Dyrcona |
JBoyer: Yes, that was the only one listed in the logs, but I deleted it and the main postgresql packages apparently. |
17:31 |
|
sandbergja joined #evergreen |
17:36 |
|
sandbergja joined #evergreen |
17:43 |
|
sandbergja joined #evergreen |
18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
22:00 |
|
sandbergja joined #evergreen |
22:41 |
|
sandbergja joined #evergreen |
00:15 |
|
rjackson_isl_hom joined #evergreen |
00:22 |
|
dbwells joined #evergreen |
00:23 |
|
dbwells_ joined #evergreen |
06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
07:19 |
|
rjackson_isl_hom joined #evergreen |
07:34 |
|
rfrasur joined #evergreen |
08:06 |
|
Dyrcona joined #evergreen |
14:00 |
|
sandbergja joined #evergreen |
14:02 |
jeffdavis |
berick: btw I applied your c-backlog-speedbump fix on our 3.5 server and it seems to have successfully prevented the log problem when we hit max_children today |
14:02 |
jeffdavis |
so thanks for that! :) |
14:03 |
berick |
jeffdavis: nice, thanks for testing |
14:05 |
|
sandbergja joined #evergreen |
14:59 |
|
miker joined #evergreen |
14:59 |
|
ericar joined #evergreen |
16:48 |
|
rjackson_isl_hom joined #evergreen |
17:14 |
|
mmorgan left #evergreen |
17:42 |
berick |
csharp++ |
18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
19:12 |
|
mantis1 joined #evergreen |
19:13 |
|
mantis1 left #evergreen |
06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
07:20 |
|
rjackson_isl_hom joined #evergreen |
07:27 |
|
Dyrcona joined #evergreen |
07:48 |
|
rfrasur joined #evergreen |
10:31 |
|
dbwells joined #evergreen |
10:35 |
|
rfrasur joined #evergreen |
10:36 |
|
sandbergja joined #evergreen |
10:54 |
pinesol |
[evergreen|Bill Erickson] LP1837656 Org proximity admin disable org filter - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=07971c7> |
11:13 |
|
berick joined #evergreen |
12:04 |
|
jihpringle joined #evergreen |
12:09 |
mmorgan |
I'm trying to change a best hold selection sort order on a test system and it's not working. |
12:10 |
mmorgan |
We were using a sort order which always sent holds home, and I just changed it to Traditional, and it's still sending holds home. |
12:11 |
mmorgan |
I've restarted services, ran autogen, am I missing something? Traditional should capture a hold where an item lands, right? |
12:22 |
|
mantis2 joined #evergreen |
12:22 |
Dyrcona |
mmorgan: Have you run the hold targeter since making the change? |
12:23 |
|
sandbergja joined #evergreen |
12:24 |
mmorgan |
Dyrcona: I have manually retargeted the individual holds I'm testing, and confirmed that the non-owned item I'm checking is in the hold copy map for the hold at the pickup point. |
12:25 |
Dyrcona |
TBH, I don't know how that works any more. It's too complicated. |
12:26 |
mmorgan |
Agreed, it is complicated :) |
13:08 |
|
sandbergja joined #evergreen |
13:10 |
jeffdavis |
My test server with rel_3_5 and a few backports ran out of disk space due to 34159161 "Could not launch a new child" messages in the logs. |
13:11 |
Dyrcona |
jeffdavis: Yes, that happens. |
13:12 |
jeffdavis |
It didn't happen on a beta server with the same configuration. |
13:13 |
|
sandbergja joined #evergreen |
14:01 |
berick |
specifically regarding the log spewing, this should fix it. noting here in case this continues to be a thing. |
14:01 |
berick |
https://git.evergreen-ils.org/?p=working/OpenSRF.git;a=shortlog;h=refs/heads/user/berick/lpxxx-c-backlog-speedbump |
14:01 |
berick |
(though probably should fix it regardless) |
14:01 |
jeffdavis |
thanks Bill, we'll try that out |
14:05 |
jeffdavis |
FWIW, we have two test servers, upgrade1 (~3.5beta) and upgrade2 (~ current rel_3_5). They are configured pretty much identically, use the same db cluster, etc. upgrade1 has been in use for weeks without issues; upgrade2 ran into the max_children problem within a day or two of first use. |
14:05 |
Dyrcona |
I've seen the fine generator and/or hold targeter go ballistic when there's too much to do, like running the fine generator on old data when circulations haven't happened in a month, so there's a ton of overdue and lost stuff. I had that fill the disk on a training server. IIRC cstore messages like those. |
14:07 |
Dyrcona |
I may have mentioned it in here. I'm pretty sure that I did.... |
14:07 |
jeffdavis |
It could be just a transient usage or db issue, but given how similar the environments are, I am taking a look at the EG/OpenSRF code differences to see if there are any plausible causes there. We're upgrading this weekend so I want to know if the upgrade2 version has important bugs. :) |
15:46 |
jihpringle |
we're going to be coming up to this too soon so thanks sandbergja for asking the question and mmorgan for the answer :) |
16:14 |
sandbergja |
mmorgan++ |
16:34 |
sandbergja |
mmorgan: just to check, when you say they've fallen off the autorenewal train, does that mean that they just happen to have hit their limit of autorenewals? Or is there something specific about autorenewals that makes them fall off the train? |
16:38 |
mmorgan |
sandbergja: It relates to the processing delay in the autorenewal trigger, not the autorenew limit. Our items autorenew early in the morning the day they are due. |
16:38 |
mmorgan |
Because the item gets the due date of May 13 when it is autorenewed on May 13, it won't be picked up by the autorenew trigger that runs on May 14th. |
16:45 |
|
jihpringle joined #evergreen |
16:54 |
mmorgan |
Regarding my question earlier about best hold selection sort order. There was a hold policy affecting my test. Changing it to Traditional worked as expected. |
17:02 |
|
mmorgan left #evergreen |
18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
18:06 |
|
drigney joined #evergreen |
18:24 |
|
rjackson_isl_hom joined #evergreen |
18:51 |
|
rjackson_isl_hom joined #evergreen |
06:00 |
|
rjackson_isl_hom joined #evergreen |
06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
07:11 |
|
Dyrcona joined #evergreen |
07:16 |
|
rjackson_isl_hom joined #evergreen |
07:27 |
|
rfrasur joined #evergreen |
11:30 |
csharp |
my initial instinct says no, but the people who pushed for the fix probably want it sooner than 3.5 |
11:32 |
berick |
csharp: if it merges cleanly, i'd be in favor of merging |
11:32 |
jeffdavis |
+1 |
11:34 |
csharp |
10-4 |
11:35 |
csharp |
nope :-( |
11:36 |
csharp |
https://pastebin.com/Qm1dEVST |
11:37 |
csharp |
there are enough changes in the admin-page.component that I'm uncomfortable pushing it to 3.4 |
11:37 |
csharp |
I'll update the bug |
11:39 |
csharp |
as I said in my comment, if someone wants to resolve the conflicts, I'll be happy to test and signoff |
11:39 |
berick |
i'll push a fix |
11:39 |
berick |
well share a branch |
11:49 |
berick |
hm, it would mean untangling and backporting other stuff that the admin pages rely on |
16:46 |
|
rjackson_isl_hom joined #evergreen |
17:09 |
|
mmorgan left #evergreen |
17:27 |
|
jihpringle joined #evergreen |
18:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
20:57 |
|
sandbergja joined #evergreen |
22:45 |
|
sandbergja joined #evergreen |
23:52 |
|
sandbergja joined #evergreen |
04:57 |
|
mrisher joined #evergreen |
05:00 |
|
alynn26_away joined #evergreen |
05:19 |
|
AFloyd__ joined #evergreen |
06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
07:19 |
|
rjackson_isl_hom joined #evergreen |
07:33 |
|
rfrasur joined #evergreen |
07:42 |
|
sandbergja joined #evergreen |
15:01 |
abneiman |
Bmagic: so, just the standard process? pullrequest, a couple signoffs, committer merge? |
15:01 |
Bmagic |
I believe so, yes |
15:02 |
dluch |
Can we make that happen? |
15:03 |
Bmagic |
the output of the Antora docs are online (linked above) - for anyone to test, for a sign off |
15:03 |
|
remingtron_ joined #evergreen |
15:04 |
dluch |
So, do we have a pullreequest already? |
15:04 |
Bmagic |
There are two seperate sets of concerns: merging this branch to master, setting up the new documentation to a server. I don't think they need to be closely linked |
15:04 |
dluch |
Just need testing and signoff? |
15:04 |
Bmagic |
seperate/separate |
15:05 |
dluch |
But we have the new docs server...did we not put Antora stuff there? |
15:05 |
Bmagic |
that's the way it is - but it has not been linked officially on the Evergreen page |
15:20 |
Bmagic |
@karma Bmagic |
15:20 |
pinesol |
Bmagic: Karma for "Bmagic" has been increased 7 times and decreased 0 times for a total karma of 7. |
15:20 |
Bmagic |
that proves it for sure - bmagic was raised (thank you rfrasur) - and it affected Bmagic |
15:21 |
rfrasur |
bmagic++ # for testing whether or not case sensitivity comes into karmic play. |
15:21 |
Bmagic |
:) |
15:21 |
Bmagic |
rfrasur++ |
15:22 |
rfrasur |
rfrasur-- # it's cool. my contributions today have been subpar |
17:06 |
|
alynn26_away joined #evergreen |
17:16 |
|
jvwoolf joined #evergreen |
17:27 |
|
rjackson_isl_hom joined #evergreen |
18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
20:42 |
|
sandbergja joined #evergreen |
21:45 |
|
sandbergja_ joined #evergreen |
22:28 |
|
sandbergja joined #evergreen |
03:15 |
|
pastebot joined #evergreen |
03:15 |
|
jeff joined #evergreen |
03:29 |
|
mrisher joined #evergreen |
06:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
07:18 |
|
rfrasur joined #evergreen |
07:19 |
|
rjackson_isl_hom joined #evergreen |
08:15 |
|
Dyrcona joined #evergreen |
09:57 |
|
jvwoolf joined #evergreen |
10:12 |
Dyrcona |
I don't know what the problem is, but I often have to do a reingest on a database after restoring it from a dump. I assume that some process was updating a search-related table while the dump was being made, leaving things in an inconsistent state. |
10:13 |
Dyrcona |
When MVLC was on Horizon, we used to rebuild the OPAC search indexes on a weekly basis, and sometimes they'd still blow up and have to rebuilt in between times. I mention that because the search result pages look pretty much the same as in Evergreen when a reingest is called for. |
10:17 |
Dyrcona |
These blank results certainly make testing for a potential upgrade more difficult. Everyone suspects it is something in the upgraded code until the ingest finishes. Oh well, guess we're not upgrading next week. |
10:20 |
rfrasur |
-- |
10:20 |
* rfrasur |
has no answers. |
10:21 |
* Dyrcona |
doesn't expect any answers. |
15:06 |
jeff |
#info jeff = Jeff Godin, Traverse Area District Library (TADL) |
15:06 |
Dyrcona |
#topic Action Items from Last Meeting |
15:06 |
|
Topic for #evergreen is now Action Items from Last Meeting (Meeting topic: 2020-05-05 - Developer Meeting) |
15:07 |
Dyrcona |
#info csharp will arrange testing for sandbergja's fix to https://launchpad.net/bugs/1821094 on a realistic test server |
15:07 |
pinesol |
Launchpad bug 1821094 in Evergreen 3.3 "Item status refresh after editing can get confusingly slow" [Medium,Confirmed] |
15:07 |
csharp |
we installed the fix for bug 1821094 on a test server and one of our testers provided a comment on the bug |
15:08 |
csharp |
that's kind of where we left it as far as I'm aware |
15:08 |
sandbergja |
csharp++ |
15:08 |
Dyrcona |
So the action item is done. Is any more work required that merits a new action item? |
15:09 |
csharp |
I'll check on our end to see if they think the feature is ready |
15:46 |
Dyrcona |
Bmagic: If you want help with that, I'm sure we'll be able to make it happen. |
15:47 |
Bmagic |
cool, thanks for taking the time today to talk about that |
15:47 |
Dyrcona |
So, anything else for Evergreen releases? |
15:48 |
csharp |
Bmagic: looking forward to testing it out |
15:48 |
Bmagic |
csharp: feel free to click through what's there http://eg-docs.georgialibraries.org/prod/ |
15:49 |
csharp |
oh cool |
15:50 |
Dyrcona |
#topic New Business |
17:54 |
Bmagic |
I have a patch file for the target differing files - https://git-scm.com/docs/git-am doesn't seem to inform me how to make it patch *different* files |
17:55 |
Bmagic |
oh well - something for tomorrow - have a good evening Evergreen! |
18:00 |
berick |
Bmagic: oops, I mean 'git apply'. if the only difference is the path to the file, see the -p flag |
18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
18:05 |
|
sandbergja joined #evergreen |
18:37 |
|
sandbergja_ joined #evergreen |
20:14 |
|
sandbergja joined #evergreen |
03:56 |
|
mrisher joined #evergreen |
04:07 |
|
mrisher joined #evergreen |
05:40 |
|
mrisher joined #evergreen |
06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
07:35 |
|
rfrasur joined #evergreen |
08:03 |
|
dbwells joined #evergreen |
08:14 |
|
Dyrcona joined #evergreen |
11:25 |
Dyrcona |
Here are the results of doing the original update again, after undoing them: https://www.sigio.com/~jason/redochan.html |
11:26 |
Dyrcona |
And, here's the output from the cold update that shows the IFs taking a long time: https://www.sigio.com/~jason/firstchan.html |
11:31 |
Dyrcona |
BTW, I also verified that we have all of the expected indexes for Evergreen 3.2.8 this morning. In fact, we have a few extra indexes. |
11:36 |
Dyrcona |
Is the above Lp worthy? Out catalogers haven't been able to update Jackie Chan's authority record in production via the staff client because of the time it takes to update the 117 attached bibliographic records. I can update it successfully via SQL in the test database. |
11:42 |
Dyrcona |
I can try turning some of the NOTs into positive logic to see if that helps any.... |
11:44 |
Dyrcona |
Though on the one I'm eyeballing, I think it's the = ANY( attr_list) that contributes the most to the run time. |
11:55 |
|
mrisher joined #evergreen |
14:06 |
pinesol |
felicia wanted to retrieve ALL THE USERS. |
14:10 |
Dyrcona |
Well, I know who actually did it. Logged in, first thing, search for all of the patrons in the database, apparently give up, and start doing acq. |
14:35 |
Dyrcona |
Back to Jackie Chan, it still takes 2 minutes to update the authority record even with everything cached. |
15:12 |
pinesol |
[evergreen|Jeff Davis] LP#1865533: save changes on Edit Hold in My Account - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=69f9ec7> |
16:03 |
|
sandbergja joined #evergreen |
16:16 |
|
mantis1 left #evergreen |
16:49 |
|
mantis1 joined #evergreen |
16:55 |
|
jihpringle joined #evergreen |
17:06 |
|
mmorgan left #evergreen |
18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
18:11 |
|
abowling joined #evergreen |
19:45 |
|
Stompro joined #evergreen |
20:06 |
|
mantis1 joined #evergreen |
01:40 |
|
sandbergja joined #evergreen |
02:17 |
|
dbwells joined #evergreen |
03:15 |
|
dbwells joined #evergreen |
06:02 |
pinesol |
News from qatests: Failed Installing Angular web client <http://testing.evergreen-ils.org/~live//archive/2020-04/2020-04-29_04:00:02/test.29.html> |
07:11 |
|
agoben joined #evergreen |
07:42 |
|
rfrasur joined #evergreen |
07:55 |
|
Dyrcona joined #evergreen |
08:24 |
|
dbwells_ joined #evergreen |
08:39 |
|
mmorgan joined #evergreen |
08:40 |
|
mantis1 joined #evergreen |
09:23 |
pinesol |
[opensrf|Chris Sharp] LP#1272937 - Quiet warnings from autoreconf -i - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=982b22a> |
09:28 |
|
collum_ joined #evergreen |
09:36 |
|
collum joined #evergreen |
09:37 |
Dyrcona |
D'oh! |
10:09 |
Dyrcona |
Ha! |
10:10 |
Dyrcona |
@blame The Archies |
10:10 |
pinesol |
Dyrcona: The Archies is really just another name for autogen |
10:16 |
berick |
pgtap test fix if anyone wants it: working => user/berick/lp1858448-age-money-pgtap-repair |
11:42 |
pinesol |
[evergreen|Jason Stephenson] LP1873286: Fix Bad End Tags - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2d45e0f> |
11:42 |
pinesol |
[evergreen|Chris Sharp] LP#1873286 - Add release notes entry - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9a1cec8> |
11:56 |
|
mrisher joined #evergreen |
13:07 |
csharp |
bshum++ |
13:08 |
* rfrasur |
does shine the Evergreen Community Spotlight on bshum. Because he is particularly awesome as well as my birthday sharer. |
13:08 |
rfrasur |
bshum++ |
13:19 |
jeffdavis |
Hey, so we are testing 3.5 in preparation for an upgrade next month, and there's a long list of Angularized admin pages that simply aren't useable in real-world circumstances due to bug 1847800 and bug 1846042. Those issues have existed since at least 3.3 but the list is growing as more pages get migrated to Angular. |
13:19 |
pinesol |
Launchpad bug 1847800 in Evergreen "Missing links to secondary admin pages" [High,Confirmed] https://launchpad.net/bugs/1847800 |
13:19 |
pinesol |
Launchpad bug 1846042 in Evergreen 3.4 "Angular admin pages need filters" [High,Confirmed] https://launchpad.net/bugs/1846042 |
13:20 |
jeffdavis |
We are probably going to be pointing people to the old, pre-Angularized UIs in a lot of cases, which is what we did last year for our 3.3 upgrade. |
13:33 |
jeffdavis |
Dyrcona: I think they're critical, but more curious to get others' feedback. I also know we're on the brink of the 3.5.0 release, so... |
13:34 |
Dyrcona |
We're planning to do RC1 today. |
13:34 |
Dyrcona |
The calendar says 3.5.0, but that hasn't been updated. |
13:37 |
* Dyrcona |
tries to remember how to run pgTap tests. |
13:38 |
Dyrcona |
pg_prove... right. |
13:41 |
|
sandbergja joined #evergreen |
13:50 |
pinesol |
[evergreen|Bill Erickson] LP1858448 Aged money pgtap test repair - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7a66de5> |
13:52 |
csharp |
jeffdavis: we've been managing those similarly - by changing the Admin page to link to the dojo versions |
13:53 |
Dyrcona |
Well, I think more pertinent issue is will they be fixed for the 3.5.0 release? |
13:54 |
csharp |
I can look after I finish this reports template I can't seem to get done :-/ |
16:41 |
|
sandbergja joined #evergreen |
17:20 |
|
mmorgan left #evergreen |
17:32 |
|
jihpringle joined #evergreen |
18:00 |
pinesol |
News from qatests: Failed Installing Angular web client <http://testing.evergreen-ils.org/~live//archive/2020-04/2020-04-29_16:00:02/test.29.html> |
19:48 |
|
jihpringle54 joined #evergreen |
22:58 |
|
mrisher joined #evergreen |
03:05 |
|
dbwells joined #evergreen |
05:07 |
|
dbwells joined #evergreen |
06:01 |
|
dbwells joined #evergreen |
06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
06:29 |
|
Dyrcona joined #evergreen |
07:10 |
|
rfrasur joined #evergreen |
07:24 |
|
rjackson_isl_hom joined #evergreen |
08:19 |
|
mmorgan joined #evergreen |
08:27 |
|
mantis1 joined #evergreen |
09:05 |
|
dbwells joined #evergreen |
09:19 |
csharp |
rfrasur: last we tested, we saw the errors shown in the bug comments. I don't specifically remember which ones, but pretty sure the circ UIs weren't loading as a consequence |
09:19 |
csharp |
(been testing a lot of bugs lately, so I may be conflating that with another issue, but I think that's right) |
09:20 |
rfrasur |
Right. Is there any impetus to fix it? I know there's LOTS and lots going on. |
09:49 |
|
jvwoolf joined #evergreen |
09:52 |
|
sandbergja joined #evergreen |
09:58 |
mmorgan |
rhamby: Are you still looking at bug 1482757? |
09:58 |
pinesol |
Launchpad bug 1482757 in Evergreen 3.1 "Loading records with located URIs should not delete and recreate call_numbers" [Low,Confirmed] https://launchpad.net/bugs/1482757 |
09:59 |
rhamby |
mmorgan: I had in the past and have a lightly tested branch somewhere but saw you pushed one the other day so I have it on my todo list to test your branch |
09:59 |
rhamby |
mmorgan: hopefully this week though it's a crazy busy week for me |
10:00 |
mmorgan |
Okay, great! Do you think it's appropriate to target it as a bug fix? |
10:00 |
rhamby |
I think so. I could argue it either way but I think it falls on the bug fix side. |
10:03 |
mmorgan |
Ok, thanks, I'll add targets. |
11:08 |
berick |
Dyrcona++ # osrf timeout testing |
11:08 |
berick |
mmorgan: rhamby: +1 to treating that as a bug |
11:09 |
Dyrcona |
berick++ # timeout fixing |
11:25 |
|
CBrown joined #evergreen |
11:34 |
CBrown |
Good Morning! I hope that everyone is well. By chance, is anyone using the Bibliotheca inventory wand? If so, a question on the settings configurations in the Bibliotheca Inventory Reader app for the LMS setup. Evergreen is not listed in the dropdown box of LMS, do you know which LMS we'd select instead? |
13:26 |
pinesol |
[evergreen|Jason Stephenson] LP 1772053: Cleanup Dan's code. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4629b27> |
13:26 |
pinesol |
[evergreen|Chris Sharp] LP#1772053 - Fix minor typos - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=44d3de1> |
13:26 |
miker |
jeffdavis: I suspect the old UI was using a dedicated call to get just those resources owned at or "below" the ws_ou, rather than the magical pcrud fm-editor stuff |
13:30 |
jeffdavis |
Hm, I'll take a look. Also going re-test adding the scoped retrieve perm to fm_IDL.xml (both of them). Could be pebkac. |
13:36 |
|
rjackson_isl_hom joined #evergreen |
13:49 |
Dyrcona |
berick: I've tested your latest changes on Lp 1858448 and the upgrade scripts have worked for me also in a variety of scenarios, including against our production database where a little modification was required. |
13:49 |
pinesol |
Launchpad bug 1858448 in Evergreen 3.4 "Aged Payment (and Billing) Table Breaks Cash Report and Removes Relevant Payment Tracking Abilities" [High,Confirmed] https://launchpad.net/bugs/1858448 |
13:49 |
Dyrcona |
Should I just signoff or are you OK with me pushing the branches to master, rel_3_5, and rel_3_4? |
14:02 |
berick |
Dyrcona: i'm ok w/ you pushing them, thanks! |
14:53 |
Dyrcona |
OK. All fixed! Sorry for the commit inflation... Been too long since I pushed an upgrade script, I guess. |
14:54 |
Dyrcona |
berick++ csharp++ dpearl++ # Though he's retired. |
14:54 |
pinesol |
[evergreen|Jason Stephenson] Lp 1858448: Fix version number in upgrade script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=badd829> |
15:10 |
jeffdavis |
I must have made a mistake in testing before. Adding a resource type retrieve perm with context_field is limiting the list appropriately now. |
15:24 |
pinesol |
[evergreen|Jeff Davis] LP#1848550: client-side caching of org settings for AngularJS - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=83e1820> |
15:24 |
pinesol |
[evergreen|Bill Erickson] LP1854850 Angular IndexedDB Shared Worker Communication - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=8c9187e> |
15:24 |
pinesol |
[evergreen|Bill Erickson] LP1848550 Cache org settings in IndexedDB (Angular) - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9e8d662> |
15:24 |
pinesol |
[evergreen|Bill Erickson] LP1848550 / LP1835128 Redirect to AngJS splash page - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=fe76f62> |
15:32 |
|
mantis1 left #evergreen |
16:05 |
|
sandbergja joined #evergreen |
16:51 |
|
jvwoolf left #evergreen |
17:13 |
|
mmorgan left #evergreen |
17:36 |
|
sandbergja joined #evergreen |
17:56 |
|
sandbergja joined #evergreen |
18:01 |
pinesol |
News from qatests: Failed Installing Angular web client <http://testing.evergreen-ils.org/~live//archive/2020-04/2020-04-28_16:00:03/test.29.html> |
18:13 |
|
rjackson_isl_hom joined #evergreen |
18:16 |
phasefx |
that error aside, there was also a pgtap test failure with aged circs, which is related to recent commits: http://testing.evergreen-ils.org/~live//archive/2020-04/2020-04-28_16:00:03/test.47.html |
18:16 |
phasefx |
aged billing, rather |
18:52 |
|
rjackson_isl_hom joined #evergreen |
19:38 |
|
sandbergja joined #evergreen |
20:04 |
|
rjackson_isl_hom joined #evergreen |