| 06:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:52 |
|
rjackson_isl_hom joined #evergreen |
| 08:30 |
|
Dyrcona joined #evergreen |
| 08:32 |
|
mmorgan joined #evergreen |
| 09:37 |
Dyrcona |
JBoyer: I think we do, so I'll check that. Thanks for the suggestion. |
| 09:47 |
jeff |
chopPunctuation, chopPunctuation, chopPunctuation... heh. |
| 09:49 |
Dyrcona |
Yeah, I haven't looked but I suspect a busted field in the MARC. Maybe i should dump it now before someone changes it. |
| 09:54 |
jvwoolf |
Dyrcona: Before I forget again, I wanted to say that we tested the patch in 1482757 and it worked fine. We've got it running in production now. |
| 09:54 |
jvwoolf |
Let's see if I can get that to link correctly - lp1482757 |
| 09:54 |
Dyrcona |
Lp 1482757 |
| 09:54 |
pinesol |
Launchpad bug 1482757 in Evergreen "Loading records with located URIs should not delete and recreate call_numbers" [Low,Confirmed] https://launchpad.net/bugs/1482757 |
| 09:54 |
jvwoolf |
Dyrcona++ |
| 16:17 |
Dyrcona |
"Paprika! That will fix it." |
| 16:18 |
Dyrcona |
I just have to figure out why the proper logo isn't showing up, and why it still looks like it is in the navbar. I think that latter is a style issu. |
| 16:22 |
Dyrcona |
Guess I'll squash these little fixes out later... |
| 16:27 |
Dyrcona |
OK. I think I need to update the Apache configuration on my test vm to handle our library URLs correctly. |
| 16:27 |
Dyrcona |
But, that will have to wait for Monday. |
| 16:35 |
Dyrcona |
Have a good weekend, everyone! |
| 17:09 |
|
jihpringle joined #evergreen |
| 17:12 |
|
JBoyer joined #evergreen |
| 17:12 |
|
mmorgan left #evergreen |
| 17:49 |
|
jvwoolf left #evergreen |
| 18:02 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live//archive/2022-02/2022-02-25_16:00:02/test.42.html> |
| 01:22 |
|
Bmagic joined #evergreen |
| 01:38 |
|
Bmagic joined #evergreen |
| 01:38 |
|
dluch joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Failed Installing Evergreen database pre-requisites <http://testing.evergreen-ils.org/~live//archive/2022-02/2022-02-22_04:00:02/test.39.html> |
| 07:16 |
|
rjackson_isl_hom joined #evergreen |
| 07:32 |
|
collum joined #evergreen |
| 08:26 |
|
rfrasur joined #evergreen |
| 08:34 |
|
jvwoolf joined #evergreen |
| 09:05 |
|
Dyrcona joined #evergreen |
| 09:07 |
|
Keith__isl joined #evergreen |
| 10:04 |
csharp_ |
somebody commit something to master so I can see whether the @rss version of commit announcement suffices for our purposes :-) |
| 10:06 |
csharp_ |
Dyrcona: I missed that you had included removing PG 9.6 on your branch - makes sense, but I wasn't seeing it before :-/ |
| 10:11 |
csharp_ |
Dyrcona: I'm interested in seeing that branch go in... to fully test it, would I want to run all the PGtap tests on PG 10-14? or is there another way? |
| 10:13 |
csharp_ |
(this is why I prefer more granular bugs/fixes, btw - not trying to be critical since you've done so much work though :-) ) |
| 10:28 |
Dyrcona |
csharp_: Commit the branch that updates the PostgreSQL prerequisite targets. That should test the rss feeds. :) |
| 10:29 |
Dyrcona |
My branch changes the default client to Pg 14, IIRC. I'm using it on almost all of my VMs with Pg 10 databases with no issues. |
| 10:30 |
Dyrcona |
As for more granular bug fixes, I mostly agree. I don't like the giant omnibus branches that sometimes appear. I also prefer more, smaller commits over larger commits that touch more lines/files. |
| 10:30 |
Dyrcona |
In the case of my branch, I think it's scope is fine. I don't see why removing Pg 9.6 and adding support for newer Pg version should be separate. |
| 10:32 |
csharp_ |
Dyrcona: makes sense - I wasn' |
| 10:32 |
csharp_ |
t speaking specifically about removal of 9.6 - it just looks like a whole lot to test at once :-) |
| 10:33 |
csharp_ |
but, I'm going for it, so we'll see :-) |
| 10:33 |
Dyrcona |
Nah, not so much. Just inst all Pg 10, if the tests pass, that's all you've really got to worry about. I say int he README that the other versions are not fully tested and may have performance issues. |
| 10:34 |
* Dyrcona |
wishes his fingers would cooperate. |
| 10:34 |
Dyrcona |
csharp_++ |
| 10:34 |
csharp_ |
ok, that's where I was starting anyway |
| 10:35 |
Dyrcona |
If you want to test a different Pg version, I'd recommend Pg 14. |
| 10:35 |
Dyrcona |
It has the most changes from Pg 9.6/10, and it is the latest. |
| 10:37 |
csharp_ |
will do |
| 10:40 |
Dyrcona |
I should use the other installations on my development db server more. I've mostly just been using Pg 10 lately. |
| 10:41 |
csharp_ |
Dyrcona: do you have the alternate versions running together on different ports? |
| 10:42 |
Dyrcona |
csharp_: Yes. When I want to test one version in particular, I'll swap out a configuration file with optimized parameters and reboot. |
| 10:42 |
Dyrcona |
If I'm not too fussed for performance, I'll just change the ports in my client config. |
| 12:00 |
|
jihpringle joined #evergreen |
| 12:04 |
csharp_ |
Dyrcona: I see this when running pg_prove on PG 10/master + your branch: https://pastebin.com/cYA4qzDW |
| 13:00 |
csharp_ |
Dyrcona: now I'm getting https://pastebin.com/LjE1DtxJ (I cherry-picked your latest commit on top and rebuild the DB) |
| 13:02 |
csharp_ |
s/rebuild/rebuilt/ |
| 13:02 |
csharp_ |
gonna step away for a few |
| 13:09 |
Dyrcona |
Another typo. I thought I tested these after making the changes.... |
| 13:10 |
Dyrcona |
Again, the db upgrade script is correct. Maybe I only ran the tests after running the db upgrade with the switch from namespace to local-name()? |
| 13:14 |
Dyrcona |
OK. This one looks like the last issue. I've poured over the diffs and don't see any other changed XPath that looks bad. |
| 13:16 |
Dyrcona |
Fortunately I put the XPath canges all in one commit. |
| 13:16 |
Dyrcona |
s/canges/changes/ |
| 13:16 |
Dyrcona |
typos-- |
| 13:19 |
Dyrcona |
csharp_: Same deal I pushed a new commit. |
| 13:22 |
* Dyrcona |
sighs. Some days are more typo-prone than others. |
| 14:41 |
csharp_ |
yay!: |
| 14:41 |
csharp_ |
Result: PASS |
| 14:41 |
csharp_ |
ok, now onto PG 14 |
| 15:01 |
csharp_ |
Dyrcona: ok, PG 14 pgtap tests pass too - is there anything else I should test? |
| 15:07 |
Dyrcona |
You could try the Perl tests. Do anything you'd normally do, like circulation or whatever. |
| 15:08 |
csharp_ |
10-4 |
| 16:07 |
Dyrcona |
So, I'm trying to figure out how the bootstrap OPAC knows to load main_logo.png. So far it just seems to be magic. My motivation is, I want to replace it with CWMARS' Logo, name home-logo.png. I'd rather not just replace main_logo.png, but I will if I have to. |
| 16:08 |
* csharp_ |
looks around for terranm but doesn't see her |
| 16:08 |
csharp_ |
she's our resident boostrap OPAC person :-) |
| 16:08 |
csharp_ |
@seen terranm |
| 16:08 |
pinesol |
csharp_: terranm was last seen in #evergreen 2 years, 23 weeks, 6 days, 4 hours, 39 minutes, and 31 seconds ago: <terranm> Bmagic++ for setting up bug squashing test server! https://docs.google.com/spreadsheets/d/1qYNGrJBt42_ArQzbwlcnKxS3TobDnmquSXZzopOkZh4/edit#gid=0 |
| 16:08 |
csharp_ |
huh I guess she's using a different nick lately :-/ |
| 16:10 |
Dyrcona |
My suspicion is it has something to do with glide.js, but my suspicions are frequently incorrect. |
| 16:11 |
csharp_ |
https://gapines.org/opac/images/main_logo.png - she must have figured out how to change it |
| 16:52 |
|
jvwoolf left #evergreen |
| 17:02 |
|
jihpringle joined #evergreen |
| 17:09 |
|
mmorgan left #evergreen |
| 18:00 |
pinesol |
News from qatests: Failed Installing Evergreen database pre-requisites <http://testing.evergreen-ils.org/~live//archive/2022-02/2022-02-22_16:00:02/test.39.html> |
| 06:00 |
pinesol |
News from qatests: Failed Installing Evergreen database pre-requisites <http://testing.evergreen-ils.org/~live//archive/2022-02/2022-02-15_04:00:02/test.39.html> |
| 08:00 |
|
collum joined #evergreen |
| 08:36 |
|
mantis1 joined #evergreen |
| 08:38 |
|
mmorgan joined #evergreen |
| 11:19 |
berick |
heh |
| 11:25 |
mmorgan |
csharp_++ |
| 11:26 |
mmorgan |
though my head is now spinning a bit :) |
| 11:37 |
Dyrcona |
csharp_: Part of the point of what I'm testing is to avoid cataloging staff from using MarcEdit to edit the 856s....They say it's the most time consuming step. |
| 11:37 |
Dyrcona |
Since I've got a Perl program to do that part, I may just add code to clean up certain junk characters. |
| 11:38 |
csharp_ |
good plan |
| 11:39 |
Dyrcona |
Yes, I've assigned myself to look at Bmagic's record loader, but don't think I'll use it for this process, just yet: Bug1947898 |
| 11:39 |
Bmagic |
Dyrcona++ |
| 11:39 |
Dyrcona |
Missed a space: Lp 1947898 |
| 11:39 |
pinesol |
Launchpad bug 1947898 in Evergreen "Enhanced MARC importer script electronic_marc_import.pl" [Wishlist,Confirmed] https://launchpad.net/bugs/1947898 - Assigned to Jason Stephenson (jstephenson) |
| 11:54 |
Dyrcona |
The reload finished in time for me to start another test run before lunch, so here goes. |
| 11:55 |
|
jihpringle joined #evergreen |
| 12:33 |
Dyrcona |
Yeah, after looking up the Windows-1252 character set, I'm pretty sure that what I'm seeing are the Euro symbol (0x80), double dagger (0x87), and right single quotation mark (0x92). |
| 12:34 |
Dyrcona |
There may be others, but I remember those three codes from the output. |
| 12:51 |
Dyrcona |
We're using Pg 10. Haven't noticed any real performance differences with Pg 9.6. |
| 12:51 |
Dyrcona |
At Pg 11, most things start getting faster, but others seem to get hit. |
| 12:52 |
Dyrcona |
We do a dump and restore at least whenever we get new hardware. |
| 12:52 |
Dyrcona |
I do them weekly to keep some test databases up to date. Anyway, getting off topic. |
| 12:54 |
Dyrcona |
Going back to my record load/character issues, the message isn't coming from MARC::Record, either. I've got a program to dump the 856s that uses the same code to read the records and it doesn't peep. |
| 12:56 |
Dyrcona |
I wonder if I can just convert the raw MARC data or if I need to do it field by field.... |
| 13:04 |
Dyrcona |
Now, it's just looking like some garbage and not necessarily Windows 1252... Probably a mix.... :( |
| 16:27 |
abowling |
Dyrcona++ |
| 16:28 |
Dyrcona |
I'm not sure if Elaine's comment regards the patch (it sounds like it), or if she's saying that she doesn't see the bug. |
| 16:29 |
Dyrcona |
I guess since I |
| 16:29 |
Dyrcona |
I'm having fun loading resources in a test database, I could check that one out, too... |
| 16:38 |
Dyrcona |
Alright, so, some of the records were not set to UTF-8 in the LDR, and I suspect that at least one of them was giving me this warning/error. |
| 16:39 |
abowling |
Dyrcona: thanks again! that fixed it. |
| 16:40 |
Dyrcona |
abowling: Cool. If you could update the Lp bug, that would be great. |
| 16:47 |
|
jvwoolf left #evergreen |
| 16:47 |
abowling |
Dyrcona: will do |
| 17:04 |
|
mmorgan left #evergreen |
| 18:00 |
pinesol |
News from qatests: Failed Installing Angular web client <http://testing.evergreen-ils.org/~live//archive/2022-02/2022-02-15_16:00:02/test.29.html> |
| 18:23 |
|
jeff joined #evergreen |
| 18:59 |
|
jonadab joined #evergreen |
| 00:52 |
|
troy joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Failed Installing Evergreen database pre-requisites <http://testing.evergreen-ils.org/~live//archive/2022-02/2022-02-14_04:00:02/test.39.html> |
| 07:44 |
|
collum joined #evergreen |
| 08:17 |
|
Dyrcona joined #evergreen |
| 08:37 |
Dyrcona |
Another stuck search query running for 18 hours, well, two, but they look like the same search in the database. I guess the patron/staff tried it again when it didn't return any results. |
| 11:13 |
Dyrcona |
We had some libraries leave a few years ago. While looking into adding records for an e-resource vendor, I stumbled across asset.uri entries from this vendor for one of the libraries that left. |
| 11:15 |
Dyrcona |
I though we must have some 856s still in the database, but no. There are no links to asset.uri_call_number_map for these asset.uri entries, no asset.call_number entries, and I didn't find any metabib.real_full_rec entries when I did a tsquery on index_vector. |
| 11:15 |
Dyrcona |
Anyone else seen orphaned asset.uri entries before? |
| 11:16 |
Dyrcona |
I was able to just delete them from a test database. |
| 11:16 |
mmorgan |
bug 1482757 rears its ugly head :) |
| 11:16 |
pinesol |
Launchpad bug 1482757 in Evergreen "Loading records with located URIs should not delete and recreate call_numbers" [Low,Confirmed] https://launchpad.net/bugs/1482757 |
| 11:18 |
Dyrcona |
Yeah, maybe, but this feels like a different bug. I'll have to reread that one to see if orphaned entries are mentioned. |
| 11:22 |
pinesol |
Launchpad bug 1482757 in Evergreen "Loading records with located URIs should not delete and recreate call_numbers" [Low,Confirmed] |
| 11:22 |
Dyrcona |
Intereestingly, I found 20,000+ entries in metabib.real_full_rec that reference this particular libary in the 856, but no subfield u, just 9, y and z. |
| 11:22 |
Dyrcona |
GIGO. |
| 11:23 |
Dyrcona |
mmorgan: Cool, I'll read the bug description again. IIRC, I already signed off on the branch, no? I don't think it made much difference in performance when I tested it. |
| 11:24 |
* mmorgan |
needs to refresh memory on that, too. We are running some version of that patch in production. |
| 11:25 |
mmorgan |
Not sure it makes much difference in performance, but does eliminate call number churn. |
| 11:34 |
Dyrcona |
Right. I think I'm just going to do a blanket search for orphaned asset.uri entries and delete them. |
| 12:35 |
Dyrcona |
Over 2/3 of our asset.call_number table is deleted = 't' rows. I didn't bother to count those with the ##URI## label. |
| 12:38 |
|
jihpringle joined #evergreen |
| 12:44 |
|
jihpringle68 joined #evergreen |
| 12:52 |
Dyrcona |
Maybe it's high time that patch went in. I signed off over a year ago, but that probably means it needs a rebase and to be tested again. |
| 12:58 |
jvwoolf |
Dyrcona: If you rebase it, I can test it on a 9.6 DB with production data |
| 12:58 |
jvwoolf |
We're only running Evergreen 3.6 though |
| 12:59 |
jvwoolf |
Also, I see that there's an upgrade query in here to get rid of the orphaned entries in asset.uri_call_number_map but nothing to get rid of the call numbers |
| 13:00 |
jvwoolf |
I think that probably needs to be addressed in the release notes at the very least. It's probably better handled outside the upgrade scripts since it would be deleting the majority of the asset.call_number table in our case. |
| 13:03 |
Dyrcona |
jvwoolf: You can't really get rid of the call number. They just get tagged deleted. Or, do you mean, that there should be something to set call numbers deleted, too? |
| 13:04 |
jvwoolf |
Dyrcona: I think for us, we're going to need to get rid of the call number or our reports for filtering on call number are going to stay broken |
| 13:04 |
jvwoolf |
So maybe we're a special case |
| 16:30 |
|
Keith-isl joined #evergreen |
| 16:51 |
|
jvwoolf left #evergreen |
| 17:10 |
|
mmorgan left #evergreen |
| 18:01 |
pinesol |
News from qatests: Failed Installing Evergreen database pre-requisites <http://testing.evergreen-ils.org/~live//archive/2022-02/2022-02-14_16:00:02/test.39.html> |
| 09:09 |
|
jvwoolf joined #evergreen |
| 09:10 |
csharp_ |
yes, lesson is never upgrade anything ever for any reason whatsoever |
| 09:11 |
alynn26 |
csharp_++ |
| 09:11 |
Dyrcona |
Pretty much. At least not without testing it on more or less the same hardware, first. |
| 09:11 |
Dyrcona |
csharp_++ |
| 09:14 |
|
jvwoolf1 joined #evergreen |
| 09:16 |
csharp_ |
now fighting with fastcgi (I think) |
| 09:36 |
jeff |
I'm not even certain open-ils.auth is to blame, or the only service affected. It's just the first thing that a staff login page hits. :-) |
| 09:44 |
jeff |
oh, cute. yep, it was auth. found more clues in router syslog messages, found a misbehaving client. |
| 09:44 |
jeff |
still, the misbehavior could be symptom-not-cause, but worth pulling on this thread next. |
| 09:51 |
Dyrcona |
jeff: I'm taking bug 1959904 from you. I'm testing a potential fix today. |
| 09:51 |
pinesol |
Launchpad bug 1959904 in Evergreen "Angular Patron Search Can Freeze the Browser" [Undecided,Confirmed] https://launchpad.net/bugs/1959904 - Assigned to Jeff Godin (jgodin) |
| 09:52 |
jeff |
cool, i was working on that this morning but I'll stop. |
| 09:53 |
Dyrcona |
Well, I don't want to intrude, but we really want this fixed. :) |
| 16:07 |
|
pinesol joined #evergreen |
| 16:31 |
|
jihpringle joined #evergreen |
| 17:05 |
|
mmorgan left #evergreen |
| 18:01 |
pinesol |
News from qatests: Failed Installing Evergreen database pre-requisites <http://testing.evergreen-ils.org/~live//archive/2022-02/2022-02-11_16:00:02/test.39.html> |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 08:28 |
|
mantis1 joined #evergreen |
| 08:31 |
|
rfrasur joined #evergreen |
| 08:40 |
|
mmorgan joined #evergreen |
| 13:03 |
Dyrcona |
miker: I haven't tried that search. |
| 13:03 |
miker |
looks like we should push the exact match construct down into the initial search structures. I wonder if my "make joins CTEs" patch helps here. I'll dig that up. |
| 13:08 |
Dyrcona |
Did they actually type "winter AND sports" in the search box? Do I understand that corectly? I did a keyword from advanced search with winter in one and sports in the other and it came back rather quickly. |
| 13:09 |
jeff |
I haven't specifically tested the "make joins CTEs" patch against postgresql < 12 and >= 12, but the change in CTE optimization fence behavior suggests that it might be a good idea (to test/compare). :-) |
| 13:09 |
Dyrcona |
Looks like they typed "winter" AND "sports" |
| 13:10 |
Dyrcona |
I hate when they try to outsmart the query engine. They usually do with bad consequences. :) |
| 13:11 |
Dyrcona |
Yeahp. The variation with the quotes takes longer/hangs. Hasn't been long enough to tell, but the quotes definitely take longer. |
| 16:02 |
|
jihpringle joined #evergreen |
| 17:03 |
|
jvwoolf left #evergreen |
| 17:10 |
|
mmorgan left #evergreen |
| 18:01 |
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:19 |
|
rjackson_isl_hom joined #evergreen |
| 08:24 |
|
collum joined #evergreen |
| 08:27 |
|
rjackson_isl_hom joined #evergreen |
| 15:12 |
phasefx |
miker++ |
| 15:12 |
shulabear |
What are the duties of the release team? |
| 15:12 |
terranm |
miker++ |
| 15:13 |
miker |
shulabear: coordinating, prodding folks to test/signoff/commit, release building |
| 15:13 |
gmcharlt |
miker++ |
| 15:13 |
terranm |
I'm happy to be bug squash/feedback fest wrangler again |
| 15:13 |
phasefx |
I didn't help a lick with the last team I was on; I'm willing to, but may need some help/direction |
| 15:27 |
Dyrcona |
gmcharlt: Does it still use Dojo? |
| 15:27 |
gmcharlt |
Dyrcona: correct, that hasn't changed |
| 15:28 |
Dyrcona |
Do we have plans to replace it with something that doesn't use Dojo? |
| 15:29 |
JBoyer |
I assume the choicest signoffs will involve using an Overdrive testing account, which I ... have gotten in the past but no longer remember the level of hassle one is required to endure. Have you and jeffdavis verified the actual downloading bits so that "Doesn't break my system and looks sane" type signoffs are sufficient? |
| 15:29 |
gmcharlt |
JBoyer: yes, we've verified it w.r.t. to real OverDrive credentials |
| 15:29 |
JBoyer |
gmcharlt++ |
| 15:29 |
JBoyer |
jeffdavis++ |
| 15:29 |
Dyrcona |
JBoyer: Even if you have credentials the Overdrive test environment is a pain to use. |
| 15:30 |
|
jvwoolf1 joined #evergreen |
| 15:31 |
JBoyer |
Though to guess at the answer to your Q Dyrcona, I haven't seen specific mention of a major update to the feature that I can recall. Depending on what Dojo is doing it could be a major undertaking. |
| 15:31 |
JBoyer |
And I can't say I'm surprised that it's a hassle to work with their backend. I'm still salty about the time they took away ftp access to new records. |
| 15:39 |
terranm |
JBoyer++ |
| 17:06 |
|
mmorgan left #evergreen |
| 17:34 |
|
jvwoolf1 left #evergreen |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:12 |
|
jihpringle joined #evergreen |
| 21:52 |
pinesol |
[evergreen|gmontimantis] Docs: Updating Opac Lists doc - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ad42342> |
| 22:45 |
pinesol |
[evergreen|Lynn Floyd] Adding videos from Conferences - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=bb054da> |
| 00:08 |
|
Kolvir joined #evergreen |
| 00:09 |
Kolvir |
Can I run the evergreen server and the client interface on a single system? |
| 00:22 |
jeff |
It can be done, especially for testing or development, but I wouldn't recommend it for "real" production use. |
| 00:26 |
Kolvir |
I'm going to be in charge of computerizing a small church library, completely paper based now, and am looking for a software package |
| 00:31 |
Kolvir |
There will only be one computer for patron use, and really doesn't need to be a separate one for admin, unless evergreen would require it. |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:16 |
|
rjackson_isl_hom joined #evergreen |
| 07:55 |
|
alynn26 joined #evergreen |
| 08:34 |
|
mantis1 joined #evergreen |
| 14:42 |
|
Christineb joined #evergreen |
| 16:44 |
|
jvwoolf left #evergreen |
| 17:10 |
|
mmorgan left #evergreen |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:40 |
|
jihpringle joined #evergreen |
| 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: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> |
