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 2025-12-01

13:46	Dyrcona	I found another case of "we're doing it wrong."
13:48	Dyrcona	https://git.evergreen-ils.org/?p=working/Evergreen.git;a=blob;f=Open-ILS/src/perlmods/lib/OpenILS/Application/Circ/Circulate.pm;h=e20473162ac427698d6f0de691afa9c55b3adf97#l1762
13:49	Dyrcona	from perldoc -f ref: It is a common mistake to use the result of "ref" directly as a truth value: this goes wrong because 0 (which is false) can be returned for a reference.
13:50	Dyrcona	However, we may not want to change the status in that case. Also, I'm not sure that's quite the proper use of ref. I'd have to write a test program.
13:52	Dyrcona	I've also spent only about 30 minutes looking at this today, so I could be off.
13:56	Dyrcona	OIC.
14:39		kmlussier joined #evergreen

Results for 2025-11-26

12:27	Dyrcona	csharp_++ That's the main argument for merge in my opinion.
12:27	jonadab	That makes sense to me.
12:27	Dyrcona	jonadab: Yeah, cherry-pick makes it easy to get individual commits and that's its main purpose as far as I can tell.
12:28	csharp_	when I'm testing something, I like seeing the pile of commits on top, and that seems to be the main point in favor of patch workflow
12:28	csharp_	but there are ways to sort git log too
12:28	Dyrcona	When I get really desperate, I'll sometimes generate patches from git and apply them in another branch with `git am`
12:29	* Dyrcona	confesses to editing patches occasionally to remove stuff I don't want.
12:30	Dyrcona	All of that being said, I'm not sure there's a workflow that easily reconciles code drift like we're looking at with eCard.

Results for 2025-11-25

12:32	gmcharlt	missing from the instructions: set the added content base_url to https://content.chilifresh.com/
12:35	gmcharlt	force-pushed to the working branch to remove the extra warn and to clarify that base_url needs to be set
12:45	Dyrcona	OK. I base_url is likely the problem. I was able to get cover images with cURL when I tried last week.
12:46	Dyrcona	A force push makes trying the changes more difficult since I've already cherry-picked in the branch I'm testing. I'll just set base_url and see what happens.
12:50	Dyrcona	gmcharlt++ That was it. I set base_url and it works!
13:01	csharp_	Dyrcona: whoooo
13:01	csharp_	gmcharlt++

Results for 2025-11-24

10:46	Dyrcona	The brownser and Zoom see that the camera is there. They just get no output. The Camera app works until you stop the camera, then it won't turn it back on.
11:02	Bmagic	browser mic/camera passthru is funky
11:09	Dyrcona	I think it's lingering IPU6 issues. I couldn't find anything that says my particular laptop would still be a problem, but some Alder Lake laptops still have camera issues with kernel 6.17.
11:12	Dyrcona	Is anyone using Chilifresh with Evergreen? I tried setting it up on a test system, and even though we have a free trial setup, it's not working. I get no cover images.
11:13	Dyrcona	I "corrected" the URL to what Chilifresh redirects to, and If I retrieve that with cURL, I do get something that looks approximately correct.
11:14	Dyrcona	I think we're going to have to update the API. Chilifresh has a cover image API, and if I hit the cover art URL for an ISBN directly, I do get an image. (Again, with cURL.)
11:15	Dyrcona	I've been in contact with Chilifresh, but haven't heard anything since last Wednesday. I suspect time off on both sides may be a factor.

Results for 2025-11-19

13:38	Dyrcona	auth_internal, too. No failed services, either.
13:43	Dyrcona	I am able to login via the OPAC.
13:43	Dyrcona	Let me try again. I have restarted services since I got the error. Maybe it was just one of those things.
13:44	Dyrcona	Woah. I hit my bookmark for the staff client on this test machine, and I'm logged in.....
13:44	Dyrcona	Goes straight to the splash page.
13:45	Dyrcona	I'll log out and see what happens when I log in again.
13:46	Dyrcona	It's working. I must have just needed to restart services or soemthing.
15:33	csharp_	maybe just as a thought experiment
15:33		jihpringle joined #evergreen
15:33	csharp_	Bmagic: sipping on my Fretboard coffee :-)
15:38	Dyrcona	Hm... tests failing with a 401 but expecting a 403, that's probably an Apache configuration difference.
15:43	Dyrcona	yeahp. That was it.
15:45	csharp_	A Patchy Webserver
15:45	csharp_	sometimes I want ansible to be more bash-y
16:00	Bmagic	they do good work
16:00	Bmagic	It's like a new toy
16:02	Bmagic	csharp_++ # Fretboard
16:05	Dyrcona	Running the nightwatch tests for eg2 seems to take a while.
16:08	goood	csharp_: yes, no more external password files! also, I think we can move the redis admin password into opensrf_core.xml (in addition to redis.conf, obv) rather than storing it externally or passing it on the command line or in the env. that would simplify things even more.
16:08	* csharp_	nods
16:09	goood	(and, speaking of "goood's branch", it's updated now with leak fixes and ready for more testing, if anyone is feeling saucy)
16:09	csharp_	@band add Sassy's Sassiest Boys
16:09	pinesol	csharp_: Band 'Sassy's Sassiest Boys' added to list
16:10	csharp_	@dunno add Sprechen zie Sassy?
16:10	pinesol	csharp_: The operation succeeded. Dunno #103 added.
16:24	Dyrcona	I wonder if anything is actually happening with the nightwatch tests. I probably have to set the tmp directory because snaps...
16:29	Dyrcona	Did that and now my vm is actually doing something.
16:31	JBoyer	Mentions of ansible having caught my eye: there's no need to do almost anything with a shell command (except install python pre-reqs or something that low level)
16:32	JBoyer	lineinfile is extremely useful for line editing (when just using template or file isn't better)
16:38	Dyrcona	Yeah, setting TMPDIR got the tests to work.
16:44	csharp_	JBoyer++
16:47	abneiman	merge pause is lifted, point releases are out
16:50	abneiman	gmcharlt++ mmorgan++ Bmagic++ mdriscoll++

Results for 2025-11-17

15:04	sandbergja	Dyrcona: you asked if anybody had a fix for `npm install -g @angular/cli@^15.0`? There's a fix at bug 2096711 -- it's not a needed step, so in my opinion, the fix is to simply remove that step
15:04	pinesol	Launchpad bug 2096711 in Evergreen "Don't install @angular/cli globally" [Undecided,New] https://launchpad.net/bugs/2096711
15:06	* Dyrcona	had no idea that step was superfluous, but guess it is.
15:19	Dyrcona	Think I'll take that bug, too, and give it a whirl on a test vm.
15:22	Dyrcona	Bmagic: You updated a related bug with a comment describing what I'm seeing exactly 1 year ago today: https://bugs.launchpad.net/evergreen/+bug/2080794/comments/3
15:22	pinesol	Launchpad bug 2080794 in Evergreen "Upgrade nodejs to 22" [Undecided,Fix released]
15:45	Bmagic	oh! I do remember writing that now that you mention it

Results for 2025-11-14

11:59		jihpringle joined #evergreen
12:15		jihpringle joined #evergreen
12:33		jihpringle joined #evergreen
15:12	pinesol	News from commits: LP2045073 follow-ups: update angularjs condition and add angular unit test <http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=c3140c60fc0be9ae1aa03ced4d15bbf2505986f3>
15:12	pinesol	News from commits: LP2045073 Disable print, download CSV on empty grids <http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=059e3f0aabf2a02ed3ea94e0ff66329435a0dde4>
16:42	pinesol	News from commits: Docs: SIP filter documentation <http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=fb4959fec943baf9ef1057354b0e5e17634139ec>
17:04		mmorgan left #evergreen
17:38		scottangel joined #evergreen

Results for 2025-11-12

15:33		BDorsey joined #evergreen
15:37	BDorsey	Howdy, all! Question: Does the demo server have an account with buckets that were previously deleted? We're making the switch to 3.15+ and many (if not all) of my deleted buckets are showing up in the angular record buckets module. Once you delete it in 3.15, it's gone, but they shouldn't be there in the first place, right?
15:37	BDorsey	I was hoping to confirm on the demo server, but I'm not seeing any buckets on the admin account.
16:11	mmorgan	@later tell BDorsey The concerto data set that gets loaded into test and demo systems does not have any buckets by default, so there isn't a way to test that on the demo server.
16:11	pinesol	mmorgan: The operation succeeded.
16:25	gmcharlt	jeffdavis: not necessarily
16:26	gmcharlt	i.e., one can continue to do cherry-picking, and if one is working directly through GitHub, it provides options to force doing linear rebase + cherry-picks rather than merge commits

Results for 2025-11-11

15:09	dluch	#info dluch = Debbie Luchenbill, MOBIUS
15:09	JBoyer	#info JBoyer = Jason Boyer, EOLI
15:09	Bmagic	#info Bmagic = Blake GH, MOBIUS
15:09	gmcharlt	#info the RediSRF stream based has received testing during the hack-a-way; various bugfixes under way
15:10	Rogan	#info Rogan = Rogan Hamby, EOLI
15:10	gmcharlt	#info The Debian 13 compatibility branch has been committed to main
15:11	ying_h	#info ying_h Ying-Hsiang Huang, KCLS
15:57	gmcharlt	so I'm curious how much appetite there is for doing an extra normal bugfix release for 3.14
15:58	abneiman	I put it in because I wasn't sure what the sense was about that
15:58	Dyrcona	Are there sites running 3.14 that would upgrade to 3.14.12?
16:00	abneiman	I'm not seeing anything critical on 3.14.12, and the one High-importance bug might be invalid at this point anyway (needs more testing tho IMO)
16:00	dluch	I'd say cut it off, then
16:00	abneiman	that being lp 2107346
16:00	pinesol	Launchpad bug 2107346 in Evergreen 3.15 "Enhanced MARC Editor - Field tags, indicators, and subfield tags not saving consistently" [High,Incomplete] https://launchpad.net/bugs/2107346
16:09	abneiman	lp 2122539
16:09	pinesol	Launchpad bug 2122539 in Evergreen "Copy attribute unsetting fails for number-ish fields" [Critical,Confirmed] https://launchpad.net/bugs/2122539
16:09	abneiman	thank you pinesol
16:12	JBoyer	good news re: 2122448, there's an alternative branch being tested now that fixes a couple things. With that out of the way I was planning to look into 2122539.
16:12	abneiman	JBoyer++
16:13		mmorgan left #evergreen
16:18	goood	https://bugs.launchpad.net/evergreen/+bug/1954937

Results for 2025-11-06

13:42		smoodyECDI left #evergreen
13:55	gmcharlt	claiming 1501 and 1502
13:57	csharp_	berick: same here
14:18	pinesol	News from commits: LP#1847805,2098043,2098407,2098117: stamp database updates <http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=0b1ce3cf65cddf5d923c732107b29f6e8ce9ca2e>
14:19	pinesol	News from commits: LP#1847805: (follow-up) correct number of test cases <http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=dd5036c1acb46edceb2e03ddf932db27c84d7a4b>
14:19	pinesol	News from commits: LP#2098043,2098407,2098117: Angular Bucket updates <http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=38a46cb3905719e4800176f6f7f66eee0ca2b9c7>
14:19	pinesol	News from commits: LP#1847805: in-query pcrud perm checks <http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=9301601b4684929e4eca3921916476db599fc208>
14:40	gmcharlt	noting that what I just commit makes it an even BETTER idea than normal for folks to test the RC (which will be announced after some further smoke-testing today)
14:53	csharp_	gmcharlt++
15:19	pinesol	News from commits: LP#2098043,2098407,2098117: (follow-up) de-lint <http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=8b5add12242ab10226424726443bfb7adf378f48>
17:02		mmorgan left #evergreen

Results for 2025-11-05

11:57	eeevil	no, it's not the built-in browser cache
11:57	eeevil	it's the indexeddb cache that we build
11:58	Bmagic	I see, so I would see the websockets request, just after the request, somewhere before firing off the request over the internet, it supplies the answer internally?
12:01	* csharp_	appears
12:03	csharp_	abneiman: I go by this (or my working memory of it): https://wiki.evergreen-ils.org/doku.php?id=dev:bug_wrangler:faq
12:03	csharp_	Incomplete - The bug report is missing important information preventing it from being fixed. The submitter should be notified to provide additional information.
12:03	csharp_	Won't Fix - Bug will not be fixed. Reasons may vary.
12:04	csharp_	in the case of bug 2130454, jihpringle tested and could not reproduce, so I marked Incomplete
12:04	pinesol	Launchpad bug 2130454 in Evergreen "Holdings View tab: "Show" checkboxes aren't sticky" [Undecided,Incomplete] https://launchpad.net/bugs/2130454
12:05	csharp_	similar situation with bug 2107346 - the most recent comments indicate they aren't seeing the reported issue
12:05	pinesol	Launchpad bug 2107346 in Evergreen 3.15 "Enhanced MARC Editor - Field tags, indicators, and subfield tags not saving consistently" [High,Incomplete] https://launchpad.net/bugs/2107346
12:06	csharp_	also, just for the record, I'm cool with other people deciding that I'm wrong about choosing a status, etc. - it actually kind of happens a lot :-)
12:06	csharp_	I just don't want to keep a bug in "New" or "Confirmed" if it doesn't appear to still be a real bug in recent testing
12:07	csharp_	</my_opinion>
12:08	csharp_	agreed that a review of statuses/wrangling expectations would be useful
12:11	abneiman	csharp_++
12:11	abneiman	thanks!
12:14	csharp_	re: 11:45 < Bmagic> Maybe "invalid" "feels" too harsh. And it would make the bug report-person feel invalidated :)
15:39	csharp_	yeah, obviously have zero investment beyond this discussion :-)
15:40	Bmagic	I'm verifying that deleting a bib (via delete from biblio.record_entry) will trigger-delete the volumes
15:43	Bmagic	it does not
15:45	Bmagic	I'm testing that little switcharoo in the $vols check
15:49	Bmagic	I think it's well overdue that Evergreen automatically delete it's URI's when BRE is deleted
15:50	Bmagic	imma fix it
15:52	Bmagic	found a couple old related bugs: https://bugs.launchpad.net/evergreen/+bug/761085 https://bugs.launchpad.net/evergreen/+bug/761130

Results for 2025-10-27

19:15		jihpringle joined #evergreen
19:48		jihpringle joined #evergreen
21:24		sandbergja joined #evergreen
22:03	pinesol	News from commits: LP1902937 follow-up: update bootstrap 4 class to bootstrap 5 class <http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=584a6610a75105c32e52d8e130c3e9185d645f69>
22:03	pinesol	News from commits: LP2032665: follow-up: get unit tests compiling again <http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=224c4f22cb7d54ac44a763ba1f7cb7f056b390df>
23:24		stephengwills joined #evergreen

Results for 2025-10-23

09:45		redavis joined #evergreen
10:12	berick	Dyrcona: FYI i'm probably canceling the Rust session today so I can try to do some regular EG stuff
10:15	redavis	berick++
10:16	eeevil	Bmagic: cursors came in with commit 19984921b8. they make it possible (like, at all, period) to handle certain shapes of data via prcud, given the current "test each row after fetching" logic. the FETCH is equivalent to a SELECT, and is the "give me the first 100 rows" request of the associated DECLARE ... SELECTs plan. the underlying query plan will be the same (or better, cursors tell PG to use a plan that should return the first row faster, rather
10:16	eeevil	than the whole query faster). tl;dr: you can ignore the fact of the fetches, just look at the DECLARE ... SELECTs for investigation. relatedly, the branch at the end of https://bugs.launchpad.net/evergreen/+bug/1847805 actually disables cursors in favor of direct limit/offset because it pushes access restrictions into the query instead of fetch-then-test. that branch, btw, shows a 2-10x speedup in statistically-measurably-long (more than a few ms)
10:16	eeevil	queries in my testing.
10:16	pinesol	Launchpad bug 1847805 in Evergreen "pcrud search can fail to retrieve rows that the user has access to" [High,Confirmed]
10:19	Dyrcona	berick: OK. I haven't had a chance to look at much of anything Rust-related since the last meeting.
10:30		mantis left #evergreen

Results for 2025-10-22

11:32	csharp_	yeah, we upped it to allow for better planning - again, meh
11:32	Bmagic	right, I've reviewed that setting in the past
11:32	csharp_	eeevil almost certainly has better ideas about how to set things like that
11:32	Bmagic	it doesn't explain the test machines not having an issue
11:32	csharp_	(pretty sure he was the one to point me to that setting in the past)
11:33	* eeevil	reads up...
11:34	csharp_	if it's literally the same plan on test/development/production/whatever, then the stats stuff might be a red herring
11:36	csharp_	having run PG on multiple types of machines/VMs/environments, I can say that some of the differences I've seen can only be attributed to the supernatural :-)
11:36	Dyrcona	It's not the same plan. It's the same query and different data, about 200 rows less in development.
11:36	Bmagic	My theory is the plan is different between the two. The databases are identical in terms of general size and shape of the tables involved. call number 1717933 happens to be one with lots of connections
11:37	csharp_	select * from pg_ghost;
11:38	eeevil	I'm confused about what is being tested here
11:39	Bmagic	eeevil: click the "query" tab on those explains
11:39	eeevil	I did
11:39	Dyrcona	I was leaning in the direction of tweaking the query planner. It's using more indexes in development and doing more scans in production.
11:54	Dyrcona	Removing the coalesce speeds it up.
11:54	Dyrcona	AND acp.circ_lib IN (SELECT id FROM actor.org_unit_descendants((evergreen.org_top()).id));
11:55	Dyrcona	Why are we doing the coalesce? Are there cases where org_top() could return null?
11:57	eeevil	Dyrcona: we're NOT, in the actual function
11:57	eeevil	we're passing $2, an optional (default NULL) org id
11:58	eeevil	interestingly, we're not testing that the acn is not deleted. no biggie, IMO, but ... odd
11:58	Bmagic	right, the function needs to accomodate an OU
11:58	Dyrcona	Hm. I'll look at the actual function, then. I thought Bmagic was testing a verbatim copy/paste with values plugged in.
11:59	Bmagic	Dyrcona: exactly, copy/pasted the function and plugged in null for the OU, and the ID number for the bib
11:59	Dyrcona	Well, if the acn is deleted, it should have all deleted copies, so if the copy isn't deleted, then neither should the acn be deleted.
12:00	Dyrcona	Well, eeevil said the function doesn't do the coalesce... So I'll still have to look at the function.
12:03	eeevil	(and yes, re acn.deleted, acp.deleted is a pretty safe proxy)
12:03	Bmagic	bug 2129571
12:03	pinesol	Launchpad bug 2129571 in Evergreen "asset.record_has_holdable_copy can be slow" [Undecided,New] https://launchpad.net/bugs/2129571
12:05	eeevil	Bmagic: https://lumen.esilibrary.com/p/HBAe8E30.html if you want to test my first-order patch above ... works for me
12:06	Dyrcona	eeevil: I guess I didn't understand something you said earlier or whatever, but I can say that removing the coalesce makes it faster on our production database. The development database doesn't care and they should be about the same, execpt for settings.
12:07	Bmagic	eeevil++ # testing
12:07	Dyrcona	With an ou id, the coalesce doesn't seem to make a difference.
12:08	eeevil	Dyrcona: ah, I confused things, pardon. I should use all my words.
12:08	pinesol	News from commits: Docs: 3.15.6 release notes <http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=11842140c303686b69042ff9e32bd908b24ed042>
12:17	eeevil	something about putting the function there (as a coalesced param to another function) is convincing the planner that scanning the tables /in toto/ will be faster than maybe calling the function. it may depend on the stats related to the first bib used, but that's unlikely. I think it's a planner reasoning issue in param-nested functions in a plan that has to work for both NULL and NOT NULL cases, so it probably CANNOT optimize the call away, ever. (
12:17	eeevil	different versions of PG obviously have different optimizations for function cached plans, so 16 may be smart enough for the old version)
12:17	Bmagic	abneiman++
12:18	Dyrcona	eeevil: Both of the databases where I'm testing this are Pg 16, and they show radically different performance.
12:18	eeevil	Bmagic: well, not the whole function. just the filter we're focusing on. there's no difference between "and is in the FULL list of orgs" and just not asking if it's in the full list
12:19	eeevil	Dyrcona: ah, well, I dunno then.
12:19	eeevil	stats, jit, work_mem, parallel workers, etc
12:23	eeevil	it would be nearly as fast (to the point of no measurable difference, I'd wager) and more maintainable to just build an array of orgs and use "= ANY"
12:23	Dyrcona	IIUC, that function is looking for any holdable copies at the org unit or at any of its descendants, so you want the select on actor.org_descendants() in either case.
12:23	Bmagic	if you don't specify a circ_lib, it's all circ_libs
12:24	eeevil	Dyrcona: only if there is an ou passed in. if ou is NULL, we use all orgs for the "is it here" test. that's the same as not asking the question -- it's always true
12:24	Dyrcona	What would make sense, and maybe I missed a comment to that effect, would be to set an array variable at the top and then use the ANY in the query. We could probably use ANY even in the current form.
12:25	Dyrcona	eeevil: Yes, I elided that bit thinking it was obvious.
12:25	Dyrcona	Maybe I should use all the words, but verbosity is a drag.
12:29	eeevil	Dyrcona: I believe we have all arrived on the same page from different edges
12:29	Dyrcona	eeevil++
12:31	Bmagic	https://pastebin.com/nLv3zzVf
12:31	Bmagic	I just put that function on my test machine and it dropped the execution time from 2.2ms to 1.3ms
12:32	Bmagic	I lifted the exact logic from eeevil's comment above
12:35	Dyrcona	Bmagic: I don't like it. Running different code based on the second input variable being NULL is a maintenance bug waiting to happen.
12:36	Bmagic	I can see that, offer the ANY version
12:47	csharp_	@dunno add I WANT MY TWO DOLLARS!
12:47	pinesol	csharp_: The operation succeeded. Dunno #101 added.
12:47	Dyrcona	Well, I think eeevil's original solution is fine. If we want to got the ANY route, then I prefer mine. :)
12:47	Bmagic	FWIW, on my test machine: ANY = 8ms, eeevil's single = 2.1ms, split IF = 1.2ms
12:48	Dyrcona	Yeahp. Is .9ms worth a potential maintenance issue?
12:48	Bmagic	nope, I don't think so
12:49	Bmagic	plus, it's slower when provided a second argument
12:50	eeevil	oh, nm, Dyrconasaid that
12:50	Bmagic	happy to do that
12:50	Bmagic	which one are we going with?
12:50	Dyrcona	On my test database, the ANY version is 4.777ms.
12:51	Bmagic	and race it against eeevil's original
12:51	Dyrcona	And the original is 3.763ms.... :(
12:51	Bmagic	the original, original? or eeevil's original proposed fix?
12:51	eeevil	which function? the one with the least amount of maintenance overhead is my preference. if single-query =ANY is as fast as my first one, go with =ANY.
12:52	eeevil	(because =ANY /can/ be faster, even if it's not always)
12:52	Bmagic	they are super close in speed, with ANY taking an additional 1ms (sometimes)
12:54	Bmagic	I just tested a bunch of random integers as the second argument. The ANY performs the same as eeevil's OG
12:55	Bmagic	I'm leaning towards ANY
12:55	Dyrcona	OK, go with ANY.
12:55	Bmagic	was there a nit pick on the variable name from Dyrcona's paste?
12:58	Dyrcona	It's the old way of addressing parameters in functions. We've upgraded past any version that does not support named parameters.
12:58	Bmagic	my $annoy_eeevil_crazy_name;
12:59	jeff	and I misremembered. it's only in the method name now (or only ever was).
12:59	Dyrcona	On my test database, eeevil's implementation outperforms the any version without a second parameter almost every time.
13:02	csharp_	jeff++ # I had the same thought about crazy search
13:04		jihpringle joined #evergreen
13:06	Bmagic	https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/blake/lp2129571_slow_asset_record_has_holdable_copy
13:39	Dyrcona	I wonder if the problem is the coalesce inside the function parameters?
13:40	Dyrcona	Both of them get slower when I add a second argument, and the non-any version still takes almost twice as long.
13:41	Dyrcona	Grrr.... The any version takes about twice as long as the non-any version: 58.664 ms vs. 25.795 ms.
13:48	Dyrcona	So, I'm putting the any version in production. Testing on one record really isn't very scientific, and I agree that ANY on a pre-fetched array can be faster than IN against a query.
13:59	Dyrcona	Bmagic++
13:59	Dyrcona	eeevil++
14:08	Dyrcona	I have another implementation to test that mixes the two approaches. It uses eeevil's original code to set a v_ou variable and then uses that variable to retrieve an array of ous. We'll see if that's faster.
14:15	Dyrcona	Nope. eeevil's original suggestion is still faster.
15:00	Bmagic	A hole in one we would say! eeevil++ miker++ Dyrcona++
15:44		mantis left #evergreen

Results for 2025-10-21

14:55	csharp_	ok, so probably not kernel
14:55	Bmagic	yeah, that number is so large, I can't imagine it's imposing any restrictions
14:56	csharp_	maybe play with setting shared_buffers during off hours and see if anything changes?\
14:56	Bmagic	I'm hopeful it's shared_buffers. I have a test machine with the same database on it, I'll increase the buffer to 192, and see if it's slow, then back to 8GB
14:58	csharp_	https://www.postgresql.org/docs/current/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-MEMORY - note the advice about that setting
14:58	csharp_	also that it requires a restart
14:58	csharp_	sorry, probably over-advising

Results for 2025-10-20

13:31	pinesol	News from commits: LP2102049 ARIA counts for grid action buttons <http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=ecd1d5f8d769f2a44b41cc9b3ae1773fcbf905eb>
14:01	pinesol	News from commits: LP2087870 Transit destination shortname <http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=1c6692b5fe017689ee4b3f57400793c7301e9e0a>
14:31	pinesol	News from commits: lps-2116206-2116127-2116129: Add initials input field and validation to note dialog <http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=e1cd685044166890d3ac090601d3ca884c982f71>
15:05	sandbergja	Bmagic and anybody else who wants to help with the nightwatch tests: bug 2129093
15:05	pinesol	Launchpad bug 2129093 in Evergreen "Nightwatch tests are failing on main" [Undecided,New] https://launchpad.net/bugs/2129093
16:01	pinesol	News from commits: LP1949222 Add to basket action in record view <http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=b12f65c8a8e5a40450d7e45561c7d4cd80337fa3>
16:09	Bmagic	sandbergja++
16:44		terranm joined #evergreen
17:03		mmorgan left #evergreen

Results for 2025-10-14

15:10	mmorgan	redavis++
15:11	shulabramble	anyone have any other notes on updates for OpenSRF, etc?
15:11	Dyrcona	is it too late to sneak in support for Debian 13?
15:11	csharp_	Dyrcona: testing that is on my to-do this week
15:12	Dyrcona	csharp_++
15:12	shulabramble	csharp_++
15:13	shulabramble	okay, wall o' text incoming.
15:17	csharp_	Dyrcona: we do, very happily
15:17	eeevil	right now, I think there is a segfault or use-after free when ALL services are dereg'd, causing the routers to croak. otherwise, it's been working well for me in my dev env for ~3mo
15:18	shulabramble	csharp++ pines_team++
15:18	Dyrcona	I have no trouble in dev. In prod or testing we quickly run out of drones.
15:18	eeevil	in particular, I would like to invoke berick's name ... he def knows the redis rewrite's guts best
15:19	csharp_	@seen berick
15:19	pinesol	csharp_: berick was last seen in #evergreen 5 days, 5 hours, 38 minutes, and 6 seconds ago: <berick> Dyrcona: heh, you tell me. my 2006 goggles are on the fritz
15:20	Dyrcona	No, I don't think we're going cross domain.
15:20	eeevil	kk
15:20	csharp_	we are not cross registering - just single app servers that don't know about the others
15:21	eeevil	csharp_: if you have test-env tuits, I'm glancing longingly in your direction ... ;)
15:21	Dyrcona	I can't promise anything. I'm terribly swamped lately.
15:22	* csharp_	bats eyelashes
15:22	shulabramble	#action eyes wanted on Redis Stream-based HA/LB branch (https://bugs.launchpad.net/opensrf/+bug/2116980)

Results for 2025-10-09

09:56	Dyrcona	:)
09:56	Dyrcona	I'm trying it with PCRE2.
10:01	Dyrcona	Looking at it, the interface isn't more complicated, it's just different.
10:21	Dyrcona	Oof... I dropped my change for checking libdbi with my latest change on the test vm.
10:24	Dyrcona	Yay! Configure works.
10:37	Dyrcona	Wow! More changes.
10:39		sandbergja joined #evergreen
12:27	Dyrcona	OK. Some mumbo jumbo about the info on the concerto logins page not working. When I changed a patron's password to something that I know what it is, it worked.
12:46		collum joined #evergreen
14:04	Dyrcona	We should stop supporting installation on Debian 10 "Buster." It is EOL since June of 2024.
14:24	Dyrcona	Tests are failing on Debian trixie.
14:32	Dyrcona	I think I might add a follow up on the pcre2 commit to log the error from pcre2_match. We can log it, so why not?
14:32		sandbergja joined #evergreen
14:40	Dyrcona	Ugh.... I love it when all I do is reload the database and restart services and the failing tests all suddenly pass.
14:41	Dyrcona	Who knew that mucking with 1 user's password would break so much?
14:57	Dyrcona	I love how tests just seem to randomly fail.
15:16	sandbergja	it would be much nicer if our perl live tests that require a very specific database state could be responsible for setting up that state themselves. Rather than just hoping for the best.
15:19	sandbergja	it's a bit annoying that for some tests, you can't run them twice in a row; you have to reload the database before each run. Makes it pretty time consuming to see if your changes broke anything haha
16:04	Dyrcona	Well, it's also annoying when 1 fails on a clean database; you reload it; it passes; reload again; it fails.
16:06	Dyrcona	I think I had a bunch of test failures on my first run because I had the wrong branch checked out when I built the database.
16:07	Dyrcona	After that the tests passed 2 out of 3 tries.
16:11	Dyrcona	I am testing the trixie branch on jammy.
16:34	Dyrcona	Yeah, first time running the perl live tests after a database reload and a bunch of them fail. I bet after a second reload, they all work.
16:34	Dyrcona	Well, 2 of them failed: cover uploader and remote patron api. I did do autogen.sh -u, so maybe my apache config is broken?
16:34	Dyrcona	Everything has to be "just so."
16:35	Dyrcona	Huh.. nginx not running.
16:39	Dyrcona	hrm.. Apache was still trying to use port 80.... Guess I didn't restart it properly....
16:39	Dyrcona	Too many moving pieces.
16:41	Dyrcona	Everything has to be done in the correct order.
16:44	Dyrcona	Yeah, now the Perl live test all pass. The pgtap and static perl tests already passed.
16:46	Dyrcona	That's enough for today.
17:02		JBoyer joined #evergreen
17:06		mmorgan left #evergreen

Results for 2025-10-06

12:47	Dyrcona	configure: error: "pgsql driver not installed?"
12:47	Dyrcona	See 'config.log' for more details
12:50		mantis joined #evergreen
12:52	mantis	does anyone enable Global Flags related to ingest? We started giving it a try in our test server but our cataloger can't delete any records
12:52	mantis	we enabled ingest.queued.biblio.all,
12:52	mantis	ingest.queued.biblio.insert, and ingest.queued.biblio.update - not sure if that's overkill with .all enabled
12:53	mantis	sorry also the .delete flag
13:06	Dyrcona	mantis: maybe there's a cron job required for queued ingest? I don't remember.
13:07	Dyrcona	./config.log:configure:14202: gcc -qversion >&5
13:07	Dyrcona	./config.log:gcc: error: unrecognized command-line option '-qversion'; did you mean '--version'?
13:13	mantis	just wondering if it's needed at all
13:37	Dyrcona	mantis: Our production version doesn't have that feature.
13:43	Dyrcona	The libdbi packages are installed, so it's a change in behavior in GCC.
13:51	Dyrcona	OK! I fixed the test for libdbi. However, since we're looking for a dbi package, we can probably remove the test from configure.ac.
13:52	Dyrcona	I think this should be a different bug from Lp 1325054.
13:52	pinesol	Launchpad bug 1325054 in Evergreen "libdbi deprecation warnings when building Evergreen" [High,Confirmed] https://launchpad.net/bugs/1325054
13:53	Dyrcona	Now that I've fixed that a check libpcre fails.
14:23	Dyrcona	csharp_++ I was going to check bullseye and bookworm, too. I confirmed it's available on Ubuntu 25.04. I'm going to check noble, too.
14:23	csharp_	so yeah, I think we can assume it's fine to change for all debian-ish targets
14:23	Dyrcona	Yeah.
14:24	csharp_	we can put in a testing note in the bug that we need to actually compile on all current versions
14:24	Dyrcona	Ok. 2 new bugs: 1. Fix configure check for libdbi. 2. Switch to libpcre2.
14:24	csharp_	Dyrcona++
14:25	Dyrcona	I pushed a signed-off branch for the OpenSRF changes.

Results for 2025-10-01

10:33	Dyrcona	I added the filters in the implementation_config of the institution as shown in the example. I restarted SIPServer, but it's not redacting the field.
10:33	Dyrcona	OK. Maybe my SIPServer is too old on this system.
10:34	Dyrcona	Bingo.
10:42	Dyrcona	I was missing the one commit that I was trying to test. :)
10:43	Dyrcona	That also means this virtual machine is older than I thought.
10:51		sandbergja joined #evergreen
10:53	sandbergja	eeevil: your fix for bug 2125510 has some ng lint issues, could you please fix them (see https://github.com/evergreen-library-system/Evergreen/actions/runs/18142067027/job/51635123330)? Thank you!
15:52	Dyrcona	Can't use an undefined value as an ARRAY reference at /usr/local/share/perl/5.34.0/OpenILS/Application/Vandelay.pm line 136.
15:52	Dyrcona	We really should check that there is a value, and it an array reference before trying to dereference it.
15:53	Dyrcona	Line 136: if ($e->search_vandelay_bib_queue( {name => $name, owner => $owner, queue_type => $type})->[0])
16:05	Dyrcona	Did anyone test the background import manager?
16:08	csharp_	Dyrcona: we're using the background import manager - haven't heard of problems lately
16:09	csharp_	(3.14.3-ish)
16:12	csharp_	looking at nvm with an eye on how we're installing nodejs: https://github.com/nvm-sh/nvm

Results for 2025-09-26

11:28	sandbergja	eeevil++
11:33	* eeevil	idly wonders why action.hold_request_reset_reason_entry exists when action.unfulfilled_hold_list is right there, with the same structural purpose ... oh well
11:35	Dyrcona	Perhaps someone didn't know about one when the other was created, or didn't know what the one did?
11:40	Dyrcona	It sure is taking a long time to delete this staff account on my test database.
11:40	Dyrcona	Twenty-two minutes so far.
11:45	eeevil	Dyrcona: it's common for new features to reimplement existing wheels in EG, yes
11:49	Dyrcona	Twenty-nine minutes and 36 seconds to delete this staff account. They must have had a lot of data.
12:39	Dyrcona	eeevil++
12:40	Dyrcona	Looks like my changes to actor.usr_delete and actor.usr_purge_data are working.
12:47	eeevil	grabbing 1486
12:53	pinesol	News from commits: Stamping upgrade script <http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=747da794c4a8dafa79e99aff96b2a94af0bb69f7>
12:53	pinesol	News from commits: LP2107581 (follow-up): adjust seed data, add a live test <http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=cc2c28fcf1d0fc09671bceef0a192681c5c18999>
12:53	pinesol	News from commits: LP#2107581: Fix constraint on action.hold_request_reason_entry <http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=68932c33507bee240d990822c12af25fcbb8e796>
12:53	pinesol	News from commits: LP#2099920: attempt to fix hold targeter failures and quiet the logs <http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=4c3717efc01bb220eff4964aa21908fd0fd31bfb>
12:57	Dyrcona	Thinks this could use a pgtap test.
13:12	Dyrcona	There is a purge user live test that does not need to be changed.
14:24	Dyrcona	I'm getting errors when doing --load-all-sampe with eg_db_conf on a 3.15.5 branch today. I don't feel like investigating right now, but it is probably worth looking into later
14:30	Dyrcona	OK. Looks like I have a test that hits the main points of PII.
15:16	Dyrcona	Should I include a data update beside the functions update to remove the data from the auditor.actor_usr_history and auditor.actor_usr_address_history tables or should I put that in the release note?
15:19	jeffdavis	I'd vote for a data update.
15:19	JBoyer	Since they could potentially run for a very long time and aren't actually related to the process of upgrading the database themselves, maybe the cleanup should be output via \qecho like the symspell sideload stuff is

Results for 2025-09-22

12:52	Dyrcona	Interesting stuff: Looks like we've got some race conditions with patron updates and deletes, but those are rare. I've 1 setting and 2 "penalties" added to deleted patrons with timestamps right around the delete time.
13:11	Dyrcona	I might split this up into multiple bugs....
13:23		mantis joined #evergreen
13:26	mantis	had a question about the patron_loader.pl. I'm testing it out with a csv that has cardnumber, usrname, profile, home_library, family_name, first_given_name filled out. These are completely new patrons. When running the script, I get these kinds of errors: line 6 could not find valid profile, id: none, column: 2 for 55555264687
13:27	mantis	the way I'm reading it is there's no id which I'm assuming is for the actor.usr table
13:27	mantis	btw the barcodes are just made up numbers
13:28	mantis	I also get this error that shows with the --debug: parameters: 1758561898,line 2 could not find valid home library, id: none, column: WDBURY for 55555264683,0,117
13:31		jvwoolf joined #evergreen
13:35	jeffdavis	looks to me like the missing id's in question are the profile (permission.grp_tree.id) and home_library (actor.org_unit.id)
13:36	jeffdavis	i.e. that either your data contains profile and home lib values that aren't valid for the EG system you're running this on, or they weren't mapped successfuly to valid values
13:54	sandbergja	I believe the profile should be the actual name of the profile (e.g. Patrons)
13:54	sandbergja	based on this sample in the code base: https://github.com/evergreen-library-system/Evergreen/blob/main/Open-ILS/src/perlmods/live_t/data/patrons-to-import.csv
13:54	sandbergja	(^ mantis)
13:55	mantis	ok so I was right about the shortcode
13:55	mantis	thank you!
13:55	mantis	I might update the current docs to reflect this if the test passes
13:55	sandbergja	that would be great!
13:59	sandbergja	full credit goes to Rogan for that sample CSV
13:59	mantis	the script did process, but I don't see the patrons in the actor.usr table

Results for 2025-09-19

12:39	Dyrcona	Looks like those deletes are not finishing but the function moves on...
12:41	Dyrcona	Weird.
12:43	Dyrcona	Think I'll update the gist to do what this copy does. Seeing the tables that the stuck data is in is probably more useful than getting the whole user row.
12:46	Dyrcona	So, one example user that was recently purged had 2 rows left in auditor.actor_usr_history. This same user had the same data on a test system, so I ran the same delete that the usr_purge_data function does and the delete went through. I've got 144,925 rows in the output with actor_usr_history in them. That's the majority.
12:48		jihpringle joined #evergreen
12:59	Dyrcona	I have a batch of users at the very beginning that were all purged soon after the migration to Evergreen in 2012. They all have a row in reporter.report_folder. I deleted one on my test server and that seemed to work.
13:09	Dyrcona	Totally unrelated, but I swear I had saved some SQL to reset acq.edi_messages entries so that they would "resend," but can I find it today? Of course not.
13:18	Dyrcona	I thought that there was a resend status I could stick on the messages in the database, but I'm not seeing it in the code.
13:20	Dyrcona	Ah ha! It's retry.

Results for 2025-09-18

09:31		Dyrcona joined #evergreen
09:43	Dyrcona	So, this stuff that I was saying yesterday: http://irc.evergreen-ils.org/evergreen/2025-09-17#i_583595
09:45	Dyrcona	It turns out not to be the order of the unions clauses because I got different results with the exact same query. I blame the differences on running it on a replication database, which can be unreliable for large queries.
09:46	Dyrcona	When I run the queries with the unions in a different order on the production database, or a non-replicated test database, I get the same results every time.
09:50	Dyrcona	Also, how do people using the Internet in 2025 not recognize a captcha when they see one?
10:00	Dyrcona	If anyone is interested, my query to find deleted users with unpurged data finds 193,720 in production today. I could share the queries and/or the program to generate it later, probably via gist.
10:01	Bmagic_	Dyrcona++

Results for 2025-09-16

12:37	* csharp_	says the guy running PG 11 forevah
12:38	csharp_	planning to upgrade PG later in the fall
12:38	csharp_	not sure if 14 has any active orgs running it
12:39	Dyrcona	We're on Pg 16 in production. I have Pg 17 on some test servers. I've never used Pg 14 much except for a little light testing.
12:40	jeffdavis	We're on 14.
12:40	csharp_	yeah, seems like most sites kind of stayed on PG 10/11, then moved past 15 maybe, but that's anecdotal based on not much information
12:40	csharp_	ha! disproven out of the gate!

Results for 2025-09-15

09:57	* pinesol	brews and pours a pot of Chamomile Lemon (Sweet Meadows), and sends it sliding down the bar to Dyrcona (http://ratetea.com/tea/numi/chamomile-lemon/504/)
09:57	mmorgan1	Bmagic: pinesol should have known what you meant!
10:03	Bmagic	:)
10:31	Dyrcona	I have had a report that the background import feature (https://docs.evergreen-ils.org/docs/latest/cataloging/batch_importing_MARC.html#background_import) isn't working on our 3.15 test system.
10:32	Dyrcona	"[T]he load never completes and no queue is created if the option is selected." The user has the necessary permissions to use the feature.
10:35	Dyrcona	"A server side batch job will periodically check for background import requests." Is that ingest_ctl?
10:36	Dyrcona	Must be background_import_manager.pl.
11:39	pinesol	News from commits: LP2114920 package-lock.json follow-up <http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=f9caeef886e25e5a48e1314411cfa07d294aac96>
11:49	Bmagic	Dyrcona++ # I was grepping the repo for that script seeing where it was mentioned
11:51	Bmagic	Dyrcona: I know this doesn't help, but I did find the release notes on the script https://evergreen-ils.org/documentation/release/RELEASE_NOTES_3_13.html#_acquisitions_6
11:54	Dyrcona	Bmagic: Thanks! I just updated the crontab for opensrf on dev to run it every minute. We'll see if we can fix the import to get it working. The person who was testing last week is out today.
11:55	Dyrcona	My suspicion is that the wrong import type was selected. I think this is supposed to be an acq import.
11:55	Dyrcona	"But anyway..."
12:05		Christineb joined #evergreen

Results for 2025-09-10

13:28	mantis1	one question for those who use EDI - does anyone know how to reactiviate a PO?
13:32		jihpringle joined #evergreen
13:41	mantis1	we're also running into a problem where a file name is not producing, and based on the error message, this seems to be stemming from Evergreen and not the account setup or connection. Does anyone know how the filename is produced? That might give us a good start on where to look.
14:12	Dyrcona	Well, related to acquisitions, I want to ask if anyone is using the Angular acq and having trouble running out of acq drones? We've had 1 person doing some basic stuff in acq on our test system, and we've gotten no children available with 35 drones.
14:13	Dyrcona	mantis1: I can't answer your questions off the top of my head, but what does the error say?
14:17	sleary	Dyrcona bug 2003973 maybe?
14:17	pinesol	Launchpad bug 2003973 in Evergreen "Embedded copy attrs eats acq and actor drones" [High,New] https://launchpad.net/bugs/2003973
14:42	Bmagic	mantis1: you can issue a command on the command line on your utility server to debug a certain message or resend a certain message. I'll get the incantations, just a minute
14:42	Bmagic	edi_order_pusher.pl --teset-mode --po-id <POID>
14:43	Bmagic	uhhg
14:43	Bmagic	edi_order_pusher.pl --test-mode --po-id <POID>
14:43	csharp_	not teset mode! that's the worst mode!
14:43	Bmagic	:)
14:43	Bmagic	you can ask it to be more verbose to help diagnose:
14:46	Bmagic	then you can update the status like this: UPDATE acq.edi_message set status='retry' where id=<DISCOVERED ID FROM STEP ONE> ;
14:47	Bmagic	then you can run the order pusher again to resend just that one: edi_order_pusher.pl --po-id <POID> --verbose
14:49	Bmagic	it goes without saying: be careful with update queries on production. It's a good idea to use psql command line, and put the update inside of a transaction by using BEGIN; first
14:50	mantis1	Bmagic: ran the test mode pusher and got back a crazy looking string
14:50	Bmagic	lol, I see that teset poisoned my paste a bunch.
14:50	csharp_	mantis1: can you paste it somewhere like pastebin.com?
14:51	Bmagic	mantis1: that's the EDI message. If you were a computer it would make sense :) Suffice it to say:t that's expected and probably what the vendor needs in order to get the order started
14:55	Bmagic	try putting this at the beginning of your command: export FTP_PASSIVE=1 &&
14:56	mantis1	mmorgan: we were and confirmed it was what they need
14:56	csharp_	the line is eval { $filename = $self->_ftp->put(@{$self->{put_args}}) };
14:56	mantis1	Bmagic: for the test mode again?
14:56	csharp_	so at that point $self->_ftp is undefined
14:57	Bmagic	the whole thing would be "export FTP_PASSIVE=1 && edi_order_pusher.pl --po-id 67414"
14:57	Bmagic	It's not going to retry until you update the row in the DB as described above
15:03	mantis1	and the date updated to today
15:03	Bmagic	It sounds like you need to edit your cron jobs and make sure export FTP_PASSIVE=1 && is prefixed on your fetcher/pusher command
15:04	mantis1	we also don't have a filename producing in the GUI either
15:04	Bmagic	still seeing an error? In the logs? Was that error generated for your manual test?
15:04	mantis1	I'm seeing the error within the GUI
15:04	mantis1	under EDI Messages
15:05	mantis1	it's updated with the retry status though

Results for 2025-09-09

15:02	terranm	#info terranm = Terran McCanna, PINES
15:02	shulabramble	if so, it's going under New Business.
15:02	abneiman	I did add something to the agenda, but it was not my existential crisis
15:02	shulabramble	abneiman++ thanks for the heads up
15:03	shulabramble	latecomers can continue introductions
15:03	shulabramble	#topic Action Items from Last Meeting
15:03	shulabramble	#topic sleary and sandbergja will report further progress on test writing wiki pages next month
15:04	sleary	you may have noticed that we've been adding custom lint rules (and I have one more in the works)
15:04	sleary	info on lint: https://wiki.evergreen-ils.org/doku.php?id=dev:contributing:qa#angular_lint
15:04	sleary	there's a link there to a commit that can be checked out to use as a template for writing your own rules
15:04	sandbergja	I also have a question for the group: we used to have a twice-daily update from the test-runner about whether tests were passing or failing. That came to this IRC channel.
15:04	shulabramble	sleary++
15:05	sandbergja	would anybody find that (or something similar) useful?
15:06	* mmorgan	would say Yes.
15:07	shulabramble	sandbergja++
15:08	mmorgan	sandbergja++
15:08	mmorgan	sleary++
15:09	shulabramble	do y'all want to report on this again next month, or do you feel like the test-writing wiki page is good as of now?
15:09	sandbergja	I could go either way
15:09	sandbergja	sleary?
15:09	sleary	I think we will have a discussion item later about using git hooks, but that can be a separate agenda item
15:24	shulabramble	sleary++
15:24	Bmagic	signoff rather
15:25	shulabramble	#topic there are several high priority bugs with pull requests that need review; https://wiki.evergreen-ils.org/doku.php?id=dev:code_review has the roundup as well as some filtered Launchpad links.
15:26	sleary	I'm sure a bunch of those are OPAC accessibility bugs. I'll be happy to answer any questions about how to test those once bug 2122448 is behind us.
15:26	pinesol	Launchpad bug 2122448 in Evergreen "Clearing the shelving location in the holdings editor crashes the browser" [Critical,Confirmed] https://launchpad.net/bugs/2122448 - Assigned to Stephanie Leary (stephanieleary)
15:26	shulabramble	sleary++
15:27	shulabramble	If there's no more new business, then --

Results for 2025-09-08

14:58	csharp_	(I think I reversed those - j is down, I think)
14:59	csharp_	they have been absorbed into the csharpmatrix
15:07	Dyrcona	Probably the same as vi(m).
15:08	Dyrcona	So, we're having an issue with Angular print templates on our test system, and I wonder what would cause this: eg.print.template.error {name: 'hold_pull_list', id: undefined}
15:08	Dyrcona	I'm assuming no data coming back. A busted IDL would probably be visible elsewhere.
15:09	csharp_	Dyrcona: I see that when something perl-ish is not compiling
15:10	Dyrcona	OK. I'll check for syntax errors.

Results for 2025-08-28

09:36	* Dyrcona	gives it a try with snakeoil.pem.
10:30	pinesol	News from commits: LP#2096672: Simple Reports template folder <http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=f8113a263db93843466d06e27c1b920d08817f30>
11:01		sandbergja joined #evergreen
11:05	Dyrcona	Whee! Got postgres_openssl to work with rust at least for my test database.
11:17	Dyrcona	TLS doesn't work with ssh tunnels. I get a hostname mismatch with the certificate. That's good to know, but TLS should also not be needed with a ssh tunnel. :)
11:23	Dyrcona	Added an option to set sslmode and I can connect over a ssh tunnel by setting it to "disable." :)
11:26	Dyrcona	Rust is OK as far as languages go. :)
15:23	Dyrcona	ok, gonna be more "rustic" this time around. less perly.
15:29		mantis1 left #evergreen
15:31	pinesol	News from commits: Docs: Resolves LP#2121614 <http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=4d508431a6b10c00c007af3ef09c3c6d45c9328e>
16:11	Bmagic	eeevil++ # I'll give that branch some testing
16:16	eeevil	Bmagic: cool, thanks. note: the way the message bus is set up has changed significantly. please take a look at the new stuff in osrf_control, and note too the new way that the redis default user password is set up in /etc/redis/redis.conf via the "requirepass" setting (see: `osrf_control --help\|less` for info, along with the commit message and docs changes)
16:45	Bmagic	eeevil: thanks for pointing that out, will do!
17:00		mmorgan left #evergreen

Results for 2025-08-20

08:35		mmorgan joined #evergreen
09:06		Dyrcona joined #evergreen
10:19		sandbergja joined #evergreen
10:22	sandbergja	Heya! If anybody is looking for a quick pull request to review and/or wants to learn more about Perl tests, I would appreciate a review on bug 2121068
10:22	pinesol	Launchpad bug 2121068 in Evergreen "Get staged patrons (aka patron self-registration) under test" [Undecided,New] https://launchpad.net/bugs/2121068
12:00		jihpringle joined #evergreen
14:05		jihpringle joined #evergreen
14:54	Dyrcona	berick: Do you have a recommendation for a crate to connect to PostgreSQL from Rust?

Results for 2025-08-14

12:14	Bmagic	mmorgan ^ sorry for the late reply
12:15	jeffdavis	Any relation to this bug? https://bugs.launchpad.net/evergreen/+bug/2081327
12:15	pinesol	Launchpad bug 2081327 in Evergreen "Angular Circulation cannot save a patron" [High,Confirmed]
12:15	mmorgan	Bmagic: no issues saving a new patron, or editing a patron on main ca. 2 weeks ago (plus a few patches for testing)
12:15	mmorgan	Angularjs
12:18	Bmagic	it might be, I'll have to dig. I'll reply back
12:18	Bmagic	mmorgan++
12:46	Dyrcona	@coin

Results for 2025-08-12

15:04	shulabramble	#topic sleary and sandbergja will report further progress on test writing wiki pages next month
15:04	sandbergja	There's this puppy, feedback very welcome: https://wiki.evergreen-ils.org/doku.php?id=qa:preventing_regressions
15:05	shulabramble	sandbergja++
15:05	sleary	sandbergja has made great progress on improving the tests themselves; see bugs.launchpad.net/evergreen/+bugs?field.searchtext=&orderby=-date_last_updated
15:05	shulabramble	#info feedback appreciated on https://wiki.evergreen-ils.org/doku.php?id=qa:preventing_regressions
15:05	sleary	... paste fail, sorry, that's http://bugs.launchpad.net/evergreen/+bugs?field.searchtext=&orderby=-date_last_updated
15:06	sleary	we are working on more custom lint rules, and will update the wiki accordingly
15:42	* mmorgan	kicks a tumbleweed
16:58		berick joined #evergreen
17:02		mmorgan left #evergreen
17:57	pinesol	News from commits: lp2120490: Add a custom eslint rule to catch untranslatable column labels <http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=27c27f2753aef09be27fa7775e1a58324973f0f2>
23:27	pinesol	News from commits: LP2116978: resolve angular unit test runtime error <http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=741c1ad6647ffbc73ea752906b8f404adbe3d662>
23:27	pinesol	News from commits: LP#2111291 follow-up: ng lint fixes <http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=e52f2611927bd68f277569eb32f10d7d1f3ad588>