12:26 |
|
Guest20 joined #evergreen |
12:43 |
|
_collum joined #evergreen |
12:50 |
|
jihpringle joined #evergreen |
13:41 |
* Dyrcona |
ponders spamming himself with 2-day courtesy notices to test the filter. |
13:43 |
Dyrcona |
I suppose that I can test the filter without sending email. |
13:47 |
Dyrcona |
Might as well wait until Tuesday, since my test database will be automatically refreshed on Sunday. |
14:14 |
|
jihpringle joined #evergreen |
14:50 |
Dyrcona |
Running a test of the filter today anyway. Set myself as recipient_email in event_params, just in case one of the vms can actually send email. |
15:58 |
|
Dyrcona left #evergreen |
15:59 |
|
Dyrcona joined #evergreen |
16:03 |
Dyrcona |
My date is so out of date that this test is pretty much meaningless, though the vm/database with the filter does show fewer events than the one without. Tuesday will be better because the data will be from midnight Sunday. |
16:03 |
Dyrcona |
My data is out of date, too. :) |
16:18 |
|
mantis1 left #evergreen |
16:50 |
|
jihpringle joined #evergreen |
08:41 |
|
mmorgan joined #evergreen |
09:08 |
|
Dyrcona joined #evergreen |
09:23 |
|
kworstell-isl joined #evergreen |
09:40 |
StomproJ |
I didn't realize bug 1862834 was a thing... we have 88 call number prefixes in use with 250 templates... lets go test that fix out. |
09:40 |
pinesol |
Launchpad bug 1862834 in Evergreen 3.11 "regex based url building that can match hostnames" [Medium,Confirmed] https://launchpad.net/bugs/1862834 |
09:41 |
StomproJ |
Ooops, bad paste buffer. I mean bug 1983156. |
09:41 |
pinesol |
Launchpad bug 1983156 in Evergreen "Allow Call Number attributes in Item Templates option gone" [High,Confirmed] https://launchpad.net/bugs/1983156 - Assigned to Michele Morgan (mmorgan) |
09:46 |
StomproJ |
So it needs the bits to save back into the template when updating the template? |
09:46 |
mmorgan |
StomproJ: Exactly! |
09:47 |
mmorgan |
Also, the standalone template editor under Local Admin DOES allow the call number attrs to get saved in the template - that interface hasn't been angularized yet. |
09:48 |
StomproJ |
That makes testing a bit harder, if someone cannot add that info to the prefix.... ah. |
09:49 |
* mmorgan |
can add some testing notes to the LP bug. |
09:49 |
StomproJ |
I'm seeing two actor.usr_setting types for storing templates, cat.copy.templates and staff_client.copy_editor.templates. |
09:49 |
StomproJ |
Is staff_client.copy_editor.templates the old XUL key? |
09:50 |
Dyrcona |
One of them is, and I don't remember which. |
09:52 |
Dyrcona |
"[T]he standalone template editor under Local Admin" this points to a problem without intending to. |
09:53 |
|
Rogan joined #evergreen |
09:57 |
StomproJ |
mmorgan, I'm in what I think is the standalong template editor, but there is no item section where the prefix can be set. |
10:00 |
mmorgan |
StomproJ: Just posted some testing notes: https://bugs.launchpad.net/evergreen/+bug/1983156/comments/9 |
10:00 |
pinesol |
Launchpad bug 1983156 in Evergreen "Allow Call Number attributes in Item Templates option gone" [High,Confirmed] - Assigned to Michele Morgan (mmorgan) |
10:00 |
mmorgan |
You need to set preferences in the holdings editor to get those to display. |
10:01 |
StomproJ |
Thanks |
10:22 |
mmorgan |
Hmm. Shouldn't be, unless I missed something - which is possible :) |
10:24 |
StomproJ |
AngularJS volcopy prefs seem to be in cat.copy.defaults - and the "Allow Call Number attributes" sets the ""show_vol_template_controls": true," json value |
10:25 |
StomproJ |
Angular seems to use "eg.cat.volcopy.defaults" and sets "show_vol_template_controls": true |
10:27 |
mmorgan |
Ok, that makes sense. So it sounds like you DO need to set the preference in the angularjs holdings editor to get the call number attributes to show in the standalone holdings editor. |
10:28 |
mmorgan |
Just so you can create a template to test. I can see how this is difficult to test. :-/ |
10:29 |
StomproJ |
Yes, but I'm making progress. I'm just adding some Call number suffix entries to make sure I try them also. |
10:31 |
mmorgan |
StomproJ++ |
10:34 |
pinesol |
News from commits: LP2028088 Fix info, primary, success button colors <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=5186c72cc0d5aa0ab142a8515697735bef6cd1b5> |
10:39 |
* mmorgan |
will need to take a look at that. |
10:41 |
StomproJ |
mmorgan, false alarm, had to log out and log in for the template change to get read. Could have been a side effect of me doing things in different tabs. |
10:42 |
StomproJ |
The Suffix does apply. |
10:42 |
mmorgan |
Ok, thanks! I have to admit, in my testing I was mostly focusing on Classification and Prefix, but thought I did try Suffix a few times :) |
10:43 |
StomproJ |
We don't use suffix at all either in production, but I don't want to hurt it's feelings by not testing it. |
10:44 |
mmorgan |
We have lots of libraries that use Prefix, many fewer that use Suffix, but it needs to work, too! |
10:46 |
Dyrcona |
If it is there, someone will use it. :) |
10:47 |
StomproJ |
I really hate that template save button being there. Gets me every time. |
10:42 |
Dyrcona |
s/Arc/Arch/ |
10:42 |
Dyrcona |
Also, busted packages lately on Ubuntu 20.04, but this is off topic. |
10:43 |
berick |
Arch is fun. but also, xubuntu++ |
10:44 |
Dyrcona |
Arch will test/improve your actual Linux chops. I've come to appreciate systemd. I still don't like, but I don't dislike it as much as I used to. :) |
10:58 |
Dyrcona |
I'm trying to install vanilla Gnome on Ubuntu 20.04, but package dependencies are out of sync. |
11:02 |
Dyrcona |
I like how apt says "you have held broken packages." But I have no held packages. Neither of the ways to check (aptmark, dpkg) say I have held packages. |
11:03 |
berick |
Dyrcona: maybe start w/ a server install so you don't have all that existing Gnome stuff? |
12:05 |
|
rfrasur joined #evergreen |
12:09 |
Bmagic_ |
StomproJ: I forgot about that! I'll get on it |
12:10 |
|
Bmagic joined #evergreen |
12:10 |
StomproJ |
Bmagic, it is ok, I have a test system setup now to test it. |
12:10 |
Bmagic |
don't need me to do anything? |
12:10 |
StomproJ |
Nope, but thank you. |
12:11 |
Bmagic |
sorry! I know I said I would do that |
13:38 |
kmlussier |
berick++ |
13:57 |
jeffdavis |
I'm trying out memcached StorageService for Shibboleth and it's not working. A shib session is being successfully created and there's a shibsession cookie in my browser that corresponds to the session ID stored in memcached, but I'm not actually logged into EG. Is there some extra mod_shib config required? I can't find much in the Shibboleth docs. |
14:27 |
JBoyer |
It logs you in as expected with the default backend but not memcached? |
14:27 |
jeffdavis |
yes, default backend works fine |
14:45 |
jeffdavis |
hmm, this is interesting: I click Login with SSO, enter credentials in the SSO login form, and get bounced back to the OPAC, and I am not logged in. But if I then click Login with SSO again, I *do* get logged in (without being redirected to the SSO login form). |
14:46 |
jeffdavis |
whereas with the default backend I'm logged in right away as soon as I'm redirected back to the OPAC |
14:53 |
jeffdavis |
this is on a single test server using the same local memcached that EG itself uses |
15:23 |
JBoyer |
That sounds vaguely familiar. Something about the target of the login link needing to be specifically /myopac rather than /login or something like that. |
15:25 |
|
mantis1 left #evergreen |
17:05 |
|
mmorgan left #evergreen |
11:09 |
|
kmlussier joined #evergreen |
11:36 |
|
collum joined #evergreen |
11:52 |
|
Dyrcona joined #evergreen |
12:26 |
jeffdavis |
I'll test that EG branch for 1999823 today |
12:28 |
Dyrcona |
Lp 1999823 |
12:28 |
pinesol |
Launchpad bug 1999823 in OpenSRF "Name collision causes apache gateway modules to fail when mod_shib is installed" [Medium,Confirmed] https://launchpad.net/bugs/1999823 |
12:38 |
|
kworstell-isl joined #evergreen |
12:46 |
|
kworstell_isl joined #evergreen |
13:18 |
|
kworstell_isl_ joined #evergreen |
13:19 |
|
kworstell-isl joined #evergreen |
13:52 |
jeffdavis |
JBoyer++ # initial testing suggests that mod_idlchunk branch resolves the issue - need to test further before signoff but feeling pretty optimistic. Thanks! |
13:54 |
JBoyer |
jeffdavis++ glad to hear it. I'd like to see the rest of the files in both OpenSRF and Evergreen switch to those funcs since neither fix is committed, but at least you should have everything you need to get things going locally. |
13:55 |
jeffdavis |
Should I open a new bug about changing the function names everywhere, or do we want to do it as part of this bug? |
13:56 |
|
kworstell-isl joined #evergreen |
13:00 |
|
collum joined #evergreen |
13:12 |
|
Stompro joined #evergreen |
13:42 |
|
kworstell-isl joined #evergreen |
14:14 |
jeffdavis |
I seem to be running into issues with Shibboleth (for SSO) in a multi-server environment. It looks like the same issue as bug 1992024 but we've already applied the fix for that. Not seeing the same problem on a test server. |
14:14 |
pinesol |
Launchpad bug 1999823 in OpenSRF "duplicate for #1992024 Name collision causes apache gateway modules to fail when mod_shib is installed" [Medium,Confirmed] https://launchpad.net/bugs/1999823 |
14:17 |
jeffdavis |
Specifically the same behavior as 1992024 - with mod_shib enabled I get a 502 error when I try to load the reporter. We have the fix for 1999823 which resolved the same issue in a test environment. |
14:48 |
JBoyer |
jeffdavis, when you mention multi-server, do you mean multiple apache servers? And if so, what StorageService backend are you using? |
14:51 |
jeffdavis |
By multi-server I mean four full-stack EG servers (Evergreen + Apache + nginx etc) sitting behind a load balancer. |
14:52 |
|
mantis1 left #evergreen |
08:24 |
|
Stompro joined #evergreen |
08:38 |
|
mmorgan joined #evergreen |
08:58 |
|
Dyrcona joined #evergreen |
09:16 |
Stompro |
Since the Bug squashing week is coming up... would anyone be willing to name their test systems with the prefix eg to allow this bug #1862834 to be tested. |
09:16 |
mmorgan |
@coffee #evergreen |
09:16 |
pinesol |
Launchpad bug 1862834 in Evergreen 3.11 "regex based url building that can match hostnames" [Medium,Confirmed] https://launchpad.net/bugs/1862834 |
09:16 |
* pinesol |
brews and pours a cup of Hamma Cooperative Yirgacheffe, Fair-Trade Organic, and sends it sliding down the bar to #evergreen |
12:03 |
mmorgan |
The library that reported it says it started happening about 2 months ago. I see it in both Chrome and Firefox. |
12:04 |
Dyrcona |
I don't use the client or work directly with those who do. You might want to try one of the mailing lists. |
12:07 |
|
kworstell-isl joined #evergreen |
12:10 |
mmorgan |
Ok, I think I'll wait til Monday on that. I should be clear that it's happening in the angularjs pull list, I don't see the same problem in the Angular pull list. In my 3.9 and 3.11-ish tests, I entered the old url manually: https://<hostname>/eg/staff/circ/holds/pull |
12:28 |
|
jvwoolf joined #evergreen |
12:49 |
|
kmlussier joined #evergreen |
12:50 |
kmlussier |
Hello #evergreen and Happy Friday! |
13:09 |
|
jihpringle joined #evergreen |
13:29 |
|
bgillap joined #evergreen |
13:33 |
Dyrcona |
I always have to spend time in the code to (re)figure out how the hooks work.... |
13:39 |
* Dyrcona |
is trying to figure out why a test machine did not generate any of a certain kind of notice last night while production did with similar date. |
13:39 |
Dyrcona |
s/date/data/ |
13:41 |
Dyrcona |
Doh! It's as simple as that. The default filters were not copied/renamed. |
13:42 |
* Dyrcona |
tries an experiment. |
15:37 |
JonGeorg |
Thanks. So it's a known issue. I can at least let the libraries know that. |
15:39 |
Dyrcona |
JonGeorg: We removed Boost Mobile as an option for SMS in the CW MARS Evergreen installation because their gateway doesn't exist any more. |
15:42 |
Dyrcona |
If you're in the USA, this might help: https://en.wikipedia.org/wiki/List_of_United_States_mobile_virtual_network_operators |
15:43 |
Dyrcona |
You can sometimes figure out which actual provider to use for a patron's SMS by sending them test texts until one goes through. |
15:51 |
Dyrcona |
As for the "magic:" `cd Open-ILS/src; make ./support-scripts/marc_export` |
15:51 |
Dyrcona |
Then just cp it into place if you want. |
16:03 |
JonGeorg |
Thank you. I do have a few numbers that I keep getting bouncebacks for, but when I search for the number it comes up as not there. |
13:29 |
Bmagic |
I was thinking the threshold would tolerate a few log messages but not more than X number in the last hour |
13:30 |
Dyrcona |
Well, your filter is a program, so it can track whatever you want. Now that I think about it, it will run as the syslog user, so it would probably have to sudo or something to restart services. I've used this feature before, but not for restarting OpenSRF services. |
13:33 |
|
kworstell_isl joined #evergreen |
13:43 |
Dyrcona |
We've got some AngularJS grids, namely the holds pull list, where some fields are turning up "null" if you mouse over them or try to print the full grid. This just started after we installed the open-ils.fielder patch, however it doesn't seem to be related because it happens on a test system without the fielder patch. Does this ring a bell for anyone? |
13:44 |
Dyrcona |
I've also been told by a reliable source that it isn't Lp 1785260. |
13:44 |
pinesol |
Launchpad bug 1785260 in Evergreen "Web Client: Holds Pull List - fields blank when using "Print Full Grid" or "Download Full CSV"" [Undecided,Confirmed] https://launchpad.net/bugs/1785260 |
14:13 |
Dyrcona |
This is frustrating. |
12:01 |
Dyrcona |
It can't download to gvfs mounted location. |
12:03 |
Dyrcona |
I may have to seriously consider switching distros. |
12:24 |
Dyrcona |
Maybe I'll switch back to FreeBSD on the desk....erm laptop? |
12:33 |
Dyrcona |
3.9.4 is basically ready. I need to test it. |
12:38 |
Dyrcona |
Heh, Listening to Def Leppard while doing this takes me back to when I first started programming on Commodore and Apple computers.... |
12:42 |
Dyrcona |
@decide new vm or focal |
12:42 |
pinesol |
Dyrcona: go with new vm |
12:43 |
Dyrcona |
Thanks for your opinion, pinesol, but I'm going to override that answer. :) |
13:18 |
* Dyrcona |
wonders if some of our tests still depend on undefined behavior. I find that live_t/29-lp1817645-remoteauth-patron-api.t seems to fail and then succeed later. |
13:19 |
Dyrcona |
Hmm cover uploader failed, too. I ran autogen.sh..... |
13:20 |
Dyrcona |
Pretty sure that I restarted apache2... I'll try again. |
13:26 |
Dyrcona |
Nope: Failed test 'Basic request for external user correctly returned 403' at live_t/29-lp1817645-remoteauth-patron-api.t line 137. got: '502' expected: '403' |
13:27 |
Dyrcona |
So, nginx or apache config is botched? |
13:29 |
Dyrcona |
OK. figured it out. |
13:31 |
Dyrcona |
Forgot to change the ports in the eg.conf VirtualHost entries. |
13:35 |
Dyrcona |
I think we neglect the Apache ports in the configuration instructions. |
13:38 |
Dyrcona |
And, live_t/30-lp1508208-age-protect-hold-capture.t fails on me for like the first time ever. |
13:38 |
* Dyrcona |
mumbles something about Micky Mouse. |
13:41 |
Dyrcona |
Meh. Feels like I'm the only one who runs all the tests for releases. I'll "release" it anyway. |
14:34 |
|
Dyrcona joined #evergreen |
14:35 |
Dyrcona |
So I guess things are missing from the 3.9.4 release notes because things were backported that should not have been. If someone else wants to fix the release notes, feel free. I'm done. |
16:30 |
|
sleary joined #evergreen |
10:54 |
|
jvwoolf left #evergreen |
10:57 |
|
sandbergja joined #evergreen |
11:01 |
|
sandbergja joined #evergreen |
11:09 |
Bmagic |
testing 3.10.3 tarball |
11:36 |
Bmagic |
test is good, making 3.11 now |
11:41 |
sandbergja |
Bmagic++ |
11:46 |
|
terranm joined #evergreen |
11:53 |
sharpsie |
Bmagic++ |
12:40 |
sharpsie |
well now you have to admit it! |
12:40 |
* mmorgan |
was thinking the same thing! |
12:41 |
Dyrcona |
I overwrote the authorized_keys file for a user on a server, but I can probably just copy another user's file on top of it. |
12:42 |
sharpsie |
this one time, I removed /usr from a running server - that was a fun test of our backup capabilities |
12:43 |
berick |
this one time... in band camp... |
12:43 |
sharpsie |
berick: almost said that |
12:43 |
sharpsie |
their band camp sounds way more fun that ours was IRL |
12:49 |
sharpsie |
Dyrcona++ |
12:49 |
Dyrcona |
I was being clever and doing a keyscan on a new host for a vendor, and I redirected the output to the wrong file. |
12:50 |
sharpsie |
in other news, joining the MS-ISAC alert lists has made me very glad I'm not administering big proprietary things like Citrix stuff |
12:51 |
Bmagic |
testing 3.11.1 |
13:19 |
Bmagic |
3.11.11 good, publishing on our site |
13:29 |
Bmagic |
ok yall, new tarballs for 3.10.3 and 3.11.1 are on the page, complete with release notes and changelog and readme's. The last step would be to commit the tag branches to the main repo: collab/blake/tags/rel_3_11_1 and collab/blake/tags/rel_3_10_3 . Anyone around to evaluate/push those? |
13:31 |
Dyrcona |
Bmagic++ |
13:41 |
Dyrcona |
I'll take a look at the tag branches. |
13:49 |
Dyrcona |
Has anyone done a release announcement? |
14:02 |
terranm |
Trying to wrap my head around the basic concept of creating a new table (student_card.school) that can be edited from the server admin page. I have a script to create it and I've added it to the fieldmapper (class id="scs") and it's appearing, but when I navigate to the page I get an error with this in the logs: "Method [open-ils.pcrud.search.scs] |
14:02 |
terranm |
not found for service open-ils.pcrud" -- any thoughts? My test code is here: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=commit;h=56ae78eed93c8dbe7040db543d75e796a1d3737f |
14:05 |
Dyrcona |
terranm: I'm pretty sure that an object with a pcrud controller needs a permacrud block, even if it is mostly empty. |
14:06 |
terranm |
Ooooh, thanks I'll try that! |
14:13 |
terranm |
Dyrcona++ that solved that error, thanks! |
08:29 |
|
mmorgan joined #evergreen |
08:53 |
|
kworstell-isl joined #evergreen |
08:55 |
|
sandbergja joined #evergreen |
08:59 |
mantis |
Morning. Tried to start a reingest on our test server with 3.11 installed and got back an error. https://pastebin.com/Kv6tHz4m |
08:59 |
mantis |
any advice appreciated |
09:00 |
mantis |
ERROR: index row size 3136 exceeds maximum 2712 for index "browse_entry_sort_value_value_key" HINT: Values larger than 1/3 of a buffer page cannot be indexed. Consider a function index of an MD5 hash of the value, or use full text indexi |
09:08 |
|
sandbergja joined #evergreen |
09:16 |
|
rfrasur joined #evergreen |
10:51 |
sharpsie |
so, yeah, the same |
10:54 |
sharpsie |
argh - I hate when there's no record of changes - apparently whatever that index is was added out-of-band |
10:54 |
mantis |
alright at least we know that |
10:55 |
sharpsie |
mantis: nevertheless, eeevil's suggestion should help - basically it's saying "however long the actual value is, truncate it after 1000 chars" |
10:56 |
sharpsie |
mantis: is this in a test environment or live? |
10:56 |
mantis |
test environment |
10:56 |
sharpsie |
good :-) |
10:58 |
mantis |
haha |
10:58 |
sharpsie |
in a test environment that no one else depends on, you can be cavalier |
10:59 |
sharpsie |
the "safe" way to create/drop indexes on a live server is usually to create the new index with "concurrently" which doesn't lock the table and make everyone miserable |
11:00 |
sharpsie |
then drop the "old" index (again, with "concurrently") |
11:02 |
sharpsie |
in this case though, you can DROP INDEX CONCURRENTLY browse_entry_sort_value_value_key; since it is apparently unnecessary? |
11:04 |
sharpsie |
then DROP INDEX CONCURRENTLY browse_entry_sort_value_idx; CREATE INDEX CONCURRENTLY browse_entry_sort_value_idx ON metabib.browse_entry USING BTREE (substring(sort_value from 1 for 1000)); (completely untested, just following substr docs) |
11:59 |
sharpsie |
Dyrcona: might be a different bug, but worth looking at for future generations' sakes |
12:30 |
|
collum joined #evergreen |
12:52 |
|
kworstell-isl joined #evergreen |
13:05 |
eeevil |
mantis / sharpsie / Dyrcona / jeff / jeffdavis: sorry, meetings and then lunch! glad you found the old bug, a bell was ringing... berick has a reasonable plan in that older bug, but one key to keep in mind is making sure that we can find duplicates quickly, as that's core to the browse phase of ingest. so, large dataset testing is necessary for this one, and ingest function changes might be needed. the configuration-offered fix of using substr() to |
13:05 |
eeevil |
cap the length can retain the existing infrastructure (that's we're confident works) and can be automated in the upgrade script by just applying the normalizer to extant browse fields, but will require thought when adding new browse fields locally as Dyrcona implies via "fix it for everyone". I'd personally prefer avoiding encoding low level implementation restrictions in the indexing, but display-field truncation is something to consider as a trade |
13:05 |
eeevil |
off there. |
13:26 |
sharpsie |
eeevil: 10-4 |
13:29 |
|
Dyrcona joined #evergreen |
13:30 |
|
jihpringle joined #evergreen |
14:48 |
jeff |
Dyrcona: there are various tricks for doing that, especially if you don't care which row you keep. Most involve using ctid. :-) |
14:52 |
|
kworstell_isl joined #evergreen |
14:54 |
sharpsie |
like "Circ report (clone) (clone) (clone) (clone) (clone)" |
15:09 |
jeffdavis |
wondering if there should be a way for certain users to be able to bypass MFA - like consortial support staff logging in with a Circ Desk Staff account at BR1 for support/testing purposes without having to use whatever second auth factor that would normally require |
15:10 |
jeff |
arguably that should be a different account. |
15:11 |
jeff |
but yes, that's just one of a pile of questions that remain to be addressed. :-) |
15:12 |
jeffdavis |
yeah I'm sure we'll come up with more headaches^Wuse cases to think about |
15:14 |
jeff |
including determining some hard guidelines around what requires a user to use MFA to auth (home_ou, any working location requiring MFA, workstation OU? other?), and given a user that does not require MFA, are they prevented from logging in in any scenarios, like with a workstation tied to an org unit that does require MFA, etc? |
15:28 |
Dyrcona |
MFA for everyone. |
15:30 |
Dyrcona |
jeff: On my delete thing from earlier, I'm just going to delete the 3 rows and then insert the data back once. (That's easy enough.) I'll then add a unique constraint. I've tested it, and it works. |
15:48 |
|
mantis left #evergreen |
16:23 |
|
jvwoolf joined #evergreen |
16:23 |
|
jihpringle joined #evergreen |
11:20 |
|
Christineb joined #evergreen |
11:36 |
|
sleary joined #evergreen |
11:43 |
|
tsadok joined #evergreen |
13:33 |
Dyrcona |
Hmm. I seem to be getting random live test failures on Ubuntu 22.04 with user/berick/lp2017941-opensrf-on-redis-v2 and PostgreSQL 15. I ran livecheck, and the neg balances test failed. I ran eg_db_config, restarted things, and ran livecheck again. This time the geosort test failed. |
13:34 |
berick |
Dyrcona: i'm assuming stock eg/osrf on pg15 does not have these issues? i mostly tested with pg 14. |
13:36 |
Dyrcona |
berick: Well, it didn't have these issues with the same branch last week or the week before. I have seen the neg balance test fail on the first try, and succeed on the second in the past. |
13:37 |
Dyrcona |
I.E., the neg balance test has been finicky. |
13:38 |
Dyrcona |
I'm going for a 3rd try to see if anything is different. |
13:41 |
Dyrcona |
Right. All passed this time. |
13:41 |
Dyrcona |
:/ |
13:47 |
Dyrcona |
I'll test stock main on a different Ubuntu 22.04 vm talking to the same pg 15 database server. |
13:59 |
Dyrcona |
Hm.. This one appears to have frozen up while installing prerequisites. |
14:03 |
Dyrcona |
Looks like it finally finished installing prerequisites for OpenSRF. |
14:46 |
mantis |
I'm starting a new blog on all the mistakes I'm going to make as a sys admin: openseedsforme.wordpress.com |
15:30 |
mmorgan |
If I tried to chronicle all my mistakes, I would never succeed with anything :) |
15:31 |
mmorgan |
sharpsie: Your blog is telling me it's open only to invited readers. |
15:47 |
* Dyrcona |
used to blog, too, but time.... |
15:48 |
Dyrcona |
All right, I finally ran livecheck on stock main with ubuntu 22.04 and pg 15, and a bunch of tests failed. I'm pretty sure I did everything correctly, but I might have missed some setup step. |
15:50 |
* Dyrcona |
tries again. |
15:54 |
Dyrcona |
I wonder if there's some network issues going on where my VMs are hosted? |
15:56 |
Dyrcona |
Ok. I think my apache or some other configuration is busted for the moment. I looked at the output of the auth api test and it's getting 500, not 403, so internal server error. Apache and nginx are running, though. |
16:09 |
jeff |
makelivecheck || make undeadcheck |
16:09 |
jeff |
er, only without the typo. |
16:12 |
sharpsie |
mmorgan: try again if you want |
16:12 |
sharpsie |
apparently made it private way back then since I was nervous about people seeing it |
16:17 |
mmorgan |
sharpsie++ |
16:25 |
Dyrcona |
Hmm... Didn't change anything, and geosort is failing. |
16:25 |
Dyrcona |
The tests are being erratic for me today. |
16:27 |
Dyrcona |
RE Blogs, here's mine: http://evergreen.sigio.com/ |
16:32 |
berick |
and mine :) https://chomp.dev/ |
16:36 |
Dyrcona |
And, all tests pass this time.... |
17:03 |
|
mmorgan left #evergreen |
18:51 |
|
Jaysal joined #evergreen |
12:52 |
Dyrcona |
Doesn't xact_begin start a new session if there isn't one? Could the session have gone away, but the drone not know it? |
12:56 |
berick |
Dyrcona: that's what i'm thinking. the session timed out while compiling the template, it then tried to send a BEGIN on a disconnected session. |
12:57 |
Bmagic |
it almost has to be |
12:57 |
berick |
and it didn't know it was disconnected because no recv() / queue_wait calls occurred before the "am I still connected" test in editor's xact_begin() sub. |
12:57 |
Dyrcona |
I'd still check the database logs for anything weird around that time. |
12:58 |
Bmagic |
db logs don't have anything interesting around that time |
12:58 |
Bmagic |
lots of " WARNING: there is no transaction in progress" |
12:59 |
Dyrcona |
Well, that's a bummer. |
13:00 |
Bmagic |
we do have a clear log that says "No request was received in 6 seconds, exiting stateful session" - so, I wouldn't expect that the postgres service would have expierenced an error |
13:06 |
Dyrcona |
Can you tell if that's for the same cstore drone/process? |
13:13 |
* Dyrcona |
just added 64 tests to live_t/20-hold-targeter.t. |
13:21 |
|
sleary joined #evergreen |
13:25 |
* Dyrcona |
wishes there was a decent way to test the pull list from the backend, but the results are not predictable enough. |
13:37 |
|
Dyrcona joined #evergreen |
13:38 |
Bmagic |
sorry guys, I was pulled away, now, I'm back at it |
13:38 |
* Dyrcona |
is switching internet connections. |
13:46 |
Bmagic |
now I'm getting hits, to answer the question about what the action trigger logs look like above* the 6 second timeout line |
13:47 |
Dyrcona |
OK. I was going to suggest using -F on the grep or zgrep, or even eliminating the second grep and try the timestamp via zgrep. |
13:51 |
|
collum joined #evergreen |
13:54 |
* Dyrcona |
considers adding more tests... but needs to refresh his memory on making cstore requests from srfsh. |
13:54 |
Bmagic |
berick: RE: "between 08:47:07 and 08:47:13 or thereabouts" https://pastebin.com/8agDcMnX |
13:55 |
Bmagic |
the event ID that I'm tracking: 123020652 |
13:59 |
Bmagic |
do we start the transaction (the one that we're going to use to write the output to the database), and then* start generating the template? Leaving that transaction open for the duration? |
14:08 |
Bmagic |
It does succeed most of the time |
14:08 |
Bmagic |
I was just curious about this time |
14:09 |
Dyrcona |
Yeah. It happens more often than one would like. |
14:19 |
Dyrcona |
Well, I think that's enough tests. We can always add more later. |
14:25 |
berick |
oddly it tries to create the transaction after it's compiled the template. "trigger: writing 3273 bytes to template output" happens after template compilation. |
14:26 |
berick |
then cstore sends a bunch of stuff back after the begin. that part I don't get. |
14:43 |
Dyrcona |
Eighteen commits rebased down to 1, and I'm ready to share the code... |
15:04 |
Dyrcona |
I suppose we have functional tests for the staff client that can be run. I guess I should learn how those work. |
15:11 |
* eeevil |
reads up and sees Bmagic's adventure... ah yes, a Very Expensive Template Output (esp a grouped set of expensive events) could take longer than the session keepalive time (configured in opensrf.xml, per service) and it does look like that. the fast fix is to increase the keepalive time. I know of EG instances that have in the past had a timeout of 12s (slower hardware, and before some code changes lowered the timeout risk), but I don't see |
15:11 |
* eeevil |
any currently. if it's right at the edge of the time limit, that'd give breathing room to figure out where we need to insert more interaction and avoid that particular session timeout in A/T land. |
15:19 |
Bmagic |
eeevil++ berick++ Dyrcona++ mmorgan++ # thanks for the ideas. timeout 6 > 12 seems easy enough. What's the drawback? Tying up more Drones, and running up against max_children? |
09:43 |
berick |
Dyrcona: i've had similar thoughts lately re: merging opensrf because of this project. there's quite a bit of duplicated effort. |
09:43 |
berick |
Dyrcona: yes, those are the correct branches. |
09:43 |
Dyrcona |
berick: Thanks. |
09:44 |
berick |
Dyrcona++ # testing |
10:04 |
|
sleary joined #evergreen |
10:33 |
* Dyrcona |
hasn't done much today. I've been mucking about with UNIX account configuration. |
10:40 |
StomproJ |
oclc-- |
13:47 |
Dyrcona |
berick: For practicing rust locally would your recommend installing the rust-all apt package or going with rustup? |
13:48 |
Dyrcona |
s/your/you/ |
13:48 |
berick |
Dyrcona: either works. i've mostly used rust-all. |
13:49 |
Dyrcona |
Ok. I was thinking of going with rustup on my laptop for newer features, etc. I installed rust-all on the Ubuntu 22 vm where I'm testing redis. I'll give universe-rs a whirl later. |
13:50 |
Dyrcona |
I'm rerunning the perl live tests because I forgot to start apache2, so the tests that depended on Apache failed... |
13:51 |
Dyrcona |
Looks good so far |
14:23 |
Dyrcona |
I notice that gmcharlt is (righly) concerned about the universe-rs pulling in 167 crates. However, npm pulls in almost 1390 packages in Open-ILS/src/eg2. That should be a concern, too, no? |
14:23 |
Dyrcona |
Where are my fingers today?.... Must Typoday.... |
10:20 |
Dyrcona |
That's much safer than setting a flag in actor.usr. |
10:21 |
Dyrcona |
My second promised email about our rusty future might go into some detail about issues I have with the current staff client, but I might save that for yet another email. |
10:21 |
Dyrcona |
I have examples of bad API design and even worse use or bypassing of existing API. |
10:22 |
berick |
we have exactly 2 accounts w/ superuser. one for logging in/testing/etc and one a backend utility account. not following the use case where a standard human person would get superuser. |
10:24 |
jeff |
seconding deprecation and possibly eventual removal of actor.usr.superuser, if only for simplicity and for the sake of having permissions in fewer places. |
10:24 |
Dyrcona |
berick: Doesn't matter if you don't get it. Doesn't mean it's wrong. When someone is on the phone wanting something fixed, that permission comes in handy. |
10:25 |
jeff |
and yes, both EVERYTHING and superuser should be rarely handed out / relied upon. |
10:34 |
jeff |
csharp_: that "unless" bit around the check_perms call is because check_perms returns undef on success. if the return value is truthy, it means that the user doesn't have the perm. it's... perhaps less than intuitive. |
10:35 |
csharp_ |
jeff: ah - out of context it was really throwing me |
10:35 |
Dyrcona |
Another unpopular opinion: I think we should ditch Perl for the back end (other than utility scripts). |
10:36 |
jeff |
Dyrcona: I don't object to PL/pgSQL functions being used to test "does this user have this perm at X location" and such. It seems efficient and not an egregious "that doesn't BELONG in the database!" kind of thing. |
10:36 |
csharp_ |
Dyrcona: preview of your "rusty" email? :-) |
10:36 |
Dyrcona |
csharp_: yes, but I'll have to write it. It might take me a few more days. |
10:38 |
|
kworstell_isl joined #evergreen |
11:04 |
mmorgan |
Cool! |
11:04 |
Dyrcona |
Yeah, thanks. |
11:05 |
mantis1 |
Dyrcona++ |
11:07 |
gmcharlt |
Dyrcona== |
11:07 |
gmcharlt |
er |
11:08 |
gmcharlt |
Dyrcona++ |
11:14 |
gmcharlt |
if you give a mouse a cookie^W^W^W^W GitHub Actions a commit... |
11:14 |
gmcharlt |
anyway, the GitHub-based automatic tests are now happy again |
11:14 |
pinesol |
News from commits: fix title of 3.11.0 release notes <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=8c52cb5dfef7485f4bec742c2a431c35b39d6c58> |
11:15 |
pinesol |
News from commits: LP#2023582 - 3.11.0 release notes - remove redundant section <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=ba9550376925919ddab361b4b9f918fd8f5b66f7> |
11:15 |
pinesol |
News from commits: LP#2023582: Update RELEASE_NOTES_3_11.adoc - formatting fixes <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=500b04d7a729d30bc87b66aafe53d52220163256> |
11:28 |
|
Christineb_ joined #evergreen |
12:51 |
|
jvwoolf joined #evergreen |
13:13 |
|
dmoore joined #evergreen |
13:45 |
jvwoolf |
Anybody have an issue with Perl modules not getting installed correctly with 3.9.3? |
13:45 |
jvwoolf |
We've installed it a few times over the past few weeks (including for our production system) but seem to be having issues with the install on 2 different test servers today. |
13:58 |
JBoyer |
jvwoolf, any OS upgrades in the mix there? |
13:59 |
JBoyer |
(Like 20.04 -> 22.04, not 20.04.9 -> 20.04.10) |
14:13 |
jeff |
jvwoolf: can you say more about what the issues/symptoms are? are there errors at "make install" time, or something else? |
15:10 |
jvwoolf |
I know I did everything right this time on the server I'm working on and I'm getting the same error on make check |
15:11 |
jvwoolf |
@bartender mantis1 |
15:11 |
* pinesol |
fills a pint glass with Ommegang Witte, and sends it sliding down the bar to mantis1 (http://beeradvocate.com/beer/profile/42/16506/) |
15:13 |
jeff |
Above the "Test Summary Report" should be a collection of more specific/detailed error messages. Often times I like to start with the first one, though it's not guaranteed to be the clue that leads to a solution. :-) |
15:14 |
Dyrcona |
jvwoolf: Is this a virtual machine? |
15:15 |
jvwoolf |
Dyrcona: Yes |
15:16 |
|
mantis1 left #evergreen |
15:17 |
Dyrcona |
I'd destroy it and start over. The output from your find commands suggests that it has been upgraded from Ubuntu 16 to 18 to 20. |
15:19 |
jvwoolf |
Dyrcona: That's the case with all of our test VMs at this point |
15:20 |
jvwoolf |
This is the only one that's decided to be a PITA |
15:25 |
Dyrcona |
Try this one: find /usr -name Logger.pm |
15:28 |
* Dyrcona |
was just wondering why my database was missing indexes, and then realized I was checking the wrong schema. |
15:28 |
Dyrcona |
No asset.copy indexes in the actor schema! |
15:29 |
jeff |
based on that output, my next suggestion would be perl -c /usr/local/share/perl/5.30.0/OpenSRF/Utils/Logger.pm |
15:30 |
Dyrcona |
Yeahp. What jeff said. |
15:30 |
Dyrcona |
Probably a busted module somewhere. |
15:32 |
jeff |
(but I also think we may be using the output of paste gKQdDQSz ("the start error") to debug a different machine, so that may not be helpful.) |
15:33 |
jeff |
the errors from "make check" that occurred before the Test Summary Report are my best suggestion at the moment. |
15:33 |
jvwoolf |
jeff: Yes, sorry for the noise on that one |
15:33 |
jvwoolf |
It was just a coincidence that they were both getting Perl-related errors at the same time |
15:34 |
jvwoolf |
/usr/local/share/perl/5.30.0/OpenSRF/Utils/Logger.pm syntax OK |
16:42 |
pinesol |
Launchpad bug 1904737 in Evergreen "Flag/setting for Items with Specific Statuses to Display on Holds Pull List" [Wishlist,In progress] https://launchpad.net/bugs/1904737 - Assigned to Jason Stephenson (jstephenson) |
16:43 |
Dyrcona |
I think I'll see what happens with the current query using that index and dropping the cp_available... index. |
16:43 |
Dyrcona |
I'll bet it's faster. |
16:47 |
Dyrcona |
Yeah... On my test system performance is comparable to the modified query and just slightly faster than the previous cp_available_by_circ_lib_idx. Going to modify the queries to include "deleted is false" to force the is false index to be used. Maybe drop the circ with status code index, too. |
16:49 |
Dyrcona |
Heh. It's using both indexes when they are there. |
16:49 |
Dyrcona |
oops. It's the index on serial.unit that I'm seeing... |
16:53 |
Dyrcona |
To be fair, I should probably loop these variations thousands of times and average them out, and they will likely all be comparable, i.e. within a fraction of a second of each other. |
09:07 |
|
Dyrcona joined #evergreen |
09:09 |
|
Christineb joined #evergreen |
09:23 |
|
mantis1 joined #evergreen |
09:24 |
mantis1 |
Found this error when running autoreconf -i for our 3.11.0 test server install |
09:24 |
mantis1 |
autoreconf: automake failed with exit status: 1 |
09:24 |
mantis1 |
I think this was related to a makefile when I saw it before, but it's been some time |
09:32 |
gmcharlt |
mantis1: what Linux distribution? |
09:40 |
pinesol |
News from commits: LP2019735 Fix Bootstrap5 checkbox borders <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=e62173478e9e509f3f8c225b4ea262e0ffb18dfa> |
09:41 |
mantis1 |
gmcharlt: I figured it out |
10:11 |
pinesol |
News from commits: LP#1996818 Issues Placing Holds from the Patron Record <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=2a2af7843d2db0440ffb3b0fe4c59e3157af35f9> |
10:11 |
Dyrcona |
That might have been the problem. Whenever you do a major version upgrade of Evergreen, it's best to delete the node files in /usr/local/ and to do a `git clean -x -f -d` in your local Evergreen repository to remove any old files. |
10:14 |
mantis1 |
Dyrcona: I have the code prep and scripts done. Is it possible to run these now or does it need to be done at a specific time during the code prep? |
10:16 |
Dyrcona |
mantis1: They should be done before you do anything else. You will probably be OK, because we don't change Node versions that often. I do the git clean -x -f -d from time to time to clean things up on my dev systems particularly if I'm switching release versions or about to test big changes, |
10:18 |
Dyrcona |
I've had weird issues after doing an installation that going back and doing the node deletion or a git clean and reinstalling has fixed. |
10:54 |
Dyrcona |
@blame Apple |
10:54 |
pinesol |
Dyrcona: Apple is really just another name for autogen |
15:05 |
berick |
Dyrcona++ |
15:05 |
Bmagic |
#info RUST timeline |
15:05 |
Bmagic |
berick: I threw this on the agenda because it was bare. Feel free to tell me to move on |
15:06 |
berick |
well... |
15:06 |
berick |
not much so say on the Rust side at this point. kind of waiting/hoping others will get interested and join the momentum |
15:06 |
berick |
i did at this https://github.com/kcls/evergreen-universe-rs/blob/main/PRIMER.md |
15:06 |
berick |
tiny primer |
15:07 |
berick |
i think the bigger question now is more about the Redis stuff, which has been decoupled from Rust now |
15:07 |
berick |
and is ready for wider testing |
15:07 |
Dyrcona |
berick++ |
15:07 |
Bmagic |
oh! berick++ |
15:07 |
Dyrcona |
I'll take a look. |
15:16 |
berick |
so, it's a long game |
15:17 |
jeffdavis |
kind of works as a roadmap though - there's some time to get up to speed on Rust while Redis dev continues, then ramp up with Rust once the Redis stuff is in main? |
15:18 |
berick |
jeffdavis: yeah, pretty much |
15:18 |
Bmagic |
I'm sure more discussions will be had, we can table it. Good to know that berick has Redis up for testing sans Rust! |
15:18 |
Bmagic |
berick++ # for good measure |
15:18 |
jeffdavis |
yeah, really excited for Redis and hoping the Rust interest takes off |
15:18 |
JBoyer |
berick++ |
15:31 |
jeff |
i've no strong opinion either way on one-channel or many-channels, but support having a list of "official" project channels and making logs more readily available for those channels. |
15:32 |
Bmagic |
hmmm, it's public as far as I know. The security stuff wouldn't be there (correct me if I'm wrong releaseers) |
15:33 |
Dyrcona |
It's public, but it is not logged by the bots. |
15:33 |
jeff |
sleary: I think the reason you can't see the channel in your IRC client is the same reason you wouldn't be able to see this channel if you weren't already in it: the channels are +s ("secret") to avoid being listed in the commands that spam bots use, etc. Something we did long ago, and could test removing if folk think +s is causing more trouble than its worth. |
15:33 |
Bmagic |
I mean, the chatter is public |
15:34 |
jeff |
I mention the above because I'm happy to be the one to set up logging / join the bots / list the channels on the wiki or web page / toggle channel modes as needed / etc. |
15:34 |
Bmagic |
so, shall we remove it? |
16:16 |
Dyrcona |
It might be a while before others see the change. |
16:19 |
|
sleary_ joined #evergreen |
16:51 |
jeff |
gmcharlt: in a recent comment on bug 1483496 you mentioned "evergreen.change_db_setting() will be removed shortly" -- I'm wondering if there's additional context to that? I've no objection, just curiosity. |
16:51 |
pinesol |
Launchpad bug 1483496 in Evergreen "evergreen.change_db_setting needs test" [Undecided,Won't fix] https://launchpad.net/bugs/1483496 |
16:52 |
gmcharlt |
jeff: a pending security fix |
16:52 |
jeff |
ah. :-) |
17:02 |
|
mmorgan left #evergreen |
08:04 |
|
BDorsey joined #evergreen |
08:09 |
|
rfrasur joined #evergreen |
08:10 |
|
PhilMakesStuff joined #evergreen |
08:11 |
PhilMakesStuff |
This is a test message to see if I am posting in the correct channel |
08:12 |
PhilMakesStuff |
Quick question: I was wondering if evergreen has a Voluntary Product Accessibility Template (VPAT)? |
08:13 |
PhilMakesStuff |
We will need this in order for our organization to use Evergreen |
08:23 |
JBoyer |
Hi PhilMakesStuff , that sounds familiar but you may have more luck getting responses on the Evergreen general email lists as IRC activity is pretty irregular. |
16:00 |
javier_guel |
great thanks, i will try |
16:44 |
|
dmoore_doppel joined #evergreen |
16:59 |
|
mmorgan left #evergreen |
17:31 |
dmoore |
hey all - any thoughts on this API note published on EBSCO's Novelist page - https://connect.ebsco.com/s/article/Setting-up-On-The-Shelf?language=en_US |
17:32 |
dmoore |
"Note: There is an Evergreen API that supports automatic harvesting of your collection. However, we were unable to obtain a complete harvest for any customers during the testing of this functionality, as Evergreen’s Web Services API was not built for such a wide-scale application. We discourage Evergreen customers from utilizing this feature for collection harvesting." |
17:32 |
csharp_ |
dmoore: we don't use it in PINES, but anecdotally, I've heard from sites who do that the harvesting can eat into available server resources |
17:33 |
berick |
hah, yeah, IIRC, they were madly spewing api calls |
17:33 |
csharp_ |
dmoore: we sent a monthly upload to NoveList so they can reference it offline |