Time |
Nick |
Message |
03:11 |
|
jventuro joined #evergreen |
05:17 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
05:41 |
|
sseng_ joined #evergreen |
07:06 |
|
Sato joined #evergreen |
07:32 |
|
rjackson-isl joined #evergreen |
07:48 |
|
kmlussier joined #evergreen |
08:01 |
|
mtate joined #evergreen |
08:01 |
|
eeevil joined #evergreen |
08:02 |
|
phasefx joined #evergreen |
08:02 |
|
Callender joined #evergreen |
08:03 |
|
graced joined #evergreen |
08:09 |
|
_bott_ joined #evergreen |
08:09 |
|
_bott_ left #evergreen |
08:09 |
|
_bott_ joined #evergreen |
08:27 |
|
mrpeters joined #evergreen |
08:28 |
|
tspindler joined #evergreen |
08:33 |
kmlussier |
Good morning! |
08:35 |
tspindler |
@coffee kmlussier |
08:35 |
* pinesol_green |
brews and pours a cup of Ethiopia Yirgacheffe Koke, and sends it sliding down the bar to kmlussier |
08:35 |
kmlussier |
tspindler: Thanks! I needed that. We're out of coffee this morning. |
08:36 |
tspindler |
kmlussier: prices are going up apparently, drought in brazil |
08:37 |
* kmlussier |
is trying to make do with tea. |
08:41 |
kmlussier |
@love new edit links in the catalog |
08:41 |
pinesol_green |
kmlussier: The operation succeeded. kmlussier loves new edit links in the catalog. |
08:42 |
|
mmorgan joined #evergreen |
08:50 |
|
ericar joined #evergreen |
08:50 |
|
jwoodard joined #evergreen |
08:52 |
|
DPearl left #evergreen |
09:06 |
|
Dyrcona joined #evergreen |
09:08 |
|
collum joined #evergreen |
09:12 |
|
Sato joined #evergreen |
09:18 |
kmlussier |
eeevil: The working branch with all column picker options that you mentioned in your e-mail last week: do you know if that's loaded on webby right now? |
09:18 |
mrpeters |
kmlussier: what can you edit with those links? i haven't been following that |
09:19 |
mrpeters |
are they just for staff, or for patrons as well to make corrections/contributions? |
09:19 |
kmlussier |
mrpeters: In 2.7, when you're logged into the staff client, you'll get edit links for items you have permission to edit. |
09:19 |
kmlussier |
So you can skip the step of going to holdings maintenance to edit item information. |
09:19 |
mrpeters |
oh very cool |
09:19 |
mrpeters |
i like it |
09:19 |
mrpeters |
top |
09:19 |
mrpeters |
oops |
09:20 |
kmlussier |
cwmars++ #Funding development that saves time for staff. :) |
09:20 |
|
Shae joined #evergreen |
09:25 |
* dbs |
ran into https://rt.cpan.org/Public/Bug/Display.html?id=84841 (simplezoom seg faulting on Ubuntu 12.04), apparently SITKA addressed this by using yaz's deb packages instead. will report back. |
09:32 |
csharp |
so that would appear if you're allowing z39.50 access to your catalog? |
09:33 |
jeff |
@coffee [coffee] |
09:33 |
* pinesol_green |
brews and pours a cup of Kenya Karogoto, and sends it sliding down the bar to brews and pours a cup of Burundi Kinyovu, and sends it sliding down the bar to jeff |
09:34 |
jeff |
my coffee needs a coffee this morning. |
09:34 |
kmlussier |
heh |
09:34 |
csharp |
@coffee [someone] |
09:34 |
* pinesol_green |
brews and pours a cup of Ethiopia Sidamo Special Prep, and sends it sliding down the bar to mtate |
09:34 |
csharp |
@quote random |
09:34 |
pinesol_green |
csharp: Quote #14: "<Dyrcona> Alas, poor Craftsman. I knew him well, Horatio." (added by bshum at 04:18 PM, August 02, 2011) |
09:34 |
mtate |
mmmm ... thank you! |
09:35 |
csharp |
mtate: my pleasure ;-) |
09:35 |
csharp |
@praise [someone] |
09:35 |
* pinesol_green |
mrpeters is the very model of a modern major hacker |
09:35 |
mtate |
@love coffee |
09:35 |
pinesol_green |
mtate: The operation succeeded. mtate loves coffee. |
09:35 |
mrpeters |
haha |
09:35 |
kmlussier |
@whocares coffee |
09:35 |
pinesol_green |
kmlussier, csharp and mtate love coffee |
09:36 |
mtate |
he is script kiddie, hex coder, and little bit of safe-cracker... |
09:39 |
|
yboston joined #evergreen |
09:39 |
dbs |
csharp: yes indeed. We're big fans of open z39.50 access here (in fact, required as part of our participation in a national ILL service) |
09:39 |
jeff |
he exploits [redacted] [redacted] [redacted] |
09:40 |
dbs |
fwiw, we never had a problem with the distro packages when we were on debian. ubuntu-- |
09:41 |
Dyrcona |
dbs: Debian is more conservative. Ubuntu pulls from snapshots from Sid every 6 months. |
09:42 |
Dyrcona |
And Sid is named Sid because.... |
09:43 |
mtate |
...he's unstable |
09:43 |
mtate |
. o O (...maybe even malicious...) |
09:44 |
Dyrcona |
mtate: Specifically because he's the kid next door who breaks his toys. |
09:44 |
mtate |
lol |
09:48 |
|
sarabee joined #evergreen |
09:48 |
dbs |
Oh, I know Sid. |
09:49 |
dbs |
I'm still decrementing ubuntu because this problem has existed for a couple of years. |
09:51 |
csharp |
well, to be pedantic, the LTS releases sync with debian testing, so this is likely a problem that would exist in jessie too |
09:52 |
csharp |
unless it doesn't pass muster with Debian testers, that is |
10:01 |
|
RoganH joined #evergreen |
10:15 |
kmlussier |
Web client testing is also a good way to remember old bugs that I forgot to file in LP. |
10:42 |
|
ningalls joined #evergreen |
10:48 |
kmlussier |
I'm looking at the self-check docs at http://docs.evergreen-ils.org/2.7/_self_checkout.html#_configuring_self_check_behavior. For "Patron Login Timeout," it says not currently supported. Is that still true? |
10:48 |
bshum |
kmlussier: Right |
10:49 |
kmlussier |
Oh, wait. I see the bug report. |
10:49 |
bshum |
kmlussier: So there's a bug ticket for that and I wrote new code during the hackaway |
10:49 |
bshum |
I have to polish it up a bit |
10:49 |
mmorgan |
bshum++ |
10:49 |
kmlussier |
OK. Then I withdraw my next comment since code it sounds like code is forthcoming. :) |
10:49 |
kmlussier |
bshum++ |
10:51 |
bshum |
I haven't decided if it's a "new feature" or a "bug fix" though. |
10:53 |
kmlussier |
I would think bug fix since there is an existing setting that doesn't work. |
10:53 |
* mmorgan |
agrees that it's a bug fix |
10:53 |
bshum |
Oh fun then. |
10:54 |
bshum |
Well if anyone feels brave to try :) |
10:54 |
bshum |
http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/bshum/lp1306814-selfcheck-timeout |
10:54 |
bshum |
That's where I put the initial code I was poking at |
10:54 |
bshum |
I have to test it with an actual library setting configured. |
10:57 |
bshum |
I updated the bug report with a link to the code |
10:57 |
bshum |
And assigned targets as a bug fix. |
10:57 |
csharp |
heh - so it multiplies the patron timeout value by 1000? |
10:57 |
bshum |
Right, cause I think the setting is assigned as seconds |
10:57 |
bshum |
But the value is like milliseconds |
11:00 |
bshum |
The thing I'm not sure yet is whether I applied the timeout reset to enough places |
11:00 |
kmlussier |
We've been discussing this question locally, so I'll pose the question here. Has anyone noticed slower catalog searches since upgrading to 2.6? |
11:00 |
* bshum |
doesn't want to answer that question |
11:00 |
* csharp |
chuckles at the exorbitant values PINES libraries have been putting in to avoid any sort of timeout |
11:00 |
* RoganH |
thinks that bshum sees no evil, hears no evil, speaks no evil. |
11:00 |
kmlussier |
Well, given that response, I think I know what the answer is. |
11:01 |
kmlussier |
bshum: But some of that was based on your custom 001 record attribute, right? |
11:01 |
bshum |
kmlussier: Correct, for us, abnormally large entries in our uncontrolled values table was causing slowdown, among other things. |
11:01 |
* kmlussier |
is looking at search performance on a system that doesn't have custom record attributes. |
11:01 |
bshum |
I'm finishing testing eeevil's fixes for that. |
11:02 |
bshum |
Define "slow" |
11:02 |
bshum |
Like have you guys turned on the debug timing and grabbed numbers on how things are? |
11:03 |
kmlussier |
This is a system where they timed searches on 2.5 and then timed then again after uprading the same system to 2.6. We're seeing numbers where the search took 3 seconds on 2.5 and is now taking 12-14 seconds. A big difference. |
11:03 |
kmlussier |
bshum: No, we haven't. |
11:04 |
|
DPearl joined #evergreen |
11:04 |
bshum |
kmlussier: Well, what we did in our system was to start looking at the database logs and trying to track down which query calls were taking a long time. |
11:05 |
bshum |
eeevil suggested me to start watching for queries that were taking longer than like... 1 second. And that's what led me to scrutinize unapi.bre |
11:05 |
bshum |
And the stuff inside it |
11:05 |
bshum |
But yeah, I don't have anything specific to contribute to say, "yeah, it's super slow" |
11:05 |
|
vlewis joined #evergreen |
11:05 |
bshum |
In fact, our speed has definitely improved since we made the adjustment to production. |
11:05 |
bshum |
It's still slower than I'd prefer, but it's better. |
11:06 |
kmlussier |
https://drive.google.com/file/d/0B74gDMUDwDXqRHlHN1Y3SFdiTlE/view?usp=sharing |
11:06 |
bshum |
Could also be tuning related. |
11:06 |
bshum |
Do you know what postgresql version is being used behind the scenes? |
11:07 |
kmlussier |
Possibly. I was just curious to hear if others have seen it or if it's just us. |
11:07 |
tspindler |
bshum: i'm not sure is thre an easy way to check version |
11:07 |
bshum |
tspindler: Not remotely anyways, it's just a matter of asking whoever is running the show I would think :) |
11:07 |
tspindler |
bshum: it is our server so i have command line access |
11:08 |
bshum |
kmlussier: I'm not sure I'd say it's slow for everyone. MVLC has stayed pretty fast to me :) |
11:08 |
bshum |
We only got slow when we started reingesting and our uncontrolled got huge |
11:08 |
bshum |
Prior to that people definitely felt Evergreen was fast. Though we are using our new DB servers too. |
11:09 |
bshum |
Too much change at once. |
11:09 |
tspindler |
bshum: version is tspindlertraining:~$ psql --version psql (PostgreSQL) 9.1.13 |
11:27 |
kmlussier |
Reporting back for the sake of the logs. Looks like we also have a very large metabib.uncontrolled_record_attr_value table. |
11:28 |
csharp |
kmlussier: you might try vacuuming that table too - might edge up the speed |
11:29 |
csharp |
'vacuum analyze verbose metabib.uncontrolled_record_attr_value' that is |
11:29 |
kmlussier |
I think they're going to try the code at bug 1374091 |
11:29 |
pinesol_green |
Launchpad bug 1374091 in Evergreen 2.7 "unapi.bre and slow views" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1374091 |
11:29 |
csharp |
verbose is optional, of course, but I like to see the messages |
11:33 |
|
sandbergja joined #evergreen |
11:38 |
dbwells |
kmlussier: We didn't experience anything like the slowdowns shown in your chart. (great chart btw!) We also have a "normal" uncontrolled_record_attr_value table size (2551 rows). |
11:39 |
kmlussier |
dbwells: The credit for the great chart goes to tspindler. :) |
11:47 |
bshum |
csharp: Vacuuming the table didn't do anything for us, the new code helped :) |
11:50 |
Bmagic |
Im testing 2.7, right off the bat I don't see the secondary permission group UI in the staff client. Was there something I forgot to setup? |
11:51 |
kmlussier |
Bmagic: It should just display in the patron editor. And you need permission to see it. |
11:52 |
Bmagic |
kmlussier: huh, no magic trick? I am using an account with global everything |
11:54 |
bshum |
Hmm, it's working for me |
11:54 |
bshum |
There's a button for "Secondary Groups" that appears next to the profiles |
11:54 |
Bmagic |
bshum: kmlussier: I will take another look |
11:55 |
|
bkuhn joined #evergreen |
11:55 |
Bmagic |
I preformed an upgrade on an existing directory full of 2.6.1 code |
11:56 |
Bmagic |
aka /openils |
11:56 |
bshum |
Bmagic: That I don't know, all I know is that a clean install test server I was looking at seems fine. |
11:59 |
|
nhilton joined #evergreen |
11:59 |
|
ningalls joined #evergreen |
12:05 |
|
jihpringle joined #evergreen |
12:09 |
berick |
gmcharlt: were you able to make any headway w/ your nginx for websockets test? |
12:10 |
berick |
one of the OPW candidates cannot access webby... wondering if it's a port issue |
12:10 |
Bmagic |
bshum: I got it figured out, yay! |
12:10 |
gmcharlt |
berick: wouldn't surprise if it were; I expect to have tuits for that tomorrow |
12:10 |
kmlussier |
berick: We had a similar issue with another OPW candidate. We narrowed it down to the ports issue. |
12:10 |
berick |
gmcharlt: i have zero nginx experience (so far), but if I can be of assistance, let me know. |
12:11 |
berick |
kmlussier: good to know |
12:11 |
berick |
gmcharlt++ |
12:12 |
gmcharlt |
and, to share in the general "fun": http://the-digital-reader.com/2014/10/06/adobe-spying-users-collecting-data-ebook-libraries/ |
12:12 |
kmlussier |
I almost forgot. Snigdha said she was still waiting on a response for her SSH key submission. gmcharlt / dbs / tsbere: did any of you see it come through? |
12:12 |
gmcharlt |
kmlussier: yep, and was responded to, IIRC - perhaps it fell into a spam folder? |
12:13 |
kmlussier |
gmcharlt: Thanks. I'll let her know. |
12:17 |
|
mrpeters1 joined #evergreen |
12:18 |
bshum |
Bmagic++ # cool :) |
12:25 |
|
dreuther_ joined #evergreen |
12:36 |
|
dreuther joined #evergreen |
12:50 |
|
dreuther_ joined #evergreen |
12:52 |
|
eby_ joined #evergreen |
13:00 |
Bmagic |
Has anyone setup the web based staff client from the 2.7 branch? I was able to install grunt and bower and node but I'm sort of at a loss as to where the jumping point is for a URL to see the resulting pages |
13:04 |
|
dreuther joined #evergreen |
13:05 |
|
buzzy joined #evergreen |
13:06 |
gmcharlt |
Bmagic: https://yourhost/eg/staff/home |
13:09 |
Bmagic |
gmcharlt: I must need to start a service? (internal server error) |
13:11 |
Bmagic |
gmcharlt: nevermind, that's not the error, it's just a blank page |
13:15 |
Bmagic |
from the apache logs: File does not exist: /openils/var/web/js/ui/default/staff/build |
13:16 |
gmcharlt |
Bmagic: ah - running the grunt/npm steps IN /openils/var/web/js/ui/default/staff is necessary - or if you ran them in your Evergreen unpacked tarball or Git checkout, just copy the directoriwes over |
13:17 |
gmcharlt |
note that I may be getting paths a bit wrong - I'm currently waiting to start a webinar |
13:17 |
Bmagic |
oh I see, I ran them from the Evergreen source |
13:17 |
Bmagic |
not the /openils dir |
13:17 |
Bmagic |
thanks |
14:16 |
|
ldwhalen joined #evergreen |
14:59 |
|
julialima joined #evergreen |
15:08 |
|
mrpeters joined #evergreen |
15:12 |
mrpeters |
in A/T event hell! I have one particular event (the stock "Hold is ready for pickup") that just simply will not come out of the 'pending' state. All other events with the same granularity settings (Hourly) are working fine. The event is active, and new events are added to action_trigger.event regularly, they just never change state. Any ideas what I might be overlooking? |
15:13 |
bshum |
mrpeters: Are you using any granularity? |
15:13 |
mrpeters |
yeah, Hourly |
15:13 |
mrpeters |
/openils/bin/action_trigger_runner.pl --process-hooks --granularity hourly |
15:14 |
bshum |
What about --run-pending? |
15:14 |
mrpeters |
yeah, that runs every 30 -- /openils/bin/action_trigger_runner.pl --osrf-config=/openils/conf/opensrf_core.xml --run-pending |
15:14 |
bshum |
Do you have one setup for that granularity too |
15:14 |
bshum |
? |
15:14 |
bshum |
By itself, that may not catch the particular granularity. |
15:14 |
bshum |
It'll run everything else. |
15:15 |
bshum |
Or at least, that's been my experience so far, with adding other types of custom granularity. |
15:15 |
pastebot |
"mrpeters" at 64.57.241.14 pasted "AT cron example" (26 lines) at http://paste.evergreen-ils.org/16 |
15:15 |
bshum |
I have to define one cron for --process-hooks and later another for --run-pending |
15:16 |
mrpeters |
have a look at that....i think this was baselined from the example that comes with the tarballs, but i didn't do the initial setup so I can't be 100% for certain. Really strange. They worked prior to upgrade to 2.6.2, but just now finding out about it (2 months later---eesh) |
15:17 |
bshum |
Well I have no idea exactly |
15:17 |
bshum |
I just know that I have to have a --run-pending --granularity X cron job |
15:17 |
bshum |
That if I don't specify separately, it doesn't run those granularity |
15:17 |
mrpeters |
thats interesting |
15:17 |
mrpeters |
i'll give it a shot |
15:18 |
bshum |
I would add an entry for the hourly hook and see what happens. |
15:18 |
bshum |
Maybe this is some weird regression bug in 2.6 |
15:18 |
bshum |
I don't know if A/T changed |
15:19 |
mrpeters |
yeah, i am going to try that, its super strange...only that one hourly granularity |
15:20 |
mrpeters |
so you are thinking one like this: . ~/.bashrc && /openils/bin/action_trigger_runner.pl --osrf-config=/openils/conf/opensrf_core.xml --run-pending --granularity hourly |
15:20 |
* bshum |
checks his own crons, but yeah |
15:21 |
mrpeters |
ok, going to give it a shot |
15:23 |
* bshum |
doesn't seem to have hold pickup on granularity |
15:23 |
mrpeters |
yeah i was almost wondreing if it needed to be |
15:23 |
bshum |
Guess that came after our 1.6-era A/T setup |
15:23 |
mrpeters |
you probably want those to go out frequently |
15:23 |
bshum |
Pretty much as soon as they're ready to ship and once the delay is done |
15:24 |
Bmagic |
we run action_trigger_runner.pl --osrf-config /openils/conf/opensrf_core.xml --process-hooks --run-pending every day at 4am |
15:26 |
mrpeters |
i think this granularity addition is working....it's actually doing something now |
15:26 |
bshum |
Whee :) |
15:26 |
bshum |
So |
15:26 |
bshum |
Two choices |
15:26 |
bshum |
Run it separately like that |
15:26 |
bshum |
Or just remove the granularity |
15:26 |
bshum |
And let it ride :) |
15:26 |
mrpeters |
yeah, you know, i do wonder if this is a weird 2.6 thing |
15:26 |
|
dreuther_ joined #evergreen |
15:35 |
|
dreuther joined #evergreen |
15:38 |
csharp |
@who [quote random]? |
15:38 |
pinesol_green |
Bmagic Quote #68: "<senator> what a nice smile, dojo. why thank me, angularjs, and that's a nice outfit me're wearing." (added by gmcharlt at 10:52 AM, September 27, 2013. |
16:09 |
Bmagic |
Web staff client - Once I have node, grunt, bower installed, I presume I need to start the node server? My web browser is complaining about not getting a connection on port 7682 |
16:10 |
bshum |
Bmagic: So, assuming you have OpenSRF 2.4 installed? |
16:10 |
bshum |
Bmagic: And you have an apache2-websockets thingy around? |
16:10 |
Bmagic |
bshum, yes 2.4 alpha |
16:10 |
Bmagic |
not sure about apache2-websockets |
16:11 |
Bmagic |
did I miss that in the docs? |
16:11 |
bshum |
Bmagic: So one of the things that's in the README.websockets file that ships with alpha are steps to setup websockets. |
16:11 |
Bmagic |
ah! |
16:11 |
bshum |
I've been trying to integrate them with the core OpenSRF README file itself |
16:11 |
bshum |
See, this bug.... |
16:11 |
bshum |
https://bugs.launchpad.net/opensrf/+bug/1369169 |
16:11 |
pinesol_green |
Launchpad bug 1369169 in OpenSRF "Add install instructions for websockets to README (and other cleanup)" (affected: 1, heat: 6) [Undecided,New] |
16:11 |
berick |
Bmagic: node, bower, etc. are only used for dependency retrieval and unit tests. it's not needed for running the browser client. |
16:12 |
bshum |
Bmagic: http://evergreen-ils.org/~bshum/OpenSRF-README.html#_optional_websockets_installation_instructions |
16:12 |
bshum |
That's a generated copy of the integrated steps |
16:12 |
Bmagic |
!! |
16:12 |
Bmagic |
I new I was missing something |
16:12 |
bshum |
I still need to revise them a bit, to remove some of the hardcoded assumptions |
16:12 |
bshum |
Like where's the OpenSRF files to be found |
16:12 |
bshum |
Not always /home/opensrf/.. |
16:12 |
bshum |
But for the most part, those steps ought to work |
16:13 |
bshum |
That should spin up the websockets portion of OpenSRF 2.4 |
16:13 |
Bmagic |
ok, cool, I will walk through these instructions and provide feedback then |
16:13 |
bshum |
And then you should work out from there. |
16:13 |
bshum |
In theory |
16:16 |
|
buzzy joined #evergreen |
16:18 |
|
tspindler left #evergreen |
16:21 |
Bmagic |
bshum #it's working http://www.youtube.com/watch?v=AXwGVXD7qEQ |
16:21 |
Bmagic |
bshum++ |
16:22 |
bshum |
Bmagic: HAHA! |
16:22 |
bshum |
Amusingly enough, I was just about to go setup a new VM called "Anakin" :D |
16:22 |
Bmagic |
lol |
16:22 |
Dyrcona |
Bmagic++ |
16:26 |
bshum |
Bmagic++ |
16:26 |
Bmagic |
!! |
16:38 |
|
buzzy joined #evergreen |
17:15 |
|
mmorgan left #evergreen |
17:24 |
|
buzzy joined #evergreen |
17:49 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
17:51 |
bshum |
But gmcharlt, the quest_for_knowledge is over! |
17:51 |
bshum |
http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=988605ececad7850f2a7276b64a697b6b5c9ae31 |
17:51 |
pinesol_green |
[evergreen|Dan Wells] LP#1290496: The quest for knowledge is over - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=988605e> |
17:51 |
* bshum |
just read twitter and it uplifted my day. :D |
17:51 |
gmcharlt |
bshum: it's just been redirected ;) |
17:51 |
bshum |
gmcharlt++ |
17:52 |
gmcharlt |
bshum: also, I feel like I'm forgetting one of the code names |
17:53 |
bshum |
Heh |
17:56 |
dbwells |
maybe Vandelay? |
17:57 |
dbwells |
nevermind, that's what started it :) |
17:58 |
bshum |
Heh |
18:01 |
dbs |
conify? |
18:01 |
* dbs |
hasn't seen the tweet in question |
18:01 |
gmcharlt |
aha! |
18:02 |
gmcharlt |
dbs: https://twitter.com/mjgiarlo/status/519591580437458948 |
18:02 |
|
dbwells joined #evergreen |
18:02 |
|
remingtron_ joined #evergreen |
18:21 |
jeff |
cute. |
18:22 |
jeff |
open-ils.storage.actor.user.crazy_search amused me when i ran into it years ago, but i'm not sure it's a good example. |
18:41 |
|
tsbere joined #evergreen |
19:41 |
|
artunit joined #evergreen |
20:33 |
|
remingtron_ joined #evergreen |
20:33 |
|
dbwells_ joined #evergreen |
20:35 |
|
dbwells__ joined #evergreen |