04:41 |
|
malexander joined #evergreen |
04:48 |
|
dbwells joined #evergreen |
05:40 |
|
dbwells joined #evergreen |
06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
06:09 |
|
dbwells joined #evergreen |
07:16 |
|
rjackson_isl_hom joined #evergreen |
08:03 |
|
mantis1 joined #evergreen |
08:35 |
csharp |
miker: unfortunately, the sideloader consumed all available RAM and swap on the server and it locked up (64GB/8 core testing standalone DB server) |
08:35 |
csharp |
miker: last message from the script was Dictionary built in 9840 seconds, writing.. |
08:54 |
|
jvwoolf joined #evergreen |
09:04 |
miker |
csharp: that's ... very strange. once it starts writing the file, it should start /decreasing/ in ram use because it starts deleting keys from the huge hash. I have not seen any other behavior in my testing :( |
09:06 |
miker |
csharp: curious what version of perl is on that server... |
09:06 |
|
Dyrcona joined #evergreen |
09:09 |
|
alynn26 joined #evergreen |
09:23 |
csharp |
miker: 5.26.1 |
09:33 |
Dyrcona |
My development DB server is an old mail server with 128GB of RAM and 8TB of disk space, so I run multiple versions of Pg with multiple copies of production data. |
09:34 |
|
dbwells joined #evergreen |
09:34 |
Dyrcona |
I'm trying to find the bug number in yesterday's log. |
09:35 |
miker |
csharp: fwiw, I suspect it's the number of suggestions on very short prefix keys, especially coming from the "keyword" data. there are runtime rules about what suggestions can be ignored, and I'm going to cull suggestions that wouldn't pass that test. the only way I can think of memory increasing during the write phase is if there are 10s of thousands of suggestions on a key (and even then, we should be talking MB, not GB, of RAM)... but we shall see |
09:36 |
Dyrcona |
OK. Got the branch. I'll take a look just to see how it works for us.We have 2.3 million not deleted bibs. |
09:41 |
Dyrcona |
Um. Is git.evergreen-ils.org down? |
09:44 |
csharp |
miker: If I can provide any data from my end, let me know |
01:04 |
|
devted joined #evergreen |
01:04 |
|
Bmagic joined #evergreen |
05:27 |
|
khuckins joined #evergreen |
06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
06:20 |
|
khuckins joined #evergreen |
08:02 |
|
mantis1 joined #evergreen |
08:18 |
|
collum joined #evergreen |
11:06 |
rhamby |
if anyone wants a modest patch to look at before cut off today I'll throw out https://bugs.launchpad.net/evergreen/+bug/1904593 |
11:06 |
pinesol |
Launchpad bug 1904593 in Evergreen "yaous for my account url" [Wishlist,Confirmed] - Assigned to Rogan Hamby (rogan-hamby) |
11:07 |
rhamby |
at least one consortia I know is eager to distinguish the my account url and though not widely used yet getting org unti settings in PrintTemplate.pm would be nice |
11:15 |
Dyrcona |
I tried upgrading a test VM from 3.5.3 to master so I could test 1207533, and now I can't login via the staff client. All I see in syslog is "Creating new event: LOGIN_FAILED" |
11:15 |
Dyrcona |
I cleared all local data before attempting to login. |
11:52 |
|
sandbergja joined #evergreen |
11:58 |
|
jihpringle joined #evergreen |
14:20 |
Dyrcona |
We probably need a custom filter. |
14:26 |
JBoyer |
Now I'm curious what happens when you use the login redirector with multiple query params... |
14:27 |
JBoyer |
Because either it will be broken too (though it's significantly less likely to happen there) or if it's not broken, whatever mechanism it uses needs to be used for holds. |
14:28 |
Dyrcona |
IDK, I just noticed it today while trying to test bug 1207533. I thought it was my test server until I tried on training afterward. |
14:28 |
pinesol |
Launchpad bug 1207533 in Evergreen "Triggered event log times out for large-data sites" [Medium,Confirmed] https://launchpad.net/bugs/1207533 |
14:29 |
Dyrcona |
Should we Lp it? |
14:29 |
JBoyer |
Huh, well the login thing worked as expected. Better look at why... |
15:02 |
Dyrcona |
Interesting little detail: I have to do a search, first. If I click a carousel entry and place the hold from the details page, no crash. If I search first and place a hold, either from results or the details page, crash. I haven't managed a one hit search to see what happens there, but I suspect no crash. |
15:04 |
miker |
csharp / mmorgan: there's a new commit at the top of https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/lp-1893997-did-you-mean |
15:09 |
Dyrcona |
miker++ csharp++ mmorgan++ JBoyer++ |
15:22 |
csharp |
miker++ |
15:22 |
csharp |
I'll test soon |
15:23 |
miker |
csharp: thanks! let me know if you hit any snags ... the upgrade script describes how to generate the COPY sql, should be straightforward (I hope) |
15:23 |
csharp |
good - going to restore our DB to a fresh image, then test |
15:24 |
miker |
csharp: unrelated, except that it's feature freeze rush day, do you know if Terran will have a chance to look at the lasso changes? |
15:24 |
mmorgan |
miker++ |
15:24 |
csharp |
miker: I'll check with Terran |
15:24 |
miker |
csharp: fwiw, you can test the sideloader without any DB involvement, at tleast as far as getting the COPY file |
15:24 |
* gmcharlt |
grabs 1251, again, for real |
15:25 |
csharp |
miker: did you see https://bugs.launchpad.net/evergreen/+bug/1815815/comments/21 ? |
15:25 |
pinesol |
Launchpad bug 1815815 in Evergreen "Bringing lassos back: library groups functionality" [Wishlist,New] |
15:26 |
miker |
csharp: I did not, going to look now |
15:26 |
csharp |
miker: ah - I'll just see how that part goes - thanks |
15:26 |
miker |
ah, well, I can certainly rebase |
15:27 |
mmorgan |
miker: csharp: I'm taking a look, but not sure I have actual data to test on. |
15:27 |
csharp |
ls |
15:27 |
csharp |
doh |
15:27 |
|
mantis1 left #evergreen |
15:28 |
pinesol |
[evergreen|Kyle Huckins] lp1861319 Expired Patron Item Renewal - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=eb2f12e> |
15:28 |
pinesol |
[evergreen|Kyle Huckins] lp1861319 Auto-Renew/OPAC Renewal Compatibility - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e5f46bb> |
15:28 |
pinesol |
[evergreen|Jason Stephenson] Lp 1861319: Repair expire setting logic - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=45d69d3> |
15:28 |
pinesol |
[evergreen|Jason Stephenson] Lp 1861319: Add Release Notes and Perl Live Tests - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9adf235> |
15:28 |
pinesol |
[evergreen|Galen Charlton] LP#1861319: stamp schema update - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1fc6ed0> |
15:28 |
miker |
mmorgan: did you mean? any data will do :) I'm confident in the speed, but would appreciate a second set of eyes on the output (and I'm willing to keep fighting it during slush if we're happy getting it into freeze) |
15:30 |
mmorgan |
Ok! will see what I can do! |
15:35 |
gmcharlt |
it is always a good day when one gets to use "fell swoop" in a release notes entry |
15:37 |
csharp |
:-) |
15:39 |
|
stephengwills joined #evergreen |
15:40 |
miker |
csharp: terranm will get an email from LP in 15 min about the new rebase :) |
15:41 |
csharp |
miker: I rode my horse through the sleet and freezing rain to deliver the message - she's testing again now |
15:42 |
miker |
csharp++ |
15:42 |
csharp |
s/rode my horse through the sleet and freezing rain/sent her a chat/ |
15:44 |
|
dbwells joined #evergreen |
16:43 |
csharp |
miker: there's a stray conflict marker in https://git.evergreen-ils.org/?p=working/Evergreen.git;a=blobdiff;f=Open-ILS/src/perlmods/lib/OpenILS/WWW/EGCatLoader/Util.pm;h=f98c0912143760a46ea7c438a24a35813142a36e;hp=33cf92d7315401830ad258cd3c17f300ebd168d7;hb=4b5268385d516be5b80f6f4cd5489124c08df7ab;hpb=854ce8839747c50d50eb9f2e8b505594c4a89162 |
16:44 |
miker |
csharp: uuuuugh. sorry, will get that now |
16:44 |
miker |
csharp: but you can just chop that out if you want to locally |
16:46 |
csharp |
yeah, did it locally and Terran is back to testing |
16:47 |
miker |
csharp: I force-pushed an update to the branch (rewrote history with the marker removal) |
16:47 |
csharp |
cool |
16:47 |
miker |
thanks for alerting me! :) |
17:37 |
pinesol |
[evergreen|Bill Erickson] LP1908444 Support browse search record result sorting - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=8442ed7> |
17:48 |
|
dbwells joined #evergreen |
17:50 |
gmcharlt |
hi - calling on any available committer to review and merge my pull request for bug 1918511, which implements our decision yesterday to make the Bootstrap skin the default |
17:50 |
pinesol |
Launchpad bug 1918511 in Evergreen "make Bootstrap the default public catalog skin" [Wishlist,Confirmed] https://launchpad.net/bugs/1918511 |
17:59 |
|
dbwells joined #evergreen |
18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
18:04 |
miker |
gmcharlt: will do in a few minutes |
18:16 |
|
dbwells joined #evergreen |
18:17 |
miker |
gmcharlt: complete |
05:01 |
pinesol |
News from qatests: Failed Installing OpenSRF pre-requisites <http://testing.evergreen-ils.org/~live//archive/2021-03/2021-03-09_04:00:04/test.7.html> |
06:57 |
|
rjackson_isl_hom joined #evergreen |
07:20 |
|
wsmoak joined #evergreen |
07:59 |
|
collum joined #evergreen |
15:13 |
Dyrcona |
I think we have too many rewrites going on and everything feels half-baked. It should be experimental until its done, then we can have a good 4.0 release in a year or so. |
15:14 |
|
jwoodard joined #evergreen |
15:15 |
sandbergja |
gmcharlt: holding off on deprecation, but still making bootstrap default seems good to me. |
15:16 |
JBoyer |
I don't really anticipate it ever being "finished" if it's just a thing that systems play with on test servers. It would also be hard to tell devs working on opac features they have to focus on the one that's off by default or do everything twice. |
15:17 |
csharp |
well, we are running it without major problems in PINES, so it's definitely beyond test server status |
15:17 |
Dyrcona |
I don't think I expressed myself as well as I could have, but so be it. |
15:18 |
csharp |
Dyrcona: I agree with your point that we're in a half-baked status with a lot of our major UIs: bootstrap, ang OPAC, etc. |
15:19 |
JBoyer |
Heh, moving to the bootstrap opac over the course of the next couple major releases is one way to get rid of all of the dojo in the opac. :) |
15:28 |
mmorgan |
Ok, thanks! |
15:28 |
gmcharlt |
I think geographic sorting (bug 1863252) is close, but any testers available for today/tomorrow? |
15:28 |
pinesol |
Launchpad bug 1863252 in Evergreen "Wish List - Ability to sort holdings in OPAC based on geographic proximity to user specified location" [Wishlist,New] https://launchpad.net/bugs/1863252 |
15:28 |
shulabear |
I'd be available to test it tomorrow. |
15:29 |
gmcharlt |
also noting that we found some testing issues re consolidate patron notes/alerts/message (bug 1846354); I'm personally a bit dubious about it make it in tomorrow, but I do think that we need to get it in as early as possible during the 3.8 cycle |
15:29 |
pinesol |
Launchpad bug 1846354 in Evergreen "wishlist: Consolidate patron notes, alerts, and messages" [Wishlist,New] https://launchpad.net/bugs/1846354 - Assigned to Galen Charlton (gmc) |
15:29 |
gmcharlt |
shulabear++ |
15:30 |
gmcharlt |
and a general plea for scale testers of triggered events log rewrite (bug 1207533) |
15:30 |
pinesol |
Launchpad bug 1207533 in Evergreen "Triggered event log times out for large-data sites" [Medium,Confirmed] https://launchpad.net/bugs/1207533 |
15:30 |
gmcharlt |
miker: what did you want to bring up? |
15:30 |
terranm |
We tested notes consolidation late last week and didn't find any problems, but I didn't go through all the comments to verify |
15:30 |
miker |
terranm: first, thanks for all the lasso testing so far! do you think you'd have a chance to look at the record detail copy table changes on festivus? |
15:30 |
terranm |
I was mainly testing conversion |
15:30 |
gmcharlt |
terranm: we subsequently found issues related to it re patron merging and purging |
15:31 |
terranm |
miker: Yes, I can look tomorrow if that's not too late |
15:31 |
gmcharlt |
but it's definitely good that the conversion is looking good to you |
15:31 |
miker |
(note, but both tpac and boopac are lasso-adjusted -- they share the relevant code) |
15:31 |
miker |
terranm: thanks. as for if that's too late ... |
15:31 |
gmcharlt |
csharp: DYM still building on your test system? |
15:32 |
csharp |
gmcharlt: yep |
15:32 |
miker |
is feature freeze tomorrow EOD or at midnight in 8.5 hours |
15:32 |
csharp |
still on "identifier" |
15:36 |
pinesol |
Launchpad bug 1901930 in Evergreen "Evergreen SIP2Mediator Support" [Wishlist,New] https://launchpad.net/bugs/1901930 |
15:36 |
JBoyer |
Dyrcona, not a bad idea; I always thought the "feature" part was the significant bit, so no more features after tomorrow (like DYM or geosort) but smaller bugfixes would still be ok. |
15:36 |
gmcharlt |
^ yeah |
15:36 |
csharp |
oooh - I keep meaning to test that and keep getting derailed (SIP2Mediator) |
15:38 |
gmcharlt |
berick: out of curiosity, are you y'all running that in production (particularly with your sorter?) |
15:38 |
berick |
gmcharlt: not yet. soon, though |
15:39 |
rhamby |
I had been wanting to test that so I'm willing to do so tonight / tomorrow. |
15:41 |
csharp |
52,071,071 lines in that file (wc -l took a while) |
15:42 |
gmcharlt |
I'm personally a bit dubious about rushing that one in - while it /mostly/ stands off to the side, the new interface for managing SIP2 accounts could very much give the wrong impression if you don't want to jump off SIPServer right away |
15:43 |
gmcharlt |
so, are there any other new feature pull requests that anybody wants to strongly advocate for putting in tomorrow? |
15:50 |
pinesol |
Launchpad bug 1207533 in Evergreen "Triggered event log times out for large-data sites" [Medium,Confirmed] https://launchpad.net/bugs/1207533 - Assigned to Jason Stephenson (jstephenson) |
15:50 |
rfrasur |
also like to see 1853006 go in, and then we can look at bootstrap update to it. |
15:50 |
mmorgan |
csharp++ |
15:51 |
JBoyer |
Looks like there's a lot of good stuff to test out tomorrow, anyone have anything else they want to bring up before we move on? |
15:52 |
JBoyer |
tick |
15:52 |
JBoyer |
tick |
15:52 |
JBoyer |
#topic DIG evaluating outstanding 3.6 documentation and turning to 3.7 |
16:08 |
csharp |
JBoyer: Dyrcona: happy to help with dojo destruction/docs |
16:08 |
JBoyer |
. # startmeeting csharp volunteers... |
16:08 |
JBoyer |
;) |
16:09 |
terranm |
shulabear: Do you have a test server you can load the geosort stuff on, or do you want me to load it onto mine? I have a Google API account |
16:10 |
miker |
csharp / mmorgan: I'm going to see if I can get a rough side-loader for did you mean going, and if so, generating the baseline dictionary can happen in parallel with all other upgrade steps (and, if there's a cataloging freeze or "pause", can start with that), and then just use PG's COPY to shove the data in. If I can get close tonight, I'll ask for testing tomorrow... |
16:10 |
shulabear |
terranm: If I could use yours, that'd be great; the one I've set up is not reliable. |
16:11 |
csharp |
miker: 10-4 |
16:11 |
terranm |
shulabear: okay - I'll let you know when it's ready! |
16:55 |
mmorgan |
Make that fith! |
16:55 |
Dyrcona |
I hope not. |
16:56 |
Dyrcona |
"And there was much rejoicing!" |
17:01 |
Dyrcona |
Well, ng build --prod worked. I'll test the code tomorrow. I think it should be OK. |
17:27 |
|
mmorgan left #evergreen |
18:00 |
|
sandbergja joined #evergreen |
18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
20:31 |
|
wsmoak_ joined #evergreen |
21:04 |
|
sandbergja joined #evergreen |
21:51 |
|
sandbergja joined #evergreen |
01:50 |
|
khuckins_ joined #evergreen |
02:40 |
|
khuckins joined #evergreen |
06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
06:18 |
|
khuckins joined #evergreen |
06:27 |
|
khuckins joined #evergreen |
07:17 |
|
Dyrcona joined #evergreen |
13:03 |
jeff |
apache's /tmp is not your /tmp :-) |
13:04 |
jeffdavis |
I believe private /tmp is a change between Ubuntu 16.04 and 18.04 fwiw |
13:07 |
Dyrcona |
Well, I hadn't noticed because I don't use it much on development, and we've been using /openils/var/tmp mounted via NFS in production for years. |
13:08 |
Dyrcona |
So, I'm actually testing a security bug and trying to import a MARC record to trigger it, but the record won't import. |
13:08 |
Dyrcona |
When I select it and hit Import Selected Records, the screen goes back to the main Import view, and the record does NOT end up in biblio.record_entry. |
13:09 |
Dyrcona |
FWIW, I have no idea what I'm doing in the staff client, particularly the Angular interface. |
13:28 |
Dyrcona |
So, maybe Vandelay is broken in master on Ubuntu 20.04? |
15:03 |
|
jvwoolf joined #evergreen |
15:07 |
Dyrcona |
I wonder if XUL really matters for bug 1076582? |
15:07 |
pinesol |
Launchpad bug 1076582 in Evergreen "Remove or document references to openils_dojo.js" [Low,Confirmed] https://launchpad.net/bugs/1076582 - Assigned to Jason Stephenson (jstephenson) |
15:08 |
Dyrcona |
After applying the branch, I found a couple of active references to openils_dojo.js in the XUL code, and I wonder if building a XUL client and testing it is worth the trouble at this point? |
15:13 |
|
sandbergja_ joined #evergreen |
15:20 |
|
jihpringle joined #evergreen |
15:24 |
JBoyer |
If there's not a reference under Open-ILS/xul/server I don't think it matters whether the client works or not. (I was thinking there *may* be something still using parts of server/* ?) |
16:01 |
Dyrcona |
Well. It seems to have undone the security patch that I just installed, but I think that's because I switched branches when building the custom dojo. |
16:03 |
Dyrcona |
I seem to be getting a lot of uncaught exceptions, too. |
16:19 |
Dyrcona |
I should probably wipe /openils and install fresh. |
16:27 |
csharp |
so we're running the upgrade script for bug 1893997 against a PINES test server and lordy that's going to take a long time to run |
16:27 |
pinesol |
Launchpad bug 1893997 in Evergreen "Wishlist: Did you mean? Single word, single class substitutions" [Wishlist,New] https://launchpad.net/bugs/1893997 |
16:27 |
csharp |
followed by a reingest |
16:28 |
csharp |
gonna research whether the changes can be applied outside of a downtime window |
16:35 |
Dyrcona |
Yeahp. |
16:36 |
Dyrcona |
It looks to me like you'll be ok as long as you don't set the opac.did_you_mean.max_suggestions org unit setting. |
16:45 |
|
sandbergja_ joined #evergreen |
16:57 |
Dyrcona |
Ah, well. Testing will have to continue tomorrow. |
16:58 |
csharp |
Dyrcona: thanks for checking on that |
16:59 |
Dyrcona |
Well, I'm not 100% certain. I based that assumption on what I see in the upgrade script. |
16:59 |
|
jvwoolf left #evergreen |
17:01 |
Dyrcona |
I'll be back tomorrow. Have a good rest or your day or night, everyone! |
17:12 |
|
stompro_ joined #evergreen |
17:24 |
|
mmorgan left #evergreen |
18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
18:02 |
|
sandbergja_ joined #evergreen |
20:39 |
|
sandbergja_ joined #evergreen |
20:51 |
|
malexander joined #evergreen |
01:08 |
|
phasefx joined #evergreen |
03:44 |
|
khuckins joined #evergreen |
04:16 |
|
khuckins joined #evergreen |
04:56 |
pinesol |
News from qatests: Failed Installing OpenSRF pre-requisites <http://testing.evergreen-ils.org/~live//archive/2021-02/2021-02-25_04:00:18/test.7.html> |
04:56 |
|
book` joined #evergreen |
04:57 |
|
akilsdonk_ joined #evergreen |
06:21 |
|
khuckins joined #evergreen |
10:31 |
Dyrcona |
Based on my "research," your current script is complete for the stock indexes. I haven't added any custom GIST indexes. |
10:34 |
Dyrcona |
JBoyer: I'm 99% sure that neither supports multicolumn indexes, and GIN only works on columns of type tsvector. |
10:34 |
Dyrcona |
https://www.postgresql.org/docs/10/textsearch-indexes.html |
10:35 |
Dyrcona |
JBoyer: I'll assign the bug to myself and test your upgrade script on my training database over the weekend. |
10:35 |
JBoyer |
That's convenient then. If some enterprising committer wants to strip out the last AND clause I wouldn't argue. I also think it's really unlikely that anyone would have their own but you never know. |
10:35 |
JBoyer |
Dyrcona++ |
10:41 |
Dyrcona |
I agree with you that if someone added their own, then they should take responsibility for updating them. |
10:49 |
|
collum_ joined #evergreen |
11:06 |
|
khuckins joined #evergreen |
11:17 |
|
collum joined #evergreen |
11:30 |
miker |
Dyrcona: just had a thought and wanted to surface it outside my head, and since you've been testing modern PG versions... one thing to consider, especially WRT query speed differences and particular queries, is the new [NOT] MATERIALIZED clause for WITHs (CTEs) in PG 12+. We've started using WITH a good bit in hand-tooled queries and the behavioral change to fold CTEs when they appear to be side-effect free and are only referenced once could |
11:30 |
miker |
potentially hurt us. so, if you run into queries that are slower /and/ use WITH, I'd personally be very interested in those examples |
11:50 |
|
jihpringle joined #evergreen |
12:03 |
|
sandbergja___ joined #evergreen |
12:04 |
Dyrcona |
miker: OK. I'll keep an eye out for WITH queries. The ones that I've noticed so far have negative logic. |
12:05 |
Dyrcona |
JBoyer: There's an extra semi-colon in your update script. It's no biggie. I'll fix it. Do you mind if I write a release note? |
12:05 |
|
gmcharlt joined #evergreen |
12:07 |
Dyrcona |
miker: I have done almost 0 testing on Pg 11 or Pg 13, fwiw. I've mostly looked at Pg 12. Pg 10 seems to perform about the same as Pg 9.6. |
12:41 |
|
sandbergja_ joined #evergreen |
12:42 |
JBoyer |
Dyrcona, +1. I guess I hadn't considered a relnote since no features or anything are actually changing; though it is good to know that things should be faster. |
12:42 |
JBoyer |
And which semicolon since I'm curious? |
16:58 |
|
sandbergja_ joined #evergreen |
17:19 |
|
mmorgan left #evergreen |
17:57 |
|
sandbergja_ joined #evergreen |
18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
20:48 |
|
sandbergja_ joined #evergreen |
21:29 |
pinesol |
[evergreen|Bill Erickson] LP1913458 Bucket Add/Delete Item Operations Batched - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1d0e181> |
21:45 |
|
sandbergja_ joined #evergreen |
22:30 |
|
malexander joined #evergreen |
23:51 |
|
sandbergja_ joined #evergreen |
00:07 |
|
sandbergja joined #evergreen |
00:48 |
|
sandbergja joined #evergreen |
04:12 |
|
khuckins joined #evergreen |
06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
07:16 |
|
rjackson_isl_hom joined #evergreen |
08:15 |
|
mantis1 joined #evergreen |
08:15 |
|
collum joined #evergreen |
13:38 |
pinesol |
Launchpad bug 1871211 in Evergreen "wishlist: Single Sign on for Evergreen OPAC" [Wishlist,New] https://launchpad.net/bugs/1871211 |
13:40 |
mmorgan |
sandbergja: That's not my area of expertise, so I don't feel comfortable weighing in. Sorry! |
13:57 |
|
Cocopuff2018 joined #evergreen |
14:31 |
jeffdavis |
sandbergja: I'm not on the release team but I would support that. I haven't been able to test properly for the same reason as you (difficulty setting up a Shibboleth test instance) but I trust the signoff and your judgement. :) |
14:57 |
|
sandbergja_ joined #evergreen |
15:57 |
|
collum_ joined #evergreen |
16:07 |
|
dbwells joined #evergreen |
16:51 |
|
mantis1 left #evergreen |
16:57 |
|
jihpringle joined #evergreen |
17:10 |
|
mmorgan left #evergreen |
18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
18:14 |
|
sandbergja_ joined #evergreen |
18:17 |
|
dbwells joined #evergreen |
19:45 |
|
sandbergja_ joined #evergreen |
04:51 |
|
khuckins joined #evergreen |
06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
07:20 |
|
khuckins joined #evergreen |
07:21 |
|
rjackson_isl_hom joined #evergreen |
07:47 |
|
collum joined #evergreen |
08:30 |
|
rfrasur joined #evergreen |
08:37 |
|
mmorgan joined #evergreen |
08:39 |
|
Dyrcona joined #evergreen |
08:46 |
Dyrcona |
I'm trying to decide if I should do my next test on Pg 9.6 or Pg 12. I also wonder if I should log all queries or just those over a certain threshold, like 250ms or so. |
08:48 |
Dyrcona |
Looks like I have plenty of free space to log all queries for a while. |
08:59 |
csharp |
looks like my troubles from yesterday may have been a super-long-running emergency closing (15 hours) |
08:59 |
csharp |
also did some PG vacuuming last night |
10:56 |
Dyrcona |
Looks to me like the query is running over a second only to have the results ignored. |
11:00 |
Dyrcona |
OK. That's IDL stuff. Moving along.... |
11:08 |
Dyrcona |
Hmm.. Looks like my hold targeter ran faster than yesterday, but it is still too long. |
11:14 |
Dyrcona |
I'll test my changes on Pg 9.6, and then tomorrow run the old code and log long running queries. The old code seemed faster yesterday. |
11:27 |
Dyrcona |
So, my code is faster on Pg 9.6 than it is on Pg 12. This is an area that we'll have to look at. |
11:29 |
Dyrcona |
The 9.6 db has default optimizations, and it was updated yesterday morning, so it has not had the hold targeter run since Saturday. |
11:30 |
Dyrcona |
miker: Should I open a Lp bug about future Postgres versions? |
11:37 |
Dyrcona |
I've also discovered that my maintenance_work_mem setting is way out of whack on my development server for Pg 12. I'm going to remove my optimizations from the config for now. |
11:38 |
Dyrcona |
I had GB instead of MB. :) |
11:38 |
csharp |
oof - I've done that |
11:41 |
Dyrcona |
I should reload Pg 11 and Pg 13 and test this against those dbs, too. |
11:53 |
|
jihpringle joined #evergreen |
12:30 |
|
mantis1 left #evergreen |
12:30 |
|
khuckins joined #evergreen |
17:49 |
|
akilsdonk joined #evergreen |
17:51 |
|
WarpedMJ joined #evergreen |
17:59 |
|
PityDaFool joined #evergreen |
18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
18:01 |
|
ome joined #evergreen |
18:08 |
|
ljharbjj joined #evergreen |
18:10 |
pinesol |
[evergreen|Terran McCanna] LP1916085 Bootstrap OPAC - Pagination on copy table - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c2e0686> |
19:49 |
|
nfBurton28 joined #evergreen |
21:19 |
|
yar joined #evergreen |
11:10 |
Dyrcona |
Trying to create a VM from the Ubuntu 18.04.5 live server image is not going very well. |
11:18 |
|
malexander joined #evergreen |
11:28 |
|
malexander joined #evergreen |
11:31 |
terranm |
phasefx: I'm configuring the geo work on my test server with my Google API key - which map API(s) do I need to enable? I have Maps JavaScript API and Geocoding API enabled already, do I need something else? |
11:34 |
terranm |
Distance Matrix API maybe? |
11:37 |
terranm |
Geolocation API? |
11:50 |
JBoyer |
terranm, I would expect that Geocoding is the primary one you need, is it giving you errors or just not giving you results? |
11:50 |
terranm |
Just no results |
11:54 |
terranm |
The browser console just says "Net: request open-ils.actor.geo.retrieve_coordinates" and then doesn't do anything |
13:04 |
csharp |
maybe needs a RewriteCond to handle that |
13:06 |
csharp |
yep, this seems to confirm the issue: https://stackoverflow.com/questions/10307406/perl-xml-rpc-over-https |
13:21 |
Dyrcona |
There's a nagging voice in my head saying there's a better way to fix that, but I'd really have to look at the code again, and I'm doing something else at the moment. |
13:22 |
* Dyrcona |
tests the Ubuntu 20.04 branches. |
13:22 |
csharp |
well turns out the "better way" was for the client to use "https://" instead :-) |
13:22 |
csharp |
that Just Worked™ |
13:25 |
Dyrcona |
Yeah, I was looking at the module and about to say that it shouldn't affect us. |
13:37 |
berick |
related, bug 1882967 |
13:38 |
pinesol |
Launchpad bug 1882967 in Evergreen "SSL / TLS changes" [Wishlist,New] https://launchpad.net/bugs/1882967 |
13:39 |
Dyrcona |
Yeahp. |
13:41 |
Dyrcona |
I'm also going to test websocketd 0.4.1. I've been using 0.3.1 in production for the past 2 years, and it has been rock solid, even more so than 0.3.0. We should consider updating the README. |
13:53 |
|
alynn26 joined #evergreen |
13:53 |
berick |
Dyrcona++ # websocketd testing |
14:00 |
|
abowling2 joined #evergreen |
14:03 |
Dyrcona |
csharp: I'm going to test the nginx redirect to https on this vm. |
14:08 |
Dyrcona |
I'm gonna update the TLS settings, too. |
14:08 |
Dyrcona |
I'll open a Lp bug for the TLS settings. |
14:12 |
Dyrcona |
And, these changes stop XUL from being able to connect. :) |
04:13 |
|
khuckins joined #evergreen |
04:29 |
|
khuckins joined #evergreen |
05:20 |
|
rjackson_isl_hom joined #evergreen |
06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
07:24 |
|
Dyrcona joined #evergreen |
08:05 |
|
collum joined #evergreen |
08:17 |
|
mantis1 joined #evergreen |
10:08 |
Dyrcona |
OK. We're all 18.04 in production here, and I'd like to jump to 20.04 soon. *cough* ahem. bug 1875544 *cough* |
10:08 |
pinesol |
Launchpad bug 1875544 in OpenSRF "Ubuntu 20.04 (Focal Fossa) support" [Undecided,Confirmed] https://launchpad.net/bugs/1875544 |
10:08 |
Dyrcona |
Also, I feel like I should have sent that email to the development list earlier this week. |
10:09 |
Dyrcona |
Ackshually, I should replace my egdev vm at CWMARS with 20.04. I used it originally to test 18.04. |
10:11 |
|
terranm joined #evergreen |
10:17 |
csharp |
[en-US] open-ils.actor open-ils.actor.ou_setting.ancestor_default.batch 402, ["opac.holds.org_unit_not_pickup_lib","credit.payments.allow"] |
10:18 |
csharp |
that's a call that's spamming us - not sure exactly how to track it up to which UI is doing that |
14:46 |
Dyrcona |
Seems to have been chugging right along processing fines and bills, then BOOM! |
14:50 |
Dyrcona |
@band add Angular Grids |
14:50 |
pinesol |
Dyrcona: Band 'Angular Grids' added to list |
15:25 |
terranm |
JBoyer or gmcharlt - I'm trying to test the lassos functionality on festivus, but admin / demo123 isn't allowing me to log in |
15:29 |
terranm |
Not able to log into the staff client with any concerto logins either |
15:37 |
terranm |
(but I *am* able to log into the opac) |
15:46 |
|
mantis1 left #evergreen |
16:05 |
JBoyer |
terranm, I'm able to login to the opac and staff client as admin, are you still having trouble? |
16:08 |
terranm |
JBoyer: Bah, yes - I had to clear my cookies for that domain. Bad workstation was stuck, I guess? We've seen that with some of our libraries in production as well |
16:09 |
JBoyer |
Oof, hope that's not common for the libraries. Glad you're in again. |
16:12 |
terranm |
Thx, I should have thought of that first. We saw it a number of times coming back from our upgrade last month. Hatch broke for most people that were using it and had to be reinstalled, too. |
16:32 |
|
Dyrcona joined #evergreen |
16:41 |
Dyrcona |
Here's something that I like to do when testing with Chrome. I'll open the developer tools to the Application "tab." Below the circular chart showing data usage, there's a button called "Clear Site Data." Comes in real handy for clearing cache, settings, etc. |
16:45 |
|
dbwells joined #evergreen |
16:45 |
terranm |
Oh, nice. I have the setting page bookmarked because I have to clear data so often, but that's easier |
16:47 |
|
dbwells joined #evergreen |
17:08 |
|
dbwells joined #evergreen |
18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
18:26 |
|
jihpringle joined #evergreen |
22:16 |
|
sandbergja joined #evergreen |
22:23 |
|
sandbergja joined #evergreen |
01:20 |
|
mrisher_ joined #evergreen |
06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
07:56 |
|
collum joined #evergreen |
08:00 |
|
rjackson_isl_hom joined #evergreen |
08:06 |
|
mantis1 joined #evergreen |
10:56 |
Dyrcona |
Yes, it is that trigger. We're trying to "move" copies from a branch locations to system locations with the same names. |
10:57 |
miker |
yep, gets me every time, too :) |
11:00 |
Dyrcona |
Do I remember correctly, or am I making this up, that you can disable a trigger inside of a transaction and that has no effect outside of the transaction? |
11:02 |
terranm |
mmorgan: which server were you testing when you tested this one? https://bugs.launchpad.net/evergreen/+bug/564026 |
11:02 |
pinesol |
Launchpad bug 564026 in Evergreen "Wishlist: add error msg when searching by ID" [Low,Confirmed] |
11:03 |
|
Cocopuff2018 joined #evergreen |
11:04 |
Dyrcona |
I think I'm making that up. |
11:06 |
terranm |
mmorgan: yes, it's working fine on current master (see terran-testbox) so maybe it was a more recent change |
11:07 |
terranm |
checking our 3.6.1 production server... |
11:07 |
terranm |
Hmm, no, I'm getting a nice "Record not found" error message on our production server as well |
11:08 |
mmorgan |
terranm: Checking my master test server, I see Record not found. |
11:09 |
mmorgan |
Hmm. So this was fixed somewhere along the line? Maybe some local customization is breaking it. |
11:10 |
terranm |
That's what I'm guessing - I'm going to go ahead and close that lp bug unless you object |
11:10 |
mmorgan |
No objection here! |
11:10 |
terranm |
thx! |
12:11 |
csharp |
not sure if someone with rootly powers on git could amend my commit to add a signoff or if that's worth doing at all |
12:12 |
csharp |
also, since I've been using gitlab and github more often for other things, I want to move EG to one of those (self-hosted gitlab or otherwise), but that is not this day |
12:15 |
|
jihpringle joined #evergreen |
12:25 |
JBoyer |
csharp, I'm going to assume that it's ok that a signoff was missed so long as it was tested. Wouldn't be the first time, won't be the last. :) |
12:26 |
JBoyer |
csharp++ Dyrcona++ # yay code cleanup |
12:34 |
Dyrcona |
charp++ |
12:34 |
mmorgan |
@karma charp |
13:17 |
pinesol |
Launchpad bug 1888723 in Evergreen "Holdings and Item Attributes Editors (VolCopy) Angular Port" [Wishlist,New] |
13:20 |
Bmagic |
terranm, his branch was merged at this time Feb 9 16:06:35 |
13:20 |
terranm |
Bmagic++ |
13:21 |
Bmagic |
I took a look at the source, and the last commit onto that branch DID NOT make it into the test machine |
13:22 |
Bmagic |
neither did this one https://git.evergreen-ils.org/?p=working/Evergreen.git;a=blobdiff;f=Open-ILS/src/eg2/src/app/staff/cat/volcopy/volcopy.service.ts;h=46d9b39dc7aa1bc8f40b96f90dffd7ac10958de9;hp=1396a8d346c8692e6f5103bc4aaee8665246f714;hb=9413ae89f1f71a3ea720532289849baf0c566a41;hpb=99ef208257f7578449c4ae71410e9dc43c71f217 |
13:23 |
Bmagic |
looking back through the branch, there are quite a few commits that are not on the test server |
13:26 |
Bmagic |
I used this command: git merge working/user/berick/lp1888723-angular-volcopy-v8 and it was successful. Now that you've got me looking at the git log, I' |
13:27 |
Bmagic |
I'm not seeing his commit messages. Maybe I don't understand what git merge does to my branch. Should it make the same number of commits as his branch? |
13:27 |
Dyrcona |
I was rereading bug 608308 just now, and it made me think: Has anyone started a branch to remove XUL? |
13:51 |
|
jvwoolf1 joined #evergreen |
14:00 |
Dyrcona |
Bmagic: Merge reorders commits by date. I'd recommend the following: |
14:01 |
Dyrcona |
git checkout -b <branchname> working/user/berick/lp1888723-angular-volcopy-v8 ; git rebase origin/master |
14:02 |
Dyrcona |
Where <branchname> is what ever you want to call your testing branch. |
14:03 |
Dyrcona |
If the rebase has conflicts, don't bother trying to resolve them, just comment on the bug that it needs a rebase on master, and move on to another bug. |
14:03 |
Dyrcona |
You can clean up a failed rebase with git rebase --abort |
14:11 |
|
terranm joined #evergreen |
14:21 |
Bmagic |
RFF+ON:199189'RFF+LI:199189EasyHoliday/7370'ALC+A++++DI'PCD+3:0'LIN+3++9780310769064 |
14:22 |
Bmagic |
It appears that the edi_li->id is getting assigned "7370" |
14:22 |
Bmagic |
which matches acq.lineitem.id from 2013 |
14:22 |
berick |
Bmagic: Open-ILS/src/support-scripts/test-scripts/edi_reader.pl can be used to see what EDIReader produces, BTW |
14:23 |
Bmagic |
ah! right! I'll double check the theory |
14:25 |
Bmagic |
berick++ # confirmed: 'id' => '7370', |
14:26 |
Bmagic |
so the big question is: do we have a bug? |
15:32 |
|
mantis1 left #evergreen |
15:33 |
berick |
Dyrcona++ |
15:41 |
JBoyer |
berick, not urgent, but I figure you have a good chance of knowing a simple for bug 1915326 |
15:41 |
pinesol |
Launchpad bug 1915326 in Evergreen "AngularJS egOrg tests fail" [Low,New] https://launchpad.net/bugs/1915326 |
15:42 |
JBoyer |
Basically, referencing lf (for lf.isOffline) breaks the tests since lf isn't defined at that point. |
15:45 |
* berick |
calls 1245 |
15:50 |
JBoyer |
Though if there's no better fix than if ( (lf && lf.isOffline) ... I can throw that branch together |
16:00 |
pinesol |
[evergreen|Galen Charlton] LP#1474029: teach Evergreen how to prevent expired staff from logging in - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=18f5404> |
16:16 |
|
dbwells joined #evergreen |
16:22 |
|
terranm joined #evergreen |
16:23 |
|
jihpringle joined #evergreen |
16:24 |
Dyrcona |
I have successfully tested the backport of sandbergja's Angular fix on bug 1913219 to rel_3_5. Should I just push it or does anyone else want to have a look on 3.5? |
16:24 |
pinesol |
Launchpad bug 1913219 in Evergreen 3.5 "Edit from OPAC View doesnt' close on Save & Exit" [Medium,Confirmed] https://launchpad.net/bugs/1913219 - Assigned to Jason Stephenson (jstephenson) |
16:29 |
csharp |
Dyrcona: got for it |
16:29 |
csharp |
er... *go* for it |
17:25 |
|
malexander joined #evergreen |
17:56 |
|
dbwells joined #evergreen |
17:58 |
|
dbwells joined #evergreen |
18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
18:11 |
|
dbwells joined #evergreen |
18:16 |
|
sandbergja_ joined #evergreen |
20:09 |
|
sandbergja_ joined #evergreen |