| Time |
Nick |
Message |
| 04:38 |
|
JBoyer_ joined #evergreen |
| 04:38 |
|
abneiman_ joined #evergreen |
| 04:39 |
|
akilsdonk joined #evergreen |
| 04:39 |
|
pinesol` joined #evergreen |
| 04:39 |
|
Bmagic_ joined #evergreen |
| 04:40 |
|
phasefx_ joined #evergreen |
| 04:41 |
|
denials joined #evergreen |
| 04:41 |
|
tsadok joined #evergreen |
| 04:42 |
|
jweston_ joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:18 |
|
rjackson_isl_hom joined #evergreen |
| 08:25 |
|
mantis joined #evergreen |
| 09:49 |
|
rfrasur joined #evergreen |
| 09:56 |
jeff |
I'm looking at a few AngularJS staff interfaces that don't catch errors, like a 500 server error. I'm sure there are many, but there's a few I'm taking a particular interest in today. |
| 09:56 |
jeff |
So far, the first I've looked at is a promise where there's a success function but no second function to handle error. |
| 09:58 |
jeff |
I can "return egAlertDialog.open(resp);" and get a red danger alert with the text of the failure ("error calling method open-ils.circ.mark_item_missing_pieces : 500 : *** Call to [open-ils.circ.mark_item_missing_pieces] failed..."), but is there another place where there is a more elegant mechanism already set up for this kind of unexpected error? I'm thinking of the XUL skull and crossbones with "send |
| 09:58 |
jeff |
this info to the helpdesk". |
| 09:58 |
jeff |
(AngularJS or Angular, I'm curious about either) |
| 09:59 |
berick |
jeff: server errors should be intercepted and logged within the core net module, followed by a promise rejection. it does not show an alert, though |
| 10:00 |
berick |
i suppose it could, though |
| 10:04 |
jeff |
Yep, most of that is happening as expected, with an additional "Possibly unhandled rejection" message after the first message. |
| 10:05 |
jeff |
(because the promise's .then() only had one argument in this case) |
| 10:12 |
jeff |
Hrm. Could I have the core net module open call egAlertDialog.open()? |
| 10:12 |
* jeff |
looks |
| 10:12 |
jeff |
There are probably places where we're handling a failure like that already, though... surfacing them ALL might be undesirable. |
| 10:12 |
jeff |
But surfacing them piecemeal seems like a bad idea also. |
| 10:13 |
berick |
hard to say. i wonder if maybe a Toast would be better. convey the info without requiring a clickthrough. |
| 10:14 |
|
jvwoolf joined #evergreen |
| 10:14 |
berick |
could play an error sound too |
| 10:14 |
jeff |
hah, I was just thinking of an amusing error sound. |
| 10:15 |
berick |
*sad trombone* |
| 10:23 |
jeff |
okay, yes. looks like I can happily call egAlertDialog within services/net.js for a method error. I might leave that in place on my test instance for a while and see what it surfaces. |
| 10:24 |
jeff |
in the case of missing pieces where I have a method error and added a second function to the promise to surface that error on that specific action, I end up with two egAlertDialogs. :-) |
| 10:32 |
jeff |
having recently upgraded, I find myself wanting a test instance with our previous version of Evergreen... oops. :-) |
| 10:40 |
|
bshum joined #evergreen |
| 10:42 |
jeff |
bah: |
| 10:42 |
jeff |
> We detected an application built with production configuration. Angular DevTools only supports development builds. |
| 10:59 |
|
mmorgan joined #evergreen |
| 11:21 |
|
abowling joined #evergreen |
| 11:47 |
|
Keith-isl joined #evergreen |
| 12:00 |
mmorgan |
berick: jeff: Any success in getting the updated Hatch to the Chrome store? |
| 12:07 |
|
jihpringle joined #evergreen |
| 12:09 |
|
mantis joined #evergreen |
| 12:13 |
mmorgan |
berick: jeff: NM, I see it's on the agenda for the dev meeting. |
| 12:18 |
|
collum joined #evergreen |
| 12:19 |
JBoyer |
Do you mean to tell me that in the year two-thousand, twenty and one that I should ever see the error message "The password is too long." ? Microsoft: "Uh..." |
| 12:19 |
JBoyer |
Also, mmorgan++ for reminding me about the dev meeting when my calendar apparently did not. |
| 12:20 |
mmorgan |
:) |
| 12:20 |
mmorgan |
yeah, technology... |
| 12:36 |
|
Dyrcona joined #evergreen |
| 12:36 |
|
Keith-isl joined #evergreen |
| 13:37 |
|
jihpringle joined #evergreen |
| 13:55 |
csharp_ |
2021-12-14 12:30:46.955 [info] <0.27953.38>@ejabberd_c2s:process_terminated:271 (tcp|<0.27953.38>) Closing c2s session for opensrf private.brick06-head.gapines.org/open-ils.actor_listener_brick06-head.gapines.org_14447: Connection failed: timeout |
| 13:55 |
csharp_ |
that^^ is the log message I get when my open-ils.actor listener dies |
| 13:56 |
csharp_ |
2021-12-14 12:31:45 brick06-head open-ils.actor: [ERR :14447:XMPPReader.pm:262:] Disconnected from Jabber server |
| 13:56 |
csharp_ |
almost a minute later |
| 13:56 |
csharp_ |
which is why it's been hard to find this |
| 13:57 |
csharp_ |
so... does anyone have ideas as to what I would look for next? |
| 13:59 |
csharp_ |
hmmm!!! |
| 13:59 |
csharp_ |
2021-12-14 12:30:46 brick06-head open-ils.actor: [INFO:115647:Server.pm:823:163950301711646611] server: child process read all available pipe data. waiting for more data from parent. bytes_needed=609599; bytes_recvd=36544 |
| 14:00 |
csharp_ |
2021-12-14 12:30:17 brick06-head gateway: [ACT:116466:osrf-websocket-stdio.c:559:163950301711646611] [127.0.0.1] [] open-ils.actor open-ils.actor.settings.retrieve.atomic ["eg.print.template.item_label_cn"], "<REDACTED>" |
| 14:02 |
jeff |
do you have logs enough now to chase down other instances of this, and see if they're all that setting? |
| 14:02 |
jeff |
it would be interesting to know that, as well as to see if you can reproduce it. |
| 14:02 |
csharp_ |
yes |
| 14:02 |
jeff |
i.e., by determining which user's setting it is, and if it reliably causes this issue. |
| 14:02 |
csharp_ |
I think this is the clue I've been looking for |
| 14:03 |
jeff |
and if there's something unusual/special about 36544 bytes into the message... |
| 14:03 |
csharp_ |
https://pastebin.com/k0JVJgv3 - that message in context |
| 14:04 |
jeff |
that's an impressively large template. |
| 14:05 |
jeff |
almost 610 kilobytes of message? |
| 14:08 |
jeff |
i wonder if you're hitting a shaper / rate limit... |
| 14:10 |
csharp_ |
I have c2s_shaper: none in my ejabberd.yml |
| 14:11 |
csharp_ |
also, strangely not finding eg.print.template.item_label_cn anywhere in my settings :-/ |
| 14:13 |
jeff |
that call will look for a user setting, workstation setting, or org unit setting (depending on various things) |
| 14:16 |
csharp_ |
huh - it's not in any of the setting_type tables |
| 14:18 |
|
mantis joined #evergreen |
| 14:20 |
* jeff |
eyes commit 6922069 |
| 14:20 |
pinesol |
jeff: [evergreen|Jason Etheridge] LP#1704873 webstaff: label printing - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6922069> |
| 14:21 |
csharp_ |
ok looks like it's a TT2 that's wrapped around settings calls |
| 14:21 |
csharp_ |
cn_wrap:settings['webstaff.cat.label.call_number_wrap_filter_width']:settings['webstaff.cat.label.call_number_wrap_filter_height']:copy['call_number.label_class'] |
| 14:22 |
csharp_ |
actually, the only variable-length piece of that would be call_number.label if I understand correctly |
| 14:22 |
csharp_ |
maybe there's a terribly large call_number.label out there somewhere? |
| 14:27 |
JBoyer |
select * from asset.call_number where is_monster_xml_mess(label) = t; |
| 14:27 |
csharp_ |
:-) |
| 14:28 |
JBoyer |
More srsly, you should hopefully be able to use the thread trace to find an authtoken and narrow down what record(s) were being worked on. |
| 14:29 |
Dyrcona |
*Should* |
| 14:29 |
jeff |
do you really have no output for this query? |
| 14:29 |
jeff |
WITH setting_types AS (SELECT 'user', name, label FROM config.org_unit_setting_type UNION SELECT 'workstation', name, label FROM config.workstation_setting_type UNION SELECT 'org_unit', name, label FROM config.org_unit_setting_type) SELECT * FROM setting_types WHERE name = 'eg.print.template.item_label_cn'; |
| 14:32 |
csharp_ |
0 rows :-/ |
| 14:33 |
csharp_ |
maybe we have a partially-implemented feature somewhere |
| 14:34 |
mmorgan |
csharp_: Not sure if/where this comes into the mix, but there are the label_prefix and label_suffix fields in asset.copy_location that get pulled into labels. Maybe there's something big there? |
| 14:36 |
csharp_ |
we don't have those really implemented - there are a few, but they all look ok |
| 14:36 |
csharp_ |
I'm finding it interesting that the only reference to select actor.get_cascade_setting_batch('{eg.print.template.item_label_cn}',272,1530615,24695); |
| 14:36 |
csharp_ |
-[ RECORD 1 ]-------------+----------------------------------------- |
| 14:36 |
csharp_ |
blah |
| 14:36 |
csharp_ |
get_cascade_setting_batch | (eg.print.template.item_label_cn,,f,f,f) |
| 14:36 |
jeff |
how about this? |
| 14:36 |
jeff |
WITH settings AS (SELECT 'user', id, name FROM actor.usr_setting UNION SELECT 'workstation', id, name FROM actor.workstation_setting UNION SELECT 'org_unit', id, name FROM actor.org_unit_setting) SELECT * FROM settings WHERE name = 'eg.print.template.item_label_cn'; |
| 14:36 |
jeff |
(with the CTE, that might take a little longer to run, depending on your postgres version) |
| 14:37 |
csharp_ |
jeff: still nada |
| 14:37 |
jeff |
yet, that's the setting that your log entry says is being requested... |
| 14:37 |
csharp_ |
the only reference I see in the EG repo to the string item_label_cn is in Open-ILS/web/js/ui/default/staff/cat/printlabels/app.js |
| 14:37 |
csharp_ |
lines 414, 445, 471 |
| 14:38 |
csharp_ |
(hopefully this is not a huge red herring/wild goose chase) |
| 14:38 |
csharp_ |
@ana mix your metaphors |
| 14:38 |
pinesol |
csharp_: Hoax yummier strop |
| 14:38 |
jeff |
there's specific mention of the setting not existing and falling back to "local, hatch only" (which isn't a think anymore in later Evergreen versions) in bug 1817932 |
| 14:38 |
pinesol |
Launchpad bug 1830391 in Evergreen 3.4 "duplicate for #1817932 Hatch omnibus circa 3.3 (Java updates and more)" [Undecided,Fix released] https://launchpad.net/bugs/1830391 |
| 14:38 |
jeff |
> core.bundle.js:1 No server setting type exists for eg.print.template.item_label_cn, using local value. |
| 14:39 |
jeff |
> Thanks, Christopher. The settings do need to be created -- some as workstation settings, some should be stored locally. I propose we open a separate LP for that. |
| 14:43 |
csharp_ |
this seems like a weird candidate for "the thing that brought PINES down"... |
| 14:44 |
csharp_ |
I want another example - I'll go hunting for another day where I know this happened and see what I find |
| 14:44 |
csharp_ |
"this" = "open-ils.actor listener died" |
| 14:46 |
mmorgan |
csharp_: fwiw, I see log entries in our production server from yesterday that reference "eg.print.template.item_label_cn" |
| 14:46 |
csharp_ |
yeah - it's in master |
| 14:47 |
mmorgan |
Nothing from today, though. |
| 14:47 |
JBoyer |
FYI, dev meeting in ~15. |
| 14:47 |
csharp_ |
we've had custom work on spine label printing done and I was staring hard at that as a factor - but still not sure it's related |
| 14:48 |
csharp_ |
if I can get this sorted before I go on vacation Friday I will be overjoyed |
| 14:48 |
JBoyer |
If someone tried to stuff a base64 image tag in there that could be pretty large, but I'm guessing most people just buy genre stickers. :) |
| 14:49 |
csharp_ |
oof - god only knows what our staff get up to |
| 14:49 |
JBoyer |
("there" being a custom label template) |
| 14:50 |
csharp_ |
we're having to smack down a library that believes amnesty checkin is Bad and is instead performing 8 concurrent emergency closures *daily* |
| 14:50 |
csharp_ |
after seeing that kind of thing for 13+ years, I'll believe anything |
| 14:51 |
csharp_ |
yesterday the DB load brought us to our knees |
| 14:51 |
JBoyer |
They could go for the hat trick and mark themselves closed 7 days a week also, I believe you start getting warnings in the logs when perl tries to parse a date in the year 3000. |
| 14:51 |
csharp_ |
I guess we can always say it's job security |
| 14:51 |
* csharp_ |
tries for a Futurama reference; fails |
| 14:52 |
JBoyer |
I've seen them high enough that I make Dune references, heh. |
| 14:52 |
csharp_ |
JBoyer++ |
| 14:52 |
JBoyer |
I believe the symptom is a storage process spinning on 100% cpu. |
| 14:53 |
csharp_ |
@blame add You MANIACS!! You blew it up! |
| 14:53 |
pinesol |
csharp_: Error: You must be registered to use this command. If you are already registered, you must either identify (using the identify command) or add a hostmask matching your current hostmask (using the "hostmask add" command). |
| 14:54 |
csharp_ |
@blame add You MANIACS!! You blew it up! |
| 14:54 |
pinesol |
csharp_: Error: Blames must contain $who. |
| 14:54 |
csharp_ |
oh hmm |
| 14:54 |
* csharp_ |
relents |
| 14:55 |
jeff |
with a large enough duration, you can break the "push to 23:59:59" trigger on action.circulation. |
| 14:56 |
jeff |
from recent upgrade notes: |
| 14:56 |
jeff |
> "psql:3.3.3-3.4.0-upgrade-db.sql:829: ERROR: integer out of range |
| 14:56 |
jeff |
CONTEXT: PL/pgSQL function action.push_circ_due_time() line 13 at IF" |
| 14:56 |
jeff |
because two circs have duration of 1546843 days and 133647235200 doesn't fit in int |
| 15:00 |
|
sandbergja joined #evergreen |
| 15:02 |
Dyrcona |
BIG INT |
| 15:03 |
JBoyer |
If (int_val > INT_MAX) {complain()} |
| 15:03 |
JBoyer |
Anyway. |
| 15:03 |
|
shulabear joined #evergreen |
| 15:03 |
JBoyer |
#startmeeting 2021-12-14 - Developer Meeting, Agenda Available at https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2021-12-14 |
| 15:03 |
pinesol |
Meeting started Tue Dec 14 15:03:57 2021 US/Eastern. The chair is JBoyer. Information about MeetBot at http://wiki.debian.org/MeetBot. |
| 15:03 |
pinesol |
Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. |
| 15:03 |
pinesol |
The meeting name has been set to '2021_12_14___developer_meeting__agenda_available_at_https___wiki_evergreen_ils_org_doku_php_id_dev_meetings_2021_12_14' |
| 15:04 |
JBoyer |
#topic Introductions |
| 15:04 |
abowling |
#info Adam Bowling, Emerald Data Networks |
| 15:04 |
JBoyer |
Hi! Who are you? |
| 15:04 |
JBoyer |
#info JBoyer = Jason Boyer, EOLI |
| 15:04 |
shulabear |
#info Shula Link, Greater Clarks Hill Regional in PINES |
| 15:04 |
gmcharlt |
#info gmcharlt = Galen Charlton, Equinox |
| 15:04 |
mmorgan |
#info mmorgan = Michele Morgan, NOBLE |
| 15:04 |
berick |
#info berick Bill Erickson, KCLS |
| 15:04 |
abowling |
#info abowling = Adam Bowling, Emerald Data Networks |
| 15:04 |
alynn26 |
#info alynn26 is Lynn Floyd, Evergreen Indiana |
| 15:04 |
phasefx_ |
#info phasefx = Jason Etheridge, EOLI |
| 15:04 |
abowling |
forgot who i was for a second |
| 15:04 |
rhamby |
#info rhamby = Rogan Hamby, EOLLI |
| 15:05 |
shulabear |
#info shulabear = Shula Link, Greater Clarks Hill Regional in PINES |
| 15:05 |
jeffdavis |
#info jeffdavis = Jeff Davis, BC Libraries Cooperative (Sitka) |
| 15:05 |
miker |
#info miker = Mike Rylander, eoli |
| 15:05 |
JBoyer |
You also type too fast for my jokes abowling. :p |
| 15:05 |
Dyrcona |
#info Dyrcona = Jason Stephenson, CW MARS |
| 15:06 |
abowling |
sorry, jboyer. i'll turn the speed knob down. |
| 15:06 |
sandbergja |
#info sandbergja = Jane Sandberg, Linn-Benton Community College |
| 15:06 |
csharp_ |
#info csharp_ = Chris Sharp, GPLS |
| 15:06 |
JBoyer |
Just need to sharpen my wit. |
| 15:07 |
abowling |
if you figure out the secret, let me in on it |
| 15:07 |
abneiman |
#info abneiman = Andrea Buntz Neiman, Equinox |
| 15:07 |
Dyrcona |
Mechanical wit, but then it runs out and you have to buy more. Plus it leaves bits all around. |
| 15:07 |
JBoyer |
Ok, people should feel free to #info up as they continue to join. |
| 15:07 |
JBoyer |
#topic Action Items from Last Meeting |
| 15:07 |
JBoyer |
#info JBoyer will test out the branch in lp 1947595 |
| 15:08 |
pinesol |
JBoyer: Error: Could not gather data from Launchpad for bug #1947595 (https://launchpad.net/bugs/1947595). The error has been logged |
| 15:08 |
JBoyer |
I'm as surprised as you all may be, but that did happen and the branch was even signed off on because it does the thing. Dyrcona ++ |
| 15:08 |
Dyrcona |
JBoyer++ |
| 15:09 |
JBoyer |
So it should be a sound base for the rest of the Pg14 stuff that we'll get to later. |
| 15:09 |
JBoyer |
Next up is |
| 15:09 |
JBoyer |
#topic OpenSRF Release Updates |
| 15:09 |
JBoyer |
With this spicy Q |
| 15:09 |
JBoyer |
#topic Is it time for OpenSRF 3.3.0? |
| 15:10 |
Dyrcona |
Well, I added the question because it came up in channel that with the Python removal or something, it was not possible to install everything from a tarball. |
| 15:10 |
JBoyer |
Oh, on Bullseye? |
| 15:10 |
Dyrcona |
Yeah, something like that. |
| 15:11 |
Dyrcona |
I figure we should either backport the Python removal or roll a 3.3.0 release and recommend that going forward, at least for newer distros. |
| 15:11 |
JBoyer |
I forgot the excise python branch wasn't already in a release. |
| 15:11 |
gmcharlt |
it's certainly time for a 3.2.3, given some of the reliability pull requests that have cropped up in the past couple weeks |
| 15:12 |
gmcharlt |
and yeah, it doesn't hurt to just get a 3.3.0 out the door ("the new OpenSRF: Now With Less!") |
| 15:12 |
Dyrcona |
:) |
| 15:13 |
Dyrcona |
Less can be a good thing. |
| 15:13 |
|
Keith-isl joined #evergreen |
| 15:13 |
gmcharlt |
looks like we have a couple minor wishlist PRs as well that could go in to 3.3.0 |
| 15:14 |
gmcharlt |
is anybody aware of anything that would be a significant new feature waiting in the wings? |
| 15:14 |
JBoyer |
I think if there's going to be a 3.2.3 that backporting the python branch would be a good idea since it isn't supported and breaks new installs. |
| 15:15 |
Dyrcona |
I'll second that. |
| 15:15 |
gmcharlt |
I disagree. provided that 3.3.0 is done at the same time, 3.2.3 can continue as a thing that can go in via a configure/make install dance |
| 15:16 |
csharp_ |
@decide The Python Branch or The No-Python Branch? |
| 15:16 |
pinesol |
csharp_: That's a tough one... |
| 15:16 |
alynn26 |
lol |
| 15:16 |
gmcharlt |
I would not expect any additional 3.2.x releases, however, barring a log4opensrf-shell situation |
| 15:16 |
berick |
heh |
| 15:16 |
JBoyer |
Of the ~50 open bugs for OpenSRF I don't think any of the major new feature contenders are near ready (I'm mostly thinking of sasl support, which I haven't touched in ages) |
| 15:16 |
Dyrcona |
Well, to be honest I'm happy either way as long as the no python code gets "released." |
| 15:17 |
Dyrcona |
Well, who says a new release has to add features? |
| 15:17 |
JBoyer |
Works for me also. 3.2.3 can be the going away present for < bullseye |
| 15:17 |
gmcharlt |
well, the wishlist PRs that could go into 3.3.0 are collectively things that look quick to review |
| 15:17 |
JBoyer |
Dyrcona, just a response to the Q asking if any others were near ready. |
| 15:17 |
gmcharlt |
so I think I'm mostly lobby for attention to several specific PRs prior to a release |
| 15:17 |
gmcharlt |
bug 1953057 |
| 15:17 |
pinesol |
Launchpad bug 1953057 in OpenSRF "Perl listener can fail to clean up children during post-crash restart" [Medium,New] https://launchpad.net/bugs/1953057 |
| 15:18 |
Dyrcona |
I think this is a problem on Ubuntu Focal also, but I usually install via git. |
| 15:18 |
gmcharlt |
bug 1953047 |
| 15:18 |
pinesol |
Launchpad bug 1953047 in OpenSRF "Perl services can crash with a "Can't kill a non-numeric process ID" error" [Medium,New] https://launchpad.net/bugs/1953047 |
| 15:18 |
gmcharlt |
and bug 1953044 |
| 15:18 |
pinesol |
Launchpad bug 1953044 in OpenSRF "Perl services can crash with a "Use of freed value in iteration" error" [Medium,Confirmed] https://launchpad.net/bugs/1953044 |
| 15:18 |
gmcharlt |
the latter two are currently in production at Equinox |
| 15:19 |
gmcharlt |
the first one is a little more prospective |
| 15:19 |
Dyrcona |
I'll see if I can make some time to test a couple of those. |
| 15:19 |
csharp_ |
these are the "think of the children!" branches you mentioned before |
| 15:19 |
gmcharlt |
yup |
| 15:21 |
JBoyer |
Sounds like a plan, hopefully all 3 of those can get some testing and make it in soon. Any other OpenSRF discussion? |
| 15:22 |
jeffdavis |
(testing some of those is on my todo list fwiw) |
| 15:22 |
JBoyer |
jeffdavis++ (and Dyrcona ++ and gmcharlt ++ ) |
| 15:22 |
JBoyer |
If not, and given the placholders holding places we can skip down to |
| 15:23 |
JBoyer |
#topic Launchpad Status |
| 15:23 |
JBoyer |
#info Snapshot |
| 15:23 |
JBoyer |
#info Open Bugs - 2566 |
| 15:23 |
JBoyer |
#info Pullrequests - 90 |
| 15:23 |
JBoyer |
#info Signedoff - 34 |
| 15:23 |
JBoyer |
#info Updates Since the November Meeting |
| 15:23 |
JBoyer |
#info Bugs Added - 63 |
| 15:23 |
JBoyer |
#info Pullrequest tag Added - 19 |
| 15:24 |
JBoyer |
#info Signedoff tag Added - 6 |
| 15:24 |
JBoyer |
#info Fix Committed - 15 |
| 15:24 |
JBoyer |
One benefit of not getting a script done is that I don't have to worry about hitting flood prevention. |
| 15:25 |
JBoyer |
And now, for something completely different |
| 15:25 |
JBoyer |
#topic New Business |
| 15:25 |
JBoyer |
#topic Further opinions re: support for Microsoft Edge |
| 15:25 |
JBoyer |
Who would like to collect these opinions |
| 15:26 |
Dyrcona |
I don't have an opinion, since I don't have any experience with Edge. |
| 15:26 |
JBoyer |
Hah. Well, it looks like I put it on the agenda. Mystery solved. |
| 15:27 |
csharp_ |
do we have a sense of how well Edge Just Works™? |
| 15:27 |
csharp_ |
and to be clear, we're talking about Edge that's based on Chrome, yes? |
| 15:27 |
Dyrcona |
I believe so. |
| 15:27 |
JBoyer |
So, with the fact that it's literally Chromium + MS sync instead of Google Sync it works pretty well. shulabear took the client for a test drive and found no potholes. |
| 15:27 |
alynn26 |
I know of several people who use it. it works great for them. |
| 15:28 |
csharp_ |
maybe support it with a huge YMMV warning? |
| 15:28 |
JBoyer |
Yeah, Not-Chromium Edge is no bueno, even for MS. |
| 15:28 |
shulabear |
I've encountered no issues with it in testing, as long as it's the Chromium version. |
| 15:28 |
csharp_ |
that's the way we support MacOS here in PINES |
| 15:28 |
csharp_ |
"feel free, but it's on you" |
| 15:29 |
mmorgan |
What does "supporting Edge" entail? |
| 15:29 |
gmcharlt |
csharp_: any brickbats tossed in your direction as a consequence, or are the Edge users happy? |
| 15:29 |
berick |
i've heard it called Chredge as clarification ;) |
| 15:29 |
csharp_ |
gmcharlt: I've heard literally nothing |
| 15:29 |
csharp_ |
lol Chredge |
| 15:30 |
JBoyer |
mmorgan, basically if something only affected Edge we would still make changes to fix it. Which we only do for things like Safari if it's the OPAC or a dev just really wants it to work. (which Safari mostly does, but I wouldn't use it for work.) |
| 15:30 |
gmcharlt |
mmorgan: IMO (a) a statement that we believe that all functionality will work on Edge and (b) if something doesn't work, it would get the same amount of general effort as a Chrome- or Firefox-specific bug |
| 15:31 |
* mmorgan |
nods |
| 15:31 |
gmcharlt |
whereas yeah, Safari currently would get no such promise |
| 15:31 |
csharp_ |
I guess Hatch should be in the mix of what "support" means too? |
| 15:32 |
JBoyer |
csharp_, it works fine as-is, just isn't yet on the Edge Extension thing. (though you can install it via the chrome web store I believe) |
| 15:32 |
csharp_ |
I don't have a strong feeling/preference either way, which I guess is effectively "yes" |
| 15:34 |
JBoyer |
It's also possible to test the Angular client with the linux version by setting CHROMIUM_BIN to the right path. (I don't actually recommend using my branch to add the edge npm launcher because there's no good way to handle missing browsers. :/ ) |
| 15:35 |
JBoyer |
I'm for it personally because it's extremely low effort and it's possible that local IT may standardize on it anyway so staff may as well know we'll make sure it works. |
| 15:36 |
alynn26 |
+1 |
| 15:36 |
gmcharlt |
+1 |
| 15:36 |
Dyrcona |
Do we want a vote? |
| 15:36 |
JBoyer |
It's been a while, why not. |
| 15:37 |
* csharp_ |
blows the dust of the #vote command |
| 15:37 |
Dyrcona |
I was thinking that we probably don't need a vote. |
| 15:37 |
JBoyer |
#startvote Should Microsoft Edge (Chromium Version) be Considered a Support Browser for the Evergreen Staff Client? yes no abstain |
| 15:37 |
pinesol |
Begin voting on: Should Microsoft Edge (Chromium Version) be Considered a Support Browser for the Evergreen Staff Client? Valid vote options are yes, no, abstain. |
| 15:37 |
pinesol |
Vote using '#vote OPTION'. Only your last vote counts. |
| 15:37 |
csharp_ |
#vote yes |
| 15:37 |
shulabear |
#vote yes |
| 15:37 |
JBoyer |
#vote yes |
| 15:37 |
abowling |
#vote yes |
| 15:37 |
miker |
#vote yes |
| 15:37 |
mmorgan |
#vote yes |
| 15:37 |
rhamby |
#vote yes |
| 15:37 |
sandbergja |
#vote yes |
| 15:38 |
berick |
#vote yes |
| 15:38 |
phasefx_ |
#vote yes |
| 15:38 |
Dyrcona |
#vote abstain |
| 15:38 |
JBoyer |
If nothing else this way we can call the discussion done and move on to the next topic. :) |
| 15:38 |
Dyrcona |
:) |
| 15:38 |
JBoyer |
#endvote |
| 15:38 |
pinesol |
Voted on "Should Microsoft Edge (Chromium Version) be Considered a Support Browser for the Evergreen Staff Client?" Results are |
| 15:38 |
pinesol |
yes (10): csharp_, shulabear, miker, abowling, berick, mmorgan, JBoyer, phasefx_, rhamby, sandbergja |
| 15:38 |
pinesol |
abstain (1): Dyrcona |
| 15:38 |
gmcharlt |
#vote yes |
| 15:38 |
gmcharlt |
(got distracted, sorry) |
| 15:39 |
JBoyer |
oops. Let the minutes show that's 11, 0, 1, not that it was a close call. :) |
| 15:39 |
JBoyer |
#topic Support for Newer PostgreSQL Versions |
| 15:39 |
JBoyer |
Dyrcona, how's things? |
| 15:40 |
Dyrcona |
Well, there are branches, one of which has been tested and signed off. |
| 15:40 |
miker |
soon to be committed :) |
| 15:40 |
Dyrcona |
mker looked at the other and had some questions about the XML changes. I'll go back an make them more consistent, using local-name() instead of namespaces. |
| 15:41 |
Dyrcona |
I'd like to get this in before the next Evergreen release. (3.9?) |
| 15:41 |
miker |
seems likely, imo |
| 15:42 |
Dyrcona |
The tests all pass, but I think there are places, like located URIs where performance suffers on newer Pg versions. |
| 15:42 |
miker |
I think I owe eyes on an old branch for that, in particular |
| 15:43 |
Dyrcona |
my three big questions are: 1. I'd like the Stretch removal branch to go in first, so that we don't have to mess with stretch prerequisites. |
| 15:43 |
JBoyer |
That shouldn't be an issue for 3.9 |
| 15:43 |
Dyrcona |
2. I'd like to make Pg 14 the default client on distros where we use the pgdg repository: Debian and Ubuntu. |
| 15:44 |
miker |
+1 |
| 15:44 |
Dyrcona |
3. I think we should make Pg 10 the default server and remove prerequisites for 9.6. |
| 15:44 |
JBoyer |
+1 to removing 9.6, though I'm less sure about preferring 10 |
| 15:44 |
Dyrcona |
Of course, Pg 10 is EOL in November 2022. |
| 15:45 |
miker |
do we want to push farther? |
| 15:45 |
Dyrcona |
Well, Pg 10 is known to work well with our current code. |
| 15:45 |
Dyrcona |
CW MARS uses 10 in produciton, fwiw. |
| 15:45 |
gmcharlt |
yeah - Pg 10 is a safer choice for a minimum at the moment |
| 15:45 |
JBoyer |
Other than the speed regressions Dyrcona noted I'd like to go up to 14 so we don't have to change as often, though 10 could certainly stay an option. |
| 15:46 |
gmcharlt |
speed regression of any sort are a significant probleml - I'd want more assurance that we've got them sorted out before pushing for new versions |
| 15:46 |
miker |
that complicates or delays dealing with some performance issues in 11+ re CTEs, but that's just timing I guess |
| 15:47 |
Dyrcona |
Well, we could remove the non-versioned db prerequisite and word the read me to recommend 10 in production environments. |
| 15:48 |
miker |
And by that I mean CTEs may need 11+ only syntax changes to avoid speed regressions |
| 15:48 |
JBoyer |
True, I kind of meant "if we can knock them out" when I said "other than these problems" :) but since we've had 9.6 and 10 available for some time we should probably have 10 and 14 available for those who want to test |
| 15:50 |
gmcharlt |
yeah, "it works" is sufficient for offering the option to install with newer versions, but I think the production recommendations need to avoid known performance regressions |
| 15:50 |
JBoyer |
I can +1 that. |
| 15:51 |
mmorgan |
+1 |
| 15:51 |
shulabear |
+1 |
| 15:53 |
Dyrcona |
I still have to do the prerequisite installation bits. I was waiting on having this conversation. :) |
| 15:54 |
Dyrcona |
So my takeway is we want to use PostgreSQL 14 Client with the option of any server 10 through 14, but recommend 10 for production. |
| 15:54 |
miker |
seem like a good summary |
| 15:55 |
miker |
Dyrcona++ |
| 15:55 |
JBoyer |
So long as the client will work as expected. I know there are problems with 9.6 clients talking to 14 dbs (some slash commands don't work anymore) but I don't know if the reverse is true. |
| 15:55 |
Dyrcona |
#action Dyrcona will finish up the branch on https://bugs.launchpad.net/evergreen/+bug/1937294 |
| 15:55 |
pinesol |
Launchpad bug 1937294 in Evergreen "Updating Evergreen for Newer PostgreSQL Versions" [Undecided,In progress] - Assigned to Jason Stephenson (jstephenson) |
| 15:55 |
JBoyer |
Dyrcona ++ |
| 15:56 |
Dyrcona |
JBoyer: Newer clients have always worked with older servers in my experience, and I think that's a promise from the PostgreSQL devs. |
| 15:56 |
sandbergja |
Dyrcona++ |
| 15:56 |
JBoyer |
That would be ideal. |
| 15:57 |
JBoyer |
better move along, we've had a busy agenda today. |
| 15:57 |
shulabear |
Dyrcona++ |
| 15:57 |
JBoyer |
#topic Migrating to Angular 12 sooner than later? |
| 15:57 |
JBoyer |
berick, how does it look? |
| 15:58 |
berick |
oh sorry |
| 15:58 |
berick |
minus a few broken unit tests, my initial Ang 12 upgrade process worked as expected |
| 15:59 |
JBoyer |
The angular update site makes it look like we can make that jump without any real code changes, which is good. |
| 15:59 |
berick |
if we want to update before EG 3.9 I'd prefer sooner than later |
| 15:59 |
sandbergja |
berick: does the linter still work? I remember something about some linting changes |
| 15:59 |
berick |
yeah, it was not such a big doeal |
| 15:59 |
berick |
sandbergja: don't recall if I tested. I can, though, when I rebase |
| 15:59 |
sandbergja |
berick++ |
| 15:59 |
sandbergja |
thanks |
| 16:00 |
berick |
ideally we could pick a merge date and me and whoever else can help will get it merged |
| 16:01 |
sandbergja |
I can be a helper, especially if it is in December or late January |
| 16:02 |
berick |
thanks sandbergja . i'll rebase and try the linter within the next week or so and reach back out |
| 16:02 |
JBoyer |
berick ++ |
| 16:02 |
berick |
any general objections to merging Ang 12 to master (only) from the group? |
| 16:02 |
JBoyer |
sandbergja ++ |
| 16:03 |
berick |
potentially before end of month |
| 16:03 |
JBoyer |
I think it's a good idea, no point in getting too far behind, especially while few are required. |
| 16:03 |
miker |
as long as there's a "do this to update your env" note, no objections from me |
| 16:04 |
berick |
yeah, there's one on the bug, but I can post to list oo |
| 16:04 |
berick |
er, too |
| 16:05 |
miker |
even just in the commit message is probably enough. just so I can go look it up again when I forget what to do :) |
| 16:05 |
berick |
can do |
| 16:05 |
JBoyer |
Sounds like a .plan. |
| 16:06 |
JBoyer |
#topic Setting up 2-factor auth for chromestoreevergreen-ils.org so we can update Hatch |
| 16:06 |
berick |
yes, I didn't feel in a position to set up the 2-factor auth |
| 16:06 |
berick |
but we need it to update the chrome store Hatch |
| 16:06 |
JBoyer |
Understandable that it's required, but annoying for our use case. |
| 16:07 |
JBoyer |
Did I see somewhere that you can have an organization with multiple separate users? That would simplify it a little |
| 16:07 |
JBoyer |
(I thought it was either berick or jeff that mentioned that) |
| 16:08 |
berick |
don't think it was me. makes sense, though |
| 16:08 |
Dyrcona |
I recall jeff saying something about that. |
| 16:09 |
JBoyer |
I suppose email isn't allowed to be the second factor? :) |
| 16:10 |
Dyrcona |
jeff said something about sharing a TOTP. |
| 16:11 |
berick |
JBoyer: phone # or auth app |
| 16:11 |
Dyrcona |
http://irc.evergreen-ils.org/evergreen/2021-12-13#i_496907 |
| 16:11 |
berick |
we need an Evergreen Headquarters phone |
| 16:11 |
JBoyer |
I figured. |
| 16:12 |
Dyrcona |
I thought he was talking about email at the time, but it is probably connected. |
| 16:13 |
berick |
https://developer.chrome.com/docs/webstore/group-publishers/ |
| 16:13 |
berick |
my concern for the moment, though, is we have lots of sites that want the new Hatch version |
| 16:13 |
berick |
it's causing real problems |
| 16:13 |
mmorgan |
Indeed!! |
| 16:13 |
berick |
re: taking time to set up group publishing |
| 16:14 |
berick |
i don't mind setting up 2FA -- if I use Authenticator IIRC it makes me scan a QR code (TOTP) which I could presumably share |
| 16:15 |
jeff |
Yep, that was my simplest suggestion. The catch is to share the token before it's in Authenticator -- it's easier. |
| 16:15 |
JBoyer |
Yeah, you could take a screenshot of it before scanning with your phone or password manager. |
| 16:16 |
JBoyer |
I'm fine with you doing that in order to get this moving, and finding a backchannel way to share the totp code with me and jeff and (I think?) csharp_ |
| 16:17 |
berick |
ok, great, I'll do that then. |
| 16:17 |
berick |
thanks for the input everyone |
| 16:17 |
JBoyer |
While we *also* setup the group publishing thing. It's annoying that it looks like we can't just use the existing group (since I thought chromewebstore@ was a group already) |
| 16:18 |
mmorgan |
berick++ |
| 16:18 |
JBoyer |
Since it'll involve evergreen-ils.org addresses, do you want to get in touch with the board berick or should I? |
| 16:19 |
berick |
JBoyer: get in touch and say what? |
| 16:19 |
jeff |
There are a lot of challenges with sharing a Google account between multiple users, though some of those issues go away if/when the shared account is in a Workspace domain. That aside, once initially set up and shared (preferably by sharing a TOTP seed), any of the trusted individuals can add one or more of their hardware tokens to the account, which then requires no further coordination other than to not |
| 16:19 |
jeff |
remove each other's keys. |
| 16:19 |
jeff |
JBoyer: that email address is an alias on lupin. |
| 16:20 |
jeff |
(whatever the address is -- not looking it up right now) |
| 16:20 |
JBoyer |
Ah, so I may be a little behind there then. Google wants a google group to do this, which can be setup since I believe evergreen-ils.org has gsuite access. |
| 16:21 |
jeff |
Ah, but you found the secret "you can only have one owner, but that one owner can be a group" bit. That's handy. |
| 16:21 |
* jeff |
scans |
| 16:22 |
jeff |
Hefty caveats. |
| 16:23 |
JBoyer |
Yeah, don't ever want to delete anything. |
| 16:26 |
jeff |
The middle ground between "carefully make a group the owner" and "share a single Google account among trusted individuals" is what I was talking about the other day, where you can add users to your Play Console developer dashboard, granting them rights (almost but not quite owners) to publish updates, etc. |
| 16:31 |
JBoyer |
Sorry, have been distracted by other things |
| 16:33 |
JBoyer |
Needing to vanish over here, I can work with the board to setup group publishing if that's what we want to going forward |
| 16:33 |
JBoyer |
Otherwise we can keep going with the shared totp code for a while. |
| 16:34 |
jeff |
keep going with shared totp seed for now would be my preference. revisit after Hatch extension update is published and come up with a plan. |
| 16:34 |
JBoyer |
jeff, can do. we can always revisit. |
| 16:36 |
berick |
Hatch extension submitted to Goog for review. They now say "it can take weeks" depending on the extension. Fun. it's never taken more than a day before, though, so fingers crossed |
| 16:36 |
alynn26 |
yea |
| 16:37 |
JBoyer |
Time for me to ghost, FF does also need updating though it seems it's less pressing than Chrome. At least there isn't an MFA requirement I can see. |
| 16:37 |
JBoyer |
#endmeeting |
| 16:37 |
pinesol |
Meeting ended Tue Dec 14 16:37:47 2021 US/Eastern. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) |
| 16:37 |
pinesol |
Minutes: http://evergreen-ils.org/meetings/evergreen/2021/evergreen.2021-12-14-15.03.html |
| 16:37 |
pinesol |
Minutes (text): http://evergreen-ils.org/meetings/evergreen/2021/evergreen.2021-12-14-15.03.txt |
| 16:37 |
pinesol |
Log: http://evergreen-ils.org/meetings/evergreen/2021/evergreen.2021-12-14-15.03.log.html |
| 16:37 |
mmorgan |
JBoyer++ |
| 16:38 |
mmorgan |
berick++ |
| 16:38 |
sandbergja |
JBoyer++ |
| 16:38 |
shulabear |
JBoyer++ |
| 16:38 |
mmorgan |
jeff++ |
| 16:38 |
alynn26 |
jboyer++ |
| 16:38 |
alynn26 |
berick++ |
| 16:38 |
miker |
jboyer++ |
| 16:38 |
|
mmorgan left #evergreen |
| 16:39 |
sandbergja |
claiming 1309 |
| 16:42 |
pinesol |
[evergreen|malexander] lp-1942645 term name uniqueness - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a11ce47> |
| 16:42 |
pinesol |
[evergreen|Jane Sandberg] LP 1942645: stamp upgrade script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e79df5d> |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
