Search in #evergreen

Results

Result pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148

Results for 2023-03-01

13:23	Dyrcona	csharp_: I fix that one and I get more.
13:27	Dyrcona	csharp_: I have a patch, but I want to make sure it is correct.
13:32	Dyrcona	I think we might want to fix some of the other changes from 06dd3972f5b
13:47	csharp_	Dyrcona: thanks - happy to test when you're ready
13:47	Dyrcona	csharp_: No usable branch yet, but I did open a Lp 2008925
13:47	pinesol	Launchpad bug 2008925 in Evergreen "Template Toolkit Syntax Errors Introduced by Aria Label Fix" [Undecided,New] https://launchpad.net/bugs/2008925
13:53	csharp_	Dyrcona++
16:47	kmlussier	Oh! Of course. This must've been a post-Kathy thing then, because I don't remember seeing it before.
16:48	* Bmagic	says Good to see you kmlussier!
16:48	mmorgan	JBoyer: You need to do a sweetdumpling next.
16:49	JBoyer	Yeah, it's a post-2019 thing, I didn't regularly run a testing server this week until I started at EOLI. (We did do some local testing on prod-ish data at the ISL)
16:49	kmlussier	butternut is my favorite squash
16:49	berick	if it's in GA, sweetdumplin'
16:49	JBoyer	I apparently have to look this up.

Results for 2023-02-28

09:09	Stompro	Dyrcona, I didn't see your question yesterday, I'll send you what I have for Content Cafe. I have an integration guide from 2010.
09:19		montgoc1 joined #evergreen
09:21		Stompro joined #evergreen
09:21	Stompro	mmorgan, I just tested it again with Postman, and the request worked!!!
09:21	Dyrcona	Stompro++
09:23	mmorgan	Woo! Just cleared added content cache for a record and got a cover image!
09:23	mmorgan	Stompro++

Results for 2023-02-27

07:47		BDorsey joined #evergreen
08:30		mmorgan joined #evergreen
08:31		kworstell-isl joined #evergreen
08:33	Stompro	mmorgan, I didn't see your question on Friday, B&T did say it was on their end. It is still broken this morning when I test it.
08:35	mmorgan	Stompro: Thanks! I got a similar reply from B&T late Friday. Tested it first thing myself, too.:) Still broken.:-(
08:57		kworstell-isl joined #evergreen
09:24		kworstell-isl joined #evergreen
09:37		dguarrac joined #evergreen
10:22	ahazaril	when i'm doing check-out, it shows error: no_matchpoint
10:22	csharp_	ahazaril: for all items or just some?
10:23	csharp_	ahazaril: that error means that the conditions of the circulation didn't match any of the rules you've configured
10:23	jeff	It sounds like you have created some policies (based on your post to the mailing list, "Unable to Create Circulation Policies"), but it's possible that the policies you have now created are too specific, and aren't matching the item + library + user that you're testing with. Sometimes a "catch-all" policy helps, other times you want to know that things are amiss -- like the current "no matchpoint" error
10:23	ahazaril	actually i just installed back Evergreen and i'm not fully skilful enough to set up Evergreen
10:23	jeff	you're getting.
10:24	ahazaril	i see

Results for 2023-02-24

12:11	Stompro	Full "<Error>Database 'Jacket' does not exist. Make sure that the name is entered correctly.</Error>"
12:17	Dyrcona	The flipped the case sensitivity flag in their database and didn't tell anyone?
12:18	* Dyrcona	should shut up for now and concentrate on lunch.
12:19	Stompro	Maybe it has to do with requesting multiple keys at once. I'll test if it works with just one search key.
12:22	Stompro	I'll see if my postman account still works and try the case sensitivity thing.
12:27	Stompro	Same result with just one search key.
12:28	Stompro	B&T support says they are reviewing the info now.
12:30	Dyrcona	Bmagic: What you said to me privately about PG15 search performance yesterday appears to be true. I have a Pg15 instance using default settings that's returning search results just about as fast as Pg10 that is optimized on the same hardware. That is, Pg15 and Pg10 are running on the same server.
12:31		Guest397 joined #evergreen
12:32	Bmagic	awesome! I like faster
12:36	Stompro	Dyrcona, using jacketdetail or jacketDetail doesn't fix the issue in a test request. So it must be something else. Evergreen must be one of the only products that uses the XmlPost method to grab added content from them.
12:56	Dyrcona	Stompro++
12:57	Dyrcona	Do you know if they have another method we could try?
12:58	* Dyrcona	looks around for where he left his glass of tea....

Results for 2023-02-23

12:17	Bmagic	that's it, yep
12:18	Bmagic	Evergreen also has "Examples" of interacting with it's own API's. Mostly in Javascript
12:18	Bmagic	I grepped the code for "open-ils.actor.patron.update"
12:19	Bmagic	There's a pretty straightforward example in Perl inside one of the perl tests. I'm looking at 30-barcode-completion.t
12:20	Bmagic	but in that case, you'd have to run your code on the Evergreen server. I assume you're developing something that would interact with the API over the internet
12:21	ACSpike	Right, I want to interact in JSON over HTTP.
12:22	Bmagic	so, you're going to be interested in the javascript implementation. That we have written for our own staff client
14:42	Dyrcona	OK. I should have actually looked at the repo instead of glancing at my github feed. :)
14:44	berick	the gateway is pretty easy to code for, though, and works fine for most tasks, so it's a decent option
14:45	Dyrcona	berick: On patron edit, I want to change all default visibility of 2 to 1.
14:46	Dyrcona	Yeah, the gateway isn't too bad. I wrote something once to log in and logout as a test. I did the same with XML RPC, then a bug was fixed and it broke. :_
14:48	berick	Dyrcona: modifying default visibility in patron editor (2 to 1) should be pretty simple
14:49	berick	angjs editor has a default_field_visibility map
14:49	Dyrcona	My reasoning is 2 is show which always shows up. One is suggested which can be easily hidden. This obviates the need for so many settings.

Results for 2023-02-22

08:48		kworstell-isl joined #evergreen
09:03		Dyrcona joined #evergreen
09:09	pinesol	News from commits: LP1999282 Less intense badges for staff interface <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=39c44d2c0a6f5eab4d93b564b079be1cf75d85f2>
09:56	Dyrcona	BTW, if anyone wants to try development and testing on Pg 15 before Lp 1997098 and Lp 1999274 go in, I pushed user/dyrcona/pg15-master-for-dev to the working repo that combines both of those branches into master. I'm using it on my local development VMs with concerto.
09:56	pinesol	Launchpad bug 1997098 in Evergreen "Add Support for PostgreSQL 15" [Medium,Confirmed] https://launchpad.net/bugs/1997098
09:56	pinesol	Launchpad bug 1999274 in Evergreen 3.10 "Performance of Search on PostgreSQL Versions 12+" [Medium,Confirmed] https://launchpad.net/bugs/1999274
09:57	Bmagic	Dyrcona++
10:03	Dyrcona	I don't know of any site running greater than Pg 10 in production.
10:03	Bmagic	right
10:13		kworstell-isl joined #evergreen
10:20	Dyrcona	Couple of database live tests failed. I'd better have a look.
10:36		Stompro joined #evergreen
10:41		BDorsey joined #evergreen
10:46		Christineb joined #evergreen
11:09	Dyrcona	Pro tip: Try to remember which port is which version of PostgreSQL, or you could waste an hour and a half trying to figure out whey pgtap live tests are failing on 1 server but not the others.
11:09	Dyrcona	s/whey/why/
11:09	pinesol	News from commits: LP#1999274: Add Release Note <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=31e2d9a565a603f0044ce52ff1719e9eaa151dbd>
11:09	pinesol	News from commits: LP#1999274: Improve Search Performance on Pg 12+ <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=aa30c7e7b23a6dc4f10f5f1e7382cba13d787cf5>
11:18	csharp_	ah
11:18	Dyrcona	So, tarball is busted.
11:18	abowling	Dyrcona: yes, that's our operating theory
11:18	* Dyrcona	doesn't use the tarballs, except for testing a release before release.
11:18	abowling	Git build likely works
11:18	abowling	tarball doesn't
11:19	Dyrcona	So that's bug worthy: broken tarball.
11:19	abowling	and i'm not 100% sure of this, but like i said, I wasn't the only one to witness ;)
11:19	Dyrcona	That's all supposed to be automated, but something likely went wrong with one of the npm steps.
11:20	abowling	Dyrcona: agreed; I'm hoping someone can test and disprove my theory...or confirm it
11:20	csharp_	confirmed: no eg2 directory in the 3.10.0 tarball
11:20	Dyrcona	csharp_++
11:20	abowling	csharp_: there's a ton missing...seemingly
11:22	csharp_	or maybe I'm getting punchy - fasting today for Ash Wednesday
11:23	Dyrcona	:)
11:23	abowling	installing 3.9.1 THEN 3.10.0 seemed to take care of a lot of it
11:23	Dyrcona	I solved my issues with ports and testing by doing apt purge postgresql-14. :)
11:23	abowling	we jumped from 3.7.1 to 3.10.0
11:24	Dyrcona	abowling: We were going to do the same, but decided to wait until more 3.10 bugs are fixed.
11:24	abowling	Dyrcona: you decided to wait because you're smarter than I am

Results for 2023-02-21

12:22	Dyrcona	I've referred to the documentation quite a lot, so I have it bookmarked.
12:34		collum joined #evergreen
12:40		collum joined #evergreen
13:03	* Dyrcona	ponders implementing a GUI to send SIP messages for testing purposes. Might be nice to test if check out works, etc.
13:05	Dyrcona	Not today, though.
14:23	Dyrcona	My dog is funny. I got some cashews for a snack. She likes them, too, so I gave her some. She won't eat them if I put them in a bowl or on a plate. I have to hand them to her or drop them on the floor.
14:36	pinesol	News from commits: LP#2007880: fix open-ils.actor.ou_setting.ancestor_default <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=13adaa938b5621f28ee1e30d200d9cb9787f23a3>
16:21	abowling	Dyrcona: yep. nothing.
16:22	Dyrcona	Did you install this clean or on top of a previous installation? If the latter you might want to rm -rf /openils/* and reinstall both OpenSRF and Evergreen.
16:23	Dyrcona	If it was a git checkout, I find that git clean -xfd and then a complete rebuild with autoreconf sometimes helps. Assuming that the problem could be mismatched versions of files...
16:36	pinesol	News from commits: LP1841871: Add a test for creating authority record from bib field <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=35338601f56e3961672e44b1c6001469be9d05c9>
16:38	csharp_	unfortunately our fixes for the view_perm thing for the Library Settings Editor broke holds pull lists and probably other things
16:38	csharp_	there's another bug in one of the subs - I'll file it as soon as I get a chance, but it is not this day
16:39	csharp_	another use case for better test coverage
16:43	Dyrcona	csharp_: Have you tested that with Galen's latest patch for Lp 2007880 that I pushed this afternoon?
16:43	pinesol	Launchpad bug 2007880 in Evergreen " open-ils.actor.ou_setting.ancestor_default broken" [High,Fix committed] https://launchpad.net/bugs/2007880
16:43	Bmagic	sorry abowling, I stepped away. But everyone else's suggestions are perfect!
16:44	csharp_	lawd - I chased my tail for about an hour on that without realizing gmcharlt had already found it
16:45	csharp_	Dyrcona++ # will test on another day
16:45	csharp_	today has accomplished its apparent mission of kicking my ass
16:45	Dyrcona	heh....
16:58	* Dyrcona	calls it a day.
18:41		jihpringle joined #evergreen

Results for 2023-02-20

09:40		collum joined #evergreen
14:56	jmurray-isl	I should probably not admit how much time it took me to realize one of my recently updated Action Trigger environment variables had a space at the beginning...
15:51	rhamby	if I had a dollar for every time I had to find an errant white space, quote or semicolon .....
15:57	jmurray-isl	rhamby: Indeed. This is what I get for copy and pasting from my test server. ;)
15:58	jmurray-isl	And success!
15:58	jmurray-isl	(Oops, wrong chat)

Results for 2023-02-14

15:11	JBoyer	The main event!
15:11	JBoyer	#topic New Business
15:11	JBoyer	#info scottangel: Request for testers / feedback: LP1977554 - Add Password visibility toggle on login screens
15:12	scottangel	Yes! Test away
15:12	JBoyer	Always good to call attention to accessibility and internationalization fixes.
15:12	JBoyer	scottangel++
15:12	JBoyer	#info mantis/gmonti: Procedure for updating terminology in Evergreen
15:15	JBoyer	They don't necessarily have to be individual, but reports should probably be small, limited to a single section of the client or opac.
15:16	rhamby	I think if we have a consensus to make such a change there should be a good faith effort to list logically grouped ones into just a few tickets
15:16	mantis2	JBoyer++
15:16	JBoyer	Smaller patches like that are easier to test and apply, without making them too tiny or so large that we end up with a "# items" printing option sneaking through. :)
15:16	JBoyer	(again?)
15:16	JBoyer	mantis2++
15:17	JBoyer	Any other comments before we move on?

Results for 2023-02-09

11:59		kworstell_isl joined #evergreen
12:00		kworstell_isl joined #evergreen
12:00	Dyrcona	I hope csharp_ comes back to the channel before spending a lot of time on it.
12:01	Dyrcona	I'll ask jamundson to have a look at this on our training/test server.
12:08		rfrasur joined #evergreen
12:26		jihpringle joined #evergreen
12:47	* Dyrcona	has been having weird things happen lately. Yesterday, it was the strange ghost cursor on an Ubuntu 22.04 laptop. Today it is man dumping core on Ubuntu 20.04.
13:33	* Dyrcona	is updating VMs today.
13:41	Dyrcona	That ou_ancestor_setting_log subroutine still looks a bit off to me. It doesn't do anything without an $auth argument, unlike the other.
13:42	Dyrcona	csharp_: Have your tried that second one in a case where you don't have the permission? Does it fail gracefully?
13:48	csharp_	not yet - lemme check
14:01		jihpringle joined #evergreen
14:19		kworstell_isl_ joined #evergreen
14:31	csharp_	Dyrcona: got waylaid - I'll do some testing when I can
14:32		sleary joined #evergreen
14:34	Dyrcona	OK. That function looks like it is missing some pieces, and they were missing before you touched it. I could be wrong, though. I often am wrong.
14:52		kworstell-isl joined #evergreen

Results for 2023-02-08

11:05	pinesol	csharp_: Band 'Surly Bassey' added to list
11:09		Christineb joined #evergreen
11:11	Dyrcona	Oof. My egdev branch is kind of a mess. I should fix it. I wasn't going to use override directories, but somehow there they are.
11:16	Dyrcona	Spot checking a few files, it looks the files in the override directories are the same as the one in the regular directories, so I wonder when/how/why I did that? I don't remember doing it deliberately, but maybe it was a test of something that i didn't undo or an accident.
11:17	Dyrcona	I do recall having trouble getting the commands right to copy them to another repo, so perhaps it happened then and I committed the change?
11:25	Dyrcona	Related to Lp 1979348, I'm trying to find where preferred language gets set in patron registration/edit and I'm either blind or having a bad day because I don't see it. Does anyone have any pointers for the code?
11:25	pinesol	Launchpad bug 1979348 in Evergreen "Need ability to pick what displays for Preferred Language" [Undecided,Confirmed] https://launchpad.net/bugs/1979348

Results for 2023-01-30

16:45	csharp_	@who filed the 2000000th LP bug?
16:45	pinesol	jihpringle filed the 2000000th LP bug.
16:45	csharp_	bug 2000000
16:45	pinesol	Launchpad bug 2000000 in HPLIP "Multiple instances of Python object-testing mistakes" [Undecided,New] https://launchpad.net/bugs/2000000
16:45	csharp_	pinesol: nope, not an EG bug :-/
16:45	pinesol	csharp_: Leave me alone, I'm busy right now.
16:46	* csharp_	hopes that person heard bells and alarms and the Price is Right theme as they hit submit on that

Results for 2023-01-25

10:22		sleary joined #evergreen
10:23	Dyrcona	xmllint and namespaces..... :(
10:25	Dyrcona	Remove the namespace and I still get XPath set is empty....
10:27	Dyrcona	Can I pick records to test, or what? <datafield tag="024" ind1=" " ind2=" "><subfield code="">660355362927</subfield></datafield>
10:27	Dyrcona	No subfield code.....
10:27	Dyrcona	How's that even possible?
10:30	Dyrcona	And, another one with a blank subfield code.
12:51	Dyrcona	OK. I got back to messing with my UPCs and I've verified that the XPath should work. Guess I'll have to wait for the full ingest to finish. One of the options that I used yesterday must have prevented the identifiers from being handled.
12:55	Dyrcona	Oof!
12:55	Dyrcona	I see I still have a problem and the XPath that I updated won't work....
12:58	Dyrcona	I had to modify it slightly for the test script, and I assumed it was equivalent to what was in the database. It was not.
12:59	Dyrcona	OK! Now, it works with the same syntax.
13:00	Dyrcona	Too many different domain specific languages to try and keep straight.... "Says you..." "Says who?" "Says you, the Lisp guy."
13:00	Dyrcona	There's a joke in there. I promise. :)
13:22	Dyrcona	And, here come the "closing early" emails on the directors' list... :)
13:54	jeff	just perpetually overcast and gray skies here: https://youtu.be/FDvImJ_6HYw
15:12	Dyrcona	Looks like I finally fixed the XPath. I've got 106 entries in identifier_field_entry and they all look like UPCs. The ingest hasn't finished, yet.
15:44	jeffdavis	I've got a 3.9.1 test server where I've generated search suggestions (ran the sideloader steps and populated search.symspell_dictionary with >6M rows) and have the org settings/internal flags set to default values, the but I'm not seeing any suggestions on my test searches. Are there other steps I need to take to make this work?
15:58	Dyrcona	jeffdavis: Are you doing single word searches?
16:00	jeffdavis	good question - I am, I'll double check with other testers
16:05	jihpringle	jeffdavis: I just tried a single word and then a multiple word search on our testing server and I don't see anything new whether I get results or not
16:49	Dyrcona	Sorry, got distracted by some work. :)
16:50	Dyrcona	It has been a while since I looked at it. I'll have to do some code diving tomorrow.
16:50	Dyrcona	Cheers!

Results for 2023-01-23

14:31	jeff	can you explain what you mean by "do not look like UPCs"? also, depending on a number of things, you might have a lot of outliers in that LIMIT 100...
14:31	Dyrcona	Yeah, when I do field = 18 they look like ISBNs, and 18 is ISBN.
14:32	Dyrcona	jeff: No problem: 192326039 \| 4144895 \| 20 \| 1. Selected Economic Indicators, 2014-212. Financial Soundness Indicators, 2010-16; ANNEXES; I. Risk Assessment Matrix; II. Report on the Observance of Standards and Codes (ROSCs)-Summary Assessments of BCP; III. Report on the Observance of Standards and Codes (ROSCs)-Summary Assessments of ICP; IV. Report on the Observance of Standards and Codes (ROSCs)-Summary Assessments of C
14:32	Dyrcona	PFMI; V. Previous FSAP Recommendations; VI. Banking Stress Testing Matrix; VII. Corporate Stress Testing Matrix. 1. The FSCFIGURES; 1. The Macro Context; 2. A Bank Dominated Financial Sector; 3. Banking Sector Profile; 4. Bank Business Model Convergence; 5. Bank Measures of Systemic Risk and Spillover Networks; 6. Banks' FX and Liquidity Risks; 7. Banks' Returns, Asset Quality, and Solvency; 8. Corporate Sector Risks and Vul
14:32	Dyrcona	ies; 9. Summary Results of Solvency Stress Tests of Major Banks; 10. Results of the Liquidity Stress Tests of Major Banks; 11. Funding Liquidity-Solvency Feedback in Solvency Stress Tests; 12. Corporate Sector Stress Test Analysis; TABLES.
14:32	Dyrcona	That's definitely NOT a UPC.
14:32	jeff	ah, yes.
14:32	Dyrcona	That's the first result row. I must have a conflicting definition somewhere.
14:36	Dyrcona	So, we've got 505 and 246 possibly showing up.
14:37	Dyrcona	I used to know this part of Evergreen better than I do now.
14:38	Dyrcona	jeff++ mmorgan++
14:39	Dyrcona	This is on a development/test system. I guess I'll double check production, too. Maybe it was something in this upgrade script....
14:39	jeff	nothing stock references 505, but in mods that's tableOfContents, which is matched by the xpath for the keyword field "toc".
14:40	jeff	also, that specific record is deleted in your live system, which may or may not mean that its being skipped on reingests/etc.
14:40	jeff	s/its/it's/

Results for 2023-01-20

15:05	Dyrcona	pinesol: That's not helpful.
15:05	pinesol	Dyrcona: Sorry, that command is only available to Evergreen Premium™ Subscribers. Please upgrade your subscription ASAP!
15:05	Dyrcona	:)
15:07	Dyrcona	Hrm. This worked when I tested it yesterday. I must be missing an option.
15:11	Dyrcona	Ok. Forgot to use the --directory option because the hierarchy changes from one repo to the other.
15:24	Dyrcona	So, I'm going to test that format-patch \| am trick to manage template customization. It just might work.
15:44	jeffdavis	sorry about the tree and the chainsaw, hope the cars really are ok :(
15:54	Dyrcona	jeffdavis: Thanks! There's no visible damage, not even the moon roof on mine.
16:00	Dyrcona	https://drive.google.com/file/d/118z2rQoAvw45kCiwdDjqykrLDBF6lfKP/view?usp=share_link

Results for 2023-01-13

12:49		jvwoolf joined #evergreen
13:08		mantis1 joined #evergreen
13:27		rfrasur joined #evergreen
13:42	JBoyer	Dyrcona++ # an off-hand comment lead to a test case fix so 3.8.2 can proceed as planned!
13:43	Dyrcona	JBoyer++ # For realizing the issue was in the concerto data load for Pg 10+
14:11	miker	Bmagic: from yesterday, re asset.copy vs serial.unit, if you're gathering data for future loading as part of an expanded data set, you def want to use "SELECT ... FROM ONLY asset.copy ..." because of the inheritance. but, in normal operation, yes, you'll definitely see serial.unit rows "through" the asset.copy table -- that's 100% intended.
14:14	Bmagic	yep, I did come to the same conclusion, and edited my code with "ONLY" - that seems to have fixed the bug

Results for 2023-01-12

12:44	JBoyer	Hah, I suppose you could also set fingerprint = 'fixme!' :D
12:45	Dyrcona	:)
12:46		mantis1 joined #evergreen
12:49	jvwoolf	JBoyer++
12:50	jvwoolf	I got a test database and a batch of records to target, I've got nothing to lose!
12:50	Dyrcona	jvwoolf++
12:51	JBoyer	jvwoolf++
13:07	pinesol	News from commits: Docs: Evergreen web services docs <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=2ca151971be655225c12c34fef3191fcdcd8ac38>

Results for 2023-01-11

11:42		rfrasur_ joined #evergreen
11:53		jvwoolf joined #evergreen
12:04		jihpringle joined #evergreen
12:21	JBoyer	Dyrcona++ # testing
12:47	jeffdavis	csharp_: hope it helps! So far we haven't seen that issue since deploying the fix here, hopefully that means it's working. :)
13:02	csharp_	jeffdavis: so far so good
14:07		kmlussier joined #evergreen

Results for 2023-01-10

10:02		Dyrcona joined #evergreen
12:39		jihpringle joined #evergreen
13:56		dmoore joined #evergreen
14:01	mantis1	HI all. Pushed a working branch to the EG repo but can't find it/can't check the branch out in my test box
14:01	mantis1	command was git push working lp1853630_carousel_shelving_location_desc:user/gmonti/lp1853630_carousel_shelving_location_desc
14:02	mmorgan	mantis1: it
14:02	mmorgan	's in the working repo: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/gmonti/lp1853630_carousel_shelving_location_desc
14:02	mantis1	ah thank you
14:02	mmorgan	did you do a git fetch working?
14:02	mantis1	I did sorry I was looking in the wrong repo
14:02	mantis1	Thank you!
14:03	mantis1	Do we add a sign off tag to the LP ticket?
14:04	mantis1	or is that just after testing?
14:05	Dyrcona	mantis1: If you signoff the branch, all you have to do on the ticket is say that you pushed a signoff branch and where the branch is.
14:05	Dyrcona	It's probably best to wait until after you've tested it. I don't add my signoff if I can't get it to work.
14:05	mmorgan	mantis1: It needs a pullrequest tag, the signoff tag gets added by the tester
14:05	Dyrcona	Oh, yeah. You can add the signoff tag if you tested it.
14:06	Dyrcona	I may have misunderstood the situation.
14:06	Dyrcona	The original author doesn't add the signoff tag for their signoff.
14:06	mantis1	mmorgan++ Dyrcona++
15:08	Dyrcona	jihpringle++ jeffdavis++
15:08	terranm	jihpringle++ jeffdavis++
15:08	Dyrcona	Some of those will slow things down.
15:08	jeffdavis	Testers could also use it during bug squashing weeks, people doing acceptance testing on paid development project, etc.
15:09	sandbergja	3 and 7 also seem difficult. We don't really have comprehensive information about how all our functionality/settings are supposed to work.
15:09	sandbergja	be it 100% test coverage or a super-detailed manual
15:10	JBoyer	I do like the idea of basing an interface comparison checklist on it. You don't necessarily need to know how to use all of an interface if you can tell that you can get to X on dojo but not Angular. (so long as it's not an intentional workflow change)
15:10	sandbergja	so I'd be interested in some conversation about how developers can get all that info before embarking on an angularization
15:13	Dyrcona	I wonder if the Angular version needs to have feature parity with the previous interfaces(s). What if we came up with better ways of doing things?
15:14	mmorgan	re: library settings - it seems like calls to get library settings in existing code shouldn't be too hard to identify.
15:14	JBoyer	That's what I was getting at yeah. If you can get the same outcome with a different UI that's fine, but being able to do something in the old and busted but not the new hotness isn't great.
15:15	tlittle	#info tlittle = Tiffany Little, PINES
15:17	jeffdavis	IMO the state of our tests/docs means that we'll never catch all of these problems. I think the idea with a checklist was to make sure we're consciously thinking about these types of things at some point during the contribution process.
15:17	berick	yeah, what jeffdavis said
15:17	Dyrcona	This is going to be unpopular, but maybe we need stricter standards than "works for me" and X number of signoffs.
15:18	sandbergja	Dyrcona: what did you have in mind?
15:19	berick	so more emphasis is good
15:19	berick	and having a record of usual gotchas helps focus
15:20	abneiman	this is also where non-technical end users can be helpful - in terms of interface & workflow evalution
15:20	Dyrcona	sandbergja: I'm not really looking for more process, but I do think we need better automated tests, etc. I don't have much specific in mind at the moment.
15:20	mmorgan	abneiman++
15:21	Dyrcona	Also, what abneiman said. We need more end users involved.
15:21	tlittle	abneiman++
15:22	mmorgan	It's difficult for end users to get more involved, difficult for them to get their hands on the new development to test on.
15:22	JBoyer	Yeah, testers rarely need to be conversant in the technical bits, and sometimes the tech types don't know so much about how the end users do their thing.
15:23	mmorgan	Bugsquashing week is huge, but test systems are not real world.
15:23	gmcharlt	yeah - I think an additional factor is committer time, and more automation can help around the edges
15:23	tlittle	Numbers 6-7 are concrete things that fall squarely on the dev's shoulders, though, imo
15:24	mmorgan	tlittle++
15:25	JBoyer	But to mmorgan's point, it's difficult to test on realistic data if you don't have the local staff to build and rebuild test systems. :-/
15:25	Dyrcona	Well, hire someone. What we need is more resources. It's that simple.
15:26	terranm	Yeah, we find a lot of issues when we do our intensive pre-upgrade testing with a copy of real data. And then more issues when we go live.
15:27	mmorgan	Dyrcona: Agreed more resources, but imo it doesn't seem that simple to hire someone and bring them up the Evergreen learning curve.
15:29	berick	it may be helpful to consider that this phase of EG dev won't last forever.
15:29	berick	there's only so many non-Angular UI's
15:31	dmoore	oh duh, thanks
15:31	sleary	Even just focusing on the Angular UIs is a steep learning curve. I have had trouble with the lack of inline documentation on what various components do. (This topic is on the next new dev agenda, btw.)
15:31	csharp_	dmoore: feel free to ask if there are other acronyms/jargon you don't understand
15:32	sandbergja	Dyrcona: for me, I think that goes back to better automated tests and docs -- hopefully when/if we migrate away from Angular, we'd have better safeguards against regressions
15:32	mmorgan	All part of the learning curve :)
15:32	csharp_	part of the answer is new devs - both in general and the new devs group
15:32	sandbergja	also, here's hoping Angular stays healthy for quite some time yet. :-)
15:34	csharp_	jihpringle++ jeffdavis++
15:34	abneiman	yes, jihpringle++ jeffdavis++ I have already bookmarked this
15:34	terranm	Same here
15:34	sleary	Very useful! And I would like to do more with automated testing as well.
15:34	mmorgan	Agreed QA gotchas will be useful, there will always be change, we just need to manage it well
15:35	mmorgan	just
15:35	jvwoolf	jihpringle++ jeffdavis++
15:35	JBoyer	So, I do think it should go to the dev lists (perhaps quarterly or so, even) so that we can move on to the second action item from the last meeting. :)
15:35	Dyrcona	This list is a good outline of where we need to pay attention, and tests/standard can be built around it.
15:35	JBoyer	Which is
15:35	JBoyer	#info Bmagic to email the development list about a way to share common Evergreen tools with the community.
15:36	JBoyer	Though I don't think Bmagic is available at the moment and I don't recall seeing this on the lists. We'll kick that can down the road.
15:39	JBoyer	Note though, if anyone else has an interest in the expanded sample data set and opinions on integration and etc. feel free to poke around,
15:40	JBoyer	Ugh, look at me, forgetting to add something to the agenda myself, heh.
15:40	JBoyer	#topic Evergreen Release Updates
15:40	JBoyer	#info I've built a 3.8.2 release to end the 3.8 line now that 3.10 is out, if you can help test it's at https://evergreen-ils.org/downloads/Evergreen-ILS-3.8.2.tar.gz (Note, I'm going to have to make a docs change before it's final-final, but no code changes.)
15:41	gmcharlt	JBoyer++
15:41	shulabear	Jboyer++
15:41	sandbergja	JBoyer++
15:41	mmorgan	JBoyer++
15:41	Dyrcona	JBoyer++
15:41	JBoyer	It is 1. wicked late, and 2. not too difficult to test. IF you have access to a 3.8.1 db especially and can help test it (I know the version upgrade is fine for concerto, but you know how that goes)
15:41	terranm	JBoyer++
15:41	tlittle	JBoyer++
15:42	rfrasur	JBoyer++
15:48	mmorgan	jeffdavis: Yes, mostly without branches. A few have pullrequests
15:49	jvwoolf	mmorgan: I've push patches to all of the ones that were showstoppers for us so far
15:49	terranm	We're going ahead with upgrading because they're not show stoppers for us, but we know there will be some grumblings
15:49	jvwoolf	I'm likely done with my concentrated effort unless something comes up when we widen our testing to end users, or after we upgrade
15:50	mmorgan	Template issues, silent failure issues are big ones for us.
15:51	mmorgan	We're still sorting through and prioritizing
15:51		smorrison joined #evergreen

Results for 2023-01-04

09:05		Dyrcona joined #evergreen
09:22		dguarrac joined #evergreen
09:45		mschell joined #evergreen
10:03	Dyrcona	miker: Using asset.copy_vis_attr_cache is not always faster than doing the 5 joins necessary to get similar information. The former was faster on one database server where I tested, but on another it was slower than the latter by 10 minutes.
10:04	Dyrcona	I also got different numbers of output rows, so it's not a 1:1 comparison. I am using copy_vis_attr_cache and asset.patron_default_visibility_mask() in produciton, now.
10:08		BDorsey joined #evergreen
10:38	Dyrcona	phasefx: Please see https://bugs.launchpad.net/evergreen/+bug/1959010/comments/14 . I don't know how much the functionality depends on ngbnav, so I didn't feel comfortable trying to backport the new branch to 3.10.
16:06	kmlussier	mmorgan: That's the one I was curious about. I knew about the coffee on up above.
16:07	kmlussier	@quote get 131
16:07	pinesol	kmlussier: Quote #131: "<kmlussier> All my meetings are about Evergreen, ergo all my meetings are fun." (added by gmcharlt at 03:40 PM, December 02, 2015)
16:08	kmlussier	I guess that one didn't stand the test of time.
16:09	jvwoolf	:'(
16:11	Dyrcona	:)
16:11	jvwoolf	kmlussier: I'm heading out but wanted to pop in and say hi before I go. So, hi!

Results for 2022-12-30

13:36	Dyrcona	Anyone know the magic sauce that is used by the OPAC to find visible copies to save me from having to pour over code?
13:59	Dyrcona	I feel like this shouldn't have been a surprise, like I should already know what to do about it.
14:07	Dyrcona	Really useful release note: "Public and staff catalog search is now both more accurate and faster by redesigning how the visibility of records is calculated."
14:25	Dyrcona	So, it's too complicated to do visibility testing in the database, now?
14:29	Dyrcona	Oh. I missed opac_visible on asset.copy.
14:29	* Dyrcona	tries that.
14:31	Dyrcona	I don't think that's as useful as it looks.
16:17	Dyrcona	Maybe I'll play asset.copy_vis_attr_cache for the next few minutes.
16:20	* Dyrcona	wonders if there's any documentation on vis_attr_vector. That was the bit I couldn't figure out from the code. It looks like entry 0 is opac_visible, but I don't know what the rest means.
16:23	Dyrcona	Meh. Too late in the day/week/month/year to worry about that. I'll look at it next week.
16:24	miker	there's some code comment documentation in the helper functions that build the int array, and that create the queryint value for testing against it, but, as you say, it's 30min from the end of the working year
16:39	Dyrcona	I'll see if I can find that next week.
16:40	Dyrcona	Happy New Year's everybody!

Results for 2022-12-29

15:29	JBoyer	Dyrcona++
15:35		kworstell-isl joined #evergreen
16:04		JBoyer joined #evergreen
16:05	JBoyer	testing
16:05	berick	ack: testing
16:05	JBoyer	But not from my bouncer. :(
16:06	JBoyer	A mystery for another year I suppose
16:10	JBoyer	Speaking of, whoever is around today (Dycona++, berick++, jeff++) have a happy new year.

Results for 2022-12-23

10:26	jvwoolf	Ooh
10:26	jvwoolf	Just came across this in Launchpad search: https://bugs.launchpad.net/evergreen/+bug/1998355
10:26	pinesol	Launchpad bug 1998355 in Evergreen "Did You Mean's search.symspell_dictionary can get significantly bloated" [Medium,New]
10:28	jvwoolf	Also wondering about testing this with queued ingest, since we have some time
10:34	Dyrcona	I was testing queued ingest, but other things came up before I could finish.
10:35	Dyrcona	jvwoolf: That branch you linked needs a db upgrade script.
11:25		mantis1 joined #evergreen
12:04		mmorgan left #evergreen

Results for 2022-12-22

10:10	Dyrcona	This JabberClient instance is no longer connected to the server
10:13	Dyrcona	ejabberd.log is, of course, useless.
10:26	miker	Dyrcona: I have ideas for making facets always faster (or at least never slower) since they can be turned into unique int IDs, but tuits...
10:29	Dyrcona	miker: Sounds cool. I also think that should be a separate bug from the ones I'm testing. It's just something that I've noticed.
10:30	Dyrcona	It's not always slower, just sometimes.
10:30	* Dyrcona	goes fishing through logs for a really crazy search to test.
10:45	Dyrcona	So, that jabber thing that I reported earlier: Has anyone ever seen services crash and have 8 listeners all using 100% cpu? This appears to have happened right after I restarted services this morning.
10:47	Dyrcona	I suspect something in the configuration must be busted.
10:57	Dyrcona	Huh. Just restarting ejabberd seems to have fixed it for now.
12:41	jvwoolf	(We don't have symspell in our current version, still on 3.6.5)
12:49	pinesol	News from commits: Docs: updating Global Flags docs <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=8326611f8dc232dda993dca412e429713189999a>
13:49	csharp_	jvwoolf: it's definitely quicker without all the triggers if you can spare the downtime
13:54	jvwoolf	csharp_++
13:55	jvwoolf	We have some time so I might test still test with triggers and without
13:56	jvwoolf	My guess is that the libraries may prefer to be offline than to have their Sunday staff let loose on a new version that might be slow because of the reingest, but I'll ask that question to our user group
14:05	Dyrcona	I think there are some patches in working branches that can make the ingest more palatable, but it looks like I have it on my other laptop, unless the one I was looking at went in.
14:07	jvwoolf	Dyrcona: The fix for bug 1931737 is in 3.9.1
14:07	pinesol	Launchpad bug 1931737 in Evergreen 3.8 "Did you mean breaks parallel reingest and causes deadlocks when loading/overlaying bib records in the client" [High,Fix committed] https://launchpad.net/bugs/1931737

Results for 2022-12-21

11:27	berick	BTW, not sure if the backend will cache anything for a search that times out
11:28	Dyrcona	Well, it seems to work in the OPAC most of the time.
11:29	Dyrcona	I'll have to compare the two in more depth later.
11:29	* Dyrcona	is testing some search fixes on production data.
11:31	Dyrcona	It might be this particular search is way too broad given our data, but this has been consistent with other searches, IIRC.
11:32	Dyrcona	This search isn't returning results in the OPAC, either, and it gives up almost immediately.
11:33	Dyrcona	The query doesn't run nearly as long in the database now, either.
11:56		jvwoolf joined #evergreen
12:06	miker	not here, but staff search never uses the cache. else newly added records wouldn't show up
12:16	miker	in the olden days, the #staff modifier would force skipping the cache. I think that still works? but docache probably overrides that heuristic
12:20	Dyrcona	Well, I've done some more fiddling around with that bug and comparing produciton with my test system with search patches. I get results in production regardless of filters, etc. On the test system, I either have to change to a title search or limit by library to get results.
12:20	Dyrcona	I suppose it is just my test database being slower than production.
12:26		dguarrac joined #evergreen
12:34		collum joined #evergreen
12:47		collum joined #evergreen

Results for 2022-12-20

15:09	Dyrcona	That answers my second question with "No."
15:10	Dyrcona	I should up the concurrency count, I guess.
15:13	miker	I think ab is trying to be too nice, sometimes
15:16	Dyrcona	Yeah. I was thinking of saying something about -c. My test machine has 20 CPUs assigned to it, so -c 20 shouldn't be an issue.
15:17	Dyrcona	I get 429s in clumps of 3 to 5, then a long string of 200, then an occasional 429. so looks like it works.
15:26	Dyrcona	Seems to work better with different search terms I guess pulling the results from cache speeds things up too much. :)
15:34	miker	heh, indeed

Results for 2022-12-12

09:10		Dyrcona joined #evergreen
09:11		dguarrac joined #evergreen
09:56		berick joined #evergreen
10:11	Dyrcona	miker: Regarding Lp 1999274, I'm going to search the code for CTEs that are used more than once in the parent query and test them for performance on Pg 13. If I find any that need fixing, I'll try using the offset trick on them. (I may switch to testing on Pg 15.)
10:11	pinesol	Launchpad bug 1999274 in Evergreen 3.10 "Performance of Search on PostgreSQL Versions 12+" [Medium,Confirmed] https://launchpad.net/bugs/1999274
10:11	Dyrcona	If I find (m)any more, I may change the bug summary for accuracy's sake.
10:27		jmurray-isl joined #evergreen

Results for 2022-12-09

10:38	Dyrcona	Not bad though, 3.7 seconds for a seq scan on 3.7 million records.
10:39	Bmagic	better than a human
10:43	Dyrcona	Adding an index on bre.vis_attr_vector doesn't make a difference in the explain output for the simple query.
10:44	Dyrcona	Also, there's an error in the SQL I pasted before. I'm actually running this to test: select id from biblio.record_entry where vis_attr_vector IS NULL OR NOT int4range(0,268435455,'[]') @> ANY(vis_attr_vector);
10:44	Dyrcona	I'm going to add an index on acvac.vis_attr_vector and try the big query again.
10:47	Dyrcona	That doesn't seem to make a difference either, so I'll try the procedural index that miker suggested yesterday next.
10:54	Dyrcona	"create index bre_not_deleted_idx ON biblio.record_entry (id) where deleted = 'f';" doesn't seem to help, either.
11:14	miker	select * from config.internal_flag where name like '%delete%'; if you're in psql
11:16	Dyrcona	I'm pretty sure that's on, but I'll double check.
11:17	Dyrcona	Nope. enabled = 'f'.
11:17	miker	kk
11:20	miker	Dyrcona: a big change in pg 12 is the default for non-materialized CTEs. we can't just do it across the board yet, but do you have the full original query handy to test by hand? if so, in front of each CTE (WITH-clause), after the AS keyword, what happens if you add MATERIALIZED between AS and the open-( ?
11:21	Dyrcona	I'll give that a shot. I have it open in my editor.
11:23	miker	if that makes things happy -- and I can imagine it will because estimates of the number rows coming out of a tsearch CTE are ... usually way off -- then we /can/ add a PG version check and add it when it's available. there's precedent for that in the record attribute testing infrastructure.
11:27	Dyrcona	It's worse, but I may have missed a couple: Execution Time: 115367.485 ms
11:31	Dyrcona	OK! I missed c_attr and b_attr before. after adding materialized to those two, it was much better: Execution Time: 3123.997 ms
11:32	Dyrcona	My guess is c_attr as materialized does the magic.
11:34	Dyrcona	"That's a bingo!"
11:37	miker	limit and offset are usually optimization fences ... Dyrcona, would you mind trying this? remove the MATERIALIZED on c_attr and add "OFFSET 0" just before the closing ) on that CTE
11:38	Dyrcona	OK. I was about to say that we'd have to bump the minimum Pg version to 12 if we use materialized CTEs.
11:38	miker	if that has the same effect, we should be able to (for now, until PG learns how to ignore useless limit/offset) do that.
11:39	miker	as for versioning, we already test for the version in one other place and change query structure based on that. we could do it here if MATERIALIZED is the answer
11:40	miker	we could also mark the function volatile to force materialization
11:40	Dyrcona	Execution Time: 2675.806 ms
11:40	miker	oh hey, look at that
11:40	Dyrcona	So, the offset works, too.
11:44	Dyrcona	Should I try that, too, or are we happy with "offset 0"?
11:44	miker	it is, but only in OPAC searches. staff search does use search.calculate_visibility_attribute_test thought
11:45	miker	though, even
11:45	Dyrcona	FYI, I'm testing on Pg 13, but it probably doesn't matter.
11:47	miker	offset 0 is the more self-documenting variant that works for all pg version, for now. though, again, we can version-test and use materialized in 12+
11:49	miker	testing offset 0 on an older version, just to be sure
11:49	Dyrcona	I was talking about marking search.calculate_visibility_attribute_test as volatile.
11:50	miker	right
11:50	Dyrcona	I'm going to try it just because I can.
11:50	miker	+1, try away!
11:52	Dyrcona	Volatile without offset 0 works, too, but I'll defer to your opinion on offset 0.
11:53	Dyrcona	Execution time is about the same, 4ms difference which is probably not related to the change.
12:17	miker	I got curious and checked the difference between ts_rank and ts_rank_cd ... it's bigger than I thought :(
12:18	miker	in my test query, 3ms vs 90ms, respectively
12:22		jihpringle joined #evergreen
12:28	miker	Dyrcona: do you want to branchify that, or shall I?
12:28	Dyrcona	miker: ts_rank makes a roughly 67ms difference in execution time.
12:28	Dyrcona	in my test environment.
12:29	Dyrcona	If you want to branch it, that's fine with me. I was going to open a Lp bug, but I should actually look into yet another OOM on the db server.
12:29	Dyrcona	It happened just before noon.
12:29	miker	oh, well, that's not enough to warrant further investigation this moment. my test case may be unusual
12:29	miker	I'll put together the patch and await your LP, then?
12:30	Dyrcona	OK with me.
12:36	Dyrcona	Is it possible to POST an OPAC search?
12:42	miker	it is
12:43	miker	(and, note, i was incorrect about staff search not using the patron vis test function -- it does, it just ignores that the the WHERE clause)
12:43	miker	Dyrcona: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/optimization-fence-for-pg-12-CTEs-in-search for your eyeballs
12:45	Dyrcona	miker++
12:46	Dyrcona	Re POST: I guess we'll need to work out a mitigation for POSTS with "bad" queries in them.
13:33		kworstell-isl joined #evergreen
15:21	jihpringle	Bmagic: depends on the version, there's an admin interface starting in 3.8 or 3.9 I think (we definitely have it in 3.9)
15:21	Bmagic	jihpringle++
15:22	mmorgan	It's new in 3.9
15:22	Stompro	I testing on 3.9, so I get to try that out.
15:25	jeffdavis	In addition to the new staff portal config options, we add an iframe to the page so we can display news updates from another source: http://git.sitka.bclibraries.ca/gitweb/?p=sitka/evergreen.git;a=commitdiff;h=45bfec6b5b1a7a8d0dfd898aa68926d17bb8f1ca
15:25	jeffdavis	I should probably turn that into a feature request.
15:28	Stompro	jeffdavis, thanks, that is interesting.
15:31		kworstell-isl joined #evergreen
15:34	Stompro	Shoot, "it won’t try to merge branch, system, and consortial-level entries" I cannot have System portal with the odd entry for a specific branch. But I get that would be more complex to figure out.
15:53	jihpringle	ya, if you want different portals for different org units with slight differences you have to re-create the portal for each org unit you want (but there is a clone button)
15:58	miker	Dyrcona: I'll clean up the commit message and push another branch. if you're in a position to test the patch in both opac and staff search, it'd be a much appreciated cross check.
16:00	Dyrcona	miker: Sure thing!
16:59		mmorgan left #evergreen
17:00	Stompro	Who do I contact to add something to the tabular release notes?

Results for 2022-12-08

10:06	jeff	There are a number of settings that you can tweak to make pg_restore complete faster. Most are "running with scissors" things like setting WAL to minimal, increasing checkpoint_segments, setting fsync=off (DANGER, Will Robinson!), etc. I've also seen recommendations to decrease shared_buffers so that you can increase work_mem to help with index building.
10:07	jeff	Oh, also: turning off autovacuum is usually a good idea. You're probably planning to vacuum when the restore is complete anyway.
10:07	Dyrcona	jeff: Thanks. I'll just leave things as they are.
10:08	Dyrcona	I've got a file with settings that I think are optimized for this server. I move it from conf.d to conf.d for whatever version I'm testing. I restart those specific Pg instances, and then start the restore.
10:09	jeff	I don't if there's an authoritative, up to date list of these recommendations. Not seeing it in a quick few searches.
10:09	Dyrcona	I suppose I could do some "fancy" things to speed up the restore, but whatever. I was mainly thinking about restoring into a database with default settings versus one with better settings for the hardware.
10:10	jeff	Oh, and of course -j, but you probably already had that in mind and weren't considering it as a "setting". :-)

Results for 2022-12-07

10:09	Dyrcona	csharp_: I'm not seeing the same slowness in the Bootstrap OPAC.
10:13	Dyrcona	OK. log_statement = 'all' is way too much...
10:14		kworstell-isl joined #evergreen
10:31	Dyrcona	csharp_: I ran your query on my test db server with production data on Pg 14, and I get a different explain output: https://pastebin.com/8k1cwNZM
10:32	Dyrcona	Granted, it still took almost 2 minutes to run the query.
10:49	Dyrcona	The copy_vis_attr_cache is still the worst part of the query, even if my server used an index scan: https://explain.depesz.com/s/EBTe
11:12		sleary joined #evergreen
16:07	mmorgan	primordial error :)
16:08	mmorgan	Confirmed that the lower case ones allow maintaining the closed dates.
16:27	Dyrcona	Yeah, the backend Perl code checks for the lower case permissions. open-il.pcrud will use the upper case perms.
16:39	csharp_	Dyrcona: thanks for your additional testing - just got back from four-hour commutes yesterday/today, so it will be tomorrow before I have the wherewhital to look :-)
16:43	Dyrcona	csharp_: No worries. I'm waiting on the data to restore to Pg 11.
16:43	Dyrcona	In the meantime, I've been working on bringing our customizations up to rel_3_10.
17:19		mmorgan left #evergreen

Results for 2022-12-06

10:20	Dyrcona	Yeah, we set it to 9 a few years for some large query. Don't remember if it was search or what.
10:21	Dyrcona	Every increase doubles the number of joins that can be collapsed or whatever that setting does.
10:22	Dyrcona	I might remove it from my Pg 14 config to see what happens at 8.
10:23	Dyrcona	I haven't started performance testing, yet. I'm still mucking about with getting a database upgraded and dumped so I can load it on Pg 14.
11:42	jvwoolf	We saw some high open-ils.storage drones on our OPAC servers and high load on our database this morning. I'm looking at the logs but not finding a cause that I can directly point to. Any ideas on what to look for?
11:53	jeffdavis	csharp_: fyi we have the fix for bug 1990306 in production now - too soon to say whether it resolves the problem but at least it doesn't seem to break anything
11:53	pinesol	Launchpad bug 1990306 in Evergreen "Flood of open-ils.actor.user.has_work_perm_at.batch requests for VIEW_USER with null authtoken" [Undecided,New] https://launchpad.net/bugs/1990306

Results for 2022-12-05

10:17	Dyrcona	https://github.com/EquinoxOpenLibraryInitiative/migration-tools
10:17	Bmagic	ty
10:18	Dyrcona	It turns out that I haven't cloned it on this laptop, yet.
10:22	csharp_	oof - opac queries on EG 3.10/PG 14 are taking 7 minutes
10:22	csharp_	done all the vacuuming, etc. - doing an explain analyze now
10:22	csharp_	(on a test server, not PINES production)
10:23	Bmagic	hmmm, that's no good
10:23	Dyrcona	csharp_: Not good, but not bad that you've caught it before going to production.
10:23	rhamby	Dyrcona got there before I did :)

Results for 2022-12-02

08:40	jeff	Stompro: sounds likely. I'd reach out to their support, let them know what you're seeing.
08:41	jeff	(you may have done that already)
08:43	Stompro	jeff, I did send my logs and packet dumps to my Content Cafe contact and they said they think they found the problem last night around 6:30pm cst.
08:46	Stompro	I also think I figured out how to enforce a timeout in AddedContent.pm that keeps things from slowing down so much. Need to keep testing that though.
08:59		dguarrac joined #evergreen
09:33		mantis1 joined #evergreen
09:53		Dyrcona joined #evergreen
12:20		mantis1 joined #evergreen
12:22	RMiller	ejabberd status shows an error: "Failed to request certificate for biblio01, proxy.private.localhost and 11 more hosts..." Relevant?
12:23	Dyrcona	RMiller: Maybe. Did yous stop services during the upgrade or did you leave them running?
12:25	RMiller	I'm guessing that after I updated the ejabberd configuration and tested it, I probably left it running for the rest of the process
12:25	RMiller	I stopped OpenSRF and apache2, I'm sure
12:26	RMiller	ejabberd gave me an almighty hassle about the mnesia database not belonging to localhost
12:28	RMiller	(The message about not finding libdbi that the settings-tester.pl scripts creates doesn't apply anymore, right?)

Results for 2022-12-01

09:59	Stompro	csharp_, thanks, I found them.
09:59	csharp_	Stompro: happy to help!
10:01	Dyrcona	Maybe B&T are being DOS'd? They've been having issues lately...
10:01	jeffdavis	looks like you can set a longer timeout interval for Content Cafe in opensrf.xml if that would help with testing
10:02	jeffdavis	not sure setting it to 1.2 minutes is a great idea though
10:06	Dyrcona	We're using Bootstrap 4 with Angular?
10:11	Stompro	jeffdavis, I'm fine with the request timing out quickly... but it just seems strange that the request to opac/extras/ac/jacket/small/r/ doesn't return 404 faster.
10:12	Stompro	And it doesn't seem like it registers with the error counter, that is supposed to disable the added content provider after x number of failures.
11:17	csharp_	oh postgresql 14, why oh why do you care about where VERBOSE belongs in a VACUUM statement
11:17	csharp_	VACUUM VERBOSE ANALYZE vs VACUUM ANALYZE VERBOSE
11:35	Dyrcona	There's probably a release note on that, but I never noticed.
11:36	Dyrcona	csharp_: Are you using Pg 14 in produciton, or moving data for testing?
11:57	Dyrcona	If I want a purchase order to try again after a FTP error, I just update the status to retry, right? I can't remember if there are other fields to change.
11:58	Dyrcona	The status of acq.edi_message I mean.
12:01	Dyrcona	Oh well, guess it's time to call it a day.
13:48	terranm	It works! Hallelujah!
14:19		jihpringle joined #evergreen
14:21	csharp_	berick++
15:06	Stompro	More content cafe testings... when load a catalog results page with 10 items, I'm seeing 7 successful requests, and 3 requests that eventually time out. The Timeout setting has no effect, because that only works when the agent is waiting for a response. tcpdump shows that the only communication is the initial packet to setup the connection, and then retries being sent.
15:08	Stompro	Makes me think that B&T is limiting connections per second in a very unfriendly way.
15:15		mantis1 joined #evergreen
17:05		jvwoolf left #evergreen

Results for 2022-11-30

14:46	Dyrcona	Well, that sounds reasonable.
15:09	mmorgan	We've made a lot of our opac customizations into org unit settings so we don't need to maintain the tt2 files, just update settings in the db.
15:13	csharp_	yes, squashing is appealing because it feels cleaner, but then you need to revert one of the squashed commits later and you're like "oh yeah, that's why we don't do it like that"
15:13	Dyrcona	Speaking of settings and what not. I'm trying to test something in eg2, and while I can just go there by putting eg2 in the URL, I thought there was a setting somewhere that would do it automagically from the staff opac.
15:13	Dyrcona	csharp_: Exactly that.
15:21	Dyrcona	Hmm... Looks like I'll have to edit nav.component.html
15:26	Dyrcona	So, I'm readying this right that current master still goes to AngularJS for circulation functions from eg2?
16:00	mmorgan	Stompro: Yes, I'm seeing issues in the opac and Novelist today. The service was unavailable back on 11/21, but it restored the next day.
16:02	Stompro	I keep turning it back on, and then having the requests start to fail an hour to a few minutes later.
16:06	Dyrcona	I suspect B&T have issues again.
16:06	Dyrcona	At any rate, I successfully modified nav.component.html to go to eg2 for checkin, checkout, and renewal.....so I can test the changes that I want to make.
16:08	* Dyrcona	should stash that commit in a special branch for later reuse.
16:22	Dyrcona	If I use ng build --watch do I have to specify the output directory? If so, is it /openils/var/web/eg2 or /openils/var/web/eg2/en-US ?
16:23	berick	Dyrcona: ng build puts files into $Evergreen/Open-ILS/web/eg2/