| Time |
Nick |
Message |
| 00:47 |
|
bmills joined #evergreen |
| 01:49 |
|
bmills joined #evergreen |
| 01:51 |
|
bmills joined #evergreen |
| 02:22 |
|
bmills joined #evergreen |
| 03:22 |
|
bmills joined #evergreen |
| 04:23 |
|
bmills joined #evergreen |
| 05:25 |
|
bmills joined #evergreen |
| 06:26 |
|
bmills joined #evergreen |
| 07:33 |
|
bmills joined #evergreen |
| 07:44 |
|
jboyer-isl joined #evergreen |
| 07:44 |
|
collum joined #evergreen |
| 07:45 |
|
collum_ joined #evergreen |
| 07:53 |
|
rjackson_isl joined #evergreen |
| 08:00 |
|
mrpeters joined #evergreen |
| 08:20 |
|
ericar joined #evergreen |
| 08:26 |
|
rlefaive joined #evergreen |
| 08:31 |
|
RoganH joined #evergreen |
| 08:34 |
|
bmills joined #evergreen |
| 08:38 |
|
Shae joined #evergreen |
| 08:40 |
|
mmorgan joined #evergreen |
| 09:00 |
|
Dyrcona joined #evergreen |
| 09:28 |
|
maryj joined #evergreen |
| 09:33 |
|
yboston joined #evergreen |
| 09:35 |
|
bmills joined #evergreen |
| 09:41 |
Dyrcona |
kmlussier: I'm going to reload my dev database to test some stuff for Comcat. I need fresh data from production. |
| 09:41 |
Dyrcona |
<zombie>Brains!!!!!</zombie> |
| 09:41 |
Dyrcona |
This means my dev system will be off line for a couple of hours. |
| 09:47 |
kmlussier |
Dyrcona: Thanks for the heads up! |
| 09:47 |
Dyrcona |
I'll let you know when it is done. The same code will be there. |
| 09:48 |
Dyrcona |
I just wants some holds and transits to play with, since I've already canceled them all in my dev system. |
| 09:49 |
dbs |
They're not allowed to be called Comcat. Too confusing with Comcast and concat.ca! |
| 09:52 |
Dyrcona |
heh |
| 09:52 |
Dyrcona |
Commonwealth Catalog: Comcat, CommCat, or in the case of our aou.shortname for them COMMCAT |
| 09:54 |
* Dyrcona |
is fixing a hold where the holds get in. ;) |
| 09:55 |
Dyrcona |
heah... Should be "fixing a hole...." |
| 09:55 |
Dyrcona |
<zombie>Brains!!!!!</zombie> |
| 09:56 |
* jeff |
modifies a url so that it ends in /iam/home and is reminded of the book Sphere |
| 10:10 |
jeff |
as in, I AM HERE. |
| 10:18 |
|
mmorgan left #evergreen |
| 10:20 |
|
jwoodard joined #evergreen |
| 10:25 |
Dyrcona |
Oy! Aborting a transit resets a hold and resetting a hold aborts the transit.... |
| 10:25 |
|
mmorgan joined #evergreen |
| 10:25 |
Dyrcona |
Of course the latter won't happen if it is already aborted, but still. |
| 10:29 |
Dyrcona |
And, resetting a canceled hold seems pointless, but whatevs. |
| 10:34 |
mmorgan |
Dyrcona: pointless, true, but can have annoying side effects: lp 1469287 |
| 10:34 |
pinesol_green |
Launchpad bug 1469287 in Evergreen "Retargeting a cancelled hold can cause problems with uncancelled captured holds" [Medium,Confirmed] https://launchpad.net/bugs/1469287 |
| 10:36 |
|
bmills joined #evergreen |
| 10:39 |
Dyrcona |
mmorgan: I wonder if that affects what I am doing. |
| 10:40 |
Dyrcona |
Yep. It probably will. |
| 10:41 |
Dyrcona |
Perhaps, _reset_hold needs a line added at the top to bail if ($hold->cancel_time)? |
| 10:42 |
Dyrcona |
On of the last things, _reset_hold does is retarget. |
| 10:43 |
Dyrcona |
So, perhaps I should abort the transit before canceling the hold. |
| 10:43 |
berick |
agreed we don't want to re-target a canceled hold |
| 10:44 |
berick |
but we don't want to automatically abort a transit just because a hold is canceled |
| 10:44 |
berick |
because the item is still in transit |
| 10:44 |
berick |
even if the hold is canceled |
| 10:45 |
* mmorgan |
agrees with berick |
| 10:45 |
berick |
we used to abort the transit, but that caused confusion |
| 10:45 |
mmorgan |
Those items then end up in Reshelving and nobody knows where they are. |
| 10:45 |
berick |
exactly |
| 10:46 |
Dyrcona |
berick: In my case, I know it should not actually be in transit, and if it is, too bad. |
| 10:46 |
Dyrcona |
We get a lot of tickets about "stuck transits" and I don't need more. |
| 10:46 |
Dyrcona |
Besides, this is for NCIPServer, not in Evergreen itself. |
| 10:47 |
jeff |
anyone know if roomba vacuums are rated for yak hair? |
| 10:48 |
Dyrcona |
jeff: Doubt it. You might want their anti-mine model. |
| 10:48 |
* mmorgan |
doesn't know, but you can borrow one from one of our libraries ;-) |
| 10:50 |
Dyrcona |
Hmm. Guess I could add a configuration option for abort_on_cancel to oils_ncip.xml, but that will make it harder on NOBLE and CW/MARS to update, 'cause they'll need to edit the config. |
| 10:51 |
Dyrcona |
And would require some explanation in the non-existent documentation. ;) |
| 10:53 |
Dyrcona |
It's all in a development branch. I haven't pushed anything to working/user/dyrcona/better_abstraction, yet. Not for the abort... The cancel fixes are there. |
| 11:03 |
|
gmcharlt joined #evergreen |
| 11:04 |
|
gmcharlt joined #evergreen |
| 11:04 |
|
ericar joined #evergreen |
| 11:06 |
Dyrcona |
I'll make it optional. That isn't very difficult. |
| 11:08 |
|
mdriscoll joined #evergreen |
| 11:09 |
|
JimT_ joined #evergreen |
| 11:09 |
bshum |
gmcharlt++ # website stuff |
| 11:11 |
JimT_ |
Does anyone have the browse index working for 710 tags which contain a subfield t? I think I have fixed all the author browse indexes that weren't working except for this one. Nothing I do seems to make a difference. |
| 11:20 |
Dyrcona |
And, aborting transits when holds are canceled is now optional in NCIPServer. |
| 11:20 |
Dyrcona |
Of course, I haven't tested it, yet. ;) |
| 11:20 |
* Dyrcona |
waits on the database reload to finish. |
| 11:21 |
Dyrcona |
jboyer-isl: So, I had a net removal of 156 lines of code the other day, and now a net addition of 121 lines since then. |
| 11:21 |
Dyrcona |
jboyer-isl: In case you're keeping score. :) |
| 11:22 |
bshum |
@marc 710 |
| 11:22 |
pinesol_green |
bshum: An added entry in which the entry element is a corporate name. (Repeatable) [a,b,c,d,e,f,g,h,k,l,m,n,o,p,r,s,t,u,x,3,4,5,6,8] |
| 11:22 |
* bshum |
doesn't think he has anything like that in his DB |
| 11:22 |
Dyrcona |
Well, I can't answer that, 'cause we're not really using the browse indexes. |
| 11:23 |
bshum |
And 710t is title, not author? According to https://www.loc.gov/marc/bibliographic/bd710.html anyways |
| 11:23 |
Dyrcona |
bshum: You must have some records with 710s. Doesn't mean you've indexed them. |
| 11:23 |
bshum |
Dyrcona: True... that would be the more accurate statement to make. |
| 11:23 |
bshum |
Yes, I meant that I do not believe we have any browse index like that. |
| 11:24 |
Dyrcona |
I might have added something like that to a keyword index if it wasn't there already, but we're mostly using stock indexes. |
| 11:25 |
* bshum |
glances at kmlussier and her probable mountain of knowledge with non-stock indexes. |
| 11:29 |
JimT_ |
I'm no expert and going with what the cataloger has told me should be there...710 t is a title index but supposedly the a,b,c,t,d,g,n will show in the author index as 'conference' listing. |
| 11:31 |
JimT_ |
...or maybe corporate?...gets mixed up in my head after a while. |
| 11:34 |
JimT_ |
as far as indexing...I tweak the stylesheet...and then resave my test record. |
| 11:35 |
|
dbwells joined #evergreen |
| 11:38 |
JimT_ |
The 710 t index is part of the stock indexes...it just doesn't seem to work. I'm not trying to do anything fancy...just, mostly, trying to make things work that are already defined but do not. |
| 11:40 |
JimT_ |
Was hoping to find someone who had this working and who would share what they did to make it work. |
| 11:45 |
kmlussier |
JimT_: I think there have been previous discussoins about the 710t in the irc logs. Bmagic and miker have had this discussion once or twice. I can't recall the gist of it, and, unfortunately, I'm tied up with other things right now. |
| 11:46 |
JimT_ |
okay...I'll try to track it down in the logs. Thanks. |
| 11:46 |
kmlussier |
My recollection is that sometimes it is indexed and sometimes it isn't based on some other thing that's in the 700 field. Sorry, not very helpful at the moment. :) |
| 11:46 |
kmlussier |
At some point, we should mine that info from the logs and put it in documentation somehwere. :) |
| 11:46 |
JimT_ |
Having a direction to look is always helpful. |
| 11:47 |
kmlussier |
Oh, actually, the previous discussions may have been in relation to keyword indexes. But I suspect the issue is the same whether you're looking at browse or keyword indexes. |
| 11:48 |
|
ericar_ joined #evergreen |
| 12:14 |
|
Christineb joined #evergreen |
| 12:25 |
|
JimT_ left #evergreen |
| 12:38 |
|
bmills joined #evergreen |
| 12:48 |
Dyrcona |
kmlussier: My dev system is running again in case you want to look at anything. |
| 12:49 |
|
mmorgan joined #evergreen |
| 13:25 |
|
jihpringle joined #evergreen |
| 13:42 |
|
jlitrell joined #evergreen |
| 14:25 |
|
graced joined #evergreen |
| 14:29 |
* bshum |
hates billings |
| 14:30 |
bshum |
I found 479 cases where the entry in money.materialized_billable_xact_summary where total_paid < total_owed AND xact_finish IS NOT NULL. |
| 14:30 |
bshum |
Those seem to indicate that the xact_finish was set too early on certain billings and there's still meant to be money owed. |
| 14:30 |
jeff |
time for forgiveness. |
| 14:31 |
bshum |
Well, the way it seems to manifest in the patron record is that the patrons show up as owing nothing, cause it doesn't add to the total amount owed, due to the xact_finish being set |
| 14:31 |
bshum |
But yeah, weird stuff transpired. |
| 14:31 |
bshum |
SELECT COUNT(*) FROM money.materialized_billable_xact_summary WHERE total_paid < total_owed AND xact_finish IS NOT NULL; |
| 14:32 |
bshum |
I'm sure there's other logical reasons for this to happen |
| 14:32 |
bshum |
Or maybe it was a phase of production where a bug happened |
| 14:33 |
berick |
what's the time frame? |
| 14:33 |
bshum |
berick: Hmm, good question |
| 14:33 |
tsbere |
bshum: My lookup is slightly different. SELECT COUNT(*) FROM money.materialized_billable_xact_summary WHERE balance_owed > 0.0 AND xact_finish IS NOT NULL; |
| 14:34 |
* tsbere |
isn't sure he wants to investigate the != version of his query with over 2800 returns, the 1 from > though may be worth checking |
| 14:34 |
bshum |
tsbere: Good call, I get the same result. |
| 14:34 |
bshum |
berick: The one I was looking at happened during the summer. |
| 14:34 |
bshum |
THey kind of look like theyr'e from all different dates |
| 14:35 |
jeff |
the fact that ansible uses cowsay by default if present is amusing to me. |
| 14:35 |
bshum |
xact_start for some range from 2013 through present |
| 14:35 |
bshum |
So, meh |
| 14:35 |
bshum |
These are weird cases |
| 14:35 |
mmorgan |
bshum: lp 1484989 ? |
| 14:35 |
pinesol_green |
Launchpad bug 1484989 in Evergreen 2.8 "Fines are not calculating until after circulation is closed" [Medium,Fix released] https://launchpad.net/bugs/1484989 |
| 14:35 |
mmorgan |
We were affected by this after going to 2.8 |
| 14:36 |
berick |
bshum: hm, ok, so it's a persistent issue. not something that happaned way-back-when |
| 14:36 |
tsbere |
bshum: So, I have a whopping one with a positive balance_owed, for a 0.50 balance. But negative balance_owed..... |
| 14:36 |
jeffdavis |
bshum: don't you have a nonstandard circ.lost.xact_open_on_zero setting? |
| 14:37 |
jeffdavis |
Yours was the opposite to what is in master or something. |
| 14:37 |
bshum |
jeffdavis: I think we do, but because the setting is named wrong, the effect is that having ours set is effectively like not having it set at all. |
| 14:37 |
bshum |
Which is good, cause I don't want it to leave xacts open on zero anyways. |
| 14:38 |
bshum |
mmorgan: Ah yeah, I remember that bug. It's possible that some of these more recent ones are a result of that, but those older ones shouldn't be related. |
| 14:39 |
jeff |
keep in mind that there are a few dates to look at, and which one you care about may depend on which bug you're looking at. |
| 14:39 |
bshum |
Right. |
| 14:39 |
jeff |
xact_finish vs the most recent billing_ts, etc. |
| 14:40 |
* jeff |
watches ansible go |
| 14:41 |
csharp |
any reason we'd need a 5 minute delay for emailing a receipt for an online payment? |
| 14:41 |
csharp |
(that's the default in the a/t setup for money.payment_receipt.email) |
| 14:41 |
tsbere |
csharp: To hopefully catch multiple payments into a single email? |
| 14:41 |
bshum |
csharp: I imagine any delay is just to group ... yeah, what tsbere says |
| 14:41 |
csharp |
ah |
| 14:41 |
berick |
i imagine 30 seconds would cover it |
| 14:41 |
csharp |
that makes sense |
| 14:42 |
csharp |
berick: yeah, I agree |
| 14:42 |
berick |
i mean, unless you expect them to make a series of separate CC payments |
| 14:42 |
berick |
but that would be unusual |
| 14:42 |
berick |
or would it? |
| 14:43 |
jeff |
it's grouping on usr, not something like email, right? the most common "several payments in a row" we see is families paying each account. |
| 14:43 |
jeff |
but then again, that's skewed by the fact that we don't permit partial payment. |
| 14:44 |
jeff |
but we also don't permit payment on open circs, so if you paid everything, then renewed some open circs, you could pay again. |
| 14:44 |
csharp |
jeff: we're about to have the "do we allow partial payments" discussion in PINES soon too, methinks |
| 14:44 |
csharp |
right now we allow them, and it's leading to mucho confusion |
| 14:44 |
jeff |
in terms of user expectations, i think they'll expect to get one receipt per credit card transaction, regardless of how many "payments" evergreen turns that into. |
| 14:44 |
* bshum |
hates partial payments |
| 14:44 |
* berick |
also sees no problem w/ someone receiving multiple emails of this type |
| 14:45 |
berick |
pretty sure most sites would send one email per CC transaction, which a short timeout would give you |
| 15:07 |
tsbere |
A quick question: Is anyone currently around that would be interested in a captive portal system to protect wifi? |
| 15:14 |
csharp |
tsbere: while I'm not personally particularly interested, it is a common request from our libraries, and several (if not many) are purchasing solutions |
| 15:14 |
jeff |
nope. we actively killed all of ours in the interest of having a better patron experience. |
| 15:14 |
csharp |
jeff++ |
| 15:15 |
tsbere |
We have at least one library that believes it has local businesses using the library wireless instead of paying for an internet connection. :( |
| 15:15 |
csharp |
our libraries appear to be mainly interested in collecting usage stats |
| 15:15 |
csharp |
and that allows them to sort cardholders vs. guests |
| 15:15 |
jeff |
yeah, we do that without a captive portal. |
| 15:16 |
jeff |
cardholders vs guests is something we're not doing right now. |
| 15:16 |
tsbere |
We are also interested in the potential for "those actually intentionally doing things vs those that just happened to walk by with a device that knows the network" |
| 15:17 |
jeff |
tsbere: does the library in question have concerns about local businesses checking out books for the use of the business? |
| 15:18 |
jeff |
tsbere: are you interested enough that you care to make the experience of using the library wireless harder for every user, and add greater technical complexity to the process? |
| 15:18 |
jeff |
I guess the answer is "yes" since we're having the conversation, but I like to ask. :-) |
| 15:18 |
tsbere |
jeff: I think part of the concern was when they noticed "The library is CLOSED, staff are on a different network, nobody is hanging around outside, and there is no bandwidth available on the patron side" |
| 15:18 |
miker |
tsbere: invest in copper mesh... |
| 15:19 |
jeff |
I've had this kind of conversation so often with so many people I've lost track of who -- so forgive me if I've talked about this with you before. :-) |
| 15:19 |
tsbere |
We also have a couple of libraries that are visited by people from out of state who have no card, no interest in getting a card, and want to do nothing but use the wifi. |
| 15:20 |
jeff |
Cool. Does the library kick people out for reading books in the library without being an active cardholder? :-) |
| 15:20 |
tsbere |
Depends. Are said people being highly disruptive while doing so? |
| 15:20 |
jeff |
If the patrons brought their own network connectivity would the library still feel the same about them? |
| 15:21 |
jeff |
If the people are being disruptive, have a policy that lets you deal with them being disruptive, and make use of it. |
| 15:21 |
miker |
csharp: re your short timeout on CC receipts, as a practical matter, the maximal minimum delay will be 1 minute -- the resolution of cron's timer. but it could (would often) be shorter. a 30s delay could be up to 1.5mins |
| 15:21 |
csharp |
miker: yeah - that's what I'm settling on - 30s delay plus a cron job that runs every minute |
| 15:22 |
tsbere |
jeff: Let me put it a different way: For whatever reason they feel they can't ask the people to leave (or perhaps they aren't even physically in the library) but they are preventing others from being able to function on the wifi. |
| 15:22 |
jeff |
tsbere: of course, all of this is in theory and in the abstract. sometimes you have to be practical, also. it just annoys me when i see libraries spending time and money making their services more difficult to use. |
| 15:23 |
tsbere |
jeff: I was asked to find a way to limit the wifi to card holders only. Captive portal is the best solution I have come up with. |
| 15:24 |
jeff |
if you venture into requiring a card to use the wifi, at least consider giving added benefit to the patron at the same time, by adding meaningful security to the network :-) |
| 15:24 |
jeff |
(again, for reasons of practicality i know that isn't always possible -- there's only so much you have in terms of resources, etc) |
| 15:25 |
csharp |
I would consider using QoS to create a guest network of throttled bandwidth for non-cardholders |
| 15:25 |
csharp |
(if given that particular request) |
| 15:25 |
jeff |
still not sure i get the cardholders distinction. do you card people before allowing them to plug in a laptop to power? |
| 15:25 |
csharp |
jeff: *I* don't care, but our libraries *really* care (in many cases) |
| 15:26 |
tsbere |
Some of our libraries don't have places they let people plug in laptops |
| 15:26 |
csharp |
that's probably true of our libraries too - most of my knowledge on this point is purely anecdotal |
| 15:26 |
jeff |
an oddly discordant philosophy for libraries, but i guess if i'm honest with myself it's actually a common philosophy. :P |
| 15:27 |
csharp |
jeff: yeah - I agree with the discordance |
| 15:27 |
csharp |
jeff: meaning - I agree with you that it is discordant and they are blind to that perspective ;-) |
| 15:28 |
jeffdavis |
jeff: better yet, "do you card people before letting them use books in the library?" |
| 15:28 |
* csharp |
wants to live in a utopia of freely available wifi and endless access to information |
| 15:29 |
csharp |
for instance, I cringe at this kind of thing: https://www.youtube.com/red |
| 15:29 |
jlitrell |
I'd think if power were as limited as bandwidth can be, they'd limit access more. :) Got a 150/150 connection here, and it's fairly trivial to max it out. |
| 15:29 |
tsbere |
jeff: MVLC allows out-of-state individuals to, for a fee, get a MVLC library card. Many out-of-state individuals are showing up at some libraries and using the wifi to an extreme. |
| 15:29 |
jeffdavis |
we've had libraries where the staff client becomes unusable at a certain time of day because a young person was coming into the library every day at that time and watches instructional Youtube videos. |
| 15:29 |
tsbere |
jeff: Thus, the idea is likely "get them to actually pay for their constant use of library resources or go find somewhere else to get their free internet from" |
| 15:30 |
jeff |
avoid the increased support and maintenance burden of a captive portal, and invest some of those resources in having reasonably secure wifi that is architected in such a fashion as to allow full utilization, but throttles down to something not-incredibly-slow when there's contention/competition. :-) |
| 15:31 |
jeff |
tsbere: do you think the issue would be different if they were "showing up at some libraries" and using their own internet connection, not making use of the library wifi? |
| 15:32 |
kmlussier |
jcamins: Have you decided if you'll be making it to the hack-a-way? |
| 15:32 |
jeff |
also, i do wonder what "using the wifi to an extreme" means. are you talking about disproportionately high bandwidth utilization, or something else? |
| 15:33 |
jcamins |
kmlussier: I have, and I will not be able to make it. :( |
| 15:33 |
kmlussier |
jcamins: Mint chips will be arriving just in time for me to make a bunch of cookies before everyone meets up next wee. |
| 15:33 |
jcamins |
Oh, man! That sounds delicious. |
| 15:33 |
tsbere |
jeff: I have one claim of someone showing up in a van every day, parking next to the library, and using enough bandwidth to cause issues for other patrons. |
| 15:34 |
tsbere |
jeff: I also have several claims of out-of-state individuals basically treating the library as their place to run the "internet needed" tasks of their businesses every day, to the point of claiming they are losing money when the internet is down. |
| 15:34 |
kmlussier |
jcamins: That's too bad. Maybe next time. |
| 15:34 |
berick |
kmlussier++ |
| 15:34 |
jeff |
tsbere: How will the captive portal help with that issue? |
| 15:35 |
bshum |
kmlussier: Mint chips, eh? /smiles |
| 15:35 |
bshum |
kmlussier++ |
| 15:35 |
tsbere |
jeff: As far as staff can tell none of these people have in-state cards in the first place. |
| 15:35 |
kmlussier |
bshum: I'm thinking choc. mint cookies, the saltine things I made for the doc hackfest, and some thumbprint cookies you haven't seen yet. |
| 15:36 |
tsbere |
jeff: I know one of the "running their business" people found the wifi down (the AP had taken a hit during a storm), was told they could use the in-library computers, but didn't have a card to plug into the reservation system |
| 15:36 |
|
notkyle joined #evergreen |
| 15:36 |
kmlussier |
I'm not quite sure when I'll have time to make them, with pumpkin carving and a fencing tournament on Sunday. But I'll make sure they're done by Wednesday. |
| 15:36 |
|
notkyle left #evergreen |
| 15:37 |
jeff |
tsbere: What would the solution be in these two examples if the individuals were in-state cardholders? |
| 15:38 |
jeff |
tsbere: and would it be different if they were out-of-state "paid the fee" cardholders? |
| 15:39 |
tsbere |
jeff: Excessive bandwidth people are a problem in general that they want a solution to as well, but don't want to spend a lot of money on. |
| 15:39 |
jcamins |
We're going to travel around Thanksgiving to avoid A) the fact that I've got scads to do at work, and B) losing out on the opportunity for an 8-day vacation that uses only 4 days of vacation. |
| 15:39 |
tsbere |
jeff: Otherwise, "pay state taxes" or "paid the fee" make them otherwise fine with the use of the network. |
| 15:40 |
tsbere |
(in most cases) |
| 16:33 |
|
ghostin joined #evergreen |
| 16:36 |
|
ghostin left #evergreen |
| 16:42 |
csharp |
tsbere: re low-cost solutions: buy several of http://goo.gl/AMXptq and use DD-WRT (https://www.dd-wrt.com/site/) |
| 16:45 |
jeff |
or keep the existing access points and stick pfsense on any supported hardware. |
| 16:45 |
jeff |
etc. |
| 16:45 |
jeff |
(RIP m0n0wall) |
| 16:50 |
kmlussier |
Stompro: Are you around? |
| 16:51 |
Stompro |
kmlussier, yes, what is up? |
| 16:52 |
kmlussier |
Stompro: I'll shoot you a pm |
| 17:11 |
|
mdriscoll left #evergreen |
| 17:31 |
|
mmorgan left #evergreen |
| 17:33 |
jwoodard |
"instructional Youtube videos"? Such a thing exists? |
| 17:54 |
jeffdavis |
jwoodard: Sitka support folks have made a bunch... |
| 18:31 |
jihpringle |
jwoodard: https://www.youtube.com/channel/UCiMYBCQG4QJVT-B3Ruk0Ncg/playlists |
| 19:12 |
|
remingtron joined #evergreen |
| 19:54 |
|
jihpringle joined #evergreen |
| 21:44 |
gmcharlt |
courtesy of the Let's Encrypt beta, https://evergreen-ils.org now has a free SSL cert |
| 22:05 |
csharp |
gmcharlt++ |
