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 149 150

Results for 2024-12-10

15:07	shulabramble	Okay, then
15:07	shulabramble	#action gmcharlt - create a Git commit message type and update bug 2051946
15:07	pinesol	Launchpad bug 2051946 in Evergreen "institute a Git commit message template" [Wishlist,New] https://launchpad.net/bugs/2051946 - Assigned to Galen Charlton (gmc)
15:07	shulabramble	#action waiting on gmcharlt for access to POEditor for git integration
15:08	shulabramble	#info sleary and sandbergja will report progress on test writing wiki pages next month
15:08	sleary	I've been out sick; please carry forward
15:08	sleary	(sorry sandbergja!)
15:08	shulabramble	Aww! Hope you're feeling better.
15:08	sandbergja	no problem!
15:08	redavis	Just throwing the agenda here for new people - https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2024-12-10
15:09	sandbergja	one note: outside of what sleary and I were working on, I figured out how to run perl unit tests with the perl debugger
15:09	shulabramble	redavis++ thanks, I've had an interesting day and that slipped my mind.
15:09	sandbergja	and added my notes here in case they are useful for anyone: https://wiki.evergreen-ils.org/doku.php?id=dev:testing:debugging_perl_unit_tests
15:09	shulabramble	sandbergja++
15:09	sleary	sandbergja++
15:09	berick	sandbergja++
15:12	sleary	whoops! on it
15:13	shulabramble	#action sleary will make a new LP tag denoting bugs that involve string changes
15:13	redavis	sleary++
15:13	shulabramble	#topic revisit feasibility of automated testing for string changes
15:13	shulabramble	berick++ sleary++
15:15	shulabramble	anything on this?
15:16	abneiman	tbh I don't recall whose action item that is
15:16	shulabramble	neither do i.
15:16		ajarterburn joined #evergreen
15:21	abneiman	shulabramble: yes I have your emial, thanks
15:21	shulabramble	zipping through this agenda at top speed.
15:22	Dyrcona	Lp 2055796
15:22	pinesol	Launchpad bug 2055796 in Evergreen "Have github actions run pgtap tests for us" [Medium,Fix committed] https://launchpad.net/bugs/2055796
15:22	Dyrcona	That's done.
15:22	berick	yeah
15:23	shulabramble	dyrcona++ berick++
15:37	redavis	phasefx++
15:37	sandbergja	phasefx++
15:38	phasefx	Hand holding, pep talk, chocolate...
15:38	sandbergja	I can build and test a tarball
15:38	shulabramble	sandbergja++
15:38	* mmorgan	can probably help with point releases next week
15:38	redavis	I'll call a meeting for the point releases once some more spots are filled out. So, email imminent today or tomorrow for that.

Results for 2024-12-09

11:07	Dyrcona	berick: Is that in your rust repo on GH?
11:07	berick	if it crashes, there will be a file + line number + crash message in the kernel logs. none of this C segfault hunting madness.
11:08	berick	Dyrcona: yes
11:08	Dyrcona	I'll see about testing it on of my vms. I'll put it on the one that I plan to use with a test Aspen instance. That should give it a work out.
11:09	berick	Dyrcona++
11:10	Bmagic	berick++ # This is production, albeit a single cronjob forked off to it's own machine for analyzing. I'm willing to use it as a test bed to hunt down this bug. Because, IMO, the only real way to do it is on production
11:13	Dyrcona	I think I'll get Aspen hooked up, first, and try the Rust router later. I'm already using Redis on that vm. I still have to figure out how to hook Aspen up to Evergreen and get the indexer going. I'll probably pop into Slack to ask questions.
11:15	* Dyrcona	mumbles Right. Lp bug about camera not working...
11:17	Dyrcona	Wait a minute... Maybe I read that update wrong and it autoremoved the drivers?

Results for 2024-12-05

10:14	Dyrcona	I don't think setting that to 0 was ever meant to be fine. Looks like an unreported bug was fixed.
10:22		stephengwills joined #evergreen
10:25	mmorgan	Bmagic++
10:48	Dyrcona	Well, I have Aspen running, but it's not talking to a test Evergreen instance, yet. I suppose I could get answers in Slack, but I'll peruse the docs and the code first.
10:51		kworstell-isl joined #evergreen
11:26	pinesol	News from commits: LP#2089419: fix parsing of offset/limit in C-based DB search methods <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=0458ae01ef6a84734efb7232bc1cdaf479dd3be8>
11:53		jihpringle joined #evergreen
12:14	jeffdavis	If I'm reading Open-ILS/src/c-apps/oils_auth_internal.c correctly, seems like 0 is the default timeout value if auth.staff_timeout is unset.
12:14	jeffdavis	Does the login issue occur on a 3.14 system where auth.staff_timeout is unset?
12:15	Bmagic	here's another finding: if I was using a browser that already had a workstation registered, I could login! (even with the timeout setting set to 0) - but if I needed to to the workstation registration dance, I would be in a login loop
12:15	Bmagic	jeffdavis: I didn't test that
12:16	Bmagic	I'll try it on a test machine
12:16	mmorgan	jeffdavis: I found that the issue does NOT happen when auth.staff_timeout is unset, but it would be great to see confirmation.
12:17	Bmagic	mmorgan jeffdavis: confirmed, no value (no row) in actor.org_unit_setting, I can still login
12:18	Dyrcona	jeffdavis: What branch are you looking at/
12:19	Bmagic	FYI: I'm on main OpenSRF with the redis stuff merged
12:19		jihpringle joined #evergreen
12:19	Bmagic	however, I've also tested on opensrf 3.3.2 (ejabberd) and I had the same problem/solution with the setting
12:19	* mmorgan	tested on 3.14.0
12:20	Bmagic	mmorgan: can you confirm that a zero setting will result in the login loop?
12:21	mmorgan	Bmagic: Yes, I did observe that on 3.14.0, so can confirm.
12:21	Bmagic	and! you have to be sure you're not using a browser that has the workstation registered
12:36	Dyrcona	0 seems like a bad value for an infinite time out when the setting is meant to be an interval. -1 is probably better.
12:36	Bmagic	thinking about it more, the magic trick was probably having "route to" in the query string on the login page. Where the route to was an eg page and* the login page was eg
12:37	Dyrcona	I suspect you're overthinking it, and the problem is likely simpler than that. some eg2 code is getting the time out in seconds and treating 0 as 0, not as infinity.
12:38	Bmagic	I get it, yes, eg2 JS is treating 0 differently than eg. I understand that. I'm pontificating and going over in my head the various ways I was able to overcome the issue during testing. And I think it was when I was able to never touch eg2 during the auth process
12:38	Dyrcona	OK>
12:41	Dyrcona	The core eg2 auth service looks like it gets the timeout from the backend.
12:43	Dyrcona	Staff component looks like it uses the auth service.
15:13	Dyrcona	pinesol: No, but I did try turning it off and back on again.
15:13	pinesol	Dyrcona: http://images.cryhavok.org/d/1291-1/Computer+Rage.gif
15:13	Dyrcona	Yeah, pretty much.
15:14	Dyrcona	Oh, right. I was in the middle of installing some backports on a 3.7.4 test installation.
15:15	Dyrcona	I had just run the 'chown' command and when it seemed to take too long, that's when I knew something was up. :)
15:23	Dyrcona	Sometimes, you just gotta run desktop-clear....
15:30		mantis left #evergreen

Results for 2024-12-03

10:40	Bmagic	I have a sql script that will do the trick, but I've never used it on production
10:41	Bmagic	originally from Dyrcona, tweaked by me: https://github.com/mcoia/mobius_evergreen/blob/master/Random/real_bib_delete.sql
10:41	Bmagic	it's dated, so, there might be newer links that it needs to know about
10:46	stephengwills	Bmagic++. Drycona++. I see what I can do with it on a test db. I just moved us up to 3.14 so i’m sure it will want something new. thanks.
10:58		kmlussier left #evergreen
11:00		sandbergja joined #evergreen
11:50		jihpringle joined #evergreen

Results for 2024-12-02

10:59	csharp_	redis and sip2-mediator and reports oh my!
11:00	csharp_	"wellsir..." <slaps the roof of EG 3.12> "this Evergreen version has served us very well"
11:01	berick	and we (kcls) have moved on a bit from the stock EG mediator code, which would put you on the bleeding edge csharp_ fyi
11:02	csharp_	I'll keep SIPServer around to crank up if needed
11:03	csharp_	also, willing to test bleeding edge at this stage of our upgrade (targeted for mid February)
11:07	berick	in particular, the rust variant forgoes HTTP communication, a key facet of the original design, and ops for a more evergreen-centric opensrf client approach (i.e. direct redis communication). in the end, it's just more efficient and in some ways more practical.
11:12	berick	that is to say, though the http approach has its own benefits, there are no examples of it in use in the wild.
11:12	berick	that i'm aware of
11:27	Bmagic	csharp_: I feel your pain on the bot battle
11:34		Dyrcona joined #evergreen
11:37	mmorgan	berick: jeff: Looking at bug 2076921. jeff's testing looks favorable, any reason not to roll it out? Our pc support tech is seeing changes being rolled out that disable the current extension.
11:37	pinesol	Launchpad bug 2076921 in Evergreen "Hatch: Chrome Extension Requires Redevelopment" [High,Confirmed] https://launchpad.net/bugs/2076921 - Assigned to Jeff Godin (jgodin)
11:40	berick	mmorgan: i see no reason to delay any longer
11:41		sandbergja joined #evergreen

Results for 2024-11-27

10:13	Dyrcona	Looks a bit rusty to me....
10:14	Dyrcona	Or is that typescript? Too many languages, I can't tell.
10:14	berick	yeah typescript, but to be fair, sometimes my typescript is rusty
10:49	Dyrcona	Hm. I suppose I could start over on my Aspen test system installation. It has only been on hold since September.
10:49	Dyrcona	Sorry. Just "thinking out loud."
10:55		kworstell_isl joined #evergreen
11:02	berick	@quote add <slashdot> The first 90% of a project takes 90% of the time, the last 10% takes the other 90% of the time.

Results for 2024-11-25

14:45	abowling	Use of uninitialized value $@ in concatenation (.) or string at /usr/local/share/perl/5.30.0/OpenSRF/Transport/SlimJabber/Client.pm line 162.
14:45	abowling	Exception: OpenSRF::EX::Jabber 2024-11-25T11:44:51 OpenSRF::Transport::SlimJabber::Client /usr/local/share/perl/5.30.0/OpenSRF/Transport/SlimJabber/Client.pm:162 Jabber Exception: Could not authenticate with Jabber server:
14:47		jihpringle joined #evergreen
15:29	pinesol	News from commits: LP2067191: Add documentation and tests for visibility attributes <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=9c78bbc70563a64cc26e99d198fb0355f3afd7a7>
15:29	pinesol	News from commits: LP2062944: Running angular tests with code coverage should not error <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=6963fb3afdb33fb9bd7d6772073171f75f4ecb18>
15:59	pinesol	News from commits: lp2085970: fix alignment of Filter value input in Reports editor <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=15f3d3c8f564f79a5832e163eb2b1feb899d5215>
16:17	sandbergja	Bmagic: off the top of your head, do you know if there's a way to recompile and reinstall the Evergreen C code from the dev container? `make install` fails (I think from the symlinks?), and I don't know another way to update the C code.
16:19	sandbergja	Oh, I think I can make install from within the c-apps directory, then kick off a restart?
16:21	sandbergja	ha! that did the trick

Results for 2024-11-21

12:02	Bmagic	ok, I'm game
12:03	berick	oh right, we can attach to running processes...
12:03	berick	so just restart everything like normal
12:03	Bmagic	I've isolated the issue to this machine by trial and error. The "main" util server isn't having issues, now that I've divided the crons up. And this one cron seems to be the one that consistently causes the segfault. In other words: we can use this as a test bed.
12:04	Bmagic	ok, I'm leaving the machine alive, and restarting everything like normal
12:06	berick	once it's up, get the PIDs of the 2 router proceses, open 2 terminals and run this for each pid: gdb /openils/bin/opensrf_router <pid>
12:06	berick	i /think/ that will do it
12:31	berick	oh, you mean the binary..
12:31	berick	maybe?
12:31	Bmagic	I'll try
12:32	Bmagic	that would be nice, so I'm testing the same situation where I've had this segfault a few times
12:34	berick	Bmagic: also https://stackoverflow.com/questions/21395106/how-can-i-gdb-attach-to-a-process-running-in-a-docker-container
12:35	berick	hm, don't see how that's really different from what you already tried
12:35	Bmagic	lxc-attach is the magic

Results for 2024-11-20

10:32	csharp_	no, it should be considered the new CentOS
10:32	Dyrcona	OK. I haven't been keeping up with the RedHats....
10:32	Dyrcona	I thought it was the new Fedora.
10:33	csharp_	Fedora's still Fedora - I may try to support it too - but Fedora is the testing ground for RHEL/Rocky
10:34	csharp_	like a more stable Debian sid
10:34	Dyrcona	Yeah. I would not object to adding Rocky support, but I'm a bit leery of adding Fedora install support officially.
10:34	Dyrcona	I mean, I don't want to support it. :)
10:34	csharp_	agreed - I can't imagine anyone running Fedora in production given how quickly the release cycles run
17:02	mantis	mmorgan++
17:03		mantis left #evergreen
17:04	Dyrcona	mmorgan++ redavis++ csharp_++
17:06	csharp_	starting my test of 3.13
17:06	mmorgan	3.12.9 tarball is set also, files shared.
17:11		mmorgan left #evergreen
17:31	* Dyrcona	signs out for now.

Results for 2024-11-19

15:56	Bmagic	ok, I see. Looking at a fresh installation of OpenSRF (main) - comes packed with that line CONFIG SET save ""
16:04	Dyrcona	berick++ Bmagic++
16:04	Dyrcona	I let do-release-upgrade overwrite /etc/redis.conf, so wondered when I didn't see anything in the README about it.
16:06	Dyrcona	After doing do-release-upgrade, I `rm -rf /openils/*` and reinstalled OpenSRF main and my test branch of Evergreen base on 3.14.0.
16:07	Dyrcona	It's working so far.
16:12	* Dyrcona	is also ready for translations and release building tomorrow.
16:13	redavis	Dyrcona++
16:25	redavis	Bmagic, yep. If you can. No pressure if you can't though.
16:25	Bmagic	:) I'd love to
16:25	redavis	Rock on. Thank you.
16:28	eeevil	re the reporter, they last "one more failure" test was not related to the problem at hand, but it's also (as abneiman says) fixed, pending testing. LP may not have sent my email to that effect yet
16:29	Dyrcona	eeevil: I got the email with your comment. I'm Ok with that going in if someone signs off tonight.
16:30	redavis	eeevil, I'm just refreshing for comments anyway :-). I think we're waiting on Llewelyn for the actual ticket. Is there another ticket for the "one more failure"?
16:30	redavis	Oh, eeevil, n/m my question. I see the answer in your comment.
16:30	Bmagic	I was about to say
16:30	Dyrcona	:)
16:31	Bmagic	it seems like we should wait until this tree.js branch receives it's additional commit, and maybe Llewellyn can double check it on his test machine, the same as he did with the first commit
16:33	Dyrcona	My answer is it depends on how long we have to wait.
16:33	Dyrcona	I would like to get started tomorrow morning.
16:34	Bmagic	agreed
16:44	Bmagic	that's fine, it means we'll wait
16:54	* Dyrcona	signs out for the day.
17:01		mmorgan left #evergreen
17:01	eeevil	Bmagic: ok! looking at the clock, I'm going to suggest that I push a branch with just (what we've been calling) the followup commit -- it's separate, but discovered during tree.ts testing -- and if you get the signoffs you want/need on the current branch, I recommend we proceed with merging that. then, if you also like the cut of the new branch's jib, and feel like pulling that in, I'm comfortable with it going in quickly. if it has to sit, I won't
17:01	eeevil	cry too hard.
17:02	Bmagic	ok then, we have something we can test?
17:03	redavis	Bmagic, I think it's the current branch listed at https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/lp-2087562-dynamic-tree-node-parent-links
17:03	Bmagic	that's what I'm looking at. So, roll with that for now, and we'll catch the rest next cycle, is that right?
17:04	eeevil	to that end, here's the followup commit on a branch by itself: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/fix-virtual-field-link-joins-in-upgraded-templates
17:05	Bmagic	eeevil: thanks! And you're not comfortable with that second branch just yet?
17:05	eeevil	Bmagic: next cycle, or this if it looks sane to you. I'm mainly trying to get it out there for others to test/use asap
17:05	eeevil	oh, /I/ am comfortable, but it's not been tested by not-mike.
17:05	Bmagic	understandable
17:06	redavis	How about this, maybe Llewellyn signs off on the first branch tonight.. but probably not. Even if he doesn't, we can get to testing the second branch and have both ready for next month...and for anyone that wants to apply in the meantime.
17:06	Bmagic	well, like you said, it's three lines. Seems like we should be able to test that with some humans. Sure wish we had some e2e tests to do the job for us
17:07	* eeevil	imagines the selenium script that would drive the reporter to test this ... shudders, passes out
17:07	redavis	LOL!!!
17:08	Bmagic	yeah, it'd be one heck of a test
17:09	eeevil	the test is ... clone a report that uses a might_have link on a virtual idl field and make sure it uses the left-side pkey column instead of the virtual column name in the join
17:09	abneiman	I'd be delighted to have the first one go in this evening, for point releases this month
17:09	Bmagic	it's radio silience over there at Cardinal. Maybe they'll get back with me before the "morning"
17:10	abneiman	but! I've put my finger(s) on the scale(s) too many times on this particular issue so with that imma head out and go swimmin
17:13	redavis	lol, or close to the Y
17:13	redavis	also, rock on for the first branch. So, unless anyone wants to stop me (please stop me), I'm going to open a new LP ticket for the second branch to make sure it doesn't get neglected.
17:15	eeevil	redavis: this is me, not stopping you! :)
17:15	Bmagic	yeah, that's a sane course of action I think. Considering the test is nuanced
17:15	eeevil	redavis++
17:15	redavis	Excellent! This is also you not smellin' a burning clutch.
17:15	Bmagic	digging up an old template that " uses a might_have link on a virtual idl field and make sure it uses the left-side pkey column instead of the virtual column name in the join"

Results for 2024-11-18

11:19	csharp_	ick
11:19	csharp_	pinesol: be better
11:19	pinesol	csharp_: Have you tried taking it apart and putting it back together again?
11:19	Dyrcona	berick: I'm signing off on your commits for Lp 2083856 and looking into the test failure. I swear it did not do that last Wednesday. Also, I swear I added all of the prerequisites, but maybe I didn't or switched branches and lost 'em?
11:19	pinesol	Launchpad bug 2083856 in Evergreen "Add Support for PostgreSQL 17" [Wishlist,Confirmed] https://launchpad.net/bugs/2083856 - Assigned to Jason Stephenson (jstephenson)
11:20	csharp_	berick++ # don't blame me, I voted for Kodos
11:20	berick	Dyrcona: cool, yeah, i didn't get a chance to follow up on the failures.
11:21		Christineb joined #evergreen
11:28	Dyrcona	berick: It looks like the same output with the 100 and 600 tags in opposite order.
11:29	Dyrcona	I'm going to reverse them in one of the copies and see what diff says after.
11:31	Dyrcona	Yeah, that's it. If I modify a copy of what we're looking for from the test to have the 100 before the 600, and the 905 (to put 110 before 600), the output is the same.
11:32	Dyrcona	I wonder if we have been depending on undefined behavior again?
11:32	Dyrcona	Bleh that 110 should be 100... Anyway....
11:33	Dyrcona	I suppose I can make the test check the Pg version and do something different if it 17+. It wouldn't be the first time we've done that.
11:35	Dyrcona	I wonder though if the auth overlay function needs fixing for more predictable output?
11:38	pinesol	News from commits: LP#1721026: Default owner for copy tags and types <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=79980aff138c39b6056f8c0795fa308a8293fa79>
11:42	csharp_	oh, I didn't realize the next Ubuntu release is "noble" - that kind of synergy doesn't happen often, does it NOBLE?
11:44	Dyrcona	I name my test vms for the release codenames: bullseye, bookworm, jammy, noble, etc. So, I have a test vm named noble.cwmars.org. :)
11:45	csharp_	SO CONFUSING
11:45	Dyrcona	I suppose I could have used the animal name: numbat.cwmars.org....
11:47	* mmorgan	wants to say it's cool, but agrees with csharp_ SO CONFUSING!
13:29	abowling	Dyrcona: It's what csharp_ referenced earlier; my 5.26.1 folder has the dependencies, but not the 5.30.0 folder
13:30	Dyrcona	Well, 5.26.1 should still be in the Perl path... You could try csharp_'s suggestion of deleting the 5.26.1 stuff and then reinstalling the prerequisites.
13:31		jihpringle joined #evergreen
13:36	Dyrcona	heh.. The test still fails......
13:38	Bmagic	tests++
13:48	Dyrcona	extraneous space from where I inserted the new output.
13:50	Dyrcona	The db test passes on pg 17. I'll test on an earlier pg release before committing the changes.
13:50	Dyrcona	I mean committing them locally and pushing to a working branch.
14:20		BDorsey joined #evergreen
14:34		collum joined #evergreen

Results for 2024-11-15

09:34		mdriscoll joined #evergreen
10:58		Christineb joined #evergreen
11:03	* Dyrcona	wonders if doing the translations bits for different releases on the same VM will cause problems. Probably not.
11:06	* Dyrcona	does release building on a dedicated vm, then tests it elsewhere.
11:12	jeffdavis	We've got a recurring situation where ill-behaved webcrawlers doing ~200 qtype=subject queries per minute can cause OOM problems.
11:12	jeffdavis	We're playing whack-a-mole with IP addresses since the crawlers don't properly identify themselves.
11:12	jeffdavis	It would be nice if EG handled that volume of requests more gracefully.

Results for 2024-11-14

09:40	sleary	I can't get it installed on 15 though; will try again on 18
09:40		terranm joined #evergreen
09:40	terranm	https://wiki.evergreen-ils.org/doku.php?id=evergreen-reports:rig
10:10	berick	csharp_: fyi fixed ansible on 24.04 using include_tasks: doing final tests now
10:10	sleary	scottangel: https://css-tricks.com/come-to-the-light-dark-side/
10:13		dguarrac joined #evergreen
10:18	terranm	My Hack-a-way update: KPAC overhaul is still in very early stages, but it now has the beginning of an admin interface to create/update the custom categories on the fly - no more XML config file! https://terran-main.gapines.org/eg/kpac/home

Results for 2024-11-13

09:17		sandbergja joined #evergreen
09:18	Bmagic	Dyrcona++
09:19	Bmagic	berick: I think it's a good thing (non-global).
09:23	berick	yay, github pgtap tests already paying off (working on pg17 branch)
09:25		mantis joined #evergreen
09:25		kmlussier joined #evergreen
09:27	kmlussier	Zoom link for the hack-a-way is https://us02web.zoom.us/j/88077861312?pwd=diZubjjUZTrVMs6PLDYRO5Rfxyn3Ao.1
10:21	Dyrcona	abneiman++
10:23	eeevil	2083039
10:33		smorrison joined #evergreen
11:03	mantis	hey all we are doing some open testing for Ringcentral which will be the conference software platform we'll use for the 2025 conference. If anyone has some time to spare testing, please let me know and I can send a magic link invite
11:03	mantis	or you can register here: https://events.ringcentral.com/events/eg-committee-test-event
11:11		redavis joined #evergreen
11:11	sleary	I am hearing that not everyone here is familiar with the falsehoods programmers believe about names: https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/ and the many other permutations https://github.com/kdeldycke/awesome-falsehood
11:18		Christineb joined #evergreen

Results for 2024-11-12

14:45	shulabramble	15 minute warning to the dev meeting
14:46		sandbergja joined #evergreen
14:50	shulabramble	10 minutes to dev meeting
14:52	berick	jeff++ # sigh i just noticed your Hatch test notes in LP.
14:52	berick	accidentally marked that email read
14:55	shulabramble	5 minutes to dev meeting!
14:56		smayo joined #evergreen
14:58	jeff	berick++ glad you saw it!
15:08	shulabramble	#topic waiting on gmcharlt for access to POEditor for git integration
15:08	shulabramble	And I assume the same for this unless there's any discussion to be had?
15:08	abneiman	I will ping gmcharlt in our channel about that 2nd one since Dyrcona is awaiting access
15:09	shulabramble	abneiman++
15:09	shulabramble	#action waiting on gmcharlt for access to POEditor for git integration
15:09	shulabramble	#topic sleary and sandbergja will report progress on test writing wiki pages next month / at hackaway
15:10		smorrison joined #evergreen
15:10	sandbergja	ooh! We did some work in the wiki. We haven't had a chance to coordinate something for the hackaway
15:10	sleary	I have not made much progress on my part of that, so let's kick that to next month, please!
15:10	abneiman	sandbergja++ sleary++
15:10	shulabramble	sandbergja++ sleary++ got it
15:11	shulabramble	and a belated eeevil++
15:11	shulabramble	#action sleary and sandbergja will report progress on test writing wiki pages next month / at hackaway
15:11	sandbergja	very happy if people discuss tests at hackaway though :-D
15:11	shulabramble	#topic bug 2076921 expected to get more testing and merged, and beta uploaded to store
15:11	pinesol	Launchpad bug 2076921 in Evergreen "Hatch: Chrome Extension Requires Redevelopment" [High,Confirmed] https://launchpad.net/bugs/2076921 - Assigned to Jeff Godin (jgodin)
15:12	berick	jeff did some testing, many thanks
15:12	shulabramble	jeff++
15:12	abneiman	jeff++
15:12	sandbergja	jeff++
15:23	sandbergja	sleary++
15:24	shulabramble	#action sleary will make a new LP tag denoting bugs that involve string changes
15:24	shulabramble	sleary++
15:24	jeffdavis	Do we have automated testing (or some such thing) to flag when a string has been added/changed?
15:24	abneiman	sleary++
15:24	shulabramble	jeffdavis++ for the question
15:25	abneiman	jeffdavis: I do not know - sandbergja? sleary?
15:26	sandbergja	not that it couldn't be done!
15:27	sandbergja	on the angular side it might be a bit easier
15:28	shulabramble	anyone want to look into the feasibility of that probable regex festival?
15:28	jeff	it's not a boring problem. what output/actions would be useful if we had such testing/monitoring?
15:29	shulabramble	(to be clear, I love regex problems, so that's a good thing)
15:29	abneiman	@band add Probably Regex Festival
15:29	pinesol	abneiman: Band 'Probably Regex Festival' added to list
15:34	shulabramble	jeff++ abneiman++ jihpringle++
15:34	shulabramble	phasefx++
15:35	abneiman	jihpringle++
15:35	shulabramble	#action revisit feasibility of automated testing for string changes
15:36	shulabramble	alrighty, moving on
15:36	shulabramble	#topic Updates
15:36	shulabramble	There's nothing on the agenda for these, but I know we had an Evergreen update since the last meeting.
15:37	shulabramble	so 3.14 release team++
15:37	Bmagic	+1
15:37	phasefx	release_team++
15:38	shulabramble	is it time to assemble a 3.15 release team?
16:12	shulabramble	I own four cats. I have experience.
16:12	scottangel	shulabramble++
16:12	shulabramble	#topic Okay to merge LP 2055796? berick mentioned "unclear if there's any additional decision processes re: adding github actions"
16:12	pinesol	Launchpad bug 2055796 in Evergreen "Have github actions run pgtap tests for us" [Undecided,Confirmed] https://launchpad.net/bugs/2055796 - Assigned to Bill Erickson (berick)
16:12	smayo	shulabramble++
16:12	shulabramble	sandbergja?
16:12	sandbergja	yes, pasting some text
16:13	sandbergja	The back story: we used to have our tests automatically running regularly (2x/day?), and alerting IRC if there was a test failure. This has not worked for some time, so currently we don't find out about those bugs we've added to Evergreen until somebody runs the tests manually (which may be a while later). Github offers free infrastructure for running tests, so a year ago, we decided to explore
16:13	sandbergja	I have a pull request to get our pgtap (database) tests running automatically on github actions, berick has reviewed it but mentioned "unclear if there's any additional decision processes re: adding github actions".
16:13	sandbergja	I figured this was the place to ask. :-)
16:13	phasefx	testing would be easier with simpler installations... runs away
16:13	sandbergja	phasefx++
16:14	sandbergja	100% agree
16:14	redavis	phasefx++ #also hahahahahah
16:14	sandbergja	trying to install an eg-compatible ejabberd in github actions has me totally stumped
16:14	sandbergja	so I can't wait for redis to be merged
16:14	sandbergja	but I'm getting off topic hahaha
16:15	berick	any objections to running pgtap tests via github actions? going once?
16:15	Bmagic	berick says "strong +1 to merging"
16:15	Bmagic	no objections at all
16:15	phasefx	no objections to anyone maintaining testing infrastructure
16:16	abneiman	tests++
16:16	berick	didn't think so, but it's kind of new, so..
16:16	berick	sandbergja++
16:16	shulabramble	sandbergja++
16:17	redavis	berick++
16:18	shulabramble	berick++
16:18	phasefx	berick: just main?
16:18	Bmagic	I find it interesting that the server upon which the test run, presumabely don't have the perl dependencies? But that's fine for the scope of the tests?
16:18	* phasefx	belatedly pulls up the ticket
16:19	shulabramble	#action it is okay to merge lp2055796, sandberg and berick will attend
16:19	shulabramble	wrangling before we go a full half hour over
17:40	pinesol	Launchpad bug 2032835 in OpenSRF "Discussion: Merge OpenSRF Into Evergreen?" [Wishlist,New] https://launchpad.net/bugs/2032835
17:41	sandbergja	+1
17:42	Bmagic	+1
17:48	pinesol	News from commits: LP2055796: run pgtap tests on Github Actions <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=7e83c5de8ca1e7530853878bc7562d961ce348c4>
17:50	Bmagic	sandbergja++ berick++
18:08		phasefx joined #evergreen
18:08		abneiman joined #evergreen

Results for 2024-11-01

16:56	dashohoxha	- https://gitlab.com/docker-scripts/dev/evergreen/-/blob/redis/Dockerfile?ref_type=heads
16:56	dashohoxha	- https://gitlab.com/docker-scripts/dev/evergreen/-/blob/redis/inject/setup.sh?ref_type=heads
16:56	dashohoxha	If someone would like to have a look, you can access it here:
16:56	dashohoxha	- https://tmate.io/t/ut7yN3C56e47rpZvMraHSWWNG
17:00	dashohoxha	On the other hand, there is some progress with the stable release. I don't know how it is fixed, but the login test now is working (gives SUCCESS), although there are still some other problems.
17:00	dashohoxha	The installation scripts are these:
17:00	dashohoxha	- https://gitlab.com/docker-scripts/dev/evergreen/-/blob/main/Dockerfile
17:00	dashohoxha	- https://gitlab.com/docker-scripts/dev/evergreen/-/blob/main/inject/setup.sh
17:00	dashohoxha	It can be accessed here (if someone would like to have a look):
17:00	dashohoxha	- https://tmate.io/t/MRNS9CcmuWJ2QG4kjsrPh9xGJ
17:04	dashohoxha	Don't be afraid of breaking something, because I can rebuild the containers again from scratch.
17:05		mmorgan left #evergreen
17:07	dashohoxha	For example apache2 is giving some errors on the log:
17:07	dashohoxha	[WARN:171:osrfConfig.c:251:] No Config object!
17:07	dashohoxha	[INFO:171:./osrf_json_gateway.c:72:] Bootstrapping gateway child for requests
17:07	dashohoxha	I/O warning : failed to load external entity "/openils/conf/opensrf_core.xml"
17:07	dashohoxha	[WARN:174:osrfConfig.c:99:] Unable to parse XML config file /openils/conf/opensrf_core.xml
17:07	dashohoxha	[ERR :174:osrf_system.c:350:] No Config File Specified
17:13	dashohoxha	I have noticed on the file '/openils/config/opensrf_core.xml' that <config>/<gateway>/<username> is "opensrf" for the jabberd part, and it is "gateway" for the (commented) redis part. Maybe one of them is wrong.
17:20	dashohoxha	Also, the container is behind a reverse proxy (nginx) with a basic proxy_pass configuration like this:
17:20	dashohoxha	server {
17:20	dashohoxha	listen 443 ssl;
17:20	dashohoxha	server_name ils.fs.al ;
17:20	dashohoxha	location / {
17:20	dashohoxha	include conf.d/proxy_params;
17:20	dashohoxha	proxy_pass https://ils.fs.al;
17:20	dashohoxha	}
17:20	dashohoxha	}
17:20	dashohoxha	I am afraid that it needs some additional configuration for the websocket. I don't know if the site still works without websocket configured properly.
17:35		JBoyer joined #evergreen
18:15		Christineb joined #evergreen
23:50		ianskelskey joined #evergreen

Results for 2024-10-30

03:59		dashohoxha joined #evergreen
04:05	dashohoxha	Hello. I am trying to install Evergreen on docker container with Debian 12. Everything seems ok, but when I try to test the connection from 'srfsh', by giving 'login admin-user admin-pass', I get LOGIN_FAILED.
04:06	dashohoxha	srfsh# login admin TL2jEQrvp0aekJqh2Ww9
04:06	dashohoxha	Received Data: "$2a$10$9qKCHyTrFu1NE30jX5LE3O"
04:06	dashohoxha	------------------------------------
04:06	dashohoxha	Request Completed Successfully
04:06	dashohoxha	Request Time in seconds: 0.063436
04:06	dashohoxha	------------------------------------
04:06	dashohoxha	Received Data: {
04:06	dashohoxha	"ilsevent":1000,
04:06	dashohoxha	"textcode":"LOGIN_FAILED",
04:06	dashohoxha	"desc":"User login failed",
04:06	dashohoxha	"pid":594,
04:06	dashohoxha	"stacktrace":"oils_auth.c:794"
04:06	dashohoxha	}
04:06	dashohoxha	------------------------------------
04:06	dashohoxha	Request Completed Successfully
04:06	dashohoxha	Request Time in seconds: 0.068730
04:06	dashohoxha	------------------------------------
04:06	dashohoxha	Login Session: (none). Session timeout: 0.000000
04:07	dashohoxha	When I execute 'Open-ILS/src/support-scripts/settings-tester.pl', everything seems to be ok, except for this problem:
04:08	dashohoxha	Checking postgresql version
04:08	dashohoxha	psql (PostgreSQL) 16.4 (Debian 16.4-1.pgdg120+2)
04:08	dashohoxha	Checking libdbi and libdbi-drivers
04:08	dashohoxha	libdbi PostgreSQL driver not found in shared library path;
04:08	dashohoxha	you may need to edit /etc/ld.so.conf or add an entry to /etc/ld.so.conf.d/
04:08	dashohoxha	and run 'ldconfig' as root
04:09	dashohoxha	Does anybody have any idea what this means and how to fix it?
05:12		dashohoxha joined #evergreen
06:53		JBoyer joined #evergreen
07:03		collum joined #evergreen
10:37	csharp_	dashohoxha: I would make sure ejabberd is functioning - also, look at the system logs at /openils/var/log/osrfsys.log (on a stock install)
10:42	Bmagic	csharp_: I'm not familiar with the nick, do you know if this is their first time installing?
10:43	Bmagic	I considered a response the the mailing list, but I wasn't sure where to begin :)
10:45	dashohoxha	I tried 'ldconfig' again, but this does not make 'settings-tester.pl' happy, it displays the same error message. Actually I looked at the code of 'settings-tester.pl', trying to find the part that outputs this error message, and it is something related to 'libdbpgsql': '/sbin/ldconfig --print \| grep libdbdpgsql'.
10:46	dashohoxha	However I notice that the package 'libdbd-pgsql' (on Debian 12) is already installed. This is the closest that I could find to 'libdbpgsql'.
10:49	dashohoxha	About ejabberd, I have tested (as root) the commands that are suggested on the debug wiki page (which is a bit outdated by the way): 'ejabberdctl check_password opensrf public.localhost 445b8e76450077718e36effd3717a6486eae4208 ; echo $?'
10:50	dashohoxha	It gives 0 as a result, which means it is good. The same for the command: 'ejabberdctl check_password opensrf private.localhost 445b8e76450077718e36effd3717a6486eae4208 ; echo $?'
10:53		Christineb joined #evergreen
10:53	csharp_	dashohoxha: I think the pgdbd "problem" isn't worth investigating - it's more likely something within OpenSRF isn't running correctly - again, check the logfile I mentioned - look for things with "ERR"
10:53	dashohoxha	Checking '/openils/var/log/osrfsys.log', I see some error messages in it:
10:54	csharp_	dashohoxha: use https://pastebin.com/
10:55	csharp_	dashohoxha: (also ensure nothing sensitive is in the logs before pasting)
11:00		mmorgan1 joined #evergreen
11:00	dashohoxha	https://termbin.com/9tyr
11:01	dashohoxha	There is nothing sensitive in it because I am just trying to make a test installation.
11:02	csharp_	sure
11:03	csharp_	"Could not authenticate with Jabber server:" - the Jabber server will use whatever you have in username/password in the <opensrf> and <router> elements in /openils/conf/opensrf_core.xml, so first obvious step is to make sure that file is correct
11:04	csharp_	does Debian use AppArmor? by default the apparmor profile for ejabberd is strict (on Ubuntu, anyway)

Results for 2024-10-28

08:43		collum joined #evergreen
09:00		mmorgan1 joined #evergreen
09:06		dguarrac joined #evergreen
09:48	jeff	there are at least three other issues with that set of tests for Module::Pluggable in CPAN RT: https://rt.cpan.org/Public/Dist/Display.html?Name=Module-Pluggable
09:50	jeff	though one was likely fixed by this commit, which annoyingly seems to do more than the commit message suggests: https://github.com/simonwistow/Module-Pluggable/commit/8c179586ba0edd077e3e12ac63edac70551ed661
09:55		redavis joined #evergreen
10:09		mantis joined #evergreen
10:16		redavis_reloaded joined #evergreen

Results for 2024-10-25

10:06		BDorsey_ joined #evergreen
10:18		Dyrcona joined #evergreen
10:47		sandbergja joined #evergreen
10:59	Dyrcona	Has anyone gotten this with the 3.13.4 to 3.14.0 upgrade db script? "ERROR: ALTER TYPE ... ADD cannot run inside a transaction block". I'm only asking because I got it with another script that I wrote based on the 3.14 upgrade. However, I'm pretty sure that I didn't get it when I test the 3.14 upgrade after making it earlier this week.
11:04	Dyrcona	I am going to test the db upgrade again, this time on a Pg 10 database. It was Pg 10 where it failed on me. That behavior could have changed....
11:06	Dyrcona	Yeah. It looks like it would fail with the same error...
11:13	Dyrcona	So, the 3.13.4-3.14.0 db upgrade works on Pg 16, which is where I think I tested it. I'll try Pg 10.
11:18	redavis	IIRC, we talked about stating that EG 3.14 required a minimum version of PG (I don't remember which) higher than 10 because it's out of support now.
11:19	Dyrcona	redavis: Yeah, but the release notes actually say it is compatible with Pg 10. We don't support less than Pg 13 for new installations.
11:19	Dyrcona	And, the upgrade fails on Pg 10.
11:20	Dyrcona	No, the release notes are correct. We changed it to be compatible.
11:20	redavis	Oh. okay
11:20	redavis	makes sense
11:21	Dyrcona	I swear I tested it on Pg 10, also, but I guess I didn't and thought that I had.
11:21	Dyrcona	I'll modify the db upgrade and put out a new tarball.
11:21	Dyrcona	We've had to do this before.
11:21	redavis	Dyrcona++
15:02		frank_g joined #evergreen
15:05		Dyrcona joined #evergreen
15:06	Dyrcona	Hm.. wifi flaked out on me.
15:11	frank_g	Hi all, we are migrating from 3.4.2v to 3.12.0v in a new EG server, and a Library Staff is testing the Staff view, but he says that the records migrated dont show the complete information in the Staff view label, He created a new record and it shows the complete information, so I tested just saving the old record (without any change), and now the
15:11	frank_g	record shows the complete information, My question is, Is there a Script that I have to run to upadte all records to show the complete information in Staff view label? Or the library staff has to open-save each record to update them? I hope I explain it correctly, tks
15:14	Dyrcona	frank_g: You are pretty much guaranteed to have to run some kind of ingest jumping over that many versions. I recommend running pingest.pl. It's installed in /openils/bin.
15:17	Dyrcona	I bet the library kicked me off the wifi for going over a data cap. :)
15:21	Dyrcona	Good thing Verizon doesn't care, so long as I pay my bill.
16:58	Bmagic	I'm struggling to get Evergreen to install from scratch, and again, I think I've tracked it back to this perl issue
16:58	dbriem	mmorgan thanks
16:58	Bmagic	it's not just Email::Send that isn't getting installed
16:58	dbriem	yeah it has a dependency that's has failing tests
16:59	Bmagic	Email::Abstract isn't making it either
17:01	Bmagic	I'm checking to see if I can get a system up and running without having to install from cpan
17:02	dbriem	if i install Module::Pluggable directly, then Email::Send installs through cpan for me
17:22	Bmagic	Submitted a patch for it: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/blake/install_pluggable_dependency
17:22	Bmagic	how annoying
17:24	Bmagic	that patch is really just for me and anyone else who's intersted, there's no LP yet, and it's just for jammy. I've not explored any of the other supported OSes. And it might just be for docker installs. I'm holding out hope that it will be resolved on the cpan side and we won't have to do anything for real
17:41	dbriem	i used the ansible installer (by the way, thank you berick for that, it's awesome) and ran into the same issue, hopefully Module::Pluggable can address that test. in the meantime i have your patch, thanks.

Results for 2024-10-24

09:24		mmorgan joined #evergreen
09:26		collum joined #evergreen
09:31		dguarrac joined #evergreen
09:36	Bmagic	by the way: the 3.14.0 tarbal re-test resulted in the same perl installation issue for Email::Send. In other words: it's not us, it's them.
09:36	Bmagic	also:
09:36	Bmagic	@coffee [someone]
09:37	* pinesol	brews and pours a cup of Colombia Tolima Reynel Perez Micro-Lot, and sends it sliding down the bar to mantis1

Results for 2024-10-23

12:01		mmorgan joined #evergreen
12:01	Bmagic	export CPAN_MODULES = \ ... Email::Send \
12:01	Dyrcona	I ran `sudo cpan install Email::Send` and got this: "Email::Send is up to date (2.202)."
12:02	Bmagic	you'd have to test on a system that doesn't already have it installed
12:02	Dyrcona	Of course, and I don't have one of those handy at the moment.
12:02	Bmagic	there's a compile error somewhere in the middle
12:02	Dyrcona	Well, there's a Lp bug to switch to Email::Sender...

Results for 2024-10-22

12:25		jihpringle joined #evergreen
12:27	jeffdavis	Only 79 more releases until that statement is valid, maybe we should just leave it in.
12:27	Dyrcona	Heh.
12:28	* Dyrcona	tests the 3.14.0 db upgrade script because it needed to be modified.
12:29	Dyrcona	Works for me!
12:35	Bmagic	are the branches ready for build (I'm mostly asking about "my" branch rel_3_13) ?
12:35	Dyrcona	Bmagic: I believe so.
12:57	Dyrcona	IDK.
12:57	pinesol	News from commits: Forward-port 3.12.7-3.12.8 upgrade script <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=6bc0f2ade724e4e1e083465efc33526edc3d2e59>
12:58	Dyrcona	It should be the same as main at this point.
12:58	sandbergja	Bmagic (and anybody else who might wish to test it): 3.12.8 is done building, tarball and other build artifacts are available at https://drive.google.com/drive/folders/19pGPywtrTbohBre-EBpQcoQptHXb6Bgu?usp=sharing
12:58	Dyrcona	I don't really understand our translation process. I think it all needs to be simplified.
12:58	Dyrcona	sandbergja++
12:59	Dyrcona	3.41.0 is also done. I just copied the files to lupin.
13:06	Dyrcona	I make mistakes sometimes. This multistep process invites error.
13:07	Bmagic	I think we all agree with you
13:07		sandbergja joined #evergreen
13:08	Dyrcona	I tested this all yesterday, minus the tarball part, so I think I'm just going to get the files in place once you're ready. I'll put sandbergja's files on the server and put them in place at the same time.
13:09		collum joined #evergreen
13:12	Dyrcona	That's going to take a couple of minutes over the cell network.
13:17	Dyrcona	Wonder if I've hit a cap on my unlimited plan. Seems like they're slowing me down.
16:34	Dyrcona	Can you upload it to Lupin, or do you ...
16:34	Bmagic	you have one for me to test?
16:35	Dyrcona	https://evergreen-ils.org/downloads/Evergreen-ILS-3.14.0.tar.gz
16:36	Bmagic	sweet, testing
16:39	Dyrcona	Hmm... I should see if I have a clean vm on my laptop. If not, I should probably start a new one. The one I was going to use is "contaminated" with the 3.14 prerequisites.
16:40	Bmagic	we do have the handy dandy docker tarball builder
16:40	Dyrcona	I'd have to install docker and learn it just enough. I've got a got a clean Debian 12 vm.
17:52	sandbergja	that would be sweet, Bmagic!
17:53	Bmagic	It's too soon for me to make report though. I don't know what I don't know
17:54	sandbergja	I opened bug 2053095 earlier -- I guess I should also add the pgtap live tests to this list
17:54	pinesol	Launchpad bug 2053095 in Evergreen "Make tests compatible with the enhanced concerto data set" [Undecided,New] https://launchpad.net/bugs/2053095
17:54	Bmagic	maybe we use that one
17:55	Bmagic	I will say that the standard concerto set takes much less time to reload/install
17:55	Bmagic	so, resetting the database each time we run your ansible run_test.yml script, becomes a larger endevour