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

Results for 2022-07-27

15:23	berick	ah, k
15:43	terranm	Hrrm, I don't see Galen's changes to Open-ILS/src/eg2/src/app/staff/share/holdings/copy-alerts-dialog.component.html in your commit
15:43	csharp_	looks like https://git.evergreen-ils.org/?p=working/Evergreen.git;a=commit;h=cc9c27b8647b39c44a1270b74b65bbe1a044739a was missed in the signoff/add'l branch
15:44	terranm	I have applied it to my test server and Elaine tested it successfully, so it is ready to be committed
15:44	csharp_	sorry, that's wrong
15:44	csharp_	let me keep looking
15:45	terranm	It should be the 4th commit here - https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1978889-copy-alerts-various-fixes

Results for 2022-07-26

11:25		terranm joined #evergreen
11:47		jihpringle joined #evergreen
11:56		Stompro joined #evergreen
11:59	Stompro	Is anyone already working on testing the stripe messages on terran-master?
12:08	terranm	I don't think so
12:14		terranm joined #evergreen
12:20		jihpringle joined #evergreen
12:30	Stompro	terranm, thanks for the instructions, I just emailed Dawn Dale to get a screenshot of the stripe dashboard.
13:12	JBoyer	terranm++
13:14	collum	Stompro - I was testing while you were writing. I just posted a signed-off branch.
13:15	Stompro	collum, double tested then!
13:16	collum	Excellent. Never can have too much testing.
13:17	Stompro	collum, I was just trying to remember how to do a signoff branch, so you let me know just in time.
13:21	terranm	Stompro++ collum++ Yay! Adding the patron id has helped us greatly since we implemented it.
13:22	collum	terranm, I really like that feature. It will help us, as well.
13:36	terranm	berick: If you do any updates on your test server this week can you please add the angular self-check as well? https://bugs.launchpad.net/evergreen/+bug/1840773 (I was going to test on mine, but I don't want to install the Angular circ branch on mine for this round of testing)
13:36	pinesol	Launchpad bug 1840773 in Evergreen "Angularize the Self-Check Interface" [Wishlist,Confirmed]
13:39	berick	terranm: can do.
13:40	terranm	berick++
13:52		terranm joined #evergreen
13:55		jihpringle joined #evergreen
14:16	terranm	mmorgan: I loaded the current version of https://bugs.launchpad.net/evergreen/+bug/1891369 - wanted to let you know since you did a thorough testing of an earlier version
14:16	pinesol	Launchpad bug 1891369 in Evergreen "Circulation renewals near the due date should be extended" [Wishlist,Confirmed]
14:17	mmorgan	terranm++
14:17	mmorgan	I'll see if I can take a look.
14:30	JBoyer	going to rebuild pattypan with pretty much all of berick's Angular-patron-related branches to try to get a little bit of testing for all of them.
14:36		jihpringle joined #evergreen
14:36	JBoyer	And something I wanted to throw out since I noticed it go by in email: Testing at all is great, but don't forget to fire up Firefox also; there are still 2 supported browser engines!
14:37	JBoyer	And everyone++
14:38	terranm	+1
15:06	JBoyer	So that Angular patron statement is a little less impressive because one of the branched labeled as requiring it was mislabeled. (and it conflicts with the Angular stuff, so oops.)
15:08	terranm	That was probably my fault, sorry!
16:19		terranm joined #evergreen
16:19		jvwoolf1 joined #evergreen
16:30	JBoyer	FYI, there's a preview Hatch Installer linked from the spreadsheet. Both patches are client-side only so you can test them against any Evergreen server
16:31	JBoyer	Though both fixes are also client-side only so you could pretty much install, check perms in a couple places, uninstall and make sure everything is really gone.
16:42	jvwoolf1	terranm: The link to festivus seems to go to pattypan
16:53	* berick	updates evgdemo.kcls.org
17:07	csharp_	@decide evgdemo or venmo?
17:07	pinesol	csharp_: go with evgdemo
17:20	berick	terranm: https://evgdemo.kcls.org/eg2/en-US/staff/scko -- this demo server has some odd caching proxy in front of it, sometimes I have to add a ?foo=bar to the end of the URL to get the latest page.
17:21	terranm	jvwoolf1 - it sure did! Fixed
17:22	terranm	berick: okay, thanks
17:22	terranm	berick: I will test in the morning!
17:33		jvwoolf1 left #evergreen

Results for 2022-07-22

15:57	berick	i think it only uses memcache for certain types of values
15:57	berick	otherwise, just a locally cached value
15:58	Bmagic	browser cache? apache cache maybe?
15:58	Bmagic	on a test machine, the variable looks like this: $VAR1 = bless( [569,'icon_format','eaudio','E-audio',undef,'t','E-audio','f',undef], 'Fieldmapper::config::coded_value_map' );node
15:59	Dyrcona	The memcache key looks like "EGWeb.$locale.$hint." where $locale is the current locale (probably en-US) and $hint is the IDL classs: ccvm.
15:59	Bmagic	but on the broken system: $VAR1 = ''
16:00	Dyrcona	The list will have list appended, so : "EGWeb.en-US.ccvm.list" or something like that.
16:30	Bmagic	sounds good to me. I'll just have to wait till night
16:31	Dyrcona	If you empty out the list key, it might reload. I think it works like that. berick would know better than I.
16:31	Bmagic	that key isn't in the cache
16:32	Bmagic	it exists on my test system, but not on the broken system
16:37	berick	the only thing that would prevent it from getting added to the cache is if the value for the requested ID is in the process-level cache
16:37	berick	but if you reload Apache, then that should be moot
16:37	berick	may restart apache instead shrug

Results for 2022-07-20

13:39	csharp_	we had a number of patrons in my DeKalb library days who would pay the 1 penny to get below the no-checkout fines threshold
13:52		rjackson_isl_hom joined #evergreen
14:05		jvwoolf joined #evergreen
14:14	gmcharlt	noting my current thinking for the 3.8 and 3.9 maintenance releases
14:14	gmcharlt	- produce release notes draft on Friday
14:14	gmcharlt	- accept feedback through Monday
14:14	gmcharlt	- create tarballs Tuesday and test
14:14	gmcharlt	- release on Wednesday
14:20	mantis1	Has anyone successfully added a recaptcha to a form? One of our libraries is getting targeted by spam bots from different IPs within the past few days.
15:42		jihpringle joined #evergreen
16:30	Bmagic	mantis1: I have not

Results for 2022-07-15

09:57	Dyrcona	~~~~~~~~~~~~~~~~~~~~~~
09:57	Dyrcona	src/app/share/fm-editor/fm-editor.component.ts:518:51 - error TS2339: Property 'linkedSearchConditions' does not exist on type 'FmFieldOptions'.
09:57	Dyrcona	518 field.idlBaseQuery = fieldOptions.linkedSearchConditions;
10:00	Dyrcona	Yeahp. Looks like Lp 1851884 should not have been backported or should have been tested/modified for rel_3_7.
10:00	pinesol	Launchpad bug 1851884 in Evergreen 3.8 "eg-fm-record-editor: take care wiring up comboboxes" [High,Fix committed] https://launchpad.net/bugs/1851884
10:02	Dyrcona	JBoyer \| gmcharlt_ ^^
10:03	Dyrcona	I'm gonna revert it locally and will likely revert it before building the actual 3.7.4 release unless someone comes up with a fix.
14:44	Dyrcona	So, ng build --prod blows up on rel_3_7, but just ng build doesn't.
14:47	gmcharlt_	hmm - I may have a bit of time to look over the weekend
14:48	gmcharlt_	but yeah, AIUI, --prod vs. not is actually two different copilers
15:03	Dyrcona	gmcharlt_: Cool. I'll not revert anything else. It looks like 5380bfb11a3a38bac521ce8ef92216c13d46f3b9 has issues as well. I swear that worked when I looked at it, but maybe I didn't really test it on 3.7.
15:03	Dyrcona	backports--
15:10		mantis1 joined #evergreen
15:18	Dyrcona	I am inclined to just revert that commit, too, but I'll wait to see what gmcharlt_ thinks.

Results for 2022-07-13

11:16	gmcharlt_	berick++
12:14	berick	Bmagic++ # just saw your earlier comment.
12:15	berick	working on cleaning up the branch now
12:18	Dyrcona	Crazy. I'm still seeing the discrepancy in 856 display on this test vm compared to production, and I can't find the difference in the code.
12:28	Dyrcona	Hmm.... Looks like the difference may be in the database. 856$3 shows up in asset.uri.label in the test db but goes in asset.uri.use_restriction in production.
12:28	Dyrcona	But! The database code should be identical since the test db was restored from a dump on Sunday.
12:29		collum joined #evergreen
12:29	mmorgan	Dyrcona: Is there a difference in the function biblio.extract_located_uris?
12:34	Dyrcona	mmorgan: I'll check but there shouldn't be. It's a restored dump, both on Pg 10.
12:47	Dyrcona	But, how.....
12:48	Dyrcona	I have only 1 biblio.extract_located_uris, so there's not one with a different signature hanging around.
12:51	Dyrcona	According to the db function, $Z or $2 should go in use_restriction and $y or $3 should go into label. My production db entries look like $y or $z is in label and $3 is in use_restriction.
12:53	Dyrcona	My old entries in the test database look like production, but when I update them, they get the "correct" values. I'm going to see if I can find some that were recently added. I suspect we had a hacked version of the db function that didn't make it through an upgrade.
12:55	Dyrcona	Too bad I don't have any really old dumps hanging around....
12:55	Dyrcona	Hmm... I'll check the training server it might be old enough.
12:55	Dyrcona	mmorgan++
15:22	Dyrcona	DB server is slow while it's creating a database with another as a template.
15:29		dbriem joined #evergreen
15:43		collum joined #evergreen
16:35	* Dyrcona	tests if setting an internal flag during a transaction, doing an update, then resetting the flag before commit works. I think it does, but the answer is that may depend on deferred triggers or not.
16:36	Dyrcona	I know that the internal flag update won't be visible outside of the transaction.
16:36	Dyrcona	Hmm... what's the thing to make all triggers immediate.....
16:40	Dyrcona	SET CONSTRAINTS ALL IMMEDIATE; # If you ever need it.
16:40	Dyrcona	That might break things for me but we'll see.
16:41	* Dyrcona	has a feeling the test transaction won't finish in the next 20 minutes, so we'll have to wait until tomorrow morning.
16:51		jvwoolf left #evergreen
17:05		mmorgan left #evergreen
19:56		jihpringle joined #evergreen

Results for 2022-07-12

10:50	pinesol	News from commits: LP1958573 PMC messages created by action triggers not patron-visible <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=ba2fc41399e9723361245a95e64d78a6c1eb2e59>
12:15	mmorgan	berick++ gmcharlt++ # fixing :)
12:32	Dyrcona	DBD::Pg++
13:03	Dyrcona	Hrm.. URIs aren't displaying correctly on my test VM, and I just merged my production branch into my test branch....
13:04	Dyrcona	And, there are no differences in the OPAC according to git diff....
13:13	Dyrcona	Grr... Thought maybe a git clean -xfd and a rebuild would help, but no....
13:14	Dyrcona	In production, the link is on subfield z and subfield 3 appears after it. On my test VM it is the opposite in both ways.
13:21	Dyrcona	Not even wiping out the installed bootstrap templates and reinstalling them helped....
13:22		jvwoolf left #evergreen
13:29	Dyrcona	Ah, wait a minute.... I recall something now about a difference between the ttopac and bootstrap opac and I had to patch it. However the patch doesn't seem to be missing from the git branch AFAICT.
13:48	Dyrcona	But the results are definitely different....
13:53	* Dyrcona	is perplexed, but this will have to wait, I guess.
14:46		shulabear joined #evergreen
14:46	Dyrcona	The training server looks like production, but I can't find any relevant differences between the test vm branch and those for training or production. The installed files also match those from the branches. Is there some server cache that I'm overlooking?
14:50		terranm joined #evergreen
14:50	Dyrcona	Found the eg_template_cache in the systemd temp files and deleted it just in case. Makes no difference on training.
14:53	Dyrcona	Oh... I see one thing. There's a bug in a program that I'm running to update 856s. That might be the culprit...
15:08	gmcharlt_	yes, please sign up on the spreadsheet; I'll start bugging people by Thursday
15:08	shulabear	gmcharlt++ Dyrcona++
15:09	JBoyer	I know a few people may be in late or may not make the meeting, I can send something to the dev list unless you're planning to.
15:09	gmcharlt_	and I think otherwise, given the spurt of activity the past couple days, that help testing pending Angular holdings and item editor bugs would be Good Thing
15:09	gmcharlt_	JBoyer: I'll coordinate it
15:09	JBoyer	gmcharlt_++
15:09	terranm	gmcharlt_++
15:10	JBoyer	It sounds like point releases are on their way, any discussion before moving on to LP stats updates?
15:15	JBoyer	And +1 to spacing also. Were they forced together for some reason or has experience suggested that they need more space than before?
15:15	terranm	I think it just happened sort of randomly
15:16	JBoyer	Dyrcona, perhaps worth checking, is the person you're thinking of here?
15:17	terranm	I think we get more testing participation if they are spaced out rather than in two months back to back
15:17	Dyrcona	JBoyer: They
15:17	berick	i should be able to host a bug squashing VM this time around
15:17	terranm	berick++
15:27	berick	sans menu entry changes, I should say
15:27	gmcharlt_	the branch is realistically far too large for detailed patch-level scrutiny
15:27	berick	yeah, it's a beast
15:28	gmcharlt_	but if we merge soon (and I do see reasons for doing that), I think we're going to need to organize community testing on a large scale; possibly larger than previoulsy attempted
15:28	berick	my thinking is if the UI is not yet exposed, a minimal amount of the new code will actually be used.
15:29	berick	once we do expose the new UI's, which may come after 3.10, then loads of testing would be needed
15:29	gmcharlt_	yeah, but that just kicks the can down the road, since of course the point is eventually to switch to it
15:29	Dyrcona	gmcharlt_++
15:29	Dyrcona	+1, too.... I think if it goes in, turn it on.
15:30	berick	sort of. if we can expose less ambitious interfaces that use the underlying code, then we get the chance to test parts of it without flipping a giant switch
15:30	gmcharlt_	so I think what I'm saying is that organizing broad testing needs to happen on the heals of a merge
15:30	gmcharlt_	*heels
15:31	berick	gmcharlt_: so you're thinking flip the big switch on day one too?
15:32	terranm	I could work up a list of tasks that need to be tested for each of the new interfaces as a starting point. It might be easier to get people to test if it's broken into bite-sized pieces.
15:32	mmorgan	Just to clarify, right now, the new uis are under an org unit setting?
15:32	gmcharlt_	more like stand up test systems that have the switch flipped
15:32	berick	mmorgan: sort of. it's kind of a mess what we have.
15:32	berick	that we were going to test with
15:32	berick	i'm of the opinion that when we do flip the switch, it has to be fully flipped or it's going to get really confusing real fast
15:33	berick	hopping between the same UI's depending on how you got there
15:33	gmcharlt_	(also noting that soon there will be a dump of the Angular acquisitions sprint 4 stuff, though that's more self-contained than the patron/circ stuff)
15:34	JBoyer	terranm++ I do think having a reminder of what all needs to be tested helps. I wonder if some of the staff interfaces have the 1-2 things users do most and then say "yeah, didn't fall over" by end users. A guide would help them test things they maybe do quarterly or less.
15:34	mmorgan	terranm++
15:34	mmorgan	+1 to broad community testing
15:35	shulabear	terranm++
15:35	gmcharlt_	also, I think the more that the branch can be cleaned up to have new and changed shared component live in self-contained patches, the better
15:36	gmcharlt_	as individually, those should be much more amenable to piecemeal testing by devs and committers
15:38	berick	yeah, i can clean up the shared/core changes. that's a small portion of it.
15:39	gmcharlt_	and I think the other thing that would help is ensuring that there's one big ol' switch (or maybe a small set of them) to reliably switch between old and new interfaces
15:39	berick	it gets a little complicated with the patron UI, since it's basically one big application. it kind has to be added as a whole.
15:42	jeff	another option is to have no switch, and "don't upgrade" is your only switch. combined with potentially a longer support life for the previous release, that might make sunsetting the old interfaces more of a sure thing.
15:42	berick	jeff: that would be my pref.
15:43	berick	running them side by side will get messy no matter what, imo
15:43	gmcharlt_	that still presupposes actively organized and broad testing
15:43	berick	absolutely
15:43	* Bmagic	scrolls up
15:44	* phasefx	still remembers having three or so pull lists
15:44	gmcharlt_	but I mislike the notion of potenially have 3.10.0 end up being intentionally full of regressions
15:44	berick	but going back to my original proposal, if we merge the code without any menu/link updates, then we have a body of code we can start building on, which will have the affect of testing said code. Eg. it's a lot easier to test a new Item Status UI then overhauling the whole patron UI.
15:44	mmorgan	gmcharlt_++
15:44	gmcharlt_	I wonder if we should consider an extended timeframe for 3.10, balanced with a brief 3.11
15:45	berick	i wasn't trying to flip the switch for 3.10. a full switch flip should happen basically the day after a major release is made
15:48	mmorgan	berick: Meaning not going all in and the "switch" being don't upgrade.
15:48	gmcharlt_	JBoyer: one huge change and a largish change (acq)
15:48	Dyrcona	Why not add it after 3.10, go all in, and 3.11 becomes 4.0 if the changes are that big?
15:49	gmcharlt_	because anything that isn't turned until 3.11 will largely not get significant testing untikl 3.11 starts (is my fear)
15:50	Dyrcona	Anyone testing leading up to the 3.11 release would be using the new interfaces.
15:50	gmcharlt_	berick: let me ask you this - assuming a longer 3.10 cycle, is your branch essentially feature complete now? (barring the inevitable obscure YAOUS implementations and so forth)?
15:50	phasefx	this is probably crazy, but how about we hold releases hostage until we get significant testing? super long rc-1 for whatever holds the new stuff
15:51	gmcharlt_	or are there significant known bits of the overall AngularJS circ app that aren't yet implemented in Angular?
15:51	berick	gmcharlt_: we're using in production, w/ some patches I have not yet backported. I think the patron messages stuff might need some tweaking as well
15:51	berick	since it was concurrently developed
15:54	gmcharlt_	and it sounds like - other than catching up with trigger events interfaces and notes/messages changes - there aren't significant ones?
15:54	berick	no, those are the 2 menu items that are disabled in the UI right now
15:54	berick	should be the only big things
15:55	gmcharlt_	in that case, here's a thought
15:55	gmcharlt_	1. ensure that there's a Big Red Switch for insurance purposes
15:55	gmcharlt_	2. merge sooner rather than later, hopefully with some cleanup of the branch
15:56	gmcharlt_	3. target this for 3.10, then aim for broad testing
15:56	berick	what if the Big Red Switch is a patch/commit? making all the links/buttons have optional destinations is non-trivial
15:56	gmcharlt_	3a including nudges, test systems, etc.
15:57	gmcharlt_	4. we agree to prepare to extend 3.10 into November, possibly early December
15:58	gmcharlt_	5. and by mid-November, review the state of the bugs against the Angular interfaces and make a go/no-go decision
15:58	gmcharlt_	5a. (which is potentially when the decision to apply the BRS as a commit, if that's what it has to be, gets made)
15:58	gmcharlt_	(end of my list)
15:59	gmcharlt_	but basically, combine (a) a quick merge so that the code doesn't age or diverge too much with (b) a much more intentional testing stance for a big change like this than may have been the case in the past
16:00	gmcharlt_	without kicking the can to 3.11, since the testing needs to happen eventually and it would be good not to block the potentiall for normal enhancements to patrons/circ
16:00	berick	gmcharlt_: ok, that makes sense. and the BRS will be a commit that just reverses all the link/button/menu changes?
16:01	berick	or a revert, basically
16:02	gmcharlt_	if need be; a global setting / YAOUS would make it easier for ongoing testing if we're not confident enough to release 3.10 with $NewCirc, but if it's not feasible, it's not feasible
16:03	berick	k. do-able, was just hoping to avoid that, but I understand the desire.
16:03	berick	a bold plan and I like it
16:03	berick	gmcharlt_++
16:06	JBoyer	#topic Consider merging bug 1979357? (phasefx)
16:06	pinesol	Launchpad bug 1979357 in Evergreen "fixes for qatester failures" [Undecided,New] https://launchpad.net/bugs/1979357
16:06	phasefx	yeah, someone push this
16:06	JBoyer	#info Need this so we can get the QA tester going again; changes some pre-reqs for stretch and buster, and fixes a live test
16:06	phasefx	also fixes a bug with cover image uploader for stretch
16:07	Dyrcona	So, stretch is like EOL and we should drop it from our prerequisites.
16:07	phasefx	sure

Results for 2022-07-11

08:13		mantis1 joined #evergreen
08:54		mmorgan joined #evergreen
08:55		Dyrcona joined #evergreen
09:28	Dyrcona	I ended up undoing the switch to Pg 14 as the main cluster on my test db server. I haven't applied all of the necessary patches to our production database, so the restore spit out some warnings about missing functions.
10:17	pinesol	News from commits: LP1959716 Follow up to allow managing/deleting in-place copies <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=a12a7ad653631ec09ee690571f9ec265e06c801b>
10:17	pinesol	News from commits: LP1955065 Item note dialog close value repairs <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=49307d613ad2d59375748bb127ceaec1c4642509>
10:17	pinesol	News from commits: LP#1955065: fix deletion of item notes in Angular item attributes editor <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=deab630a5837dbe723fe2f2b7fbe38926ca86121>

Results for 2022-07-08

09:55	Dyrcona	:)
09:55	Dyrcona	@blame [band]
09:55	pinesol	Dyrcona: Destructo Dog is probably integrated with systemd
09:56	Dyrcona	Anyway, I'm thinking of switching over to using Pg 14 instead of 10 as the main PostgreSQL instance over the weekend, so that means I may have to cut this test run short.
09:57	Dyrcona	I did start another query on the same cluster: 239373 \| 00:26:26.838289 \| active \| 192.168.100.103 \| psql \| delete from action.hold_request where frozen and thaw_date is null and request_time::date < now()::date - '1 years'::interval;
09:59	Dyrcona	I should probably have that query output the database name, but I typically use it only the production Evergreen dbs where evergreen is the only active database.
10:12	Dyrcona	Well, the delete works.
11:03	Dyrcona	Wow: /dev/sdc1 6.4T 5.4T 1.1T 84% /var/lib/postgresql
11:04	Dyrcona	I think it has started cleaning up.
11:19	Dyrcona	Well, I was going to wait until 9:00 PM tonight to reboot the server, but might as well do it now.
11:31	* Dyrcona	hangs his head in shame. My testing has been inadequate of late.
11:40	pinesol	News from commits: LP1976557: (follow-up) fix lint <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=e0bdcf1d033a63c3c77657759b8c32d01ab88140>
12:03		jihpringle joined #evergreen
12:40		collum joined #evergreen

Results for 2022-07-05

16:18		stephengwills left #evergreen
16:39		Guest75 joined #evergreen
16:41	Guest75	Hello everyone, I had someone ask a question and I do not know the answer... In Evergreen, is there a way to add multiple email addresses for hold notification?
16:47	jeffdavis	Guest75: I think it's possible although I haven't tested. There is some discussion in this bug report: https://bugs.launchpad.net/evergreen/+bug/1755625
16:47	pinesol	Launchpad bug 1755625 in Evergreen 3.1 "Web Client: Edit Patron Email Address Box Does Not Allow Multiple Addresses" [Medium,Fix released]
16:50	jeffdavis	basically you should be able to put multiple comma-separated addresses in the email field in the patron editor, but you may need to modify the "Regex for email field on patron registration" setting to allow it
16:55	Guest75	thanks for the info, I tried a comma without space and got an error. I will try comma with space and ;
18:19	csharp_	@who wants to delete all other languages?
18:19	pinesol	Christineb wants to delete all other languages.
18:20	jihpringle	I mean, that's true :)
18:20	csharp_	haha
18:20	csharp_	jeffdavis: I think that's all you need to do - maybe try on a test server?
18:24	jeffdavis	yeah I can give it a try, I'm just nervous because locales touch some pretty core stuff in EG
18:25		mantis1 joined #evergreen
18:26	jeffdavis	yet another reason we should all just use Esperanto

Results for 2022-06-30

08:34		Dyrcona joined #evergreen
08:39		mmorgan joined #evergreen
09:09		Stompro joined #evergreen
09:28	Stompro	Baker and Taylor support notified me this morning that PASV mode should work again on the normal ftp site. But I haven't tested it yet.
09:33	mmorgan	Offline circ issue: A library can't record checkouts, likely because the "Working Location" field isn't filled in. But the dropdown for that field is not populated. Any suggestions?
09:34	Stompro	Seems to be working when I test. Public IP returned when passive commands are sent using netkit-ftp, which doesn't have special handling I believe.
09:45	* mmorgan	goes offline to test offline circ for real
09:49	Dyrcona	mmorgan: You have to be completely offline. If it can see the server at all, offline doesn't work.
09:50	Dyrcona	:)
09:50	Dyrcona	I figured she knew, but..."Won't someone please think of the logs!?"
11:02	Dyrcona	There are also 3 autovacuum worker processes running in the database. I've been meaning to look into our autovacuum settings.
11:16	Dyrcona	INFO: scanned index "symspell_dictionary_updates_tid_idx" to remove 126549937 row versions
11:22	Dyrcona	miker: https://pastebin.com/E4iNzSzw
11:23	miker	yeah, the delayed reification isn't actually being tested... wheeee
11:23	miker	you're just testing the deadlock code (again)
11:23	Dyrcona	Did I miss a flag to turn that on?
11:24	miker	the pingest param is supposed to casue a function to be called that turns that delay feature on, and then at the end it calls a separate "clean it all up" function
11:24	miker	you know pingest better than me, so I'd appreciate eyes on that logic change
11:26	Dyrcona	OK. So, I missed using that option.
11:27	Dyrcona	Can I ask why that is optional? Shouldn't it just work that way, all the time?
11:28	Dyrcona	I simply forgot about the option when I started the test run. This is what happens when you a) get older, b) work on many things, and c) have to put one thing down for a week or more before coming back to it.
11:33	miker	because for non-batch ingest it just creates headaches. human bib editing doesn't interact often enough to matter, but because it does cause serialization (INSERT ... ON CONFLICT does that to prevent deadlocks) with intentionally parallel updates the delay makes it overall faster. same thing as with the browse part of ingest
11:34	miker	now, I could certainly see making it the default for pingest! but I didn't want to change the default behavior on my own
11:34	miker	default behavior of pingest, I mean

Results for 2022-06-29

10:38	Dyrcona	My SIP2 check programs are all written to work with ldirectord or haproxy, and that may be why I have not shared them.
10:39	Dyrcona	I have 5 because of experiments with different "features."
10:40	Dyrcona	Also, many hardcoded values, such as path to a configuration file.
10:45	Dyrcona	So, I discovered that my previous test of the symspell fixes were invalid. I forgot to enable the triggers on the tables, so I'm running them again.
10:45	Bmagic	Dyrcona++
10:47	Dyrcona	I've already signed off on the branch..... sigh
10:57	Dyrcona	It is taking longer than before. I do hope it is acceptable. The first batch have been running for 4 hours and 15 minutes. Prior to symspell, they typically have finished by now.

Results for 2022-06-28

14:09	pinesol	Launchpad bug 1945385 in Evergreen 3.8 "Circulation Limit Set interface missing sorting, filters, and back button" [Medium,Confirmed] https://launchpad.net/bugs/1945385
14:10	Dyrcona	hey, pinesol, where are the commit messages?
14:11	jihpringle	Dyrcona: great I'll add a signoff
14:12	Dyrcona	I'm going to test the code today and possibly tomorrow depending on how long it takes. I want to test on 3.7 and master at least, probably on 3.9 also.
14:14	pinesol	News from commits: LP#1932203: serialize requests on Edit Due Date in Items Out tab <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=92b75f94aa82176338084deb200be6fc9cb43820>
14:15	Dyrcona	I also plan to push the fix for bug 1931737 by the end of the week. If someone else wants to have a look at it, I'll gladly push a signoff branch and let anyone else have a look.
14:15	pinesol	Launchpad bug 1931737 in Evergreen 3.8 "Did you mean breaks parallel reingest and causes deadlocks when loading/overlaying bib records in the client" [High,Confirmed] https://launchpad.net/bugs/1931737

Results for 2022-06-27

08:55		jvwoolf joined #evergreen
10:36		Stompro joined #evergreen
10:58		RFrasur joined #evergreen
11:00	Bmagic	I'm testing an upgrade to PG 10. Performing pg_dump, then pg_restore on pg10. I'm pre-creating the database on PG10 following the Evergreen create database extension file "create_database_extensions.sql" - That setup does not call for tsearch2, which was removed back in EG2.4. When I restore my dumped database, I get errors about missing tsearch2
11:00	Bmagic	ERROR: could not open extension control file "/usr/share/postgresql/10/extension/tsearch2.control": No such file or directory
11:01	Bmagic	Command was: CREATE EXTENSION IF NOT EXISTS tsearch2 WITH SCHEMA public;
11:02	Bmagic	I found this patch bug 1175287 which was part of db upgrade 0743. which was* ran on this db according to config.upgrade_log. But maybe I'm barking up the wrong tree
16:12	Dyrcona	Trying to find patrons with over 80 circulations and this happened: SSL SYSCALL error: Connection timed out
16:15		jvwoolf left #evergreen
16:18	Bmagic	That's "fun"
16:24	Dyrcona	Well, I reconnected and ran a query with a lower having and it returned pretty quickly, so I bumped it back up to 80 and got some accounts to test with.
17:17		mmorgan left #evergreen
17:24		jihpringle joined #evergreen
17:30		Christineb joined #evergreen

Results for 2022-06-23

16:27	* Dyrcona	calls it a day. got a long drive home.
16:29	JBoyer	jeff++
16:30	JBoyer	I was just about to post that, but too slow. :)
17:30	Bmagic	B&T created an alternate server that is working in PASV mode, still in test mode ATM. But, FYI RFrasur Dyrcona (niether are here, but hey, there's IRC logs)
17:30	Bmagic	/niether/neither
17:43	jmurray-isl	Bmagic++
19:57		Dyrcona joined #evergreen

Results for 2022-06-22

12:29		jihpringle joined #evergreen
12:34		collum joined #evergreen
12:51		collum joined #evergreen
12:59	stompro__	I wonder if it would make sense to add a test script in front of the edi_pusher/edi_fetcher that does a pre check for connectivity to ftp.baker-taylor.com, to avoid runs that won't succeed?
13:00	stompro__	And avoid having to reset POs for edi_pusher orders.
13:06	Dyrcona	The whole process could be made a bit smarter..
13:06	Dyrcona	I have thoughts, some more solid than others.
13:15	stompro__	Passive is working for Filezilla because it has a setting that automatically substitutes the servers public IP if a private IP is returned in response to a PASV command, so they must have their port forwards setup at least. Maybe NET::FTP could be adjusted to have that behavior?

Results for 2022-06-21

11:14	Bmagic	B&T had a "meeting" yesterday. Still no worky today
11:29	Dyrcona	B&T seems to be working with PASV today, but it is taking two minutes per connection. I have logs that look we're getting things via the fetcher. I've not checked the pusher, yet.
11:30	Dyrcona	We're looking at configuring our firewall for active FTP.
11:31	Dyrcona	miker: Cool! I was thinking more eyes would be good, but I'm not sure who else would get to testing it nor when they could make time.
11:31	Dyrcona	miker: I'm testing with production data upgraded to rel_3_9 latest today.
11:56	stompro__	berick, we added an ftp proxy helper to our firewall and switched to Active mode for B&T ftp last week and that has been working. We noticed that on the 14th, they broke their own invoice uploading to the ftp server so invoices that should have been received that day are missing.
12:03	stompro__	berick, I just tested passive mode and it does seem to be working now, at least more than it was. The initial file list works now.
12:04	berick	thanks stompro__
12:05	stompro__	I'm not seeing the 2 minute delay that Dyrcona mentioned... but maybe that is for actual uploads?
12:06	stompro__	I tried downloading a response and it seemed to work fine... but I'm just testing with filezilla on my workstation.
12:12	Dyrcona	The 2-minute delay seems to happen when we get 0 files.
12:12		jihpringle joined #evergreen
12:20	miker	Dyrcona++

Results for 2022-06-20

09:39	Bmagic	@coffee [someone]
09:39	* pinesol	brews and pours a cup of Natural Decaf Espresso, and sends it sliding down the bar to jweston
11:39		jihpringle joined #evergreen
14:37	pinesol	News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>
16:39		jihpringle joined #evergreen

Results for 2022-06-17

06:02	pinesol	News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>
07:05		kmlussier joined #evergreen
07:05	kmlussier	bshum++
07:05	kmlussier	parts++
09:13	mmorgan	Good morning!
09:13		Stompro joined #evergreen
09:22		rjackson_isl_hom joined #evergreen
09:40	eby	miker: / berick : going to test more next week but curious with your mention of setting workstation prefs as org unit settings. Does it act as a fall back default or as a forced preference?
09:49	phasefx	berick: do you want to talk SIP2M sometime today? I don't have an agenda, but we could determine/sanity-check next steps
09:51	berick	eby: it acts as fall back default. ignored in cases where a workstation setting value is already saved.
09:52	berick	best way to create is to save the value you want at a workstation, then copy the JSON from the value into the newly created org unit setting.
09:59	pinesol	Dyrcona: go with local git
10:07	* Dyrcona	wonders if we should add some instrumentation to pingest.pl (and possibly drop the .pl extension).
10:16	Dyrcona	Hmm. I guess rebasing from master to rel_3_7 is not a good idea.
10:18	miker	Dyrcona: do I feel my ears burning? ;) (if you're looking at what I think you're looking at, if you can test closer to master I think you'll have more success)
10:18	Dyrcona	Remote syntax in git can be annoying: orign/rel_3_7 for one command and origin[space]rel_3_7 for another.
10:19	Dyrcona	miker: I am. I plan to start testing with rel_3_7 today and an upgrade to rel_3_9 next week if that's OK.
10:20		mdriscoll joined #evergreen
10:20	Dyrcona	I suppose the different syntax is what they call commitish (in the / case) and remote[space]branch in the latter.
10:22	Dyrcona	I should copy the database that I want to use so it won't get obliterated this weekend.
10:23	* Dyrcona	is tempted to test on Pg 14 since there was an update this morning... ;)
10:43	miker	Dyrcona: as far as order and timing goes, I'm just glad someone's looking at it, but just to note that deadlock+symspell branch was developed after 3.7 (recall, nocase browse) so starting with vanilla 3.8 or 3.9 (/not/ patched with this and then upgraded) may be less of a headache. I get that "with your data" testing isn't particularly feasible at scale for versions past what you're actually on, though.
10:46	Dyrcona	miker: Right. I previously made a 3.7 backport and only had had to change the db upgrade script. Looks the same still, but I'll see what happens. If it just blows up, I'll move to upgrading to 3.9 over the weekend.
10:47	Dyrcona	I'm going to compare the implementation of metabib.reingest_metabib_field_entries in the two db upgrades. I think we can delete the one from the WWW upgrade.
10:51	Dyrcona	Yeah, only difference is the check for reification.
13:16	JBoyer	I'm also basically out of pocket / on the bench / choose your own favorite game / sport related euphemism for unavailable for any real hacking at the fest. Additionally, if anyone wanted to take the reins / read the agenda for the dev meeting this afternoon I would be happy to just listen in and pop in should I have something worth saying.
13:19	miker	Dyrcona: huzzah! with that option it /should/ be as fast as before (insert-only into the unlogged table) and then at the end there'll be a pause while it shoves the changes in, in one go
13:22	Dyrcona	miker: We'll see.
13:22	Dyrcona	I also just tested a 3.7.3 to 3.9 db upgrade that I prepared for next week, and I got this error: psql:3.7.3-3.9-upgrade-db.sql:3509: ERROR: cannot drop type search.search_result because other objects depend on it
13:22	Dyrcona	DETAIL: function search.query_parser_fts(integer,integer,text,integer[],integer[],integer,integer,integer,boolean,boolean,integer) depends on type search.search_result
13:22	Dyrcona	I wonder if we have something old or custom hanging around?
13:23	Dyrcona	The suggestion in the error report was to use drop cascade.
13:24	Dyrcona	Looks like we won't be needing it.
13:27	jeffdavis	We have two versions of search.query_parser_fts in our environment and I've had to manually drop the second one for the upgrade scripts to work in testing.
13:27	jeffdavis	So yeah, probably an old version of that function sticking around on ancient EG installs.
13:30	Dyrcona	jeffdavis: Thanks. That's what this looks like.
13:30	Dyrcona	I'm using cascade on the type drop, and that appears to work.
13:32	Dyrcona	It's fun running upgrades over multiple version. :)

Results for 2022-06-16

12:42	* Dyrcona	just having fun.
12:48	miker	berick: I came in a few minutes late to your ES talk yesterday, are your slides up somewhere already? (I'll try to answer my own questions before peppering you!)
12:49	berick	miker: https://github.com/berick/Presentations/tree/master/Evergreen-2022
12:49	miker	thanks!
13:03	miker	berick: thanks again. maybe during hackfest we can discuss gaps? I'm curious about how much of the various visibility testing is implemented (staff vs patron, Located URIs with/without acts-as-copy, hierarchical org + depth, empty vs "patron empty" records) and MR search results ... to start ;)
13:05	berick	miker: yeah, happy to talk. from this list, only Located URI's are not yet taken into consideration.
13:05	berick	the rest should be there
14:44		abowling joined #evergreen

Results for 2022-06-15

17:22	Bmagic	berick++ # ES!
17:24	Dyrcona	I should do more research, but I would be interested in a comparison of ES vs. Solr.
17:24	Dyrcona	berick++
17:24	Dyrcona	Also, just ran ALL THE TESTS on Ubuntu 22.04, twice. Got all passes the second time.
17:25	Dyrcona	Had some perl live test failures the first time, but I think that was because Apache wasn't set up quite right.
17:26	Dyrcona	I'll clean up the branch and add it to the bug tonight or tomorrow. Think I'll start looking at SCRAM, TLS, or SASL during the hackfest on Friday.
17:29	eby	I think solr has caught up but when we were first comparing solr was much more fickle with index and doc changes. There was a lot of reingesting/indexing required while you could do it on the fly with es
17:29	eby	or at least with minimal downtime/overhead

Results for 2022-06-11

06:01	pinesol	News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live//archive/2022-06/2022-06-11_04:00:04/test.49.html>
23:09		mmorgan joined #evergreen