| Time |
Nick |
Message |
| 00:43 |
|
dcook joined #evergreen |
| 01:28 |
|
Bmagic joined #evergreen |
| 06:40 |
|
rlefaive joined #evergreen |
| 06:57 |
|
agoben joined #evergreen |
| 07:28 |
|
rjackson_isl joined #evergreen |
| 07:28 |
graced |
Good morning, #evergreen |
| 07:33 |
|
JBoyer joined #evergreen |
| 08:00 |
jeff |
good morning! |
| 08:03 |
|
Dyrcona joined #evergreen |
| 08:43 |
|
mmorgan joined #evergreen |
| 08:53 |
|
mmorgan1 joined #evergreen |
| 09:07 |
Dyrcona |
Did a fresh install of OpenSRF master on an Ubuntu 16.04 Xenial Xerus VM just now, and osrf_control hangs. |
| 09:08 |
Dyrcona |
Seems to take forever on opensrf.dbmath. |
| 09:08 |
|
kmlussier joined #evergreen |
| 09:09 |
Dyrcona |
If I get impatient and Ctrl-C out of it opensrf.dbmath is running, but opensrf.math is not. |
| 09:10 |
Dyrcona |
ERR opensrf.settings has no running drones. |
| 09:10 |
Dyrcona |
Hmm... I don't think I messed anything up. |
| 09:11 |
Dyrcona |
I've checked the passwords 3 times, now. |
| 09:12 |
|
collum joined #evergreen |
| 09:14 |
Dyrcona |
[2017-03-09 09:04:54] opensrf.settings [ERR :24862:System.pm:122:] server: died with error Exception: OpenSRF::EX::Jabber 2017-03-09T09:04:54 OpenSRF::System /usr/local/share/perl/5.22.1/OpenSRF/System.pm:122 Jabber Exception: Disconnected from Jabber server |
| 09:14 |
Dyrcona |
But no explanation why. |
| 09:15 |
Dyrcona |
[2017-03-09 09:04:54] opensrf.settings [ERR :24862:EX.pm:66:] Exception: OpenSRF::EX::Jabber 2017-03-09T09:04:54 OpenSRF::Transport::SlimJabber::XMPPReader /usr/local/share/perl/5.22.1/OpenSRF/Transport/SlimJabber/XMPPReader.pm:263 Jabber Exception: Disconnected from Jabber server |
| 09:15 |
Dyrcona |
I noticed a recent change to that file. |
| 09:23 |
Dyrcona |
Well, reverting the latest commit to that file makes no difference. |
| 09:24 |
|
Enjabain joined #evergreen |
| 09:25 |
Dyrcona |
It seems somewhat random what services are running or not. |
| 09:25 |
Dyrcona |
This time, opensrf.settings is fine but opensrf.validator isn't. |
| 09:25 |
Dyrcona |
opensrf.math and opensrf.dbmath are also not running. |
| 09:27 |
|
yboston joined #evergreen |
| 09:28 |
kmlussier |
Since we have less than a week left until the RC, I wanted to highlight a couple of bugs that could use some attention if anyone has tuits. We have two bugs targeted for 2.12 with a high priority. |
| 09:28 |
kmlussier |
One has a branch and pullrequest tag: bug 1442276 |
| 09:28 |
pinesol_green |
Launchpad bug 1442276 in Evergreen "Supercat encoding problems with MODS output (Zotero)" [High,Confirmed] https://launchpad.net/bugs/1442276 |
| 09:29 |
kmlussier |
The other does not have a branch: bug 1670250 |
| 09:29 |
pinesol_green |
Launchpad bug 1670250 in Evergreen "Web client: Circ staff users unable to view all checked-out items and other permission issues" [High,New] https://launchpad.net/bugs/1670250 |
| 09:29 |
kmlussier |
I identified the last one as a high priority because I'm concerned that people using the web client will be able to see the holds for patrons when they don't have view permissions for those patrons. |
| 09:31 |
|
mmorgan joined #evergreen |
| 09:32 |
|
rlefaive joined #evergreen |
| 09:33 |
kmlussier |
There are also two web client bugs that I signed off on, but then added another commit that needs a signoff before it can be merged. bug 1522644 and bug 1621178 |
| 09:33 |
pinesol_green |
Launchpad bug 1522644 in Evergreen "webclient: Transfer title holds issues" [Medium,New] https://launchpad.net/bugs/1522644 |
| 09:33 |
pinesol_green |
Launchpad bug 1621178 in Evergreen "webclient: Copy status field missing from column pickers" [Medium,Confirmed] https://launchpad.net/bugs/1621178 |
| 09:36 |
kmlussier |
If there are any other bug fixes you think need to make it into the release, let me know. I probably won't get to them today, but will make some time to review branches before gmcharlt cuts the release next week. |
| 09:47 |
|
mmorgan1 joined #evergreen |
| 09:51 |
Dyrcona |
Well, I'm gonna try on another fresh vm elsewhere. |
| 09:51 |
Dyrcona |
I should really test what I want to test with production data, anyway. |
| 09:55 |
csharp |
Dyrcona: check journalctl for apport messages |
| 09:56 |
Dyrcona |
csharp: Too late. I blew it all away. |
| 09:56 |
Dyrcona |
Here's a middle finger for systemd-- :) |
| 09:56 |
Dyrcona |
Turning Linux into Windows since 2012. |
| 09:59 |
Dyrcona |
and binary_logs-- |
| 10:00 |
Dyrcona |
Now, I have to wait for an ISO to copy, 'cause I don't have the Ubuntu server ISO on the host where I want to make the new vm. |
| 10:04 |
csharp |
we just build "stock-xenial" guests that we clone at need |
| 10:04 |
csharp |
(ours is all on remote servers) |
| 10:04 |
Dyrcona |
Uh-huh. I've cloned VMs before. |
| 10:05 |
Dyrcona |
I've also made copies "by hand." |
| 10:05 |
Dyrcona |
Doesn't help if you think your image is busted, which is my current suspicion, or you don't have clonable images handy at the moment. |
| 10:06 |
Dyrcona |
It could be the new kernel. I notice some bustification with grub-update during apt dist-upgrade. |
| 10:07 |
* Dyrcona |
grumbles and thinks he should get back to work on fixing our build so it will work on *BSD. |
| 10:07 |
Dyrcona |
It's copying sparse image files around...rsync -S |
| 10:08 |
Dyrcona |
Hmm. there's an adjective missing. I'll let the reader fill in the blank this time. |
| 10:10 |
Dyrcona |
Imagine Evergreen on NetBSD, running on your toaster! |
| 10:11 |
Dyrcona |
Imagine a Beowulf cluster of those.... ;) |
| 10:14 |
* csharp |
still wants to install EG on a raspberry pi mounted on a drone and have a mobile ILS |
| 10:14 |
Dyrcona |
Usually it's no big deal to make a new VM and I have limited space on my laptop. ;) |
| 10:14 |
Dyrcona |
Heh! |
| 10:15 |
Dyrcona |
Realistically, you'd need more RAM than a typical Raspberry Pi has. |
| 10:15 |
Dyrcona |
But, fun idea. |
| 10:15 |
Dyrcona |
Ditto the toaster. |
| 10:16 |
* Dyrcona |
takes a look at /. for the first time in...months. |
| 10:24 |
bshum |
Well, if you cluster the Pi's, you could make it work :) |
| 10:24 |
bshum |
The hardest thing is having enough memory for your database I think |
| 10:25 |
bshum |
So a flying army of drone pi's, obviously |
| 10:32 |
* bshum |
plays "the ride of the valkyries" |
| 10:37 |
Dyrcona |
:) |
| 10:38 |
* Dyrcona |
plays The Blues Brothers: Briefcase Full of Blues. |
| 10:42 |
* Dyrcona |
uses virt-manager to build the vm and lets it put it in the default location. |
| 10:44 |
Dyrcona |
My laptop is acting "weird," too. |
| 10:44 |
Dyrcona |
@blame Ubuntu |
| 10:44 |
pinesol_green |
Dyrcona: Ubuntu is why we can never have nice things! |
| 10:44 |
Dyrcona |
:) |
| 10:45 |
Dyrcona |
Normally, I'd a get a generic icon for virt-manager run remotely for Alt-Tab switching. |
| 10:46 |
Dyrcona |
But this time, task switcher has decided that virt-manager is another Thunderbird window. |
| 10:46 |
Dyrcona |
If you're on Ubuntu 16.04, you might want to wait a few days before installing updates. |
| 10:55 |
|
collum_ joined #evergreen |
| 10:55 |
|
Enjabain joined #evergreen |
| 11:08 |
|
Dyrcona joined #evergreen |
| 11:13 |
|
brahmina joined #evergreen |
| 11:21 |
berick |
i'm finally poking around the conditional negative balances stuff (prep for pending 2.9 update). wondering if someone can explain why voiding is still used in some cases like before, but in the specific case of voiding overdues during mark-item-lost it forces the use of account adjustment payments. |
| 11:21 |
berick |
from the release notes "The account adjustment payment type will also be used for all libraries, regardless of the state of negative balance settings, in cases where overdue fines are adjusted when an overdue item is marked lost." |
| 11:22 |
berick |
what's special about marking items lost? |
| 11:26 |
kmlussier |
berick: I think the reasonsing was in c) in this comment - https://bugs.launchpad.net/evergreen/+bug/1198465/comments/28 |
| 11:26 |
pinesol_green |
Launchpad bug 1198465 in Evergreen "Support for Conditional Negative Balances" [Wishlist,Fix released] |
| 11:27 |
berick |
kmlussier++ thanks |
| 11:43 |
|
tsbere joined #evergreen |
| 11:45 |
Dyrcona |
OK. I think my other image was corrupt. OpenSRF is working on this one. |
| 11:47 |
berick |
so if no neg. balance settings are applied, there will be 2 ways to undo a billing in practice, voiding (for most things), then account adjustment for undoing lost overdues. |
| 11:47 |
Dyrcona |
With the latest updates. |
| 11:47 |
berick |
wondering if this has caused any confusion in the field |
| 11:47 |
berick |
the (apparent) inconsistency |
| 11:49 |
* Dyrcona |
wouldn't be surprised. |
| 11:51 |
berick |
it does appear that removing force_zero on lost overdue voiding would still work (untested, but in theory) |
| 11:52 |
berick |
i wonder if that would be a useful feature request for lp |
| 11:52 |
* berick |
knows he's late to the neg. balance ball game but whaddya gonna do |
| 11:54 |
|
Enjabain joined #evergreen |
| 11:54 |
berick |
this also begs the question, why not use 'account adjustment' payments everywhere by default instead of voiding, regardless of whether a site allows negative balances. |
| 11:57 |
* Dyrcona |
originally developed it with a "void" payment type. |
| 11:57 |
Dyrcona |
But others didn't like that. |
| 11:57 |
berick |
interesting, ok |
| 12:05 |
dbwells |
berick: Welcome to crazy land, I will be your host :) |
| 12:05 |
|
khuckins joined #evergreen |
| 12:06 |
berick |
dbwells++ |
| 12:06 |
berick |
dbwells: if any of my questions or comments are just wrong, please let me know :) |
| 12:09 |
dbwells |
berick: obviously there was a lot of back and forth on that bug, but I think what's been said so far is true, and your questions are valid. I know the existing solution is far from perfect. |
| 12:10 |
berick |
dbwells: thanks! that's quite helpful. |
| 12:11 |
berick |
knowledge is more than half the battle in my book |
| 12:11 |
|
Christineb joined #evergreen |
| 12:12 |
berick |
well, "knowing" |
| 12:12 |
dbwells |
Without re-living all 98 comments, I will try to recall the essence of what was done. |
| 12:17 |
dbwells |
berick: I keep typing and deleting things, sorry. Hard to simplify, I guess :) |
| 12:19 |
kmlussier |
Once upon a time, there was a branch... |
| 12:20 |
kmlussier |
and it promised to get rid of the big, bad negative balances that lurked in the Evergreen world. |
| 12:21 |
|
mmorgan joined #evergreen |
| 12:25 |
dbwells |
kmlussier++ |
| 12:26 |
dbwells |
berick: I guess I will just say the crux of the matter came down to disagreement over "partial voids". If you believe, conceptually, that an event can be partially voided, then we did a lot of work for nothing. Otherwise, where we ended up, while imperfect, makes some sense. I am happy to try and answer specfic questions about the code as well, as best as I am able. |
| 12:28 |
berick |
dbwells: well, i'm just scratching the surface, so take my questions w/ many salt grains. in the short term, my concern is just a consistent user experience for those of us not using any of the neg. balance settings, which essentially means never using account adjuments (even though I'd like to). |
| 12:29 |
berick |
i think that really just boils down to removing {..., force_zero => 1, ...} when calling void_or_zero_overdues during mark-item-lost |
| 12:34 |
dbwells |
berick: The only thing I wonder off the top of my head is whether restoring overdues would work properly if you go that route. If it doesn't, that is a bug in itself, but this route would give it a much wider path to surface. |
| 12:35 |
berick |
thanks dbwells, I'll give it a shot |
| 12:38 |
Dyrcona |
Has anyone successfully used marc_export on Debian 8 Jessie or Ubuntu 16.04? |
| 12:39 |
Dyrcona |
I'm seeing an issue with looping over bre output and putting US MARC into a file on both of those distros. |
| 12:39 |
Dyrcona |
It's just a loop of fretchrow_harshref, make a MARC::Record object, and write it to a file as US MARC. |
| 12:40 |
Dyrcona |
The program eats all the RAM on the VM before any records are written. |
| 12:42 |
Dyrcona |
fretchrow_harshref....Right, Raggie? Right on, Scoob! |
| 12:42 |
berick |
dude, your harshref'ing my mellow |
| 12:42 |
Dyrcona |
berick++ |
| 12:43 |
Dyrcona |
I'll finish setting up Evergreen on this VM and try a marc_export. |
| 12:45 |
dbwells |
berick: FWIW, we've been running the setup you are trying to avoid for about a year and half, and I've only gotten one question about it (i.e. adjustments for lost overdues, voids for everything else). Very different userbase, though (obviously). |
| 12:49 |
berick |
dbwells: good to know. |
| 12:56 |
berick |
dbwells: looks like the only difference how the overdues are reinstated. previously, it would un-void, now it leaves the old ones voided, and creates a new, single combined overdue billing. |
| 12:59 |
dbwells |
berick: thanks for letting me know. I'd hoped we accounted for that path. |
| 13:00 |
berick |
yeah, it's got a code block for "if this was voided the old-school way" |
| 13:01 |
berick |
dbwells: got an example off the top of your head of the controversial "partial void"? |
| 13:03 |
dbwells |
berick: In current code, or an earlier revision? |
| 13:03 |
berick |
dbwells: either way, just trying to understand your comments up ^-- there |
| 13:05 |
berick |
in my usual fashion, if i'm not actively participating, it's all white noise. just catching up. |
| 13:05 |
dbwells |
Okay sure. One fundamental issue with avoiding negative balances is dealing with partially paid billings. |
| 13:06 |
dbwells |
If you have a $50 lost fine, pay $25, then bring the item back, if the library has a "no refunds" policy, then we need to deal with the remaining $25. |
| 13:07 |
* jeff |
raises hand |
| 13:07 |
jeff |
yup. us. |
| 13:07 |
jeff |
sorry. |
| 13:07 |
dbwells |
An earlier version of the code applied a $25 "void" to the transaction. |
| 13:09 |
dbwells |
Some, including me, felt that a void should be a black-and-white event, essentially saying "this never happened", usual implying it was a mistake. |
| 13:10 |
dbwells |
The new code was kept, but the new payment was simply renamed to an "adjustment". |
| 13:11 |
* miker |
raises had as one of the others that likes a hard definition for "void" :) |
| 13:13 |
Dyrcona |
The void payment was an attempt to void part of a billing. Previously you could only void the whole thing. |
| 13:14 |
dbwells |
It was also advantagous for sake of continuity (in interfaces, reports, etc.) to preserve the existing void structure rather than try to replace it. |
| 13:15 |
dbwells |
berick: does that help? |
| 13:19 |
berick |
dbwells: yes, absolutely. |
| 13:19 |
dbwells |
To sum up, void, if kept conceptually simple (black-and-white), was adequate modeled by the existing flag structure, so we tried to keep it that way. Adjustments are similar in the "balance-goes-down-without-real-payment" sense, but conceptually more flexible to cover more cases. |
| 13:19 |
* berick |
got a bit distracted |
| 13:23 |
kmlussier |
All of this negative balance talk reminds me of things missing from the web client. |
| 13:23 |
* kmlussier |
files LP bugs before she forgets again. |
| 13:25 |
dbwells |
berick: The case of switching voids to adjustments for lost item overdues was not functionally necessary. It was an attempt to take advantage of a richer set of tools to hopefully, eventually, actually have *more* clarity. A guy can dream, can't he? |
| 13:28 |
berick |
dbwells: also good to know. and I agree in principle. it's better. |
| 14:12 |
|
NawJo joined #evergreen |
| 14:13 |
Dyrcona |
Bmagic: Have you encountered any issues with MARC on Ubuntu 16.04? Am I right you're running Ubuntu 16.04? |
| 14:13 |
Dyrcona |
csharp: I guess the same question goes to you, too. |
| 14:14 |
Dyrcona |
jeff and I are poking and it's looking like issues with Encode.pm at the moment. |
| 14:15 |
Dyrcona |
jeff is looking at Debian 8, and sees similar things, but slightly less bad in some ways. :) |
| 14:17 |
jeff |
what i'm seeing is that if i try to stick with the defaults of USMARC and MARC8 enoding, the output file seems to have internal length issues that are likely character/byte differences between MARC8 and UTF-8 characters. |
| 14:18 |
jeff |
if i pass -e UTF-8 to marc_export, the problem appears to go away. |
| 14:19 |
jeff |
~255k records exported in 7m38.728s |
| 14:19 |
pinesol_green |
jeff: I am only a bot, please don't think I'm intelligent :) |
| 14:19 |
Dyrcona |
If I pass -e UTF-8, I still get issues that look like byte length problems. |
| 14:19 |
Dyrcona |
Difference is I'm using Perl 5.22 and jeff is using Perl 5.20. |
| 14:20 |
Dyrcona |
We get some similar messages from yaz-marcdump afterward, but I get some that he doesn't. |
| 14:21 |
Dyrcona |
Directory offset 24: Data out of bounds 8532 >= 3239 |
| 14:21 |
Dyrcona |
That's one I see that jeff doesn't. |
| 14:22 |
Dyrcona |
If I dump xml and then convert to usmarc with yaz-macdump, things are better. |
| 14:22 |
Dyrcona |
Though some of the records fail to parse. |
| 14:22 |
Dyrcona |
So, looking like length calculations and Encode.pm in MARC::Record, maybe... |
| 14:25 |
kmlussier |
Is this related at all to bug 1584891 ? |
| 14:25 |
pinesol_green |
Launchpad bug 1584891 in Evergreen 2.11 "marc_export -i gives incorrect record length in the leader when call numbers include UTF8 characters" [Undecided,Fix committed] https://launchpad.net/bugs/1584891 |
| 14:26 |
* kmlussier |
has nothing else to offer, but saw similar words in the bug report. |
| 14:28 |
Dyrcona |
Well, it could be, but I've seen really nutty behavior in my Boopsie extract program. |
| 14:28 |
Dyrcona |
It just uses MARC::Record on the out put of a database query. |
| 14:30 |
Dyrcona |
Actually, no. It has to be something else. |
| 14:31 |
Dyrcona |
I'm using master fetched as a couple of hours ago. |
| 14:32 |
kmlussier |
OK, worth a shot. I'll go back to figuring out why I haven't received e-mail all day. |
| 14:33 |
Dyrcona |
Yeah, that's probably more immediately important. :) |
| 14:33 |
Dyrcona |
I'm gonna take a break for a bit, myself. |
| 15:00 |
|
mmorgan joined #evergreen |
| 15:01 |
|
mmorgan1 joined #evergreen |
| 15:09 |
* csharp |
just hit the sms.cricket.com issue that Stompro mentioned a couple of weeks ago: http://irc.evergreen-ils.org/evergreen/2017-02-24#i_291773 |
| 15:09 |
csharp |
from this source: https://mfitzp.io/list-of-email-to-sms-gateways/ it's reported not working as of 2015 |
| 15:10 |
csharp |
anyhoo, I'm thinking of opening a bug to remove it from the list of carriers |
| 15:10 |
Stompro |
csharp, I just disabled the cricket provider and emailed all the users that were trying to use it, which was only a small number for us, like 10. |
| 15:10 |
csharp |
cool |
| 15:10 |
csharp |
it's more for us, but I'mma have a similar approach |
| 15:11 |
Dyrcona |
It should be removed from the default list, IMO. |
| 15:11 |
csharp |
yeah |
| 15:23 |
jeff |
for those using email to sms gateways, how much volume do you see in a given day/week? |
| 15:24 |
jeff |
and how much grouping of notifications do you do -- mostly one notification per hold, perhaps unless several hit within the interval where you run the notifications? |
| 15:25 |
jeff |
(i.e., grouped by usr or sms number, but only if there are several that become available between A/T runs from cron) |
| 15:27 |
jeff |
Dyrcona: zero errors or warnings emitted by yaz-marcdump on my marc_export of all records. |
| 15:27 |
jeff |
marc_export -a -e UTF-8 > export-all.mrc |
| 15:27 |
jeff |
followed by |
| 15:28 |
jeff |
yaz-marcdump -n -p export-all.mrc | grep -v '^<!-- Record .* -->$' |
| 15:28 |
jeff |
which i could have probably simplified to: |
| 15:28 |
jeff |
yaz-marcdump -n export-all.mrc |
| 15:32 |
csharp |
jeff: I'll have to do some research to get volume - it's a good question to address and terran's and my session at the EG conf </shameless_plug> |
| 15:33 |
|
Enjabain joined #evergreen |
| 15:34 |
csharp |
jeff: we group by sms number for hold requests, running every half hour |
| 15:34 |
csharp |
and by usr id for circ notices |
| 15:35 |
Dyrcona |
jeff: OK. |
| 15:35 |
csharp |
they run at 8am, 12pm, and 4pm each day |
| 15:35 |
csharp |
(we don't want to be texting people in the middle of the night) |
| 15:36 |
Dyrcona |
What I don't get is why something that worked fine on Trusty and Wheezy eats all the RAM on Jessie and Xenial and it's basically doing what marc_export does, only less... |
| 15:36 |
|
NawJo_ joined #evergreen |
| 15:36 |
csharp |
"Boopsie extract" sounds like 19th century snake oil for babies :-) |
| 15:37 |
Dyrcona |
That was my main reason for testing marc_export, to see if it used all the RAM. |
| 15:37 |
Dyrcona |
:) |
| 15:37 |
Dyrcona |
Well, I think they named Boopsie after Betty Boop. |
| 15:37 |
Dyrcona |
So, close....:) |
| 15:38 |
csharp |
oh - interesting |
| 15:38 |
Dyrcona |
But, marc_export of xml and converting with yaz-marcdump seems to be working for me. |
| 15:38 |
berick |
csharp: haha |
| 15:38 |
Dyrcona |
Well, better than either the Boopsie script or marc_export to usmarc. |
| 15:39 |
bshum |
One of the CT librarians called it "oopsie" once. |
| 15:39 |
berick |
getcha boopsie extract, guaranteed to cure festering humors |
| 15:39 |
Dyrcona |
berick: I think it would be for more...um...intimate things. :) |
| 15:40 |
Dyrcona |
Butanyway. |
| 15:40 |
csharp |
"from 100% organic free-range Boopsie" |
| 15:40 |
Dyrcona |
It's here if anyone wants to poke it, which I doubt: https://github.com/Dyrcona/boopsie |
| 15:40 |
berick |
cure your woopsies with a dash of Boopsie |
| 15:41 |
csharp |
berick++ |
| 15:41 |
Dyrcona |
I still suspect that there are issues with Encode and/or MARC::Record and Perl 5.22 on Ubuntu 16.04. |
| 15:41 |
Dyrcona |
berick++ :) |
| 15:41 |
berick |
it's fun not to work |
| 15:42 |
Dyrcona |
I'll try it with concerto data later. We have some French and Italian records with accents. |
| 15:42 |
csharp |
srsly |
| 15:42 |
Dyrcona |
it's work not to fun? |
| 15:42 |
berick |
Dyrcona: that checkouts out. transitive property |
| 15:43 |
Dyrcona |
:) |
| 15:43 |
bshum |
Huh... is the live tests system unhappy? Can't access the page, and no test success message from expected 5 am run this morning |
| 15:43 |
Dyrcona |
heh heh...he said transitive.... |
| 15:49 |
|
rlefaive joined #evergreen |
| 15:51 |
jeffdavis |
kmlussier: ebook API release notes pushed to working/user/jeffdavis/lp1541559-ebook-api-phase1-release-notes |
| 16:16 |
|
Enjabain joined #evergreen |
| 16:23 |
kmlussier |
jeffdavis: Thanks! |
| 16:23 |
kmlussier |
jeffdavis++ |
| 16:26 |
|
Jillianne joined #evergreen |
| 16:32 |
|
mmorgan joined #evergreen |
| 17:03 |
|
mmorgan left #evergreen |
| 17:37 |
|
Enjabain joined #evergreen |
| 17:59 |
|
khuckins_ joined #evergreen |
| 18:24 |
|
kaffenkj joined #evergreen |
| 18:25 |
|
khuckins__ joined #evergreen |
| 18:27 |
|
Guest34221 joined #evergreen |
| 23:46 |
|
kaffenkj joined #evergreen |
