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

Results for 2022-12-29

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:35	jeffdavis	At Sitka each library has its own OPAC skin. We have some template customizations in git that apply across all skins. We also have some library-specific settings (logo, colors, banner messages, etc.) that we manage with a separate templating system rather than tracking them in our main git repo.
14:36	jeffdavis	So, rather than maintaining 80 different config.tt2 files for 80 different libraries, we have a system that generates and deploys a different config.tt2 for each library based on some settings in a yaml file.
14:37	Dyrcona	Yeah, I'd probably do the same. We don't allow individual customization beyond changing the logo.
14:38	Dyrcona	We did toy with a separate academic skin several years ago, but it never got past testing.
14:39	jihpringle	the majority of our non-logo/colour customizations are for our academic sites
14:40	jihpringle	we recently added it to our docs to make it easier for our libraries to know what can and can't be customized - http://docs.libraries.coop/sitka/_public_catalogue_customizations.html
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/

Results for 2022-11-28

10:21		dguarrac joined #evergreen
11:42	Dyrcona	Libraries need to clear their hold shelves.
11:43	mmorgan	:)
11:48	Dyrcona	I'm not having any luck with the patches for Lp 1971745. I guess my local test system's database is just too slow. Neither patch seems to make a difference for me on an "optimized" database or a default configured database with production data.
11:48	pinesol	Launchpad bug 1971745 in Evergreen 3.9 "Holds shelf list can fail to retrieve results" [Undecided,Confirmed] https://launchpad.net/bugs/1971745
12:02		jihpringle joined #evergreen
12:02		Christineb joined #evergreen
12:33	Dyrcona	The patches are working for me on another development system running 3.7.3....
12:38	Dyrcona	I wonder if the problem is the other db server, or if something went wrong with the upgrade from 3.7.3 to master?
12:38	* Dyrcona	will test on a 3.7.3 vm with the other db server.
12:49	Dyrcona	Hmm... That system with the "bad" db server won't load a hold shelf with about 9 copies.
12:49	Dyrcona	OK. It loaded on the second try.
13:01	Dyrcona	With or without the patches this other test system can't grab a hold shelf with 100 items.
13:01	Dyrcona	@blame the db server
13:01	pinesol	Dyrcona: the db server is the SPY!
13:28	Dyrcona	This is the server that took 5 minutes to connect cstore, prcrud, and storage last week, so....
15:25	Stompro	Dyrcona, "there's a reason we setup the offline directory twice in our Apache configuration? It's done in eg.conf and again in eg_vhost.conf" I noticed this also, it seemed to be needed when I tried to add a new cgi script, I don't understand why though.
15:25	Stompro	Dyrcona++ thanks for looking at the hold shelf display bug.
15:29	Dyrcona	Stompro: That's interesting about the configuration and the cgi script. I might investigate that.
15:30	Dyrcona	I really wanted to test the hold shelf fixes on Pg 15, but that was on the server that has issues....
15:38		jvwoolf left #evergreen
15:41	Dyrcona	Hrm... What version of PostgreSQL should I recommend in the branch that removes Pg 10? I'm inclined to go with Pg 14.
15:41	Dyrcona	Maybe I'll put this branch off until we can have some developer discussion around it.
15:45	Stompro	I don't have any input on that, but I'm looking forward to having a recommendation to follow :-)
15:49	Dyrcona	Well, I'm not sure anyone else will have much to say about that at the next dev. meeting. I'm still inclined to recommend Pg 14, since I've been testing new development on Concerto with that. My latest 2 vms for concerto will use Pg 15 because I used them to develop/test the Pg 15 branch.
15:50	berick	i'm looking at 14 as our next upgrade target fwiw
15:50	berick	and have been using it for dev, etc.
15:50	Dyrcona	I also wonder if we should come up with recommendations for upgrading Pg versions. There are often extra steps required with Evergreen.

Results for 2022-11-23

12:34	Dyrcona	:)
13:00	csharp_	@dessert [someone]
13:00	* pinesol	grabs some Key Lime Pie for dluch
13:15	Dyrcona	So, for anyone who cares, I'm setting up two local test VMs with PostgreSQL 15. I'll run the tests later today to see what (if anything) breaks.
13:23	Dyrcona	Has anyone ever left a server/vm set to UTC, and if so, did you encounter any noticeable issues?
13:49		kmlussier joined #evergreen
13:51	jeff	I recall having issues with that recently on 3.7. I think it was the database server being left at UTC, and I don't recall of the top of my head how far I looked into if that was an issue with lib.timezone not being set somewhere, etc.
14:08	Dyrcona	jeffdavis++
14:09	Dyrcona	I know we fixed a bunch of issues in the past. I might set one of these vms back to UTC to try it out.
14:14	Dyrcona	I've not really noticed before, but I wonder if there's a reason we setup the offline directory twice in our Apache configuration? It's done in eg.conf and again in eg_vhost.conf. I wonder if we do that for other directories?
14:33	Dyrcona	So, first complete installations of Evergreen with Pg 15 completed. OPAC and staff client seem to work. Now to run the tests.
14:38	Dyrcona	pgtap tests all pass.
14:49	Dyrcona	Perl tests also pass.
14:58	Dyrcona	Every now and then, I think the action.hold_request.phone_notify field should be changed to a Boolean, particularly when we get tickets asking why the patron's "real" phone number doesn't print on the hold slip.
16:06	Dyrcona	Oof...
16:07	Dyrcona	Just missed .....

Results for 2022-11-22

12:53	mmorgan	jeff++
12:53	Dyrcona	So, installing plprofiler for different Pg versions was relatively easy. I should document it for future me...
12:53	Dyrcona	jeff++
13:01	Stompro	mmorgan++, jihpringle++ thanks, just tested again and seems to be back for us also. I'm going to wait a few hours before I re-enable though.
13:01	mmorgan	Stompro: Probably a good idea :)
13:01	mmorgan	Stompro++
13:42	jmurray-isl	jeff++ Verified on my dev server.

Results for 2022-11-15

15:05	JBoyer	#info sandbegja and others are looking into AngularJS node module security updates
15:05	JBoyer	#link https://bugs.launchpad.net/evergreen/+bug/1992529
15:05	pinesol	Launchpad bug 1992529 in Evergreen "Upgrade insecure npm dependencies for angularjs staff client" [Medium,New]
15:06	JBoyer	It looks like things are going alright, terranm was able to successfully do some testing but no one involved seems to be here to expand on it.
15:06	JBoyer	There is a branch available that anyone comfortable poking at Angular should take a look at, if it made it in before 3.10 that would be great.
15:07	JBoyer	#topic Evergreen Release Updates
15:07	JBoyer	Any updates from the 3.10 relteam?
15:21	gmcharlt	or "go through all of the TODO and FIXME comments in the code"
15:21	berick	agreed a list of common issues could be helpful
15:21	gmcharlt	or "go through the release notes for the past few years and note any deprecation announcements"
15:24	jeffdavis	Given our code, is it possible to automate something like testing that a shelving location selector can be scoped by org unit?
15:26	gmcharlt	generally speaking, yes - more unit tests for the Angular components is certainly possible
15:26	JBoyer	sandbergja demo'd some "e2e" testing during the hackaway that could potentially do things like that; they're Angular tests that drive the browser and verify its results.
15:26	gmcharlt	but that's a very concrete way of answering the question
15:26	gmcharlt	jeffdavis: is the question more about how to enumerate and document standing expectations for behavior?
15:27	jeff	If we start with a list that is suitable for use as a checklist, then we could use the start with using the checklist and potentially craft some automated lint-like checks of common issues like unscoped selectors.
15:29	gmcharlt	commit message templates embedding a (brief) checklist might also be a way - https://thoughtbot.com/blog/better-commit-messages-with-a-gitmessage-template
15:30	jeffdavis	sorry, I keep typing and deleting responses :)
15:30		shulabear joined #evergreen
15:30	jeffdavis	a checklist is one example of a way to improve the QA part of our test/commit process, I think we're interested in any kind of solution that improves QA to avoid these kind of recurring problems
15:31	jeffdavis	(it is a very broad problem set for sure, and I agree that formulating a more specific list would be a great next step)
15:32	jeffdavis	I can do some more work with our local support folks to gather more specific examples and flesh out a list for next meeting.
15:33	JBoyer	jeffdavis++
15:33	JBoyer	Care to #action that for the notes?
15:33	shulabear	jeffdavis++
16:00	JBoyer	#link https://bugs.launchpad.net/evergreen/+bug/1948693
16:00	pinesol	Launchpad bug 1948693 in Evergreen "Migrate from NgbTabset to NgbNav (from ng-bootstrap)" [Medium,Confirmed] - Assigned to Stephanie Leary (stephanieleary)
16:01	JBoyer	berick, sorry for the lateness, but if there's anything you'd like to add it's all yours
16:01	berick	thanks
16:01	berick	a couple quick things
16:01	berick	I'm planning to start down the path of updating to Angular 14, Bootstrap 5, etc.
16:02	berick	first part is review/test/merge of bug 1948693, which now has a patch
16:02	pinesol	Launchpad bug 1948693 in Evergreen "Migrate from NgbTabset to NgbNav (from ng-bootstrap)" [Medium,Confirmed] https://launchpad.net/bugs/1948693 - Assigned to Stephanie Leary (stephanieleary)
16:02	berick	it touches lot of UI's, so my question is if I post it on a public VM somewhere can someone help me bounce through and test the UIs?
16:02	berick	basically making sure they load OK and tabs work OK
16:03	berick	i'll post a link to the LP when it's testable
16:03	berick	i don't need a committment, just putting that out there.
16:03	sleary	I would appreciate a lot of eyes on this one. Obviously I ran through them before committing, but there are a few areas where I didn't have adequate test data
16:03	JBoyer	I'm sure pinging the dev lists would help get some people to poke at it too.
16:04	berick	more generally, the Angular etc update is going to affect probably every angular dependency.
16:04	berick	it's not something we'll want to let linger once it's ready
16:12	JBoyer	Also, scottangel feel free to ask any questions you might have now, it's basically a free-for-all when meetings aren't going on. :)
16:12	scottangel	Well then... One question I have is... can I help with the Bootstrap 5 conversion? I love me some bootstraps.
16:13	* jeff	pokes at Google Calendar a bit more...
16:13	berick	miker: if your patch involves updating nodejs or adding new deps, then I'd say yes to committing it
16:14	berick	scottangel++ # we will need lots of manual testing
16:14	miker	well, it /shouldn't/ require that. just a consequence of installing a new version of the node.js binaries
16:14	miker	and rebuilding node_modules
16:14	scottangel	I can help with that as well.

Results for 2022-11-10

12:03		rfrasur joined #evergreen
12:06	csharp_	jeffdavis: did you ever see any luck with your fix to https://bugs.launchpad.net/evergreen/+bug/1990306?
12:06	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]
12:09	jeffdavis	csharp_: I still need to properly test that branch, we don't have it in prod yet
12:13	csharp_	ok - understood - thanks!
12:14		jihpringle joined #evergreen
12:45		collum joined #evergreen

Results for 2022-11-03

16:11	terranm	Ok
16:27		sleary joined #evergreen
16:29		javier_guel joined #evergreen
16:31	javier_guel	Hi all, I am testing to migrate from 3.4.2 to 3.9.0 EG, the server and the service is up with the 3.9.0v, but I am testing on the web opac and it shows "Sorry, no entries were found for your search.", I have to run any other extra step to show records?
16:38	jihpringle	javier_guel: I can't help with your question, but we upgraded to 3.9.0 a few months ago and if you haven't already I definitely recommend looking at some of the fixes in 3.9.1 - especially the ones around the holdings editor (I think we backported most of those ones for our upgrade)
16:39	csharp_	javier_guel: may need to reingest your bibs to get all the search stuff updated
16:40	csharp_	probably instructions in the DB upgrade script outputs
22:21	pinesol	News from commits: LP1993859 Keyboard tabbing for results pagination <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=2e3eeec000f0df137523dc55097b423e8f4baf6a>
22:21	pinesol	News from commits: LP1994159 Higher contrast H2s <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=0833b874b7550929fee3da534ecca62a66edc8a7>
22:52	pinesol	News from commits: LP1995032 Add empty alt text to decorative icons <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=ef0d69f04e14e231d9d854cdb2076f118f417d62>
22:52	pinesol	News from commits: LP1824709: Allow comboboxes inputs to have IDs <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=965eed0754eee7ef213d635e8217b9f981d1e3a9>
23:22	pinesol	News from commits: LP1972928: Show course user role dropdown choices without typing <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=0a09e13670f11ddfae6e2b7e2e7fcbf01345c4f5>
23:22	pinesol	News from commits: lp1856097 stamp and small fixes to upgrade script <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=2e1ae9e2e72373af1b917709b12731461ce965eb>
23:22	pinesol	News from commits: lp1856097 Tide Default Classification Scheme Description <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=9aa6ea3e9bcaaf20ddf9520179601a0381afc11f>
23:52	pinesol	News from commits: LP1895675 Bootstrap OPAC: Add notification method testing to My Account <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=da4979dd5a786dbdf6b9ee8729a72fd21b6a506d>

Results for 2022-11-02

14:50	Dyrcona	:)
14:51	Dyrcona	Sometimes you ubunut, sometimes you ubudon't. :)
14:51		jihpringle joined #evergreen
15:02	* Dyrcona	start fiddling with Pg 15 on a test server, but may not get serious about it until next week.
15:22		collum joined #evergreen
15:24		sleary joined #evergreen
15:43		collum joined #evergreen

Results for 2022-10-28

09:17	Dyrcona	miker: I got "something new" while loading a file of 100,000 records overnight. This time an error about failing to enqueue a record during the load process. Haven't seen that before. I'll paste the scroll back in a few minutes.
09:33	miker	Dyrcona: right on, thanks
09:33		sandbergja joined #evergreen
09:35	sandbergja	Good morning! I'm getting test failures when trying to run the angularjs unit tests, in the steps to mock the orgs for the egOrg tests. Anybody else running into that?
09:37	Dyrcona	miker: https://pastebin.com/4BNh3wG1 # tmux++
09:37	Dyrcona	I'm going to run another batch of 100,000.
09:46	miker	Dyrcona: what are the chances that there are actual dupes (by id) in the file? not knowing what loadrecords (parallel? trigger shenanigans? Dark Magic?), hard to troubleshoot how that might happen. if there were truly conflicting queue entries then the fact that one or the other didn't make it into the queue is immaterial, but even in that case, we can quiet the noise. I would definitely be concerned if, at the end of enqueuing, the ids listed in

Results for 2022-10-27

09:18		stephengwills joined #evergreen
09:18	Dyrcona	miker: Since it would take a day pretty much to restore and "re-upgrade" the database, I'll stick with what I've got checked out. I'll see about pulling the top commits from your other branch.
09:57	Dyrcona	miker: Everything is failing with the changes to metabib.reingest_metabib_field_entries. I'm going to back it out.
09:59	miker	awesome. if you have more info than that, that'd be great. I'm not seeing everything fail...
09:59	miker	thanks for testing, regardless
10:02	miker	Dyrcona: that function has changes that depend on the deadlock branch, fwiw
10:03	Dyrcona	Yeah, I have those. I did the DYM deadlock upgrade, too.
10:03	Dyrcona	miker: Here's a PostgreSQL log entry, https://pastebin.com/SsECj4QB
10:13	Dyrcona	I stopped the coordinator, replaced the function, and it seems to be working again.
11:15		mantis1 joined #evergreen
11:27	Dyrcona	miker: By "replaced the function," I mean that I went back to the version from the base schema.
11:33	miker	ah, ok. well, I confess that the error message in the log doesn't make much sense to me, it's complaining about a different table... but I'll see if I can sus out what's up there
11:34	Dyrcona	I'll try the new implementation again tomorrow or next week. I'm also trying to test a load of records that say they're MARC8, but I have my suspicions.
11:35	Dyrcona	I have some smaller batches that I'll use with the new implementation.
11:36	Dyrcona	Yeah, I wasn't really sure about the error message, either. I've got a couple of thousand more if you want to extract another.
11:36	Dyrcona	Something like 2,500 failed by the time that I noticed.
11:40	Dyrcona	Let me make sure it does the new thing for the password.
11:41	Dyrcona	It does! How about that!
11:41	* Dyrcona	cranks up the Iron Maiden...
11:46	miker	Dyrcona: so, I found the issue. the problem is in the details of PG's fkey checks. the cause is updating the id (which the named table points to as "entry"), even with the original value. we can replace sort_value, since it's the same and (basically) a key as well with the same effect and not bonk into that issue. I'm testing that change now (no explosions after 5min+), but it comes down to this if you want to use "\ef metabib.
11:46	miker	reingest_metabib_field_entries" to adjust the new version in situ: https://pastebin.com/PKDrhfSX
11:46		jihpringle joined #evergreen
11:48	Dyrcona	miker: Cool, I'll give that a shot after I play with my new SIP accounts.
11:48	miker	+1
12:15	Dyrcona	I suppose that I could just replace the function while it's running and see what happens.
12:39	Dyrcona	miker++ I swapped ou the function definition and it's still working.
12:39	miker	huzzah!
12:49	Dyrcona	My SIP test is not going so well. I can't tell if I'm failing to log in or if my test script is just blowing up. I'm getting a socket error.
13:04	Dyrcona	hmm. I get no response from server when I try to login with a newly created account, but pre-existing ones work. I even tried running actor.change_password() with the password that I'm using.
13:09	Dyrcona	There's a bug, I think. I was trying to use the location to add a workstation for the new users. When I removed the location, it worked.
13:09		mrtnnbr joined #evergreen
14:12		sleary joined #evergreen
14:13	Dyrcona	The other 3 are also deadlocks.
15:29	Dyrcona	So, I am now getting sharelock violations. That's it. I'll have to reload everything next week and start over with a clean upgrade to master, etc., to make sure I have everything, but I am pretty sure that everything is up to date.
15:37	jeffdavis	Do we have a way to flag bugs that need discussion rather than testing for bug squashing week? There's a fix for bug 1863387 that I'd like to commit as-is, but it would be good to know if end users think it needs more work.
15:37	pinesol	Launchpad bug 1863387 in Evergreen "Carousels: shelving location selector should limit initial set of choices" [Medium,Confirmed] https://launchpad.net/bugs/1863387
15:37	Dyrcona	jeffdavis: needsdiscussion tag.
15:40	jeffdavis	oh, are needsdiscussion bugs already included in bug squashing? that would be great!
15:49	sleary	I forgot about that tag
15:50	Dyrcona	On the plus side, the ingest coordinator has stayed up and running.
15:51		jvwoolf left #evergreen
16:16	mmorgan	jeffdavis: I am pretty sure the main focus of bug squashing week is bugs with pullrequests, terranm does a masterful job of organizing them on test servers with signoffs as a goal.
16:17	mmorgan	But I would think BSW is a great opportunity to look at needsdiscussion bugs, too.
16:50		stephengwills left #evergreen
17:06		mmorgan left #evergreen
18:25		sandbergja joined #evergreen
18:57	pinesol	News from commits: LP1952931 release notes <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=b33f1170050401a0c6066452a09d391fd97a7cd2>
18:57	pinesol	News from commits: LP1952931 stamp upgrade script <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=25f23ca394d5759f685f6b54933e9d0db18423cd>
18:57	pinesol	News from commits: LP1952931 Support ACQ Advanced Shipment Notices (DESADV -- Dispatch Advice Messages) <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=eae6c7e0eacc9ebf4bfd2014d9c6485a61de8a0c>
19:28	gmcharlt	testing, then pusing fix to 1344
19:38		sandbergja joined #evergreen
19:38	sandbergja	gmcharlt++
19:57	pinesol	News from commits: LP#1724032: add release note entry <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=2cad20e67af7d630b18834313960e00414dd758e>
20:28	pinesol	News from commits: LP1904036 Mark Damaged always handles checkin <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=55941c65290a23c682746c230b96fff12d38efc4>
20:28	pinesol	News from commits: LP1904036 Checkin grid routeTo visible by default <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=5bc6f2816ba2124198c9763f0d17c9aac88b05c4>
20:44	* gmcharlt	claims 1347
20:57	pinesol	News from commits: LP#1934162: stamp DB update <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=00d6528742c31a7b04aa876e6e4a471fec8c6bfc>
20:57	pinesol	News from commits: LP#1934162: add release note <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=1ea534594a176b72b404f12f8071faf870e96c8f>
20:57	pinesol	News from commits: LP1934162: (follow-up) sync whitespace <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=5ec73fa03414a59bd8516e571da6070b45e3b3ce>
20:57	pinesol	News from commits: LP1934162: add pgtap test, refreshing upgrade script <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=a51d2366a735903adf04cfe7a32af1565313b334>
20:57	pinesol	News from commits: LP#1934162: delete user messages and curbside notes <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=d24c4dbe1e9b3b4dc924647c4c29082242b37622>
21:07	* gmcharlt	claims 1348
21:16	* gmcharlt	claims 1349
21:27	pinesol	News from commits: LP#1982031: add release note <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=244f0c732b9358e8c272364047e03f1b92406d06>

Results for 2022-10-26

00:21	pinesol	News from commits: LP1411819 stamp upgrade script and add release notes <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=8da533ecb4126fdaa6cd6386a4468fe11550e4da>
00:21	pinesol	News from commits: LP1411819 follow-up: add a pgtap test <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=fd0a11c18fbac315b81d04da359ba062d002d916>
00:21	pinesol	News from commits: LP#1411819: org setting to override PATRON_EXCEEDS_FINES penalty on renewals <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=98ce2c013c295509d530df40bed947279dc3b9f5>
00:51	pinesol	News from commits: LP1953692: release notes <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=18c15f0957fdea5d1213ed137d80f879b9aa7ade>
00:51	pinesol	News from commits: LP1953692 follow-up: missing character <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=6b9a7d9bdf64144b8138025713575d9f79c61650>
00:51	pinesol	News from commits: LP1953692 Angular Catalog Record Summary links should open in new tab <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=781f399afa75a6f9fae4ef164c797f1231821f22>
02:18		tsadok joined #evergreen
07:42		collum joined #evergreen
08:07		BDorsey joined #evergreen
09:28		Dyrcona joined #evergreen
09:45		dguarrac joined #evergreen
09:46		jvwoolf joined #evergreen
09:57	mmorgan	Asked this in the hackaway, but I'll try here, too.
09:57	mmorgan	Trying to build a test vm using ansible and I'm getting this: "Open-ILS/src/extras/Makefile.install:156: recipe for target 'ubuntu-bionic-developer' failed"
09:57	mmorgan	What am I missing?
10:00		sleary joined #evergreen
10:03	Dyrcona	miker: Getting different behavior with ingest_ctl today after the patch from yesterday. I'm loading the same records that I used last week after a database reload. Updating 378 records worked fine. Inserting 314 has produced 7 errors and after that, it seems to have really slowed down.
10:05	Dyrcona	And, of course, after I mention it here, it picks back up again.
10:14	Dyrcona	I have all of the patches from DYM and queued ingest.
10:17	Dyrcona	The rest are all pretty much the same.
10:24	Dyrcona	I processed 1 by hand and it worked. I update fail_time to null and the rest of them worked in parallel.
10:28	JBoyer	mmorgan, regardless of the specific error you'll want to update your testing VM to a later version of Ubuntu; building Evergreen on Bionic from a fresh git checkout is likely to start failing within days.
10:28	JBoyer	see lp 1990969
10:28	pinesol	Launchpad bug 1990969 in Evergreen "Discontinue Support for Ubuntu 18.04 "Bionic Beaver"" [Wishlist,Confirmed] https://launchpad.net/bugs/1990969
10:29	JBoyer	OR, if you're running a later version of Ubuntu on your VM it's entirely possible that some package name has changed since bionic and that's what's failing.
11:59	Dyrcona	miker: I noticed two entries for the same author name back to back, so there's some evidence of that.
12:02	mmorgan	Bmagic: Right. Will look at that when I find some time.
12:14		Dyrcona joined #evergreen
12:23	miker	Dyrcona: https://pastebin.com/csTYASPu is what I'm proposing. commit coming in a moment
12:45	miker	Dyrcona: 2 new commits on the QI branch now, though just the first is strictly required for the browse ingest conflict. the second is about a long-standing oversight that removes too much data in a "just update this one field" reingest request
12:47	miker	(IOW, you may want to pick and test just the first new commit, but I think the second is needed generally)
12:49		collum joined #evergreen
12:55		kworstell-isl joined #evergreen
12:59	Dyrcona	miker: I'll try them both in a bit.

Results for 2022-10-25

10:02	miker	Dyrcona: AFAICT, the QI coordinator is always dying when trying to gather orphaned entries. is that right?
10:02	miker	that's based on the log snippets
10:02	Dyrcona	Yes.
10:03	Dyrcona	BTW, I've dropped that database and I'm testing something else at the moment. I could reload it.
10:16		sleary joined #evergreen
11:15		jihpringle joined #evergreen
11:31		Christineb joined #evergreen
11:31	miker	Dyrcona: if/when you get back to QI, there's a small change on the current branch that should at least let us get past the "can't use undef as ARRAY ref" death.
11:41		sleary joined #evergreen
11:44	miker	grabbing upgrade stamps 1340 and 1341
11:45	Dyrcona	All right. I'll stop what I'm doing and reload the database that I was using to test queued ingest. I can rerun my tests on a different database.
11:49	Dyrcona	Well, crap. I can't reload it from the dump. Pg version mismatches, etc.
11:49	Dyrcona	I'll have to do it differently and rerun the db upgrade scripts.
11:56	Dyrcona	I probably won't be able to do anything with it until tomorrow. I'd really like for someone else to look at queued ingest.

Results for 2022-10-21

08:53		Dyrcona joined #evergreen
08:57		stephengwills joined #evergreen
09:23		dguarrac joined #evergreen
10:22	csharp_	Dyrcona: are you targeting PG 14 in your testing? looking at moving past PG 11 since we're back in the same boat soon
10:22	csharp_	(on PG 10 now, just looking at an upgrade target)
10:23	Dyrcona	If you're referring to queued ingest, I've only been testing it on Pg 10.
10:23	csharp_	upgrading my staging server and thinking about what version to move towards
10:23	csharp_	no, just generally
10:23	Dyrcona	Pg 14 should work.
10:24	csharp_	ok - I'll give it a go
10:24	Dyrcona	I've done light testing on Pg 11 - 13. I use Pg 14 on all of my local VMs where I run concerto. (By local I mean on my laptop.)
10:24	Dyrcona	I might have 1 or 2 older ones (bionic, maybe?) on Pg 10.
10:25	Dyrcona	Does anyone know how to get of screen prompting for a password? I tried closing a window using Ctrl-a x because Ctrl-b x closes a window in tmux. Didn't remember is was the lock command and screen just keeps asking for a password.
10:26	Dyrcona	None of the Ctrl-a commands work with the password prompt.

Results for 2022-10-19

08:37		mmorgan joined #evergreen
08:58		Dyrcona joined #evergreen
09:05		dguarrac joined #evergreen
09:15	Dyrcona	miker: Well, ingest_ctl survived the other 157, 000 records yesterday with nothing much going on. I'm deleting a few more URIs and then going to load some as another test.
09:16	* mmorgan	added an additional commit to abneiman, jweston and jihpringle's release notes: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/mmorgan/docs-releasenotes-2022-10-18
09:19	Dyrcona	mmorgan++
09:20	miker	Dyrcona: that's good news
10:05	Dyrcona	Checking the database real quick looks like it actually worked for at least one of the failed records when I processed it manually.
10:06	* Dyrcona	keeps looking.
10:12	Dyrcona	My 502 is probably because I'm running an out of date Apache configuration.
10:50	Dyrcona	OK. Another batch of about 28,000 records to use for a stress test.
10:55		stephengwills joined #evergreen
10:55	Dyrcona	Ugh. Forced to use screen because tmux is not installed....
10:56	stephengwills	morning. if I RAISE some text in a postgresql function should I see that message in postgresql-10-main.log? or does it channel it somehwere else?

Results for 2022-10-18

09:39		Dyrcona joined #evergreen
09:39	abneiman	docs branch here, if I did things right --> https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/abneiman/docs-releasenotes-2022-10-18
09:40	abneiman	jihpringle++ jweston++ for their work & assistance!
09:40	miker	Dyrcona: thanks for throwing QI at a "real" test task
09:40	mmorgan	abneiman++
09:41	mmorgan	jihpringle++
09:41	mmorgan	jweston++

Results for 2022-10-17

14:04	Dyrcona	I'm going to work on Pg 15 during the hack-a-way if it happens.
14:17	berick	pg10 here
15:15		jihpringle joined #evergreen
15:45	csharp_	trying to test bug 1898775 - how do I enable the traditional catalog? I've set the Library Setting GUI: Enable Traditional Staff Catalog to True for CONS but not seeing a difference
15:45	pinesol	Launchpad bug 1898775 in Evergreen "Bootstrap OPAC: Add to bucket broken" [Medium,Confirmed] https://launchpad.net/bugs/1898775
15:48	mmorgan	csharp_: You need to change /etc/apache2/eg_vhost.conf Look for this line:
15:48	mmorgan	PerlAddVar OILSWebTemplatePath "@localstatedir@/templates-bootstrap" # Comment this line out to use the legacy TPAC
16:10	csharp_	jeez, we're supporting too many things, huh?
16:11	csharp_	mmorgan++ # was able to trigger the bug
16:11	mmorgan	csharp_++
16:11	jihpringle	csharp_ I see it in the menu on our test server when I set the setting to True - but I have to log out and back if before it appears
16:11	csharp_	jihpringle: ah
16:14	csharp_	fix works!
16:14	Dyrcona	#worksforme
16:38	Dyrcona	Right... Processes that change their name after they start....
16:41	Dyrcona	Wow!
16:42	Dyrcona	The updates immediately started going "faster."
16:44	Dyrcona	Testing two things at the same time. :)
16:46	mmorgan	Dyrcona: What else are you testing?
16:46	Dyrcona	Seems to be working. Some of the records have been ingested. Others haven't been ingested, yet.
16:47	Dyrcona	I was just making sure that a script to remove URIs for a vendor by library is still working.
16:47	Dyrcona	No failures, either.
16:48	mmorgan	Sounds promising!
16:48	Dyrcona	One of our members wants to refresh their Ebrary records.
16:48	Dyrcona	Yeahp.
16:48	Dyrcona	I was sitting here with that process going and thinking how can I test queued ingest, and well, it worked out perferctly.
16:49	Dyrcona	Well, better than my spelling anyway. :)
16:50	mmorgan	Dyrcona++
16:51	Dyrcona	miker++

Results for 2022-10-12

08:37		mantis1 joined #evergreen
08:50		Dyrcona joined #evergreen
09:37		jvwoolf joined #evergreen
10:08	csharp_	seeing an issue with npm run test - looks like bca84f2fce0d might be responsible
10:08	csharp_	pinesol: ahem
10:08	pinesol	csharp_: Message root @ server God....Universe going down for reboot....
10:08	csharp_	oh, right, that plugin was borked by an upgrade
10:08	csharp_	python 2 -> 3
10:13	csharp_	heh
10:13	csharp_	ok, that's an easy fix - I'll bug it
10:20	csharp_	bug 1992657
10:20	pinesol	Launchpad bug 1992657 in Evergreen "Recent commit breaking Angular npm tests" [High,New] https://launchpad.net/bugs/1992657
11:42		jihpringle joined #evergreen
11:44		sleary joined #evergreen
11:55		rfrasur joined #evergreen
17:17		mmorgan left #evergreen
18:00		jihpringle joined #evergreen
18:17		jihpringle joined #evergreen
18:37	pinesol	News from commits: lp1992657 - fix broken NPM test <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=d5f59248d1b4a2b53b87c2dbad203137a6e36f4b>
19:07	pinesol	News from commits: LP1991344 rxjs empty() function deprecated <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=9a677906cc200db4c6f8f0fa5a326334d5da4a72>

Results for 2022-10-11

15:20	gmcharlt	for obvious reasons, I'm kinda hoping that it does turn into "let's try Angular 14 for the back branches"
15:20	gmcharlt	er, does not
15:20		lew54 joined #evergreen
15:21	sandbergja	I could throw together a branch with npm audit --fix, but it would be nice to have some help testing the results
15:22	gmcharlt	happy to help (and I am actually pretty concerned about the potential for breakage)
15:22	berick	sandbergja: is your focus at the moment just on angjs?
15:23	gmcharlt	but I may be unduly distrustful of the state of backwards compatibiliy in the NPM ecosystem
15:24	sandbergja	I definitely share the concerns about regressions...
15:24	Dyrcona	I've run npm update in the past without ill effects, but not sure if that does what's needed. I've also not done it in a while.
15:24	gmcharlt	sandbergja: certain a gold star to any of use who figures out that we can _remove_ dependencies during the process :)
15:24	sandbergja	If you'll allow me a soapbox for a minute, it sure would be nice if we had more test coverage, so we could just run any automated dependabot PRs against the test suite and get a quick yes/no
15:25	sandbergja	about whether it introduces regressions
15:26		tlittle joined #evergreen
15:27	JBoyer	sandbergja++ gmcharlt++
15:27		terranm joined #evergreen
16:13	* Dyrcona	is considering taking over SpamAssassing on FreeBSD. It's currently looking for a maintainer.
16:13	Dyrcona	It's late in the day, and my typing skills are on the fritz....
16:15	Dyrcona	Autotools doesn't really cover installing HTML files for a website, beyond maybe using localstatedir. I s'pose inventing a new option is not out of the question, but....
16:15	mrtnnbr	anyway, it looks like there's some interest/curiosity here, so how about I finish configuring my test system and put it online for review. I'll send a a link to -dev
16:17	Dyrcona	OK. I'd like git branches, too. :)
16:28	mrtnnbr	Dyrcona: A quick survey of existing ports shows somewhat even usage of --htmldir, --datadir, and --datarootdir. one of the latter two might be reasonable.
16:30	Dyrcona	Yeah. We have an option to not install the web files, but not one for where.