| 00:53 |
|
akilsdonk joined #evergreen |
| 00:53 |
|
Bmagic joined #evergreen |
| 00:54 |
|
troy joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Failed Create Evergreen Database <http://testing.evergreen-ils.org/~live//archive/2022-02/2022-02-02_04:00:02/test.41.html> |
| 08:25 |
|
mantis1 joined #evergreen |
| 08:32 |
|
mmorgan joined #evergreen |
| 08:36 |
|
rfrasur joined #evergreen |
| 13:39 |
jeff |
INSERT INTO permission.grp_tree_display_entry (id, parent, all_parents, depth) VALUES (1, 1, 1, 1, NULL), (2, 1, 1, 2, 3), (3, 1, 1, 3, 2); |
| 13:42 |
Dyrcona |
I can also just remove about 26 charactes from the code and this problem "goes away." :) |
| 13:42 |
Dyrcona |
Yeah, I should find the loop. |
| 13:42 |
jeff |
see if this finds anything? |
| 13:42 |
jeff |
with recursive tree as (select id,parent,array[id] as all_parents, 0::int as depth from permission.grp_tree_display_entry union all select c.id,c.parent,p.all_parents||c.id, p.depth+1 from permission.grp_tree_display_entry c join tree p on (c.parent = p.id) where depth < 1000) select * from tree WHERE depth > 999; |
| 13:43 |
jeff |
(modified miker's query, tested it on my little test case) |
| 13:44 |
Dyrcona |
jeff: Your query returns 0 rows on my data. I wonder if the problem is pgt? |
| 13:44 |
jeff |
wacky. |
| 13:45 |
Dyrcona |
We have multiple nodes with null parent in pgtde. |
| 17:02 |
Dyrcona |
Anyway, look at the time! |
| 17:13 |
mmorgan |
jeff++ |
| 17:17 |
|
mmorgan left #evergreen |
| 18:02 |
pinesol |
News from qatests: Failed Installing Angular web client <http://testing.evergreen-ils.org/~live//archive/2022-02/2022-02-02_16:00:02/test.29.html> |
| 03:35 |
|
Christineb joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:32 |
|
rjackson_isl_hom joined #evergreen |
| 07:48 |
|
collum joined #evergreen |
| 08:28 |
|
mmorgan joined #evergreen |
| 12:21 |
jeff |
good to hear. |
| 12:21 |
csharp_ |
so maybe a good troubleshooting practice to do packet captures when facing anything like this? Jeff was suggesting that from the beginning\ |
| 12:22 |
jeff |
the patron update API call doesn't need several things that we currently send it. I think it's still a good idea to remove children on the org unit when locally fleshing it (the current branch in that bug), but I think there's also some things we should stop sending in the patron update call, and of course there's still the unresolved issue of "services shouldn't fall over in the face of this" |
| 12:25 |
Dyrcona |
jeff: I see something else (though not strictly related) in logs from a test VM that bug me along similar lines. Looks like 1 backend call leads to 200+ on our system when it could probably be a single JSON query. |
| 12:27 |
csharp_ |
jeff++ |
| 12:30 |
|
rjackson_isl_hom joined #evergreen |
| 12:30 |
jeff |
Dyrcona: yeah, that does sound bad. |
| 16:54 |
|
jvwoolf left #evergreen |
| 17:06 |
|
mmorgan left #evergreen |
| 17:59 |
|
nfBurton joined #evergreen |
| 18:01 |
pinesol |
News from qatests: Failed Installing Angular web client <http://testing.evergreen-ils.org/~live//archive/2022-01/2022-01-31_16:00:03/test.29.html> |
| 21:59 |
|
nfBurton joined #evergreen |
| 01:00 |
|
JBoyer_ joined #evergreen |
| 01:01 |
|
jweston_ joined #evergreen |
| 01:07 |
|
berick_ joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 08:04 |
|
rjackson_isl_hom joined #evergreen |
| 08:11 |
|
Keith-isl joined #evergreen |
| 08:33 |
|
mmorgan joined #evergreen |
| 09:37 |
csharp_ |
so awitter and jlamos analyzed the packet capture and saw TCP ZeroWindow errors - we've upped net.core.rmem.max by 25% on one of our servers as an experiment and will run tshark again |
| 09:50 |
|
alynn26 joined #evergreen |
| 10:02 |
|
jvwoolf joined #evergreen |
| 10:18 |
Dyrcona |
Grr. Not sure if code is broken or the test environment is too slow. I can see in the logs that my search returned results, but the Angular catalog screen results section is "blank." |
| 10:18 |
Dyrcona |
And, now, a result is there. Just slow, I guess. |
| 10:42 |
Dyrcona |
I can't figure out why the Angular staff catalog patron search freezes for us as soon as it opens. |
| 10:43 |
Dyrcona |
It freezes the browser tab, even the JS console is non-responsive. |
| 10:43 |
Dyrcona |
Nothing in the Evergreen logs looks suspicious. |
| 10:43 |
Dyrcona |
It's consistent on a test vm and on our training server with Chrome Version 97.0.4692.99 (Official Build) (64-bit) |
| 10:45 |
Dyrcona |
There's a Chrome process running at 100.7% CPU. |
| 10:47 |
Dyrcona |
If I kill that Chrome process, I get the "Aw, snap" screen. |
| 11:13 |
|
mantis1 joined #evergreen |
| 13:07 |
csharp_ |
theory is that something in the new user message stuff is bringing in all the fleshed orgs - but I need to go talk to some food about this |
| 13:12 |
Dyrcona |
Seems like a decent hypothesis. |
| 13:13 |
|
awitter joined #evergreen |
| 13:14 |
Dyrcona |
As for my problem, it doesn't happen on a clean vm with concerto data, so I'm leaning toward an issue with our data or some crud hanging around in the test environment. I am told the problem happens on 3.5 with the experimental catalog enalbed. |
| 13:24 |
jeff |
csharp_: remind me -- is this 3.7 or 3.8? |
| 13:24 |
jeff |
(3.8 with messages, I think, but I'm being lazy and asking instead of verifying.) |
| 13:36 |
csharp_ |
jeff: 3.8.0 |
| 16:42 |
Dyrcona |
:) |
| 16:46 |
|
BAMkubasa joined #evergreen |
| 16:46 |
BAMkubasa |
Do the things in eg/staff/circ/holds/shelf live in a specific database table or are they derived from data in other tables? |
| 16:49 |
* jeff |
tests a fix |
| 16:50 |
Dyrcona |
BAMkubasa: I think that data is derived from action.hold_request where the shelf_time is not null and the shelf_lib is equal to the current working location. |
| 16:52 |
BAMkubasa |
awesome |
| 16:52 |
BAMkubasa |
thanks. I just came across shelf_lib and was starting to poke around and see what it contained |
| 17:39 |
|
mmorgan left #evergreen |
| 17:42 |
|
alynn26_ joined #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:01 |
jeff |
csharp_: one option to fix -- worked in quick testing here: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=1d6f2b25a7436060b20326e2b41b3b8ef4c306b0 |
| 18:01 |
jeff |
also, lp 1959461 |
| 18:01 |
pinesol |
Launchpad bug 1959461 in Evergreen "Fleshing org unit on standing penalties should omit org unit children" [Undecided,New] https://launchpad.net/bugs/1959461 - Assigned to Jeff Godin (jgodin) |
| 18:02 |
jeff |
we might not even need to send standing_penalties on the user object when saving, but we probably shouldn't flesh the children either. |
| 18:03 |
jeff |
(and we should more gracefully handle the large object being present, lest we have DoS issues) |
| 06:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:06 |
|
JBoyer_ joined #evergreen |
| 07:38 |
|
rjackson_isl_hom joined #evergreen |
| 07:49 |
|
collum joined #evergreen |
| 16:55 |
terranm |
jihpringle: in the actual record - lemme look at in the search results... |
| 16:56 |
terranm |
eby: I'm not a guru, but feel free to ask! |
| 16:56 |
mmorgan |
eby: Can't claim guru status, but ... What terranm said!! |
| 16:56 |
jihpringle |
I just tried on our 3.8 test server and I'm not seeing the preferred library item details showing in the grid on the search results screen (just in the counts) |
| 16:57 |
Dyrcona |
I'll have to look at this more tomorrow, but I think my problem is cstore timeouts talking to the database. |
| 16:57 |
eby |
So say have a staff with cancel hold permission at system level. When they go to cancel a hold on another account is that system looking at the patron home library, where the hold is placed or going to or ...? |
| 16:58 |
terranm |
jihpringle: I'm seeing the same thing. The only thing I see for the preferred library is the hold count. |
| 17:02 |
mmorgan |
eby: We haven't come across this, we have UPDATE_HOLD at the consortium level. |
| 17:04 |
terranm |
eby: same here - we have ours set at the consortium level, so we haven't looked into that. I would expect it to either be based on the patron's home library or on the pickup library. |
| 17:04 |
terranm |
jihpringle: +1 to that being a bug |
| 17:05 |
jihpringle |
terranm: speaking of bugs, are you planning to submit a bug for the old notes/alerts/messages surfacing? we're seeing that on our test server too |
| 17:06 |
jeff |
eby: if you are attempting to cancel a hold, the permission check on CANCEL_HOLDS is not scoped to any org unit -- if you have it anywhere, you can cancel a hold. |
| 17:07 |
eby |
Thanks I'll do some more testing. It seemed like it was checking based on the staff's home library which didn't make sense to me. But I'll dig more. |
| 17:07 |
jeff |
eby: "uncancel" is checked at the current hold pickup lib (it also tests the CANCEL_HOLDS permission) |
| 17:07 |
jeff |
so, in theory you can cancel a hold which you cannot then uncancel (without more work) |
| 17:08 |
eby |
ok that is what i was seeing jeff. it was sending the home library which of course would always allow regardless of what you were looking at |
| 17:08 |
eby |
(if you can cancel your own) |
| 17:08 |
terranm |
jihpringle: I haven't been viewing that as a bug since those old messages were still in the system and not deleted. However, we are going to do a cleanup project to mark specific types of old messages deleted. |
| 17:08 |
jeff |
eby: actually, let me fix my first statement... it wasn't quite accurate/precise. |
| 17:09 |
jihpringle |
terranm: we're still early days in our testing but we'd be very interested in what you find as you do your cleanup project since it looks like we'll need to do the same when we upgrade this summer |
| 17:09 |
jeff |
eby: when you attempt to cancel a hold, the permission is checked without passing an org unit -- which means that the permission check is performed based on the org unit of the workstation associated with the user's login session. |
| 17:09 |
jeff |
eby: that might explain what you were seeing better. |
| 17:09 |
terranm |
jeff++ |
| 17:28 |
jeff |
that might be me failing to set a new(ish) org unit setting regarding renewals and expired accounts. I'll look into it. |
| 17:28 |
eby |
I think I did run into that but may have tweaked permissions |
| 17:29 |
jeff |
for now, I'm off. another day! |
| 18:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:16 |
|
rjackson_isl_hom joined #evergreen |
| 07:47 |
|
alynn26 joined #evergreen |
| 07:56 |
|
collum joined #evergreen |
| 11:35 |
terranm |
*music added for my own entertainment |
| 11:40 |
mmorgan |
terranm++ |
| 11:41 |
mmorgan |
The music is perfect! It looks like you were getting several different template versions?? It made me dizzy! |
| 11:43 |
terranm |
Yep - the current version says "Test 8" at the top, but it is apparently randomly pulling up earlier test versions from ... somewhere? No idea where. |
| 11:52 |
Dyrcona |
terranm: Two questions: 1. Are you using Hatch? 2. Have you tried clearing all data from the browser developer tools? |
| 11:53 |
terranm |
1) Nope, 2) - let me try that |
| 12:06 |
terranm |
Nope, that didn't work either. |
| 12:07 |
terranm |
Going to try on a different test server. |
| 12:18 |
csharp_ |
I have OpenSRF debug level logs running on one of our servers and we've had a couple of instances of the open-ils.actor problem - going to keep it running throughout the day to see if we can collect enough data to help us figure this out |
| 12:23 |
|
eady joined #evergreen |
| 12:24 |
terranm |
I'm able to recreate the holds pull list problem on https://demo.evergreencatalog.com/ so I'll open a ticket |
| 16:14 |
|
jvwoolf1 joined #evergreen |
| 16:42 |
|
jvwoolf1 left #evergreen |
| 17:03 |
|
mmorgan left #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 00:22 |
|
jvwoolf joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:30 |
|
rjackson_isl_hom joined #evergreen |
| 08:13 |
|
mantis1 joined #evergreen |
| 08:39 |
|
mmorgan joined #evergreen |
| 11:02 |
Dyrcona |
Yeahp. |
| 11:07 |
Dyrcona |
The places in the OpenSRF code where the errors are coming from look like it would be on first connection or getting the first response from ejabberd. |
| 11:09 |
Dyrcona |
RE Chrome issues from yesterday: I've also had to reload GMail more frequently to it to autofill email recipients. |
| 11:11 |
csharp_ |
ulimit shows 'unlimited' for every user we've tested opensrf, root, ejabberd |
| 11:11 |
csharp_ |
@quote add < Dyrcona> csharp_: My gut could be wrong. I am hungry at the moment. |
| 11:11 |
pinesol |
csharp_: The operation succeeded. Quote #221 added. |
| 11:12 |
csharp_ |
oh - didn't mean to keep the csharp_ part :-) |
| 11:17 |
Dyrcona |
:) |
| 14:45 |
Dyrcona |
terranm++ |
| 14:46 |
terranm |
https://bugs.launchpad.net/evergreen/+bug/1958573 |
| 14:46 |
pinesol |
Launchpad bug 1958573 in Evergreen "Action triggers that create messages for Patron Message Center are setting visiblity to false" [High,New] |
| 14:46 |
terranm |
patch ready for testing |
| 14:46 |
Dyrcona |
Yeah, I got the email. I've not seen it in the wild, but I think looking at the code qualifies me to confirm it. |
| 14:49 |
mmorgan |
terranm++ |
| 14:54 |
|
terranm joined #evergreen |
| 16:33 |
|
jihpringle joined #evergreen |
| 17:03 |
|
mmorgan left #evergreen |
| 17:52 |
|
mantis1 joined #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 19:08 |
|
jihpringle joined #evergreen |
| 19:44 |
|
jihpringle joined #evergreen |
| 23:08 |
|
Keith_isl joined #evergreen |
| 04:08 |
|
phasefx joined #evergreen |
| 04:08 |
|
abneiman joined #evergreen |
| 04:08 |
|
miker joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:09 |
|
collum joined #evergreen |
| 07:32 |
|
mantis joined #evergreen |
| 08:23 |
|
Dyrcona joined #evergreen |
| 09:57 |
mmorgan |
mantis: I'm pretty sure the expired staff login block wouldn't affect patrons, though I haven't actually looked :) |
| 09:57 |
jeff |
and yes, I don't think that the changes for bug 1844121 would have made this become a new issue for you from a patron / opac POV |
| 09:57 |
pinesol |
Launchpad bug 1844121 in Evergreen 3.6 "Able to login to staff client with old card number" [High,Fix released] https://launchpad.net/bugs/1844121 |
| 09:58 |
terranm |
I just tested on a 3.8 test box with the default settings and if you have 333 as a barcode and 222 as a user name, the 333 will work and the 222 won't. |
| 09:58 |
mmorgan |
It's not uncommon in our libraries that the primary barcode in a patron record gets changed when a patron gets a new barcode, but the username does not. |
| 09:59 |
mmorgan |
Then the patron can't login with the username because that "barcode" is inactive, as jeff describes. |
| 09:59 |
terranm |
If I replace the 333 barcode with 444, then the 333 no longer works. |
| 16:30 |
|
rfrasur joined #evergreen |
| 17:23 |
|
mmorgan left #evergreen |
| 17:26 |
|
jvwoolf1 left #evergreen |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 00:46 |
|
eglogbot joined #evergreen |
| 00:46 |
|
Topic for #evergreen is now Welcome to #evergreen (https://evergreen-ils.org). This channel is publicly logged. |
| 01:28 |
|
pastebot joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:30 |
|
Dyrcona joined #evergreen |
| 07:34 |
Dyrcona |
jeff: I figured out my issue with action triggers. It was the template changes. I had the templates in individual files and used m4 to build 1 update SQL file. The string "format" in the templates was interpreted by GNU m4 as the format macro. This broke the templates, including the originals, that got loaded into the database using this method. |
| 07:35 |
Dyrcona |
Two clever by half. :) |
| 13:38 |
|
pinesol joined #evergreen |
| 13:38 |
|
troy joined #evergreen |
| 13:52 |
|
abneiman joined #evergreen |
| 14:16 |
Dyrcona |
Argh...... My tests keep "failing" because of some overlooked detail..... |
| 14:26 |
Dyrcona |
Ah well. I can salvage it this time. |
| 15:48 |
|
Guest88 joined #evergreen |
| 15:57 |
|
jihpringle joined #evergreen |
| 16:13 |
|
abowling joined #evergreen |
| 17:03 |
|
mmorgan left #evergreen |
| 18:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 04:50 |
|
alynn26 joined #evergreen |
| 06:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:18 |
|
Christineb joined #evergreen |
| 07:54 |
|
collum joined #evergreen |
| 08:31 |
|
mantis joined #evergreen |
| 09:38 |
|
jvwoolf joined #evergreen |
| 09:50 |
Dyrcona |
miker: Yes. The TTOPAC pulls titles and authors from the MARC, IIRC. BooPAC uses display fields. |
| 09:53 |
mmorgan |
JBoyer++ |
| 10:50 |
mantis |
We're on 3.6.5 using Angular for the staff but still using TPAC for the OPAC. When accessing the Patron View button on conjoined items, we get a server error. This however works when Boopac is enabled on our other test servers. Is this a known bug? |
| 11:06 |
Dyrcona |
mantis: IDK, but if it is not on Lp, then it's probably not widely known. |
| 11:41 |
|
jihpringle joined #evergreen |
| 12:15 |
collum |
mantis: We don't have any conjoined items, but I just tried it in our test database and it worked in the TPAC. We are on 3.7.2. |
| 12:17 |
mantis |
collum: Thanks for giving it a shot. With the community servers on Bootstrap, it's hard for us to tell if there is an issue on my end or an actual bug. |
| 12:43 |
|
jvwoolf1 joined #evergreen |
| 13:38 |
|
rfrasur joined #evergreen |
| 15:08 |
JBoyer |
Ah |
| 15:09 |
JBoyer |
In that case there should some good news in our email later I suppose. In short, you've got concerto and friends loading deterministically? |
| 15:09 |
JBoyer |
(again, that is) |
| 15:10 |
Dyrcona |
Yes. Test results are consistent. |
| 15:11 |
JBoyer |
Dyrcona++ |
| 15:11 |
Dyrcona |
And all pass, at least, the last few times that I tried. |
| 15:11 |
JBoyer |
Ok, I'm planning to skip release info updates for lack of non-placeholder-ness unless someone prefers that be changed. |
| 17:26 |
miker |
seems unlikely to have recently broken because of that, but I suppose it's possible. the opac email code lacks all the 2019/2020 updates that the reactor got. would be beneficial in any case to have them. I'll look at putting that in the branch as well |
| 17:26 |
miker |
but not tonight! |
| 17:26 |
terranm |
miker++ |
| 18:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 01:10 |
jeff |
Yeah, that doesn't appear to have been "forgotten". The module author appears to have done this intentionally. |
| 01:27 |
jeff |
it looks like the problematic version of the package is no longer considered "latest" in the npm registry as of about 11 hours ago: https://www.npmjs.com/package/colors |
| 01:27 |
jeff |
that timeline doesn't mesh with the build failure, though. |
| 01:28 |
jeff |
i wonder if the test script doesn't reset its modules between runs. |
| 02:47 |
|
jonadab joined #evergreen |
| 06:02 |
pinesol |
News from qatests: Failed Installing AngularJS web client <http://testing.evergreen-ils.org/~live//archive/2022-01/2022-01-09_04:00:02/test.28.html> |
| 09:11 |
|
mantis joined #evergreen |
| 10:13 |
JBoyer |
Mmm. After poking around GH a bit more this morning Jeff was right. Look like the maintainer is just a dumbass that wants to remind everyone that the npm dependency situation will always be untrustworthy. |
| 10:14 |
JBoyer |
And as for the build times, that vm is reset at 11 am and on, but the results aren’t posted until 6 am and pm |
| 10:20 |
jeff |
) |
| 10:39 |
JBoyer |
Should be, yeah. There’s no way to have stale npm artifacts on that machine (and if it doesn’t reset it also doesn’t rebuild so there wouldn’t be any 6pm results) |
| 10:42 |
JBoyer |
Mantis, sorry I missed your question yesterday since I didn’t see the notification. I haven’t tried to hand fix a build (and it should be too late now to replicate). |
| 18:01 |
pinesol |
News from qatests: Failed Installing AngularJS web client <http://testing.evergreen-ils.org/~live//archive/2022-01/2022-01-09_16:00:02/test.28.html> |
| 18:59 |
JBoyer |
Alright, this is tiring. I’ll see what’s going on with the tester in the morning. |
| 05:42 |
|
jonadab joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 12:00 |
|
miker joined #evergreen |
| 12:05 |
|
gmcharlt joined #evergreen |
| 12:11 |
|
Dyrcona joined #evergreen |
| 13:59 |
Dyrcona |
Well, I still manged to mess it up. |
| 14:17 |
csharp_ |
Dyrcona: thanks for the info! |
| 14:22 |
Dyrcona |
csharp_: You're welcome. |
| 14:24 |
Dyrcona |
I believe I have something that works with savepoint. After 1 more test run with 1 item at a time, I'll take a break. After that, I'll write a program to test a mix of items that should fail and succeed. If that works, I'll make the necessary changes to the staff client, and then update the release notes and squash the branch again. |
| 14:26 |
Dyrcona |
Yeah, tests still work. Maybe I'll add the test of multiple copies to the live test file rather than write a whole new program.... |
| 16:07 |
Dyrcona |
So, I'm returning an array ref in the back end call. Are there examples of using such a thing in AngularJS? |
| 16:13 |
Dyrcona |
I think I can just use it as an array. We'll see. |
| 16:32 |
Dyrcona |
Anyone know if I can set values in a toast? I though I could just assign a field on $scope. |
| 16:47 |
Dyrcona |
Well, now my toast is empty.... |
| 16:54 |
Dyrcona |
I'll let this go for now and I might look into it later. I've already gone over time. |
| 17:53 |
|
mantis joined #evergreen |
| 18:00 |
pinesol |
News from qatests: Failed Installing AngularJS web client <http://testing.evergreen-ils.org/~live//archive/2022-01/2022-01-08_16:00:02/test.28.html> |
| 18:04 |
|
jvwoolf1 joined #evergreen |
| 18:32 |
JBoyer |
Oops, accidentally posted this on the feeds channel. So, if you are annoyed like I am about that stupid mess in the mile-long log above it appears to be a forgotten line that was supposed to be removed from the colors package: https://github.com/Marak/colors.js/blob/master/lib/index.js |
| 18:32 |
JBoyer |
I wonder how many more dependencies he pulled in to use .zalgo on that. 🙄 |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:42 |
|
Christineb joined #evergreen |
| 07:31 |
|
rjackson_isl_hom joined #evergreen |
| 08:20 |
|
rjackson_isl_hom joined #evergreen |
| 14:31 |
alynn26 |
me |
| 14:32 |
dluch |
dbs: you want to lead off? |
| 14:32 |
dluch |
(I switched the order of new business items, btw) |
| 14:33 |
dbs |
So first up: correction to my most recent post. |
| 14:33 |
dbs |
You can download the full set of documentation from every commit / branch in GitLab Pages |
| 14:33 |
dbs |
(nothing needs to be figured out, other than my overtired brain) |
| 14:34 |
dbs |
Second: in 3.0 best practice is still to keep a separate git repo for the base Antora build stuff. So I would revert that |
| 14:36 |
dbs |
Third: working in GitLab or GitHub these days feels like lightyears ahead of CLI-based git workflows, given integrated issue tracking, project planning, Web IDE for drive-by contributions, merge request reviewing, etc |
| 14:36 |
|
bott_grpl joined #evergreen |
| 14:36 |
dbs |
but that one is way outside of the scope of "making it easier to build and test docs" and a much bigger discussion |
| 14:36 |
alynn26 |
I actually like working in GitHub better than the CLI. :) |
| 14:37 |
Bmagic |
do we need to migrate the Evergreen repository to a gitlab server in order to get this? We've talked about it as a replacement for Launchpad in a different dev discussion a couple of years ago (probably more because you have to skip the pandemic year(s)) |
| 14:37 |
abneiman |
I definitely prefer a GUI also, but I've gotten accustomed to operating within the CLI to the point where I'd need a github refresher to do the same work there |
| 14:38 |
alynn26 |
A better way to build and test docs that is more intuitive is better. |
| 14:39 |
dbs |
Bmagic: hmm - I'm mirroring the git repo on GitLab (have been since it was on gitorious like ten years ago). I don't think a mirrored branch triggers a GitLab CI/CD thing but I can check |
| 14:40 |
abneiman |
alynn26: hard agree about streamlining build/test of docs - it's a major roadblock right now |
| 14:40 |
dbs |
it might be possible to trigger a rebuild using something like a particular branch name, like docs-build or something hacky... make that a to-do for me |
| 14:41 |
dluch |
Sure |
| 14:41 |
Dyrcona |
FWIW, we run gitlab at CW MARS mainly just to try it out. We don't do any fancy CI/CD stuff though. |
| 14:41 |
Bmagic |
Having our about-to-be submitted docs reviewed and integrated into the Evergreen Docs look and feel would be super tasty. The routine would be to submit your test changes to a certain pre-defined Git branch, and poof, a minute later, it's rendered on a page somewhere |
| 14:41 |
dbs |
alynn26 abneiman: even the small win of "can't merge this because you introduced an error" with a clear error message in the branch discussion is so nice |
| 14:42 |
dluch |
#action dbs will see if it's possible to trigger a rebuild using something like a particular branch name, like docs-build or something hacky |
| 14:42 |
alynn26 |
Clear error messages would be a win for me. |
| 15:51 |
|
_collum joined #evergreen |
| 15:59 |
|
mantis joined #evergreen |
| 16:14 |
|
jihpringle joined #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 11:12 |
mmorgan |
jeff++ |
| 12:17 |
|
jihpringle joined #evergreen |
| 12:33 |
|
collum joined #evergreen |
| 15:22 |
mantis |
We have a test server that is loaded with 3.6.5. Everyone can access the Angular catalog except for one staff member who gets a webby splash page. Thoughts? |
| 15:23 |
berick |
mantis: can they access other Angular pages? |
| 15:25 |
mantis |
berick: looks like she can't access any Angular page |
| 15:25 |
mantis |
This is a new laptop we have set up for a staff member who is also new |
| 15:39 |
jeff |
oh, I may have misread the original symptom report. The hatch advice above may not be relevant. |
| 16:37 |
|
jihpringle joined #evergreen |
| 17:08 |
|
mmorgan left #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:19 |
|
alynn26_away joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:39 |
|
alynn26_away joined #evergreen |
| 07:31 |
|
rjackson_isl_hom joined #evergreen |
| 08:26 |
|
rfrasur joined #evergreen |
| 17:01 |
* miker |
reads up re ingest and mumbles something about queued ingest and a 7.5-ish year old plan and lacking time and tuits, and wanders off |
| 17:02 |
* mmorgan |
wishes many holiday tuits to all! |
| 17:04 |
miker |
@later tell Dyrcona it may be worth confirming that the record attribute vector vlist column for the records you did a partial attirbute reingest on didn't get blown away and replaced with /only/ the attribute you specified. IIRC, I've seen that happen. if it did, it's obv a bug to be fixed for the good of speedier ingest. (also, IIUC, the symspell fixes post-3.7.0 should have addressed the deadlocks -- or at least made them excedingly rare) |
| 17:04 |
pinesol |
miker: The operation succeeded. |
| 17:06 |
|
mmorgan left #evergreen |
| 17:19 |
|
rjackson_isl_hom joined #evergreen |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 19:47 |
|
jihpringle joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:42 |
|
collum joined #evergreen |
| 08:07 |
|
rjackson_isl_hom joined #evergreen |
| 08:15 |
|
mantis joined #evergreen |
| 11:46 |
miker |
and they're both restricted to 1 file, so, easy peasy |
| 11:46 |
csharp_ |
yep |
| 12:23 |
mmorgan |
Has anyone gathered some experience with 3.7+ in a production database with saving/loading bib records? We're trying to get an idea of the effect of the symspell dictionaries for did you mean. |
| 12:26 |
csharp_ |
mmorgan: we're going to 3.8 next month - running it on a training/testing server that is production-ish, datawise |
| 12:26 |
csharp_ |
what should we be looking out for? |
| 12:26 |
jeff |
We're not relying on "did you mean" and did not populate the related tables as part of our upgrade. I've noticed a deadlock or two which have made me want to look into disabling the relevant triggers until I have time to look into it more. |
| 12:28 |
jihpringle |
mmorgan: we're running 3.7.0 and do not have "did you mean" turned on. In testing with it on we couldn't save any MARC records |
| 12:29 |
jihpringle |
we haven't tested with any of the post 3.7.0 "did you mean" fixes yet |
| 12:29 |
mmorgan |
csharp_: Our big concern is loading records with 856 links. We do a lot of that, but general saving and loading of bib records via vandelay is our concern, too. |
| 12:31 |
mmorgan |
We've just begun testing with production data and so far are seeing the records with 856 links taking MUCH longer, also getting general.unknown error for some records that have failed to load. |
| 12:31 |
mmorgan |
jeff: Not sure what you mean by a 'deadlock' ? |
| 12:32 |
mmorgan |
jihpringle: We've loaded some of the post 3.7.0 fixes. |
| 12:32 |
berick |
jeff: if you decide to disable, mind sharing what all you disable? |
| 12:33 |
mmorgan |
We're very early in testing, and were just wondering if others were ahead of us and had experiences regarding saving/loading records. |
| 12:38 |
mmorgan |
jihpringle: Have you done anything other than turning off "did you mean"? My thinking is that even with it off, the sysmpell dictionaries in the database would still be updated without disabling triggers like jeff mentions. |
| 12:38 |
csharp_ |
mmorgan: a deadlock is a postgresql level problem where two processes are waiting on each other to release the lock on a paritcular tuple ("row") |
| 12:39 |
mmorgan |
csharp_: Ah. Ok, thanks. I think I've seen log entries complaining about tuples. |
| 12:39 |
jeff |
mmorgan: the postgresql logs will log a deadlock when the database detects that process X and process Y (and maybe process Z) are all waiting on things that each other are waiting on. It's one of the reasons that pingest doesn't do certain bib-related ingest things in parallel. |
| 12:45 |
pinesol |
csharp_: The operation succeeded. Quote #219 added. |
| 12:46 |
csharp_ |
when it comes down to it, aren't we all just "waiting for more data from parent"? |
| 12:48 |
* csharp_ |
is referring to the server error mentioned yesterday http://irc.evergreen-ils.org/evergreen/2021-12-14#i_497049 |
| 13:00 |
mmorgan |
testing a file of 1000 records with 856 links on our 3.7 test system is not looking good. 6% progress after an hour, and most failed. |
| 13:03 |
JBoyer |
There are a couple dym-related patches that you may not have depending on your 3.7.X version. Since they're all just function updates they can be applied anytime and absolutely should be if you don't have them. |
| 13:03 |
JBoyer |
Sadly, I don't actually have a list handy to refer to... |
| 13:05 |
jeff |
...and Launchpad search returns 101 open tickets on a search for "did you mean"... :-P |
| 16:49 |
JBoyer |
I quite enjoyed this log4j take: https://twitter.com/leanrum/status/1470954707120181253 |
| 17:01 |
|
mmorgan left #evergreen |
| 18:00 |
|
jihpringle joined #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 19:01 |
|
eglogbot joined #evergreen |
| 19:01 |
|
Topic for #evergreen is now Welcome to #evergreen (https://evergreen-ils.org). This channel is publicly logged. |
| 19:32 |
|
jihpringle joined #evergreen |
