Time |
Nick |
Message |
00:59 |
|
Mark__T joined #evergreen |
01:03 |
|
phasefx joined #evergreen |
01:43 |
|
eady joined #evergreen |
03:50 |
|
dcook joined #evergreen |
03:52 |
|
dcook__ joined #evergreen |
04:17 |
|
dcook__ joined #evergreen |
04:18 |
|
dcook__ joined #evergreen |
07:17 |
|
sarabee joined #evergreen |
07:26 |
|
geoffsams joined #evergreen |
07:48 |
|
sarabee joined #evergreen |
07:54 |
|
dcook joined #evergreen |
07:56 |
|
ericar joined #evergreen |
08:02 |
|
rjackson_isl joined #evergreen |
08:10 |
|
collum joined #evergreen |
08:21 |
kmlussier |
Good morning #evergreen |
08:22 |
kmlussier |
@coffee [someone] |
08:22 |
* pinesol_green |
brews and pours a cup of Kenya Kigutha, and sends it sliding down the bar to StomproJ |
08:22 |
kmlussier |
@tea [someone] |
08:22 |
* pinesol_green |
brews and pours a pot of Top Leaf™ Green Tea, and sends it sliding down the bar to StomproJ (http://ratetea.com/tea/mellow-monk/top-leaf/1186/) |
08:22 |
kmlussier |
Wow! pinesol_green is being very nice to StomproJ this morning. |
08:27 |
|
Dyrcona joined #evergreen |
08:28 |
|
mrpeters joined #evergreen |
08:30 |
StomproJ |
Nice! |
08:36 |
|
jwoodard joined #evergreen |
08:39 |
|
mmorgan joined #evergreen |
08:40 |
Dyrcona |
Yay! Kernel update. Back after a reboot. |
08:46 |
|
Dyrcona joined #evergreen |
09:19 |
|
ericar_ joined #evergreen |
09:20 |
bshum |
@unload Git |
09:20 |
pinesol_green |
bshum: The operation succeeded. |
09:20 |
bshum |
FYI, I'm looking at a problem with the git plugin with the bot |
09:20 |
bshum |
I think it's gone haywire :( |
09:27 |
|
maryj joined #evergreen |
09:33 |
bshum |
@load Git |
09:34 |
bshum |
Hmm |
09:34 |
pinesol_green |
bshum: The operation succeeded. |
09:34 |
bshum |
@git repolist |
09:34 |
pinesol_green |
bshum: evergreen (Evergreen, branch: master) |
09:34 |
pinesol_green |
bshum: opensrf (OpenSRF, branch: master) |
09:34 |
pinesol_green |
bshum: sipserver (SIPServer, branch: master) |
09:34 |
bshum |
Okay. |
09:45 |
|
yboston joined #evergreen |
09:50 |
jeff |
looks like https://github.com/disconnect/apache-websocket was last updated just over 3 years ago. |
10:16 |
bshum |
Maybe that means it's perfect just the way it is? :P |
10:19 |
berick |
heh |
10:19 |
berick |
guess we'll find out when people really start using it |
10:20 |
jeff |
the stock multiple instance example for apache2 is giving me issues on Jessie. not sure where the problem lies yet. |
10:23 |
jeff |
https://gist.github.com/jeff/67b18b300a72707cb8c3 |
10:23 |
jeff |
I think I've only personally run it on Wheezy. |
10:24 |
berick |
jeff: what happens if you: sudo apache2ctl-websockets start |
10:26 |
bshum |
Did you set the SSL certs? |
10:27 |
Dyrcona |
It's "working" on Ubuntu 14.04, for certain definitions of working. |
10:27 |
jeff |
berick: AH00534: apache2: Configuration error: No MPM loaded. |
10:28 |
jeff |
bshum: yup |
10:28 |
jeff |
though i can't say that there's not something wrong with the certs. i'm going to move on to the evergreen install on this vm and revisit websockets. |
10:28 |
bshum |
Dyrcona++ # "working" |
10:28 |
berick |
jeff: hm, /etc/apache2-websockets/apache2.conf -- does that look like the one from the repo? |
10:28 |
jeff |
Dyrcona: what issues are you having? |
10:28 |
berick |
the first thing it does is load an MPM |
10:29 |
Dyrcona |
jeff: Standard restart scripts don't work. You have to use apache2ctl-websockets. Other than that, no problems that I am aware of. |
10:29 |
Dyrcona |
There is a restart script created, but it don't work. |
10:30 |
jeff |
berick: it looks like the one from the opensrf repo, but it does not load an MPM. /etc/apache2-websockets/mods-enabled contains symlinks for mpm_prefork.conf and mpm_prefork.load, though. |
10:30 |
berick |
Include mods-available/mpm_prefork.load |
10:30 |
berick |
does that file exist (from the context of your websockets dir)? |
10:31 |
berick |
IOW, /etc/apache2-websockets/mods-available/mpm_prefork.load |
10:31 |
berick |
it's not using any of the magical symlinks |
10:31 |
berick |
it's just loading exactly what it needs |
10:34 |
jeff |
There we go. I was following directions a little too blindly. |
10:35 |
jeff |
I had the examples/apache2/websockets/apache2.conf in place, but Jessie is Apache 2.4 |
10:35 |
berick |
ah, ok |
10:38 |
Dyrcona |
That'll break it. ;) |
10:38 |
jeff |
using apache2ctl-websockets is still the way to go |
10:38 |
Dyrcona |
yep |
10:39 |
* jeff |
looks to see if there's (hopefully) an existing debian bug on the multiple-instance example under systemd |
10:39 |
|
Christineb joined #evergreen |
10:42 |
* berick |
marvels at the bright sun |
10:42 |
berick |
it's about time |
10:42 |
berick |
@weather 27712 |
10:42 |
pinesol_green |
berick: Durham, NC :: Clear :: 61F/16C | Tuesday: Abundant sunshine. High 72F. Winds N at 5 to 10 mph. Tuesday Night: A few passing clouds. Low 52F. Winds light and variable. |
10:43 |
jeff |
@weather ktvc |
10:43 |
pinesol_green |
jeff: Cherry Capital, MI :: Overcast :: 58F/14C | Tuesday: Sun and clouds mixed. High 66F. Winds W at 5 to 10 mph. Tuesday Night: A few clouds. Low 51F. Winds light and variable. |
10:43 |
jeff |
I like yours -- "Abundant sunshine." |
10:44 |
Dyrcona |
Ha ha. This is cute: Can't locate object method "as_usmarc" via package "27" (perhaps you forgot to load "27"?) at backstage_briefs_check.pl line 60. |
10:45 |
Dyrcona |
$record->field('590')->as_usmarc(); # No, that doesn't do what you wanted. |
10:45 |
jeff |
that was even better when my terminal wrapped it to (perhaps you forgot to backstage_briefs_check.pl line 60. |
10:45 |
berick |
use strict; use warnings; use 27; |
10:45 |
berick |
in all of your scripts, obviously |
10:46 |
Dyrcona |
Now, I question what record has 27 590 tags! |
10:46 |
Dyrcona |
berick++ # use 27; |
10:47 |
Dyrcona |
I probably don't want as_usmarc(), either, but I wanted to see what that would look like in my output. |
10:49 |
Dyrcona |
Definitely not what I want. :) |
10:51 |
kmlussier |
@weather |
10:51 |
pinesol_green |
kmlussier: Seekonk, MA :: Clear :: 58F/14C | Tuesday: Sunny. High 69F. Winds NNE at 5 to 10 mph. Tuesday Night: A few passing clouds, otherwise generally clear. Low 49F. Winds light and variable. |
10:51 |
* kmlussier |
was hoping for abundant sunshine. |
11:00 |
jeff |
Decadant Sunshine |
11:00 |
* berick |
basks |
11:00 |
jeff |
s/dant/dent/ :P |
11:00 |
berick |
from the dark confines of my basement |
11:00 |
jeff |
decadent: from the Greek, meaning "ten dents" |
11:01 |
berick |
11th dent free |
11:05 |
|
krvmga joined #evergreen |
11:11 |
Dyrcona |
I prefer dodecadent. |
11:13 |
|
sandbergja joined #evergreen |
11:17 |
* jeff |
grins |
11:21 |
|
ericar_ joined #evergreen |
12:02 |
|
bmills joined #evergreen |
12:37 |
|
jihpringle joined #evergreen |
12:41 |
|
WTBYCop joined #evergreen |
13:21 |
|
WTBYCop joined #evergreen |
13:24 |
Dyrcona |
Launchpadfreude = The feeling you get when you search Launchpad for a bug that you just know exists, but you can't find it. |
13:25 |
berick |
wouldn't that be the feeling you get when that happens to someone else? |
13:27 |
* berick |
is impressed by the outpour of support for bug #1502292 |
13:27 |
pinesol_green |
Launchpad bug 1502292 in Evergreen "web client: Need ability to add volumes from the bib record" [Undecided,New] https://launchpad.net/bugs/1502292 |
13:27 |
berick |
i think we've hit a nerve |
13:31 |
bshum |
It's certainly the bug with the most heat on it. Other than security bugs, which get extra heat for being marked as such. |
13:33 |
bshum |
affects 25 users, that's certainly got to be a record. |
13:34 |
dbwells |
Freude = joy, so Launchpadfreude would mean... something else :) |
13:34 |
* dbwells |
removes his German major hat, puts it back in the closet |
13:36 |
kmlussier |
bshum: Is that more than negative balances? |
13:37 |
bshum |
kmlussier: I'd have to go back and check the closed bugs. But it's certainly the highest heat on a bug that's still open ;) |
13:37 |
bshum |
https://bugs.launchpad.net/evergreen/+bug/1198465 only had 17 people listed. |
13:37 |
pinesol_green |
Launchpad bug 1198465 in Evergreen "Support for Conditional Negative Balances" [Wishlist,Fix released] |
13:38 |
bshum |
And an LP heat of 80. |
13:38 |
Dyrcona |
Launpadenangst, then. :) |
13:38 |
bshum |
That add volumes one is LP heat of 118, with 26 affected |
13:38 |
bshum |
For those who clicked anyways |
13:39 |
kmlussier |
Anyone know how to delete bib records in the web client? |
13:39 |
bshum |
So yes, it is "higher" than negative balances. |
13:39 |
bshum |
kmlussier: It's not in actions for this record? |
13:39 |
bshum |
That's just a guess, I'm not looking |
13:39 |
Dyrcona |
delete from biblio.record_entry; |
13:39 |
Dyrcona |
:) |
13:39 |
bshum |
Dyrcona: Hehe, no WHERE?!? |
13:40 |
Dyrcona |
where 1=1; |
13:40 |
Dyrcona |
:) |
13:40 |
Dyrcona |
That'll fix it. |
13:40 |
bshum |
Hehe |
13:40 |
kmlussier |
bshum: There is no actions for this record in the web client. |
13:40 |
* Dyrcona |
tries hitting Del a few times. |
13:41 |
Dyrcona |
Ok. Back to messing with bibs. |
13:41 |
kmlussier |
It apparently is possible since I received a report about a problem with it, but it's eluding me. |
13:42 |
kmlussier |
Well, look at that. The person reporting the issue told me where to find it. |
13:43 |
* kmlussier |
learns to read. |
13:43 |
kmlussier |
For the logs, in the web client, you delete a record from the MARC Edit tab. |
13:45 |
jeff |
press ` to open the web client console, then issue the command DELETE CURRENT RECORD |
13:45 |
* jeff |
hides behind his coffee mug |
13:50 |
* dbs |
is tempted to write a "Adding an Add Volumes option to the editor would bring about the end times!" comment, just to stir things up, but will not |
13:51 |
* dbs |
hopes somebody is going to invest either $$$ or time to make it happen though |
13:57 |
|
ericar_ joined #evergreen |
14:00 |
krvmga |
i can't seem to figure out how to get a uniform title search to work. :( |
14:00 |
krvmga |
i just want to limit to marc 240 |
14:01 |
kmlussier |
Can you give me an example of a uniform title to search? |
14:02 |
kmlussier |
krvmga ^ ^ |
14:02 |
krvmga |
i'm looking for a good one |
14:03 |
krvmga |
i'm trying to create a filter for uniform title under keyword |
14:03 |
krvmga |
http://training.cwmars.org/eg/opac/record/478048?contains=contains;_special=1;qtype=identifier%7Ctcn;query=478048;locg=1 |
14:04 |
krvmga |
i grabbed this one by the TCN |
14:04 |
kmlussier |
I thought if you set the qtype to title|uniform |
14:04 |
Dyrcona |
@eigthball Does deleting a bre change the edit_date? |
14:04 |
pinesol_green |
Dyrcona: Have you tried taking it apart and putting it back together again? |
14:05 |
krvmga |
i think my brain is frizzing out. it's too early in the day for that to happen :( |
14:06 |
krvmga |
where would you like me to set the qtype to title|uniform? |
14:07 |
kmlussier |
krvmga: http://bark.cwmars.org/eg/opac/results?query=title%7Cuniform%3Awar+dog&qtype=keyword&fi%3Asearch_format=&locg=1&_adv=1&page=0&sort= |
14:08 |
kmlussier |
krvmga: Sorry, that's wrong. |
14:09 |
kmlussier |
krvmga: http://bark.cwmars.org/eg/opac/results?bool=and&qtype=title%7Cuniform&contains=contains&query=war+dog&bool=and&qtype=title&contains=contains&query=&bool=and&qtype=author&contains=contains&query=&_adv=1&locg=1&pubdate=is&date1=&date2=&sort= |
14:11 |
kmlussier |
krvmga: Is your ultimate goal to add Uniform Title to the selector? |
14:12 |
krvmga |
kmlussier: yes |
14:12 |
|
WTBYCop joined #evergreen |
14:13 |
kmlussier |
krvmga: What I would do, then, is follow the example of the numeric search selector. |
14:13 |
kmlussier |
Instead of identifier|isbn for the qtype, you would use title|uniform. |
14:17 |
krvmga |
kmlussier: that works fine for the numeric search dropdown but not the keyword dropdown. (i was already chastized for doing this under numeric search.) |
14:18 |
bshum |
Keyword dropdown meaning... basic search? |
14:19 |
krvmga |
the same dropdown appears in both basic and advanced search: keyword, title, etc. |
14:20 |
bshum |
krvmga: It's not really the same dropdown. |
14:20 |
bshum |
(or at least I dont' think it is) |
14:20 |
krvmga |
bshum: interesting |
14:21 |
* kmlussier |
looks more closely |
14:22 |
krvmga |
krvmga wants more coffee. Coffee pot is done for the day. :( |
14:23 |
kmlussier |
krvmga: I added one here http://mlnc1.mvlcstaff.org/eg/opac/home but I don't know what might be available in the Concerto set with a uniform title to test it with. |
14:23 |
bshum |
Yeah, so... |
14:24 |
kmlussier |
But the resulting syntax on the search results page looks right. |
14:24 |
bshum |
Basic search is based off parts/searchbar.tt2 which pulls from qtype_selector.tt2 |
14:24 |
bshum |
But advanced search is from parts/advanced/search.tt2 |
14:24 |
bshum |
Which seems to do coded_value stuff |
14:24 |
bshum |
So... different. |
14:24 |
bshum |
Hence, my question stands, which search are you working on? :) |
14:24 |
kmlussier |
OK, and the test I just did was for basic search. I assume the preference is that it show up in advanced. I hope. |
14:25 |
krvmga |
i added it to qtype_selector.tt2 and it shows up in both places |
14:25 |
krvmga |
{value => "uniform", label => l("Uniform Title")}, |
14:26 |
* bshum |
wonders if maybe it's deeper than he thought then |
14:27 |
kmlussier |
Yeah, I'm finding the same results as krvmga |
14:27 |
krvmga |
'uniform' is its name in config.metabib_field |
14:27 |
kmlussier |
But if I do a uniform title search for violin, it is pulling up other stuff. So hmmmm |
14:27 |
krvmga |
kmlussier: yes, this is my experience. |
14:37 |
jeff |
the xpath on that field def and what i'm actually seeing indexed in concerto doesn't seem to match -- oh, wait. |
14:38 |
kmlussier |
When I do a "uniform title" search for "violin" on mlnc1 with Concerto data, I retrieve the same number of results as if I were searching for title. |
14:39 |
kmlussier |
However, if I copy over the end of the URL to the C/W MARS production system running 2.7, it does seem to be searching just the uniform titles. But it's hard to say. There are definitely fewer results than a title search for the same word. |
14:39 |
kmlussier |
http://bark.cwmars.org/eg/opac/results?query=violin&qtype=title%7Cuniform&fi%3Asearch_format=&locg=1 |
14:40 |
kmlussier |
I either misunderstood how you could search the uniform title index alone (very possible) or there's been a change in behavior since 2.7? |
14:41 |
krvmga |
kmlussier: i'm not sure what to make of your experience there. |
14:42 |
kmlussier |
krvmga: FWIW the code for my selector was {value => "title|uniform", label => l("Uniform Title")}, |
14:42 |
krvmga |
kmlussier: thx. i'll give that a shot. |
14:43 |
|
dcook joined #evergreen |
14:52 |
|
gdunbar joined #evergreen |
14:54 |
|
gdunbar joined #evergreen |
14:54 |
jeff |
so, once i remembered that the SuperCat feeds use a different "mods32" than exists in config.xml_transform (which is used at ingest time), I've got a whole 'nother set of questions. |
14:55 |
|
dcook joined #evergreen |
14:57 |
|
graced_ joined #evergreen |
14:57 |
miker |
krvmga: kmlussier's correct, and you can also use metabib.search_alias to give a specific field a name of its own without the class part. in fact, title|uniform can be spelled bib.titleuniform via alias already http://wiki.evergreen-ils.org/doku.php?id=documentation:technical:search_grammar |
14:58 |
kmlussier |
miker++ |
14:58 |
krvmga |
miker++ |
14:59 |
kmlussier |
miker: Thanks for confirming that. Do you have any thoughts on why it seems to be doing a title search when I tried it on a more recent master release? http://mlnc1.mvlcstaff.org/eg/opac/results?query=violin&qtype=title%7Cuniform&fi%3Asearch_format=&locg=1 |
14:59 |
kmlussier |
I don't know if there's a new bug there or if I did something wrong on the test server. |
15:01 |
miker |
kmlussier: hrm... I suspect that qtype is interpreted in EGCatLoader instead of simply used |
15:03 |
miker |
code suggests I'm wrong |
15:04 |
|
jwoodard joined #evergreen |
15:05 |
kmlussier |
@240 |
15:05 |
pinesol_green |
kmlussier: Down time is a fact of business when you're a poor 501c3 corporation. |
15:05 |
kmlussier |
@marc 240 |
15:05 |
pinesol_green |
kmlussier: The uniform title for an item when the bibliographic description is entered under a main entry field that contains a personal (field 100), corporate (110), or meeting (111) name. [a,d,f,g,h,k,l,m,n,o,p,r,s,6,8] |
15:05 |
miker |
kmlussier: 730 where ind2 != 2 is a uniform title |
15:05 |
miker |
http://www.loc.gov/standards/mods/v3/mods-mapping.html#title |
15:06 |
miker |
according to mods |
15:06 |
miker |
@marc 730 |
15:06 |
pinesol_green |
miker: Contains a related or an analytical title that is controlled by an authority file or list. (Repeatable) [a,d,f,g,h,k,l,m,n,o,p,r,s,t,x,3,5,6,8] |
15:06 |
kmlussier |
miker: Ah! OK, thanks. I'm obviously not a cataloger and I was too lazy to look at the mods definition. |
15:08 |
kmlussier |
bib.titleuniform works for me too. I've never really looked at the aliases before. Something new to have fun with. |
15:11 |
jeff |
interesting. if a bib has more than one uniform title (per the in-db MODS transform), an additional entry is created which contains all of the uniform titles concatenated together. |
15:11 |
* jeff |
looks to see why that is, and what other things behave in a similar way |
15:20 |
krvmga |
in the metabib_field xpath, can i do //marc:datafield[@tag='260' or @tag='264']/marc:subfield[@code='b'] ?? |
15:21 |
krvmga |
i know i can put 'or' in the subfield part, can i put an or in the datafield? |
15:23 |
krvmga |
i'm just trying to come up with a way to include the RDA publisher in publisher. |
15:23 |
krvmga |
right now, our database has publisher and publisher_rda |
15:24 |
krvmga |
their marc:subfield is the same, just the datafield is different |
15:25 |
kmlussier |
krvmga: Yes. |
15:25 |
krvmga |
Yay! |
15:26 |
kmlussier |
To test it, change the xpath and then edit one record with a 264. After you save it, the publisher should show up in your publisher metabib entry for that record. |
15:28 |
jeff |
okay, looks like biblio.extract_metabib_field_entry does the "output a row containing a concatenated version of all the entries" for any field that is a search field. |
15:28 |
jeff |
and now i have deja vu. :P |
15:29 |
kmlussier |
bug 1251394 is what's needed for the titles to appear in proper capitalization in the web client, right? I should try loading that branch on the test server again. |
15:29 |
pinesol_green |
Launchpad bug 1251394 in Evergreen "Metabib Display Fields" [Wishlist,Triaged] https://launchpad.net/bugs/1251394 |
15:30 |
Bmagic |
it's funny we are talking about xpath, because I have a question about it as well. "//mods32:mods/mods32:titleInfo[mods32:title and not (@type)]" is stock in our DB for "Title Proper" - It looks like it would include the 700t but it doesn't |
15:31 |
jeff |
Bmagic: what method are you using to look at the mods32 transform of your example records? |
15:31 |
jeff |
kmlussier: that is my understanding, yes |
15:31 |
Bmagic |
im looking at metabib.title_field_entry for an example record that has a 700t |
15:33 |
kmlussier |
I thought 700t was a relateditem, not a title |
15:33 |
kmlussier |
According to mods |
15:34 |
jeff |
yeah, in a sample concerto record the 700$t would not match that xpath. |
15:35 |
jeff |
it looks like it would match "//mods32:mods/mods32:relatedItem/mods32:titleInfo[mods32:title and not (@type)]" |
15:35 |
kmlussier |
I'm feeling a sense of deja vu myself. Have you had this discussion before? |
15:36 |
Bmagic |
ah relateditem |
15:39 |
|
ericar_ joined #evergreen |
15:48 |
Bmagic |
jeff: what method are you using to test your mods32 query? |
15:53 |
Bmagic |
jeff: Your query does match the 700t but it also gets the 490a? |
16:09 |
|
Sessions1024 joined #evergreen |
16:27 |
|
jlitrell joined #evergreen |
16:39 |
kmlussier |
Never fails. As soon as I start recording my actions, the software starts behaving as expected. |
16:42 |
jlitrell |
Heisenbugs! |
16:43 |
mmorgan |
Heh. |
16:44 |
jonadab |
Indeed. We had a long-standing bug in one project I'm associated with, that disappeared whenever a debugger was attached. (Eventually turned out to be a timing issue.) |
16:44 |
jonadab |
(It was solved by adding progress-bar type logic that caused network activity that prevented the timeout.) |
16:45 |
|
bshum joined #evergreen |
16:46 |
|
dcook joined #evergreen |
16:46 |
|
Christineb joined #evergreen |
16:46 |
|
miker joined #evergreen |
16:46 |
|
mceraso joined #evergreen |
16:46 |
|
akilsdonk joined #evergreen |
16:50 |
kmlussier |
bshum: bts? I haven't seen that one in a long, long time. |
16:50 |
bshum |
kmlussier: I was just testing it. |
16:51 |
bshum |
kmlussier: It's still reserved and assigned to my IRC account. |
16:51 |
bshum |
But it seems someone else was trying to use it. |
16:51 |
|
rangi joined #evergreen |
16:51 |
|
rangi joined #evergreen |
16:52 |
kmlussier |
OK, I think I've done as much sprint 2 testing as I can handle in a day. |
16:58 |
Dyrcona |
jonadab: I has something similar with an in-house GUI application at a place where I used to work. |
16:58 |
Dyrcona |
There was no generic search library, so I had to open a window hidden, fill the values in, and then do a search. |
16:58 |
Dyrcona |
Worked fine on my brand-new 233 MHz Pentium II. |
16:59 |
Dyrcona |
Not so well on the 66 MHz 486 used by the person doing the data entry. |
16:59 |
Dyrcona |
She'd end up typing into the invisible window. |
16:59 |
jonadab |
Dyrcona: Heh. |
16:59 |
Dyrcona |
The solution, buy a faster computer, or rewrite the in-house framework. |
17:00 |
jonadab |
By that point in history, buying the faster computer was probably the cheaper option. |
17:00 |
Dyrcona |
Indeed it was. |
17:00 |
Dyrcona |
And, looks like it is time for me to disappear. |
17:08 |
|
mmorgan left #evergreen |
17:11 |
* dbs |
taught a fellow librarian today the importance of leaders and fixed fields in enabling format searches to actually find CDs and scores |
17:12 |
kmlussier |
dbs++ |
17:18 |
|
bmills joined #evergreen |
19:30 |
|
eby joined #evergreen |
20:12 |
|
Christineb_away joined #evergreen |
20:41 |
|
tsadok joined #evergreen |