| 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//archive/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/distributions/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=Evergreen.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 |
