| 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 |
| 00:16 |
|
sandbergja joined #evergreen |
| 01:07 |
|
sandbergja joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 08:07 |
|
Stompro joined #evergreen |
| 10:46 |
|
Dyrcona joined #evergreen |
| 11:02 |
|
sandbergja joined #evergreen |
| 17:54 |
bshum |
@pinesol unload Karma |
| 17:54 |
pinesol |
bshum: Have you tried taking it apart and putting it back together again? |
| 17:54 |
bshum |
:D |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:01 |
bshum |
Evergreen++ |
| 18:01 |
bshum |
@karma Evergreen |
| 18:01 |
pinesol |
bshum: Karma for "Evergreen" has been increased 1 time and decreased 0 times for a total karma of 1. |
| 18:01 |
bshum |
Okay - final Karma was archived output for 2019 to https://evergreen-ils.org/~bshum/karma.final.2019.txt |
| 18:56 |
|
sandbergja joined #evergreen |
| 19:32 |
bshum |
Whoa, I had a minor freakout when looking at top in my new Ubuntu 20.04 VM before I realized that it was showing it in MiB Mem not KiB Mem :D |
| 19:32 |
bshum |
Guess they changed the defaults, hehe |
| 19:44 |
bshum |
Well, 2nd attempt at Ubuntu 20.04 and OpenSRF went better today once I ripped out all the Python dependencies from OpenSRF's Makefile :D |
| 19:45 |
bshum |
We'll need to rewrite the steps to config for ejabberd since they completely removed mod_legacy_auth from the parameters listing, but it's still easy enough to add it back in |
| 19:45 |
bshum |
So looks like the option is missing from the default, but the underpinnings are still there |
| 19:45 |
bshum |
Basic opensrf.math test successful, so simple comms are working at least :) |
| 19:45 |
* bshum |
wanders off to dinner |
| 20:27 |
|
sandbergja joined #evergreen |
| 22:36 |
|
sandbergja joined #evergreen |
| 23:45 |
|
sandbergja joined #evergreen |
| 02:31 |
|
dbwells joined #evergreen |
| 04:33 |
|
dbwells joined #evergreen |
| 06:01 |
|
dbwells joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:13 |
|
Dyrcona joined #evergreen |
| 07:32 |
|
rfrasur joined #evergreen |
| 07:55 |
|
jvwoolf joined #evergreen |
| 10:32 |
Dyrcona |
berick++ Thanks! |
| 10:33 |
Dyrcona |
I discovered that miker's ack example didn't find tags that spanned multiple lines. So, I'll have to work out a way to find those. |
| 10:34 |
Dyrcona |
I may have to write something in awk or Perl to do what I want. |
| 10:52 |
csharp |
berick: I was working on (with Terran) testing the receipt printer fixes that are targeted to 3.5.0 - would those be considered fixes or features in the context of our release? |
| 10:53 |
csharp |
https://launchpad.net/evergreen/+milestone/3.5.0 (Web client print receipts - several bugs with a single fix) |
| 10:55 |
berick |
csharp: those look like bug fixes to me |
| 10:59 |
csharp |
ok - cool - I'll work on getting them tested |
| 11:05 |
|
sandbergja joined #evergreen |
| 12:06 |
|
mrisher joined #evergreen |
| 12:07 |
csharp |
Bmagic: I'm thinking we could cut out the circular pictures of our heads and use them as game tokens - whataya think? https://evergreen-ils.org/wp-content/uploads/2020/04/Annual-Report-2019-Web-Ready.pdf |
| 12:08 |
Bmagic |
yes! |
| 12:08 |
Bmagic |
csharp++ |
| 12:10 |
Bmagic |
csharp: You are featured in 2015 pretty much exemplifying that exact notion https://evergreen-ils.org/wp-content/uploads/2017/03/Evergreen-Annual-Report-2016-Lower-Resolution.pdf |
| 16:25 |
phasefx |
I thnk there is a way to get websockets running through port 80, but I don't have hands on experience with that |
| 16:25 |
phasefx |
or 443, rather |
| 16:26 |
|
angelo joined #evergreen |
| 16:30 |
jammin |
phasefx: I'm in a spot like that with a test server. selfsigned cert vs websockets, etc. going to port 7682 gives me an ssl protocol error... haven't touched it since then, had other things pop up, but need to get in there and sort it out, don't remember what state I left it in. |
| 16:32 |
* phasefx |
uses let's encrypt these days and exposes his dev server to the internet, but he used to have to approve self-signed certs on both 443 and 7682 |
| 16:51 |
|
mmorgan1 joined #evergreen |
| 17:01 |
|
AFloyd__ joined #evergreen |
| 17:41 |
jammin |
And there's enough going on in that schema without making it worse with castaways. |
| 17:51 |
|
alynn26 joined #evergreen |
| 17:56 |
|
alynn26_away joined #evergreen |
| 18:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:19 |
jammin |
Well, I couldn't find any of the following views in fm_IDL.xml, or any references to them in the sql source (Open-ILS/src/sql/Pg) other than their own creation statements:money.cashdrawer_payment_view, money.open_transaction_billing_summary, money.open_transaction_billing_type_summary, money.open_transaction_payment_summary, |
| 18:19 |
jammin |
money.transaction_billing_summary, money.transaction_billing_type_summary, money.transaction_billing_with_void_summary, money.transaction_payment_summary, money.transaction_payment_with_void_summary |
| 18:21 |
jammin |
So, money.cashdrawer_payment_view, and any of the money.transaction* views. |
| 04:50 |
|
alynn26_away joined #evergreen |
| 04:54 |
|
alynn26 joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:24 |
|
rjackson_isl_hom joined #evergreen |
| 07:33 |
|
rfrasur joined #evergreen |
| 07:48 |
|
Dyrcona joined #evergreen |
| 10:18 |
|
sandbergja joined #evergreen |
| 10:35 |
|
AFloyd__ joined #evergreen |
| 10:49 |
|
alynn26_away joined #evergreen |
| 11:06 |
Dyrcona |
gmcharlt: Do you think jquery-migrate (https://github.com/jquery/jquery-migrate/) could help with bug 1873286? I'm thinking about adding it on my test VM later to see what comes up in the console. |
| 11:07 |
pinesol |
Launchpad bug 1873286 in Evergreen 3.4 "jQuery 3.5.0 breaks at least AngularJS interfaces" [Critical,Confirmed] https://launchpad.net/bugs/1873286 |
| 11:11 |
gmcharlt |
Dyrcona: looks like it's worth trying |
| 11:12 |
gmcharlt |
certainly beats trying to manually dig through all indirect uses of jquery |
| 11:16 |
Dyrcona |
Yeahp. I'm going to try it on 3.2.8 right now, then later on master. We may get different results on different releases. |
| 11:41 |
Dyrcona |
oops. I should have cleaned up the reports tables before starting the reporter on my test vm.... I hope no emails went out, or I'll have some confused staff. |
| 11:50 |
Dyrcona |
Hmm.. I seem to have the legacy reports interface. How do I enable the AngularJS interface? |
| 11:51 |
Dyrcona |
I get a lot of deprecated messages from jquery migrate. |
| 12:08 |
Dyrcona |
jQuery migrate doesn't pick up on the non-closing tags in the volume/copy editor. The only thing it reports is: jQuery.fn.bind() is deprecated |
| 15:39 |
|
mantis1 left #evergreen |
| 15:43 |
Dyrcona |
csharp: I made a mistake the other day when I answered your question about being to alter a commit after it has been pushed to master. The correct answer is we can't fix it. I was looking at the gitolite configuration again and no one has permission to rewrite master, so no force push is allowed. |
| 15:46 |
|
alynn26 joined #evergreen |
| 16:11 |
Dyrcona |
berick++ # I suspect you've found and fixed the source of our mysterious timeouts. I'll try your branch on test and training and see if I can get in production, soon. |
| 16:15 |
berick |
Dyrcona: yeah, i was thinking it might be at least partially to blame for some of the recent osrf woes |
| 16:20 |
Dyrcona |
I'm signing out for now. I've got plenty more to do tomorrow. ;) |
| 16:27 |
|
dbwells_ joined #evergreen |
| 16:43 |
|
mrisher joined #evergreen |
| 17:05 |
|
jihpringle joined #evergreen |
| 17:09 |
|
mmorgan left #evergreen |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 21:46 |
|
mrisher joined #evergreen |
| 22:02 |
|
mrisher joined #evergreen |
| 00:01 |
|
Stompro joined #evergreen |
| 04:58 |
|
alynn26_away joined #evergreen |
| 05:00 |
|
AFloyd__ joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:23 |
|
rjackson_isl_hom joined #evergreen |
| 07:40 |
|
rfrasur joined #evergreen |
| 08:28 |
|
Stompro joined #evergreen |
| 10:12 |
sandbergja |
Any tips for recreating that? |
| 10:12 |
pinesol |
Launchpad bug 1873286 in Evergreen 3.4 "jQuery 3.5.0 breaks at least AngularJS interfaces" [Critical,Confirmed] https://launchpad.net/bugs/1873286 |
| 10:15 |
sandbergja |
oh, maybe I should enable jquery in config.tt2 first :-) |
| 10:16 |
Dyrcona |
sandbergja: It may be our customization, but yeah, try enabling jQuery. I was going to test later with a stock master. |
| 10:21 |
Dyrcona |
As for recreating it, all I did was open the OPAC in a browser, or search the catalog from the AngularJS staff client, and Internal Server Error, so I suspect it is some interaction with our customization and jQuery 3.5.0, but I don't know why, since none of that should run on the server. |
| 10:47 |
|
dbwells_ joined #evergreen |
| 10:48 |
|
dbwells joined #evergreen |
| 15:53 |
|
mantis1 left #evergreen |
| 15:54 |
abowling |
jeffdavis: gmcharlt: et al. wondering if you had any immediate ideas as to gotchas on open-ils.ebook_api.check_session might be throwing an error (from a configuration standpoint; not from a request method structure standpoint) |
| 15:55 |
abowling |
i.e. would it be affected by perms configuration? |
| 15:58 |
jeffdavis |
Probably not a perm issue. |
| 16:00 |
jeffdavis |
curl -H "Content-Type: application/x-www-form-urlencoded;charset=UTF-8" -H "Authorization: Basic $BASIC_TOKEN" -X POST -d 'grant_type=client_credentials' https://oauth.overdrive.com/token |
| 16:00 |
jeffdavis |
abowling: ^ does that give you an error message, or a JSON string like {"access_token":"gibberish"} ? |
| 16:01 |
jeffdavis |
(substituting your Overdrive Basic Token of course) |
| 16:03 |
jeffdavis |
You can also use this Perl script for more thorough testing to confirm your credentials/settings are valid: http://git.sitka.bclibraries.ca/gitweb/?p=sitka/sitka-tools.git;a=blob;f=overdrive-eg-opac/odapi-checker.pl |
| 16:16 |
abowling |
jeffdavis: actually, log-checking sooner might have helped me. turns out, it seems it's an issue with the API not returning |
| 16:16 |
abowling |
[ERR :10117:RBDigital.pm:225:15875511017258630] EbookAPI: Unable to get patron Id from RBDigital portal: Patron not found. |
| 16:16 |
abowling |
ergo, OpenSRF is behaving properly; the vendor API is not |
| 17:46 |
|
dbwells joined #evergreen |
| 17:51 |
|
rashma_away joined #evergreen |
| 17:51 |
|
pastebot joined #evergreen |
| 18:10 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:11 |
|
jgoodson joined #evergreen |
| 18:11 |
|
phasefx_ joined #evergreen |
| 18:11 |
|
rhamby joined #evergreen |
| 09:38 |
Bmagic |
yep |
| 09:39 |
Dyrcona |
I thinks that's easier with xslt, but you can't use xslt with crad. |
| 09:40 |
Bmagic |
what's crad? |
| 09:40 |
Bmagic |
I'm working in the config.metabib_field table - reingesting a test record and then seeing what indexes were created |
| 09:41 |
Dyrcona |
config.record_attr_definition |
| 09:42 |
Bmagic |
oh - that is a different issue that I've put on hold |
| 09:42 |
Dyrcona |
You can probably do it there with a joiner, but you can't have two joiners. |
| 09:59 |
Bmagic |
removing the second 600 for now - leaves me with just one index from your recommended settings. The index that is preceeded with the double dash |
| 09:59 |
Dyrcona |
It has been a few years since I messed with this stuff much, so I'm a bit rusty. |
| 10:03 |
Bmagic |
all of the other marcxml index definitions that have joiners are using a " " space. So I wonder if those are also resulting in a preceeding space but it's not noticable |
| 10:07 |
Bmagic |
well now I am really confused - I updated the index to have a joiner space ' ', reingested the test record. And I still get "-- Wesley, John, -- -- 1703-1791 -- -- Bibliography. --" lol |
| 10:08 |
Bmagic |
I'm betting that the new definition wasn't different enough for it to recalculate |
| 10:09 |
Dyrcona |
Browsers generally compress multiple spaces into 1. |
| 10:10 |
Bmagic |
but why is it putting in the dashes when the joiner is a space? |
| 10:30 |
Bmagic |
sounds like the correct solution - I'm still confused on this dash thing. I guess it's time to just delete it |
| 10:31 |
miker |
browse entries do not get deleted once added, but the map to the source bib should be removed unless you have flags turning off browse ingest or something |
| 10:31 |
Bmagic |
putting malformed xslt in the database will probably be a bad thing, so it makes me slightly nervous. |
| 10:32 |
miker |
it would do bad things. but that's why you test with xsltproc at the command line :) |
| 10:32 |
Bmagic |
ah! - so the index that I see is leftover from a previous definition. And the new definition isn't matching (or something) - and therefore the engine doesn't re-process the index, leaving the old one there |
| 10:33 |
Bmagic |
well no, I tested that theory by deleting the 600 from the marc, saw that the index was also removed from metabib.browse_entry. Then put the tag back, and the friggin dashed index came back... pointing to my definition with a null joiner |
| 10:35 |
Dyrcona |
Bmagic: you may already have something processing the 600 tag, and your addition was not matching because of the extra stuff in the xpath field. |
| 10:35 |
Dyrcona |
I suggest select id, xpath from config.metabib_field; |
| 10:36 |
mmorgan |
But the metabib.browse_entry was pointing to definition 1003 ... |
| 11:00 |
Dyrcona |
mutlitasking-- |
| 11:00 |
Dyrcona |
or multitasking, take your pick. :) |
| 11:04 |
* mmorgan |
is not a fan of multitasking. Start many projects, finish none. |
| 11:04 |
Bmagic |
miker: when testing with xsltproc - can I just copy/paste the marc xml into a file and pass that in the second argument? |
| 11:05 |
miker |
Bmagic: that should work |
| 11:05 |
Bmagic |
wrapped in <collection> ? |
| 11:09 |
Bmagic |
I just ran the raw 880 template against the marc xml - seemed to work, though I'm not sure what to expect. It seemed to simply dump the xml back out |
