09:36 |
|
Cocopuff2018 joined #evergreen |
09:37 |
|
jvwoolf joined #evergreen |
09:38 |
|
jvwoolf1 joined #evergreen |
09:54 |
berick |
csharp: many thanks for your testing. |
09:55 |
berick |
one thing we could do is optinally turn throttling on/off, only turn it on for testing/development, and when it hits the max it just stops and logs a bunch of info. |
09:55 |
berick |
forcing the dev to refactor |
09:57 |
berick |
or even a debug thottle mode (log only) and strict throttle mode (stop everything) |
10:04 |
Dyrcona |
Maybe we should just refactor? |
10:05 |
Dyrcona |
I was thinking about that a bit this morning before clocking in. I considered raising a related topic for the next developers' meeting, but decided not to do so at this time. |
10:06 |
berick |
Dyrcona: that's kind of my goal, is to isolate the trouble areas |
15:47 |
|
dbwells joined #evergreen |
15:55 |
csharp |
I've seen that before |
16:00 |
|
sandbergja joined #evergreen |
16:20 |
jeff |
mantis1 left, but we're printing barcodes in receipts using Hatch without issue, but we're printing those to a laser printer, not thermal receipt printer. I'm not sure I've tested printing to a receipt printer, but could. |
16:22 |
jeff |
we're using the "holds for patron" template to print available on-shelf at-this-library holds and a scannable barcode. pullers grab them off the hold shelf and check the items out on our selfchecks after scanning the barcode on the slip. |
16:22 |
jeff |
(the slips are then shredded) |
16:25 |
|
Cocopuff2018 joined #evergreen |
16:26 |
jvwoolf |
jeff: We are trying to get them to print to a thermal receipt printer. Trying to get it to print the patron barcode on the hold slip. Works without Hatch, but not with. |
16:27 |
jvwoolf |
We're also on a pretty old version of EG at this point |
01:56 |
|
awitter joined #evergreen |
06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
07:18 |
|
rjackson_isl_hom joined #evergreen |
07:51 |
|
mantis1 joined #evergreen |
08:00 |
|
mantis1 joined #evergreen |
08:40 |
|
mmorgan joined #evergreen |
08:50 |
|
collum joined #evergreen |
09:03 |
|
Dyrcona joined #evergreen |
09:57 |
Dyrcona |
Truncate action_trigger.event and a test of the daily a/t runner goes really fast. |
10:00 |
|
Christineb joined #evergreen |
10:08 |
Bmagic |
Dyrcona++ # burn it all down |
11:14 |
Dyrcona |
Well, it still takes a while to churn through 14,286 events. But collecting them into the table was really fast. :) |
11:48 |
csharp |
berick: new fix applied to PINES production - so far so good, drone-wise - I'll let you know if we hear complaints |
11:53 |
berick |
csharp: cool |
12:03 |
|
jihpringle joined #evergreen |
13:01 |
jeffdavis |
csharp++ # sometimes you gotta test in production |
13:06 |
csharp |
jeffdavis: yep, it's the only way to see if something that only emerges in production actually works! |
13:36 |
jeffdavis |
updated bug 1896285 - I think the 3.5 version is OK to go in rel_3_5 |
13:36 |
pinesol |
Launchpad bug 1896285 in Evergreen 3.5 "Use batch methods for multi-row grid actions" [Medium,Confirmed] https://launchpad.net/bugs/1896285 |
17:00 |
Bmagic |
csharp: JS cache client-side might account for the patch not "taking hold" on some workstations |
17:26 |
|
mmorgan left #evergreen |
17:49 |
|
Cocopuff2018 joined #evergreen |
18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
18:02 |
|
book` joined #evergreen |
19:04 |
|
Dyrcona joined #evergreen |
19:09 |
|
sandbergja joined #evergreen |
09:07 |
|
alynn26 joined #evergreen |
09:24 |
|
dbwells joined #evergreen |
09:54 |
|
mmorgan joined #evergreen |
09:54 |
csharp |
berick: I was able to test your patch over the weekend and it works as expected - because drone exhaustion was dire this morning, I've applied it to PINES production and am watching carefully |
09:54 |
csharp |
so far so good though |
09:55 |
csharp |
if we don't see any problems by noon or so, I'll sign off/commit |
09:57 |
berick |
csharp++ |
10:00 |
|
Cocopuff2018 joined #evergreen |
10:09 |
JBoyer |
Hi! If you haven't seen my Dev Meeting Poll on evergreen-dev or evergreen-general, it's here: https://forms.gle/ypTx2zqLbW7eVoj99 |
15:21 |
csharp |
oh? |
15:21 |
berick |
csharp: it does seem likely the patch is at fault (sigh( |
15:23 |
Dyrcona |
csharp++ # For boldly going where no Evergreen sysadmin has gone before. |
15:24 |
csharp |
Dyrcona: all while staying in my living room office for nearly a year! |
15:25 |
csharp |
berick: I rolled the patch out, but I can apply any fixes to a test server |
15:25 |
csharp |
working without the patch means I have to babysit all day long |
15:26 |
* berick |
nods |
15:30 |
|
mantis1 left #evergreen |
15:32 |
mmorgan |
So, poking at Curbside, I have hours open set as 2:00pm - 5:30pm, 4 hour appointment slots. As a patron, I'm offered appointments at 2:00am, 6:00am, 10:00am, 2:00pm. Anyone seen this problem? |
16:39 |
|
rfrasur joined #evergreen |
17:19 |
|
mmorgan left #evergreen |
17:56 |
|
Cocopuff2018 joined #evergreen |
18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
18:47 |
|
sandbergja joined #evergreen |
21:26 |
|
sandbergja joined #evergreen |
21:52 |
|
JBoyer joined #evergreen |
04:15 |
|
jamesrf joined #evergreen |
04:15 |
|
JBoyer joined #evergreen |
05:08 |
|
dbwells joined #evergreen |
06:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
07:27 |
|
rjackson_isl_hom joined #evergreen |
07:35 |
|
Dyrcona joined #evergreen |
07:38 |
|
dbwells joined #evergreen |
08:59 |
pinesol |
Launchpad bug 1901760 in Evergreen "Staff Client Whitescreen on login on all browsers on iOS/Android" [High,Confirmed] https://launchpad.net/bugs/1901760 - Assigned to Jason Stephenson (jstephenson) |
09:00 |
JBoyer |
Dyrcona++ |
09:08 |
Dyrcona |
Works on my daughter's iPad, too, but I noticed the hamburger menu options appear greyed out or at least very light, though they work. Must be a style. |
09:08 |
csharp |
seeing an issue only on our production server where the search box on the splash screen for the staff client is apparently double-URL-encoding spaces and creating things that look like "query=harry%2520potter" and showing "harry%20potter" in the search box in the staff catalog |
09:09 |
csharp |
I've chased things as far as I know how and can't see what's causing it - I'm just stumped and have been for a few days now |
09:09 |
csharp |
on the other hand, this appears to be the highest-priority issue we have right now after a major upgrade, so there's that :-) |
09:10 |
csharp |
our test versions running the same code are *not* experiencing the problem and encoding the URL params correctly |
09:11 |
Dyrcona |
All O/S and package updates applied to both sets of machines? |
09:11 |
csharp |
yes |
09:11 |
csharp |
and another factor is that production is on Ubuntu 16.04 and our test machines have been on 18.04 |
09:12 |
csharp |
I went down a rabbit hole fighting with a local VM trying to install OpenSRF last night and haven't resumed |
09:12 |
csharp |
(on 16.04) |
09:13 |
Dyrcona |
I guess something recent doesn't like 16.04, but tbh, I've seen weird behavior that just "goes away" after a clean install. (I assume this after an in place upgrade on production.) |
09:27 |
|
dbwells joined #evergreen |
09:28 |
Bmagic |
csharp: strange indeed |
09:29 |
csharp |
Dyrcona: yes - it's an in-place upgrade and we're moving to fresh 18.04 installs very soon |
09:30 |
Bmagic |
Though, I just wasted almost 2 days working a problem similar. And finally, I decided to setup a whole new test environment, fresh install DB, fresh install Application server, but otherwise identical - and the problem was no longer there! Which was a bad thing, because I couldn't diagnose it |
09:30 |
csharp |
so you're confirming my working theory - gonna keep going on my 16.04 test install |
09:31 |
csharp |
it may come down to one of those things where my cautious "don't upgrade too many things at once" strategy means I have problems I wouldn't have seen if I had gone ahead and upgraded OS along with :-/ |
09:31 |
Bmagic |
Right now, the only thing I could think of was memcached on production is caching queries and introducing the difference |
09:31 |
|
jvwoolf joined #evergreen |
09:31 |
csharp |
huh - that's interesting |
12:34 |
mmorgan |
csharp: We have been seeing the same thing on 3.6, we also applied those fixes, but are still seeing the problem. |
12:35 |
csharp |
mmorgan: good to confirm - thanks |
13:11 |
berick |
if anyone can track it down i can help fix |
13:24 |
pinesol |
[evergreen|Bill Erickson] LP1901760 Improve SharedWorker non-support handling (AngJS) - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3c1188f> |
13:24 |
pinesol |
[evergreen|Bill Erickson] LP1901760 Improve SharedWorker non-support handling (Angular) - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c9f731f> |
13:24 |
pinesol |
[evergreen|Bill Erickson] LP1901760 Remove SharedWorker testing cruft - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=66e7e45> |
13:27 |
Dyrcona |
Y'kinow with that fix that I pushed applied, your users on Android Chrome and iOS devices will not be caching settings and will not have the benefit of the fix for bug 1848550. All it takes is 1 errant client to max out the actor drones. |
13:27 |
pinesol |
Launchpad bug 1848550 in Evergreen "Cache settings more aggressively in web client" [Undecided,Fix released] https://launchpad.net/bugs/1848550 |
13:29 |
berick |
ok, yeah, it's time for a comprehensive fix. i'll open a bug to support max-parallel-requests on the client side. |
17:00 |
* berick |
cleans it up |
17:02 |
berick |
force-pushed and fixed |
17:26 |
|
mmorgan left #evergreen |
18:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
18:22 |
|
sandbergja joined #evergreen |
18:40 |
|
jvwoolf joined #evergreen |
18:47 |
|
jihpringle joined #evergreen |
02:48 |
|
AFloyd__ joined #evergreen |
04:26 |
|
AFloyd__ joined #evergreen |
05:20 |
|
rjackson_isl_hom joined #evergreen |
06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
06:48 |
|
alynn26_away joined #evergreen |
07:55 |
|
mantis1 joined #evergreen |
07:57 |
|
rfrasur joined #evergreen |
11:29 |
miker |
I'll sign off yours, JBoyer |
11:31 |
|
alynn26_away joined #evergreen |
12:07 |
|
AFloyd__ joined #evergreen |
12:16 |
Dyrcona |
So, I'm doing an fresh installation and I'm testing opensrf. When I run srfsh, I get "Unable to bootstrap client for requests." Services say they are running. What did I miss? |
12:16 |
JBoyer |
Huh, didn't realize I had removed the opac tag on that bug. opos. |
12:21 |
|
jihpringle joined #evergreen |
12:21 |
Dyrcona |
OK. In my case, I botched the domain parameter in .srfsh.xml. |
17:38 |
Bmagic |
I'll make the bug report |
17:40 |
berick |
Bmagic++ |
17:44 |
Bmagic |
berick: bug 1912699 |
17:44 |
pinesol |
Launchpad bug 1912699 in Evergreen "SIP returns multiple AVs in a 64 response message" [Undecided,New] https://launchpad.net/bugs/1912699 |
17:49 |
|
collum joined #evergreen |
18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
18:34 |
|
collum joined #evergreen |
19:36 |
|
Cocopuff2018 joined #evergreen |
19:46 |
|
dbwells joined #evergreen |
00:42 |
|
sandbergja joined #evergreen |
01:35 |
|
sandbergja joined #evergreen |
06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
07:51 |
|
rjackson_isl_hom joined #evergreen |
08:18 |
|
alynn26 joined #evergreen |
08:21 |
|
stephengwills joined #evergreen |
12:52 |
Dyrcona |
Bmagic: You had something like that happen with docker and a host name that started with a number, IIRC. |
12:53 |
Bmagic |
oh that, yep |
12:53 |
Dyrcona |
I'm getting this with autogen.sh. I don't think a numeric hostname is my issue. |
12:54 |
Dyrcona |
I guess I'll break for lunch and look at this later. I may have to set this test up on a different VM. |
12:55 |
Bmagic |
for me, autogen is where it stopped. The funny thing is that I didn't get an error from autogen. autogen simply hung while apparently waiting for a response. It wasn't until I looked at the logs that I saw the error |
12:58 |
Dyrcona |
I'll just delete the VM and build a replacement. |
13:02 |
|
jihpringle joined #evergreen |
17:21 |
|
jihpringle joined #evergreen |
17:32 |
|
Dyrcona joined #evergreen |
17:36 |
Dyrcona |
Oh. Shut the laptop lid without logging out. G'night! |
18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
18:15 |
|
RBecker joined #evergreen |
18:23 |
|
dbwells joined #evergreen |
18:26 |
|
dbwells joined #evergreen |
01:58 |
|
RBecker joined #evergreen |
04:32 |
|
mrisher joined #evergreen |
05:57 |
|
mrisher joined #evergreen |
06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
06:51 |
|
mrisher joined #evergreen |
07:22 |
|
rjackson_isl_hom joined #evergreen |
07:23 |
|
Dyrcona joined #evergreen |
09:00 |
|
stephengwills joined #evergreen |
09:05 |
rjackson_isl_hom |
Running into a selfcheck issue at a library trying to use the Get Receipt and Finish option. That never works for them, but the Quick Receipt and Continue does |
09:05 |
rjackson_isl_hom |
Has anyone run into thisand if so any workarounds? |
09:42 |
mmorgan |
rjackson_isl_hom: Is this the built in selfcheck? Just tested ours on a training server and Get Receipt and Finish worked. In what way does it not work? Does it just silently fail? |
09:43 |
rjackson_isl_hom |
according to the reporting library yes - just fails to print |
09:43 |
rjackson_isl_hom |
likewise tried locally on test server with success from home - printing to a pdf since I have no real printer |
09:44 |
rjackson_isl_hom |
and yes to the built in self check for Evergreen |
09:47 |
mmorgan |
rjackson_isl_hom: The selfcheck receipts are action triggers. Could the problem be with the trigger? |
09:47 |
rjackson_isl_hom |
are they defined with a default and then possibly one per branch if so desired? |
09:50 |
Dyrcona |
It's sad that consider 8 "not connected to the network" errors in the past half hour to be normal. |
10:19 |
Dyrcona |
Just had conflict markers on a cherry-pick that make no sense. |
10:45 |
csharp |
it get's really fun if you miss a conflict and then see the conflict markers in the file when resolving subsequent conflicts :-) |
10:52 |
Dyrcona |
FYI I was making this branch: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/dyrcona/lp1879983_curbside_pickup_pr_rel_3_5_2 |
10:55 |
Dyrcona |
I'm using that as a basis for an upgrade branch for one of our test VMs and our training server. |
10:58 |
stephengwills |
I’m trying to write an angular component to pull metadata from an union catalog api and display it in the staff client. the service shows the data arriving but the component doesn’t mange to put it in the template. I’d appreciate a little coaching on what i’m doing wrong. |
10:58 |
pastebot |
"stephengwills" at 168.25.130.30 pasted "post external api issue" (144 lines) at http://paste.evergreen-ils.org/10076 |
10:59 |
|
collum joined #evergreen |
11:43 |
berick |
yeah, we have a few |
11:46 |
Bmagic |
I would guess most people do. Those that have been using Evergreen acq for a few years |
11:57 |
Bmagic |
berick: bug 1911786 |
11:57 |
pinesol |
Launchpad bug 1911786 in Evergreen "EDI Order Pusher needs tighter control over PO selection" [Undecided,New] https://launchpad.net/bugs/1911786 |
12:19 |
|
jihpringle92 joined #evergreen |
14:01 |
|
sandbergja joined #evergreen |
16:30 |
|
laurie joined #evergreen |
17:21 |
|
mmorgan left #evergreen |
18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
19:05 |
|
Christineb joined #evergreen |
19:05 |
|
troy__ joined #evergreen |
19:05 |
|
jeffdavis joined #evergreen |
01:33 |
|
sandbergja joined #evergreen |
06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
07:09 |
|
rjackson_isl_hom joined #evergreen |
08:03 |
|
mantis1 joined #evergreen |
08:29 |
|
alynn26 joined #evergreen |
09:55 |
|
jvwoolf left #evergreen |
09:59 |
JBoyer |
uuuuggghhhhh.... that one is a hassle. Given that there isn't a great way to keep it current it would ideally get a rapid check and commit shortly after rebasing. Also I don't know what state the bootstrap opac is in but at this point that should just be another bug. (That one should probably have been split into staff / opac anyway, especially since I don't know what needs done now for the Angular client...) |
10:00 |
|
Cocopuff2018 joined #evergreen |
10:04 |
Dyrcona |
Maybe it should wait until right around the 3.7 RC to be rebased, tested, and pushed? |
10:05 |
JBoyer |
That would probably be good. I'll also need to reign it in to maybe just cover the TPAC (maybe bootstrap, we'll see), staff login, and the patron editor to hit the really important bits. |
10:06 |
JBoyer |
Not sure why I thought a single 100+ file patch was a good idea. :D |
10:09 |
Dyrcona |
Meh. |
15:17 |
berick |
that's the last branch on that LP that's awaiting signoff |
15:17 |
jeffdavis |
aha! I should read these bugs I file more closely |
15:17 |
berick |
heh, well, that was from a comment csharp made |
15:17 |
jeffdavis |
berick++ csharp++ |
15:19 |
jeffdavis |
I'll try to get that tested today if I can tear myself away from US news updates |
15:21 |
berick |
heh |
15:21 |
berick |
we aim to entertain |
15:34 |
|
mantis1 left #evergreen |
16:08 |
|
khuckins joined #evergreen |
16:30 |
|
sandbergja joined #evergreen |
17:06 |
|
mmorgan left #evergreen |
18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
19:35 |
|
sandbergja joined #evergreen |
01:02 |
|
alynn26_away joined #evergreen |
03:40 |
|
alynn26 joined #evergreen |
06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
06:40 |
|
alynn26 joined #evergreen |
07:15 |
|
rjackson_isl_hom joined #evergreen |
07:27 |
|
collum joined #evergreen |
13:42 |
tlittle |
the org units are set up. I am totally stumped (a) why it works at all, and (b) why it works for most of them but not this one |
13:43 |
sandbergja |
:-( :-( :-( |
13:43 |
tlittle |
Thank you for looking for me, though! EDI is just deciding to be a real special snowflake, bless its heart... |
13:43 |
sandbergja |
edi-- |
13:54 |
sandbergja |
tlittle: do you have access to run the edi_reader support script? |
13:54 |
sandbergja |
in the test folder |
13:54 |
sandbergja |
this doodad: https://github.com/evergreen-library-system/Evergreen/blob/master/Open-ILS/src/support-scripts/test-scripts/edi_reader.pl |
13:54 |
csharp |
pretty sure she does... |
13:55 |
tlittle |
Ooh, interesting. |
13:55 |
csharp |
I may have added a bash wrapper for that |
13:56 |
sandbergja |
but maybe it will help in seeing the EDI message through Evergreen's eyes, so to speak |
13:56 |
tlittle |
sandbergja That's a great idea, I will totally try that |
13:56 |
tlittle |
sandbergja++ |
13:56 |
csharp |
oh - I'm thinking of the EDI order pusher in test mode |
13:57 |
csharp |
easy enough to do though, probably |
13:58 |
pinesol |
[evergreen|Bill Erickson] LP1846042 Angular grid filters display streamlining - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=dfa5de2> |
13:58 |
pinesol |
[evergreen|Galen Charlton] LP#1846042: turn on grid filtering for Angular admin pages - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=770689d> |
13:58 |
pinesol |
[evergreen|Galen Charlton] LP#1846042: take advantage of ngbDropdown container="body" - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=33f9590> |
15:11 |
JBoyer |
Sounds good. mmorgan++ |
15:12 |
mmorgan |
I could certainly have included more :) but 10 seemed a reasonable number. |
15:12 |
JBoyer |
Well, this morning I was messing with LP searches and came up with these: |
15:12 |
JBoyer |
#link https://bugs.launchpad.net/evergreen/+bugs?orderby=-importance&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.tag=pullrequest+-signedoff+-needsrepatch&field.tags_combinator=ALL LPs with pullrequests ready to test |
15:12 |
JBoyer |
and |
15:12 |
JBoyer |
#link https://bugs.launchpad.net/evergreen/+bugs?orderby=-importance&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.tag=pullrequest+signedoff+-needsrepatch&field.tags_combinator=ALL LPs with signedoff branches ready to look over + push if good |
15:13 |
csharp |
holy craznap |
15:13 |
JBoyer |
So if 10 bugs isn't enough challenge folks can look through around 130+ there, heh. |
15:13 |
JBoyer |
Those are, believe it or not, significantly shorter than they started. |
15:13 |
mmorgan |
JBoyer++ |
15:14 |
terranm |
Yeah, we tested a lot during the last few bugsquash/feedback fests |
15:14 |
JBoyer |
Which kind of winds us around to the topic I mentioned briefly in my email reminder this morning. |
15:15 |
JBoyer |
#topic How can these meetings be made more effective / beneficial |
15:15 |
|
Topic for #evergreen is now How can these meetings be made more effective / beneficial (Meeting topic: 2021-01-05 - Developer Meeting, Agenda Available at https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2021-01-05) |
15:22 |
sandbergja |
If we want to have a lot of discussion sometime, we could always have a topic like "Should we move to Github, Gitlab, etc." :-) |
15:22 |
csharp |
or this agenda item: finally settle the self-hosted gitolite vs. other options thing |
15:22 |
csharp |
jinx |
15:23 |
sandbergja |
Or strategizing on improving test coverage, since that always comes up, but we never really make a plan about it |
15:23 |
JBoyer |
Ugh. Yeah. That one only seems to get real traction when discussed in person. |
15:24 |
csharp |
moving onto another git platform would offer built-in testing stuff too, which would affect sandbergja's idea there |
15:24 |
JBoyer |
There was a rough consensus around GitHub during the hackaway, so that's kind of progress. (*If* we're moving, we know where to. :D ) |
15:24 |
terranm |
It might be a good idea to have a status update on numbers of commits, new bug reports, etc. each month. |
15:25 |
mmorgan |
+1 |
15:45 |
mmorgan |
It's frustrating when digging through code only to realize what you're looking at is not used anymore |
15:45 |
JBoyer |
And potential refactoring. Are there perl mods we're no longer using, are there any we're using very little of and can be written-out, etc. Fewer dependencies, fewer bugs we didn't write. ;) |
15:45 |
sandbergja |
Very true |
15:46 |
terranm |
Next Feedback Fest is Feb 8-12, and my goal is to load as many patches for testing as possible again |
15:46 |
JBoyer |
(to a point. Anyone that suggests "roll our own crypto!" gets put in time out.) |
15:46 |
JBoyer |
terranm++ |
15:46 |
sandbergja |
I nominate dead code removal + refactoring desires as a discussion item for the February meeting |
17:00 |
|
sandbergja_ joined #evergreen |
17:13 |
|
mmorgan left #evergreen |
17:36 |
|
rjackson_isl_hom joined #evergreen |
18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
19:15 |
|
sandbergja_ joined #evergreen |
20:13 |
pinesol |
Showing latest 5 of 14 commits to Evergreen... |
20:13 |
pinesol |
[evergreen|Bill Erickson] LP1889128 Clear patron barcode on staff hold - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9c1b15d> |
20:13 |
pinesol |
[evergreen|Bill Erickson] LP1889128 Support user settings for SMS prefs - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9b683dd> |
20:13 |
pinesol |
[evergreen|Bill Erickson] LP1889128 <eg-date-select/> clearable via model - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=044b4de> |
20:13 |
pinesol |
[evergreen|Bill Erickson] LP1889128 Activation date repair and form reset handling - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9ff0d6f> |
20:13 |
pinesol |
[evergreen|Jane Sandberg] LP1889128 (follow-up) associating inputs and labels - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d8666c0> |
20:29 |
|
sandbergja_ joined #evergreen |
21:49 |
|
sandbergja_ joined #evergreen |
00:46 |
|
sandbergja joined #evergreen |
06:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
07:16 |
|
rjackson_isl_hom joined #evergreen |
07:49 |
|
collum joined #evergreen |
08:08 |
|
rlefaive joined #evergreen |
11:25 |
pinesol |
Dyrcona: Quote #210: "<Dyrcona> Axiom #2: Never take vacation, you'll return with too much work to do." (added by csharp at 09:33 AM, November 24, 2020) |
11:27 |
mmorgan |
Also true that the first full work week after two short work weeks must be the longest work week of the year. |
11:31 |
rhamby |
mmorgan - agreed |
11:33 |
csharp |
berick: thanks - I'm ready to test again whenever you're ready |
11:51 |
|
mrisher joined #evergreen |
11:53 |
mmorgan |
collum++ # Signoffs! |
12:09 |
|
jihpringle joined #evergreen |
12:12 |
berick |
csharp: https://bugs.launchpad.net/evergreen/+bug/1901760/comments/7 |
12:12 |
pinesol |
Launchpad bug 1901760 in Evergreen "Staff Client Whitescreen on login on all browsers on iOS/Android" [High,Confirmed] |
12:23 |
csharp |
berick: awesome - will test asap |
12:33 |
mmorgan |
berick++ csharp++ |
13:52 |
csharp |
after tinkering with opensrf configs, routers are dying off after seeming to start successfully |
13:52 |
csharp |
nothing at all in opensrf logs sys/warn/error that look related |
16:38 |
csharp |
berick++ Dyrcona++ # helping me think it out! |
16:38 |
berick |
yay |
16:38 |
csharp |
@who has a case of the Mondays? |
16:38 |
pinesol |
eby has a case of the Mondays. |
17:06 |
|
mmorgan left #evergreen |
18:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
18:23 |
|
mantis1 joined #evergreen |
18:24 |
|
mantis1 left #evergreen |
22:47 |
|
whatthebutzman joined #evergreen |
05:37 |
|
rjackson_isl_hom joined #evergreen |
06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
08:34 |
|
rfrasur joined #evergreen |
08:35 |
|
mmorgan joined #evergreen |
08:37 |
|
mantis1 joined #evergreen |
12:43 |
|
mantis1 left #evergreen |
13:45 |
|
Cocopuff2018 joined #evergreen |
16:50 |
|
Cocopuff2018 joined #evergreen |
16:53 |
mmorgan |
Not sure who's around, but how much hard drive space to folks have on their laptops? |
16:55 |
mmorgan |
Put another way, how much is generally recommended when running vms for testing? |
17:11 |
|
mmorgan left #evergreen |
17:37 |
|
sandbergja joined #evergreen |
18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
19:49 |
|
sandbergja joined #evergreen |
21:13 |
|
sandbergja joined #evergreen |
22:21 |
|
sandbergja joined #evergreen |
11:22 |
Dyrcona |
Maybe I'll just simplify this logic... |
11:23 |
|
stephengwills joined #evergreen |
11:24 |
Dyrcona |
And, my real problem is that I made changes in master and applied them to a custom 3.2 template.....Things are very different.... |
11:24 |
Dyrcona |
So, I'll test on a 3.6.1 VM... |
11:26 |
Dyrcona |
I wonder if bootstrap OPAC will need a similar fix? |
11:30 |
Dyrcona |
So, it must be some customization.... |
11:32 |
Dyrcona |
Grrr......... customization-- |
16:23 |
csharp |
I'm finally walking away - back on 1/4/21 |
16:24 |
csharp |
everyone have a great holiday! |
16:43 |
jeff |
OpenILS::Application::get_org_tree has a process-local cache of the org tree by locale. I don't think anything clears it other than a fresh process. |
16:52 |
pinesol |
News from qatests: Failed Installing OpenSRF pre-requisites <http://testing.evergreen-ils.org/~live//archive/2020-12/2020-12-18_16:00:03/test.7.html> |
17:26 |
|
mmorgan left #evergreen |
17:49 |
|
sandbergja joined #evergreen |
18:06 |
jeff |
er, that should be OpenILS::Application::AppUtils::get_org_tree |
03:45 |
|
dwebster joined #evergreen |
04:56 |
|
rjackson_isl_hom joined #evergreen |
05:51 |
|
dbwells_ joined #evergreen |
06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
07:33 |
csharp |
jeffdavis: sorry, I lost internet right around the time you asked me that about https://bugs.launchpad.net/evergreen/+bug/1896285/comments/7 - berick said he was able to reproduce it. I believe it happens when catalogers create a bunch of new copies in the volcopy editor for a library that is not the workstation's branch |
07:33 |
pinesol |
Launchpad bug 1896285 in Evergreen "Use batch methods for multi-row grid actions" [Medium,Confirmed] - Assigned to Bill Erickson (berick) |
08:00 |
rjackson_isl_hom |
are other consortia with large pull lists running into bug https://bugs.launchpad.net/evergreen/+bug/1768022 |
11:07 |
rjackson_isl_hom |
s/elast/least |
11:42 |
|
sandbergja joined #evergreen |
12:06 |
|
terranm joined #evergreen |
12:11 |
terranm |
It appears as of 3.5 that the staff client can't be used on any mobile device - we're definitely seeing this in our 3.6 testing (on our test servers as well as the community demo server) - https://bugs.launchpad.net/evergreen/+bug/1901760 |
12:11 |
pinesol |
Launchpad bug 1901760 in Evergreen "Staff Client Whitescreen on login on all browsers on iOS/Android" [High,Confirmed] |
12:11 |
terranm |
Anyone have any thoughts? |
12:17 |
|
jihpringle joined #evergreen |
12:35 |
* jeff |
nods |
12:36 |
jeff |
indeed, much of the code that mentions shared workers appears to at least acknowledge the idea that not all browsers will support them. |
12:36 |
berick |
right |
12:36 |
jeff |
However it wouldn't surprise me if that's lightly tested. |
12:37 |
Dyrcona |
Yeah, what jeff said. I just logged into training with Firefox on Android 10. |
12:37 |
Dyrcona |
It's running 3.6.1. |
12:37 |
jeff |
eg2 also uses a shared worker for IndexDB in Open-ILS/src/eg2/src/app/core/db-store.service.ts, I think? |
13:37 |
tlittle |
I was deciding whether or not I should post it here haha |
13:37 |
JBoyer |
tlittle++ :D |
13:38 |
JBoyer |
On the barcode front, I'd also prefer a bluetooth scanner, but I *think* both Android and iOS have custom keyboards available that can do the scanning without specialized hardware. |
13:39 |
terranm |
The one I tested before for Android was "Barcode & QR code Keyboard" by Nikola Antonov but there are a bunch now. At the time, iOS didn't have one, but it looks like they do no |
13:39 |
terranm |
*now |
13:41 |
Dyrcona |
terranm: Thanks. I may give that keyboard a whirl to see how well that works. |
13:41 |
terranm |
I found out the hard way that a lot of scanners marketed as bluetooth scanners only communicate between the scanner and a piece of scanner equipment connected to a computer via USB, they would not communicate with a phone |
13:42 |
terranm |
That was probably 2 years ago, so hopefully there is something better now |
13:43 |
Dyrcona |
Well, I wasn't thinking of getting a bluetooth scanner for myself. Just thinking out loud that it would be the "better" option. |
13:43 |
terranm |
+1 |
13:44 |
terranm |
We were trying to find more efficient ways to do inventory at the time I was testing |
13:46 |
|
nfBurton joined #evergreen |
13:46 |
|
tlittle1 joined #evergreen |
13:48 |
Dyrcona |
Yes, that a mobile device would be useful for inventory. |
16:30 |
|
sandbergja joined #evergreen |
17:02 |
|
mmorgan left #evergreen |
17:14 |
|
dwebster joined #evergreen |
18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
01:36 |
|
mrisher_ joined #evergreen |
01:41 |
|
mrisher joined #evergreen |
06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
06:55 |
|
rjackson_isl_hom joined #evergreen |
08:00 |
|
mmorgan joined #evergreen |
08:00 |
|
alynn26 joined #evergreen |
15:03 |
rjackson_isl_hom |
csharp++ - our local IT professional (not me) found that little tid bit of knowledge) |
15:03 |
Dyrcona |
I use a bash script to start websocketd. It basically just runs the websocketd command line in the background. |
15:03 |
csharp |
great |
15:07 |
rjackson_isl_hom |
initially ran a test (in production) without the websocketd to reboot all application servers and that went over like a lead balloon |
15:08 |
Dyrcona |
I'm not a huge fans of systemd, but I may go that route in the future. |
15:08 |
Dyrcona |
Well, the OPAC should work just fine without websocketd. |
15:08 |
Dyrcona |
The web staff client needs it. |
15:19 |
Dyrcona |
If you're running the proxy and Apache on the same machine, then there's almost 0 risk of snooping. |
15:20 |
Dyrcona |
If you're running the proxy on a front end and passing traffic over the LAN, then it's as safe as your LAN, so you may want to keep that encrypted. Depends on your local security and level of paranoia. |
15:20 |
Dyrcona |
I actually think that haproxy would be usable for if it was not encrypting the connections to Apache. |
15:20 |
JBoyer |
Makes local testing way easier too, since Chrome won't complain about self-signed certs |
15:20 |
Dyrcona |
s/(for)/\1 us/ |
15:22 |
Dyrcona |
Guess I'll file a Lp bug about it...Maybe today, maybe tomorrow. |
15:23 |
JBoyer |
I filed one at some point, but LP gonna LP. |
15:35 |
Dyrcona |
jeffdavis: We're using ldirectord with nginx and apache on each brick. |
15:36 |
Dyrcona |
With haproxy in front, you shouldn't need nginx. (I tried that but found it killed our performance.) |
15:36 |
Dyrcona |
Maybe ldirectord is breaking things.... |
15:37 |
Dyrcona |
I did set up a test set of VMs with haproxy in front on a a pair of load balancers and just apache on the brick vms, and that worked fine. But when I put it in production, things were noticeably slower. |
15:38 |
Dyrcona |
Anyway....I'll do some more looking unless something comes up tomorrow. |
15:40 |
|
Cocopuff2018 joined #evergreen |
15:40 |
Dyrcona |
Hmm... set_real_ip_from. That may be what's missing. |