| Time |
Nick |
Message |
| 00:09 |
|
sandbergja joined #evergreen |
| 03:35 |
|
sandbergja joined #evergreen |
| 07:00 |
|
agoben joined #evergreen |
| 07:09 |
|
rjackson_isl joined #evergreen |
| 07:30 |
|
Dyrcona joined #evergreen |
| 07:31 |
|
rfrasur joined #evergreen |
| 08:04 |
|
_bott_ joined #evergreen |
| 08:11 |
|
gmcharlt joined #evergreen |
| 08:51 |
|
mmorgan joined #evergreen |
| 09:06 |
|
yboston joined #evergreen |
| 09:33 |
|
jvwoolf joined #evergreen |
| 09:34 |
mmorgan |
IDL question: the source ahopl is a query written directly in the xml, is there an advantage/disadvantage to that vs. linking to a view defined in the database? |
| 09:41 |
Dyrcona |
mmorgan: I don't think so, other than where the "view" is defined. There may be some benefit to having a view in the database versus running a query. A database view is accessible from SQL whereas a query defined in the IDL isn't. (You'd have to copy and paste the query to use it.) |
| 09:42 |
* Dyrcona |
isn't exactly the IDL expert.... |
| 09:42 |
mmorgan |
@who is the IDL expert? |
| 09:42 |
pinesol |
troy__ is the IDL expert. |
| 09:43 |
troy__ |
i'll have to disagree on that |
| 09:43 |
mmorgan |
:) |
| 09:44 |
mmorgan |
So other than it being more accessible for direct queries on the db, there's no difference in performance? |
| 09:51 |
|
sandbergja joined #evergreen |
| 09:52 |
mmorgan |
In terms of development/bug fixing, would IDL changes be less straightforward than db changes, since many sites have customized the IDL? |
| 09:54 |
Dyrcona |
mmorgan: There may be some performance benefit to a view in the database. I'm not sure, but I can imagine that postgres may be able to optimize views better than queries that come and go. /me isn't exactly a postgres expert, either. |
| 09:55 |
Dyrcona |
It might make upgrades easier to use a view, but sites that customize the IDL *should* be aware of the risks. |
| 09:56 |
mmorgan |
Dyrcona: Thanks for weighing in. |
| 09:56 |
mmorgan |
Dyrcona++ |
| 09:56 |
Dyrcona |
We typically don't mess with existing entries, other than fix some bugs with missing fields/links that usually make it into later releases. We add custom entries, though, typically with custom views in the database behind them. |
| 09:57 |
Dyrcona |
And, most of those custom entries are for reports, and were added by some other than me, a someone who doesn't work here any more. I could check and see if we have any that use SQL in the IDL, but it would be only 1 or 2 if we do. |
| 09:58 |
Dyrcona |
So, after all of that being said, I guess my preference is for views in the database, though I don't think there's much technical difference. :) |
| 10:00 |
* Dyrcona |
is figuring out networking for a test environment. I think I need a custom bridge for the external ip address to be shared by the load balancing vms. |
| 10:00 |
mmorgan |
Seems like many paths are used to get data from the db to the end user, and it would be useful to know what the best practice should be. |
| 10:00 |
|
yboston joined #evergreen |
| 10:02 |
Dyrcona |
I added a view for removing patrons from libraries that are no longer members. The view is basically open billing summary with the org unit where the money is owed added in. It's for keeping patrons who owe money to other member libraries. |
| 10:03 |
Dyrcona |
I considered adding it to the IDL so I could us it from Perl. I should probably do that and blog about it as an example of adding and using IDL entries. Someone might find it useful. :) |
| 10:04 |
Dyrcona |
But, time is not my friend. |
| 10:04 |
csharp |
@band |
| 10:04 |
pinesol |
csharp: Wrong Bug |
| 10:06 |
berick |
mmorgan: i prefer in-database views since they can be executed from psql and modifications are easier to deploy |
| 10:07 |
mmorgan |
Makes sense. |
| 10:10 |
Dyrcona |
Hmm..... |
| 10:10 |
Dyrcona |
@decide 32 or 64 |
| 10:10 |
pinesol |
Dyrcona: go with 32 |
| 10:10 |
Dyrcona |
All right, I will! |
| 10:10 |
* Dyrcona |
tries to figure out if he wants 32GB or 64GB of RAM for a postgresql vm. |
| 10:11 |
* Dyrcona |
can always increase it later. |
| 10:12 |
Dyrcona |
There won't be enough free disk space to run a full copy of production data anyway, so might as well stick to concerto. |
| 10:21 |
|
sandbergja joined #evergreen |
| 10:36 |
mmorgan |
cache-- |
| 10:38 |
Dyrcona |
perl-- |
| 10:41 |
JBoyer |
re: the block list discussion yesterday afternoon: I personally don't see any value in maintaining that list at all. I can't believe the amount of effort and time involved in developing it / keeping it current / wedging it into a browser client, etc. will ever be offset by the potential cost of items kept from users that are on it. |
| 10:42 |
csharp |
JBoyer: I've been trying to make that case here for years, even before the web client was developed, but people take it very seriously here |
| 10:43 |
Dyrcona |
mmorgan: You can change the cache settings in the Apache configuration, and I'd recommend it, though I haven't done it, yet. Commit 1cb0d8c doesn't seem to take much into consideration except that we can cache bust some things in the OPAC. |
| 10:43 |
pinesol |
Dyrcona: [evergreen|Dan Scott] LP#1681095 Set aggressive default cache expires timelines - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1cb0d8c> |
| 10:43 |
csharp |
fortunately *knocks on wood*, we haven't needed offline that much in recent years |
| 10:43 |
* mmorgan |
agrees with JBoyer. We have never used it and don't generate it. |
| 10:43 |
rfrasur |
JBoyer++ |
| 10:43 |
* mmorgan |
doesn't understand you a circ staff member can tell a patron they can't check out something, but they can't say why. |
| 10:44 |
mmorgan |
s/you/how |
| 10:44 |
csharp |
our frontline staff is convinced all the baddies out there will know they're offline and come clean out the library using blocked cards :-/ |
| 10:44 |
mmorgan |
Dyrcona: Yes, on the list of things to look at. |
| 10:44 |
* rfrasur |
laughs |
| 10:44 |
JBoyer |
I know there's a certain... segment of the profession that takes a very hardline, rule bound, punitive view of things passing over the desk. I'm not all "Free books for everyone, I sure hope some come back. :D" but there is a middle ground that I'm not sure some libraries will accept until there are some retirements. |
| 10:45 |
rfrasur |
There's a mms that goes out letting the "baddies" know. "Today, we go to the library to borrow all the stuff we're not supposed to." |
| 10:45 |
berick |
rfrasur: nah, they just cut the fiber |
| 10:45 |
rfrasur |
berick: nefarious but cool |
| 10:46 |
berick |
oh they're def. smoking cigarettes the whole time |
| 10:46 |
JBoyer |
berick++ # haha |
| 10:46 |
* csharp |
imagines an Oceans 11-style movie based on this idea... |
| 10:46 |
rfrasur |
Noooo. Not the cigarettes! |
| 10:47 |
rfrasur |
What a degenerate generation. I can't even. |
| 10:50 |
csharp |
JBoyer: I agree with you - I think the fact that no one has been able to use it for the last year and 3/4ths has probably dissolved the myths, but I'm not sure |
| 10:50 |
|
yboston joined #evergreen |
| 10:50 |
Dyrcona |
Speaking of offline and cutting fiber: I've got my heartbeat/ha issues ironed out, except that ldirectord is still gobbling up RAM. |
| 10:50 |
csharp |
sometimes lack of tickets doesn't actually mean no one cares :-) |
| 10:51 |
JBoyer |
Corrective action through inaction. I can handle that. ;) |
| 10:51 |
berick |
we just need to replace the offline list with old timey wanted posters |
| 10:51 |
Dyrcona |
And, this test setup that I've been mumbling about is to try out haproxy and keepalived. |
| 10:51 |
Dyrcona |
berick++ |
| 10:51 |
Dyrcona |
Though when one asks me for an ILS recommendation, I suggest a card catalog and paper log book. :) |
| 10:51 |
JBoyer |
This here's the DVD kid. Only comes in on down days, really likes the wrasslin' DVDs. |
| 10:52 |
rfrasur |
and cigarettes. wrasslin' and cigarettes |
| 10:52 |
* berick |
blows smoke from a dvd player |
| 10:53 |
* Dyrcona |
checks if we're still generating the offline block list because he doesn't remember, and also wants to change something in one of the crontabs anyway.... |
| 10:53 |
* csharp |
whistles The Good, The Bad, and The Ugly theme |
| 10:55 |
Dyrcona |
Ours is *only* around 20MB in size. |
| 10:55 |
miker |
mmorgan / Dyrcona: re the in-IDL "views", at least in earlier versions, a view can create a hard optimization boundary in PG, meaning that it's actually more optimizable if in-IDL. I think ahopl and friends are cases of that. there's also a maintenance advantage in the form of not having to touch the DB for updates, but that's subjective, admittedly. |
| 11:00 |
Dyrcona |
miker: I'm not sure how Pg optimization works, so... |
| 11:01 |
csharp |
not sure anyone really knows :-) |
| 11:02 |
mmorgan |
miker: Ok, good to know, so there may be some performance benefits if the in-IDL view is large? |
| 11:02 |
mmorgan |
as in lots of data. |
| 11:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 11:02 |
csharp |
to de-snark that, I'll clarify that my attempts to optimize things have mostly been unsuccessful despite following docs and expert advice :-/ |
| 11:03 |
miker |
mmorgan: s/large/complicated/ (usually correlated, obv), yep |
| 11:03 |
Dyrcona |
csharp: same here.... I've considered suggesting we hire a consultant to check our Pg configuration. |
| 11:05 |
Dyrcona |
Pro Tip: Don't get your branches reversed when doing a rebase, you may end up confused with broken branches. |
| 11:05 |
csharp |
yeah - we tried that a few years ago with an unknown-to-me consultant through our tech vendor but it wasn't successful either, and it took so much trouble to set that up that I haven't come back around to it |
| 11:06 |
csharp |
Dyrcona: that's why I always branch both the source and dest branches because I can never remember the syntax :-P |
| 11:06 |
Dyrcona |
csharp: Well, I was rebasing on 2 local branches, so I could reset the one that I messed up. |
| 11:07 |
Dyrcona |
Lesson learned: Don't text and rebase. :) |
| 11:08 |
csharp |
heh |
| 11:08 |
mmorgan |
...and don't cross the streams. |
| 11:08 |
Dyrcona |
Also, maybe I should have fewer branches... |
| 11:08 |
csharp |
so much wisdom we still learn from Ghostbusters :-) |
| 11:08 |
csharp |
e.g., "when someone asks you if you're a god, say YES!" |
| 11:09 |
Dyrcona |
git branch | wc -l says 57 |
| 11:09 |
csharp |
@decide vim or bim |
| 11:09 |
pinesol |
csharp: go with vim |
| 11:10 |
|
sandbergja joined #evergreen |
| 11:11 |
csharp |
pinesol: but the keys are right beside each other! |
| 11:11 |
pinesol |
csharp: Must be because I had the flu for Christmas. |
| 11:20 |
* Dyrcona |
decides not to comment on bug 1845668 |
| 11:20 |
pinesol |
Launchpad bug 1845668 in Evergreen "Large Block lists causes browser to close. Exit. Gone. Nadda" [Undecided,New] https://launchpad.net/bugs/1845668 |
| 11:21 |
Dyrcona |
BTW, Bmagic, that's a bug in the browser, not our fault. |
| 11:21 |
Bmagic |
I can agree with that |
| 11:22 |
* Dyrcona |
is always amused when people who use Chrome and/or Firefox complain to him that GNU Emacs uses too much memory. :) |
| 11:24 |
Dyrcona |
Just wait a week for a new browser release, it will probably do something different then. :P |
| 11:24 |
|
Christineb joined #evergreen |
| 11:56 |
|
yboston joined #evergreen |
| 11:59 |
csharp |
so the "let" issue that's causing Karma/PhantomJS to fail - should that just be changed to "var" instead? |
| 12:00 |
berick |
csharp: yes |
| 12:00 |
csharp |
sounds like "let" is allowed in ES6 but (afaik) that was released after the AngJS stuff was developed? |
| 12:00 |
csharp |
ok |
| 12:00 |
berick |
'let' is fine in most cases (e.g. chrome) but phantomjs is out of date |
| 12:00 |
csharp |
ah |
| 12:03 |
csharp |
hmm - https://github.com/ariya/phantomjs/issues/15344 |
| 12:03 |
csharp |
so it's not an active project anymore |
| 12:03 |
Dyrcona |
csharp: Where have you been? I've mentioned that every time it has come up in the channel. :) |
| 12:04 |
csharp |
Dyrcona: hah - I've been preoccupied with non-EG-dev stuff for most of the last year+ |
| 12:05 |
Dyrcona |
:) |
| 12:05 |
JBoyer |
SOMEDAY I'll stop treating wget like scp and including a . as second param. Apparently not today, though. |
| 12:05 |
Dyrcona |
You can also just ignore the failure and charge ahead. |
| 12:07 |
csharp |
yeah, I'm going down a rabbit hole |
| 12:07 |
Dyrcona |
That's OK. I'm building two bridges to nowhere. :) |
| 12:08 |
JBoyer |
csharp, berick, Dyrcona: I've looked at using chromium for testing in the past (would allow let and arrow funcs and generally modern JS all around) but I haven't seen a good way to get it installed without half a gui system coming along. If we accept that you'll just have to run the tests separately on a more heavily packaged machine it's a very simple change. |
| 12:08 |
csharp |
I think I'll do that and know that we'll have to find a suitable replacement that can run headless testing |
| 12:08 |
JBoyer |
Dyrcona, I have been to date, but ignoring errors really isn't my thing. ;) |
| 12:08 |
csharp |
JBoyer: I was just reading about https://github.com/karma-runner/karma-chrome-launcher and https://github.com/GoogleChrome/puppeteer |
| 12:09 |
JBoyer |
csharp++ |
| 12:09 |
csharp |
and yeah, we wouldn't want gnome-desktop installed on every box that needs EG installed :-D |
| 12:09 |
JBoyer |
Chrome and Chromium can both run headless and work great, I just don't know if you can get them *installed* without extra X11 stuff we don't want / need. |
| 12:10 |
csharp |
right |
| 12:10 |
csharp |
maybe a snap or flatpak? just throwing spaghetti at the wall doing 0 research |
| 12:11 |
Dyrcona |
Well, someone could always try and update PhantomJS. |
| 12:12 |
JBoyer |
Don't know if either browser is available in either of those formats. |
| 12:12 |
Dyrcona |
Are snaps statically linked? |
| 12:13 |
JBoyer |
Dyrcona, if you'd like to take on the maintenance of an out of date copy of WebKit and try to bring it up to date, I'll ... watch. ;) |
| 12:13 |
* JBoyer |
won't be touching that. |
| 12:16 |
Dyrcona |
JBoyer: Well, it's QtWebkit, so I could update it to a more recent Qt release and possibly switch to QtWebEngine. :) |
| 12:16 |
csharp |
fwiw, I just installed snapd then installed chromium without it pulling in all the Xorg, etc. stuff |
| 12:17 |
csharp |
(on 18.04) |
| 12:17 |
Dyrcona |
"Time keeps on tickin', tickin', tickin' into the future....." |
| 12:18 |
Dyrcona |
So, messing with network settings remotely is "fun." Just don't mess it up.... |
| 12:18 |
JBoyer |
Is that a re-forked fork of WebKit or just a new name for their more modern version? |
| 12:19 |
Dyrcona |
https://wiki.qt.io/QtWebEngine |
| 12:19 |
JBoyer |
Yeah, lots of potential lessons to be learned there... |
| 12:19 |
csharp |
https://github.com/cyrus-and/chrome-remote-interface |
| 12:20 |
csharp |
so theoretically, start chromium in headless mode with a remote port on localhost, then use chrome-remote-interface to connect to it |
| 12:21 |
JBoyer |
Ah, so the answer is "kind of" :) Looks like a good project. |
| 12:21 |
csharp |
seems like a lot, though - also, I might want to blow chromium away as soon as the testing is done - no need for that |
| 12:22 |
Dyrcona |
JBoyer, so yeah, it's a fork of a fork of WebKit. :) |
| 12:25 |
* Dyrcona |
thinks he'll wait until Monday to actually set up the bridge, since he'll be 50 miles closer to the collocation facility, then. |
| 12:32 |
csharp |
so when we get security warnings from NPM, is it advisable to update the versions installed in package-lock.json? |
| 12:32 |
Dyrcona |
I never do. I expect breakage. |
| 12:32 |
csharp |
that's my fear |
| 12:32 |
csharp |
I did see the conversations about the crazy number of dependencies for each of our NPM dependencies |
| 12:33 |
|
jihpringle joined #evergreen |
| 12:33 |
csharp |
thatsa lotta appsa |
| 12:34 |
Dyrcona |
Everything that uses npm is like that. |
| 12:35 |
* Dyrcona |
recently read a blog post lamenting the state of modern web development and how 10,000 packages depend on a single package with a four-line fuction, and the Internet breaks when the developer gets mad and deletes the package. |
| 12:38 |
rfrasur |
(tfw you're in the midst of a javascript course and you look in IRC and know what people are talking about now) |
| 12:39 |
Dyrcona |
rfrasur++ |
| 12:42 |
mmorgan |
When setting a sort order for some fields as part of a column config in the current web staff client, is the sort order saved in the workstation setting? Or, rather, is it supposed to be? |
| 12:52 |
|
sandbergja joined #evergreen |
| 12:59 |
jeffdavis |
csharp: probably worth a Launchpad bug at least |
| 13:01 |
* Dyrcona |
considered making a bug for phantomjs, but then didn't. I guess something else came up. |
| 13:06 |
jeffdavis |
I meant the npm security warning, but yeah phantomjs deserves a bug report too - I'll go ahead and create the latter |
| 13:08 |
Dyrcona |
I have tried updating npm before, to unhappy results. |
| 13:11 |
Dyrcona |
Not exactly the same thing, I know... |
| 13:18 |
jeffdavis |
bug 1845693 |
| 13:18 |
pinesol |
Launchpad bug 1845693 in Evergreen "Replacement needed for PhantomJS" [Undecided,New] https://launchpad.net/bugs/1845693 |
| 13:18 |
Dyrcona |
jeffdavis++ |
| 13:31 |
|
yboston joined #evergreen |
| 14:13 |
* Dyrcona |
is pleased that the bridge configuration is correct on the first try. |
| 14:14 |
|
yboston joined #evergreen |
| 14:16 |
JBoyer |
@praise Dyrcona |
| 14:16 |
* pinesol |
The Dyrcona abides. |
| 14:16 |
Dyrcona |
heh... |
| 14:16 |
Dyrcona |
Sounds 'bout right.... :) |
| 14:17 |
Dyrcona |
It's not like this is my first time configuring a bridge. I'm just always happy when there are no typos and something works on the first try. |
| 14:25 |
rfrasur |
The aspirational dream of no typos. You have attained a level of enlightenment (measured in a unit of your choice). |
| 14:31 |
Dyrcona |
:) |
| 14:39 |
jeffdavis |
afk climate strike |
| 14:42 |
|
jvwoolf joined #evergreen |
| 14:43 |
|
ddale joined #evergreen |
| 14:46 |
ddale |
Hi, Dyrcona can you give me an update on this bug https://www.google.com/url?q=https://bugs.launchpad.net/evergreen/%2Bbug/1774892&sa=D&source=hangouts&ust=1569690814979000&usg=AFQjCNHyQNa7ulaA-SMAVhJJSZBXOcXX7w |
| 14:47 |
Dyrcona |
So far, nothing to report. I'm supposed to be working on it, but I have been swapped more immediate system issues. I do know that what I thought was going to be my approach needs some adjustment. |
| 14:47 |
ddale |
So are we not compliant now? |
| 14:50 |
Dyrcona |
I don't think so, but I'm no lawyer/PCI expert. |
| 14:50 |
csharp |
jeffdavis++ |
| 14:51 |
csharp |
jeffdavis: I'll file the bug for the security warnings too |
| 14:51 |
ddale |
Thank you, Dyrcona. I will see what PINES needs to do at this point to be PCI compliant. |
| 14:52 |
Dyrcona |
One thing: You have to set the TLS settings to a point where XUL will no longer work. |
| 14:53 |
ddale |
Dyrcona, forgive me. This is a little over my head. TLS settings? |
| 14:54 |
* csharp |
is paying attention, btw |
| 14:54 |
Dyrcona |
Yeah, the settings for encryption with HTTPS on Apache. These have to be set to disallow TLS 1.0 and the ciphers set to something that our old version of XULRunner won't support. |
| 14:54 |
Dyrcona |
That's just 1 thing, though, I think there are others. |
| 14:54 |
ddale |
Thanks, I think Chris will know what this means. |
| 14:54 |
csharp |
that's probably something we can go ahead and do |
| 14:54 |
Dyrcona |
Like I said, I'm not an expert. |
| 15:04 |
csharp |
Dyrcona++ |
| 15:26 |
abneiman |
sandbergja++ # search-fu |
| 15:28 |
sandbergja |
github++ #such lovely search options |
| 15:46 |
|
khuckins joined #evergreen |
| 16:26 |
|
jvwoolf left #evergreen |
| 16:54 |
pinesol |
[evergreen|Andrea Buntz Neiman] Docs: added another contributor - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7ffaa21> |
| 17:08 |
|
mmorgan left #evergreen |
| 17:17 |
|
jihpringle joined #evergreen |
| 17:23 |
|
yboston joined #evergreen |
| 18:00 |
|
sandbergja_ joined #evergreen |
| 18:40 |
|
sandbergja_ joined #evergreen |
| 18:58 |
|
sandbergja_ joined #evergreen |
| 22:11 |
|
stephengwills joined #evergreen |
| 22:43 |
|
book` joined #evergreen |
| 23:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 23:53 |
|
gsams joined #evergreen |
