Evergreen ILS Website

IRC log for #evergreen, 2020-05-27

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat

All times shown according to the server's local time.

Time Nick Message
02:51 mrisher joined #evergreen
02:54 mrisher joined #evergreen
05:27 rjackson_isl_hom joined #evergreen
06:00 pinesol News from qatests: Failed configure CPAN <http://testing.evergreen-ils.org/~live//arch​ive/2020-05/2020-05-27_04:00:07/test.3.html>
07:18 rjackson_isl_hom joined #evergreen
07:20 rfrasur joined #evergreen
08:14 dbwells joined #evergreen
08:16 mantis joined #evergreen
08:34 Dyrcona joined #evergreen
08:35 Dyrcona I think the patch for Lp 1873286 may have also broken acq pick lists.
08:35 pinesol Launchpad bug 1873286 in Evergreen 3.4 "jQuery 3.5.0 breaks at least AngularJS interfaces" [Critical,Fix committed] https://launchpad.net/bugs/1873286
08:35 Dyrcona At least, the backport to 3.2.10 seems to have done something.
08:38 alynn26 joined #evergreen
08:47 mmorgan joined #evergreen
08:48 csharp Dyrcona: btw, I tested your no-Java branches on OpenSRF/Evergreen - I see no problems, but I would guess we want to be pretty coordinated about how we commit to master/release stuff
08:52 Dyrcona csharp: It should wait until after 3.5 is released, or at least, it should not go into the 3.5 branch, not that Java works there. It hasn't worked in years.
08:53 Dyrcona I'm looking into my earlier comment and I'm seeing strange stuff on my test VM. I'm going to have to find out what jamundson is looking at in production to see if something similar is going on.
08:55 csharp Dyrcona: I looked on my master server and I don't have any selection lists to test but I didn't see problems with the UI loading or with PO items, etc.
08:59 Dyrcona csharp: I reverted commits to the files in the picklist directory and it seems to be working, now.
09:04 Dyrcona Could be a cache issue, too. It appeared fixed after I reverted changes and used the Chromium developer tools, and I have the tools set to disable cache.
09:07 Dyrcona With or without changes, I get a bunch of these: VM1995:89 POST https://training.cwmars.org/osrf-http-translator net::ERR_INSUFFICIENT_RESOURCES
09:18 Dyrcona The net::ERR_INSUFFICIENT_RESOURCES comes up even after reverting the acq changes.
09:18 dbwells joined #evergreen
09:19 Dyrcona It's "working" on training without reverting the acq changes, but it seems more stable with the changes reverted.
09:19 Dyrcona old_dojo-- mixing-frameworks--
09:25 sandbergja joined #evergreen
09:32 dbwells joined #evergreen
09:58 jvwoolf joined #evergreen
10:01 mantis joined #evergreen
10:05 Dyrcona Well, the template changes don't seem to make a difference.
10:15 jvwoolf1 joined #evergreen
11:11 sandbergja joined #evergreen
11:15 csharp dbs: I'm working on reviving my long-standing desire to get supported installation on RHEL/CentOS - I see that the Fedora target has stagnated for a while - do you still use it?  if not, I would probably remove it since most aren't running Fedora server for anything
11:16 csharp open to input, of course :-)
11:16 csharp and, supporting it alongside the other two would probably be doable
11:23 csharp also, looking at https://github.com/nodesource/dis​tributions/blob/master/README.md as an alternative to the way we're installing nodejs (adding a repo to install from rather than source)
11:24 csharp with the added advantage of automatic point release upgrades
11:32 Dyrcona I'd remove Fedora as an installation target. It's not mentioned in the README any more.
11:33 * Dyrcona is still looking into the acquisitions "issues since the update" which may have been there all along.
11:33 sandbergja joined #evergreen
11:37 Dyrcona The 302 of "VM15962:89 POST https://training.cwmars.org/osrf-http-translator net::ERR_INSUFFICIENT_RESOURCES" still bother me.
11:46 Dyrcona That looks like something is doing an infinite recursion.
11:47 Dyrcona Well, that's one possibility.
11:54 bshum Yeah, we removed Fedora from the install / upgrade docs back in 2017.  So it remaining as a target is just remnants / wishful thinking
11:54 bshum Every time we circle around to killing the target though, somebody decides to update the deps, so... :D
11:55 bshum I think I got pretty close to figuring out how to get it working again, but got stuck on the HTTPS config parts, since it's different on Fedora vs. Ubuntu Apache
11:58 bshum I'd only be wary against moving off of pinned Node versions because of potential dependency disruption.  I think they tend to stay pretty safe along major versions, so maybe not as worrying
11:59 Dyrcona So, reverting all of the ACQ changes from the jQuery bug fix makes no difference according to the person testing this.
12:00 bshum This whole Node thing is so fickle :)
12:00 mrisher joined #evergreen
12:00 jihpringle joined #evergreen
12:01 Dyrcona Yeah, that's why they're replacing it.
12:02 Dyrcona https://thenewstack.io/node-js-creator-blasts-node​-js-offers-a-secure-typescript-based-alternative/
12:07 csharp bshum: I figured some of that out - it was selinux being mad because we're expecting it to access files in non-standard locations
12:07 csharp but not on Fedora
12:07 csharp even though that's my OS of choice for desktop, I've never installed EG on it
12:08 Dyrcona Well, EL is Enterprise Linux and Fedora is a playground.
12:08 csharp right
12:08 csharp and no one's advocating making a target of debian sid :-)
12:08 Dyrcona Right, and for the same reason, I think Fedora should be removed.
12:09 Dyrcona Fedora and Sid are fine for desktops. Though I wouldn't really recommend Sid unless you don't mind stuff breaking occasionally.
12:10 bshum Speaking of Nodejs though, I guess on master we're doing NodeJS v12.13.0, but there's what latest of 12.17.0 ?
12:11 csharp right - it would mean we're on the 12 "channel" and would receive whatever point releases they push
12:11 Dyrcona I saw a message recently saying that a version of one of our dependencies' dependencies will break on Node 14.
12:12 csharp I just prefer the package manager wherever possible, so it's my inclination to install via repos rather than statically from source
12:12 csharp but yeah, breakage
12:12 Dyrcona Turns out it was fsevents, which is only used on Mac OS X.
12:12 csharp on the other hand, the things that are breaking probably need fixing
12:14 Dyrcona Some of the things that aren't broken yet need fixing.
12:20 mrisher joined #evergreen
12:29 mrisher joined #evergreen
12:38 mrisher joined #evergreen
12:59 sandbergja joined #evergreen
13:19 eady joined #evergreen
13:41 mrisher joined #evergreen
14:27 jvwoolf joined #evergreen
14:29 jvwoolf1 joined #evergreen
14:59 mrisher joined #evergreen
15:00 berick jeffdavis++
15:06 Dyrcona jeffdavis++ berick++
15:10 Dyrcona FYI: It looks like one cannot filter the hold notification events, since filters only apply at the process-hooks stage, and the hold notification events are created as pending, and filters are not applied with the run pending stage.
15:12 mmorgan Dyrcona++
15:12 * mmorgan was looking at that, too.
15:14 mmorgan So having separate event defs for different libraries would be the only way to break them up? Not a good solution for large consortia, though.
15:17 Dyrcona mmorgan: Yes, that's where my thoughts are heading, though I'm a bit fuzzy on how to have the separate event definitions for each member library.
15:20 * mmorgan has cloned the event owned by the consortium and changed owner to the ou for the member library. Testing this again to make sure it only creates events for the owner.
15:21 Dyrcona mmorgan: I was about to look at that as a possibility.
15:30 jeffdavis berick++
15:30 jeffdavis I can create a signoff branch but I wonder if it should be reviewed by someone more familiar with OpenSRF stuff than I am.
15:31 jeffdavis mmorgan: fwiw we have separate hold notification event defs for our different libraries. Yes, it is cumbersome. :/
15:31 Dyrcona Yes, I think setting the owner would work.
15:31 Dyrcona jeffdavis++
15:32 mmorgan jeffdavis: But handy given the current circumstances :)
15:37 Dyrcona Looks like one also has to copy the action_trigger.event_params and action_trigger.environment table entries for the new event.
15:38 mrisher joined #evergreen
15:40 mmorgan Dyrcona: Yes. Though hold notifications don't have parameters, at least ours don't.
15:40 mantis left #evergreen
15:42 Dyrcona mmorgan: Ours do, but I'm not sure that they're actually used.
15:56 collum joined #evergreen
15:58 sandbergja joined #evergreen
16:00 jlundgren joined #evergreen
16:08 collum https://git.evergreen-ils.org/?p=Eve​rgreen.git;a=blob;f=Open-ILS/web/js/​ui/default/staff/circ/holds/app.js - line 65 'legnth' instead of 'length'
16:08 collum I will submit a bug.  I'm not able to create a patch right now.
16:11 mrisher_ joined #evergreen
16:24 mmorgan Hmm. So sms hold available events are created for holds that have NULL sms_notify?
16:26 mmorgan They end up as invalid, but better if they're not created in the first place.
16:28 mmorgan Ok, bug 1096209, 7 years old :-/
16:28 pinesol Launchpad bug 7 in Launchpad itself "Need help for novice translators" [High,Fix released] https://launchpad.net/bugs/7 - Assigned to Данило Шеган (danilo)
16:28 pinesol Launchpad bug 1096209 in Evergreen "SMS functionality generates unnecessary event churn" [Undecided,Triaged] https://launchpad.net/bugs/1096209
17:00 mrisher joined #evergreen
17:04 rjackson_isl_hom joined #evergreen
17:12 mmorgan Heh. Just saw that pinesol helpfully supplied bug number seven. Obviously, that's not one I was referring, to :)
17:13 mmorgan left #evergreen
17:28 jihpringle joined #evergreen
18:01 pinesol News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>
18:05 rjackson_isl_hom joined #evergreen
18:08 jvwoolf joined #evergreen
18:54 mrisher joined #evergreen
19:01 sandbergja joined #evergreen
19:07 sandbergja joined #evergreen

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat