| Time |
Nick |
Message |
| 01:41 |
|
beanjammin joined #evergreen |
| 05:00 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live/test.42.html#2019-02-01T04:59:57,371382073-0500 -0> |
| 07:18 |
|
rjackson_isl joined #evergreen |
| 07:28 |
|
agoben joined #evergreen |
| 07:34 |
|
bdljohn joined #evergreen |
| 08:01 |
|
Dyrcona joined #evergreen |
| 08:41 |
|
mmorgan joined #evergreen |
| 08:55 |
|
jvwoolf1 joined #evergreen |
| 09:02 |
|
aabbee joined #evergreen |
| 09:13 |
Dyrcona |
@weather |
| 09:13 |
pinesol |
Dyrcona: Methuen, MA :: Clear :: 8F/-13C | Wind Chill: -6F/-21C | Friday: Sunny. High 23F. Winds WSW at 10 to 15 mph. Friday Night: Clear to partly cloudy. Low 9F. Winds W at 5 to 10 mph. |
| 09:43 |
|
yboston joined #evergreen |
| 10:02 |
|
csharp joined #evergreen |
| 10:02 |
berick |
@weather 27712 |
| 10:02 |
pinesol |
berick: Durham, NC :: Clear :: 36F/2C | Wind Chill: 32F/0C | Friday: Sunny to partly cloudy. High 52F. Winds SW at 5 to 10 mph. Friday Night: Cloudy skies early, then partly cloudy after midnight. Low 31F. Winds light and variable. | Updated: 27m ago |
| 10:02 |
|
jvwoolf joined #evergreen |
| 10:03 |
csharp |
@weather 30084 |
| 10:03 |
pinesol |
csharp: Tucker, GA :: Clear :: 42F/6C | Wind Chill: 39F/4C | Friday: Clouds and some sun this morning with more clouds for this afternoon. High 58F. Winds light and variable. Friday Night: Partly cloudy skies. Low near 35F. Winds light and variable. |
| 10:03 |
mmorgan |
@weather 01923 |
| 10:03 |
pinesol |
mmorgan: Danvers, MA :: Clear :: 14F/-10C | Wind Chill: 0F/-18C | Friday: Plenty of sunshine. High 24F. Winds W at 10 to 15 mph. Friday Night: Clear to partly cloudy. Low 9F. Winds W at 5 to 10 mph. | Updated: 10m ago |
| 10:04 |
mmorgan |
Double digits! |
| 10:19 |
|
Dyrcona joined #evergreen |
| 10:32 |
|
Christineb joined #evergreen |
| 10:50 |
|
JBoyer_ joined #evergreen |
| 10:50 |
JBoyer_ |
gsams++ |
| 10:50 |
JBoyer_ |
berick++ |
| 10:50 |
JBoyer_ |
The logs tell me you figured out what went wrong after I left yesterday. Way to go! |
| 10:51 |
* JBoyer_ |
should have looked into that *before* building an entire environment to build Hatch on Windows... |
| 10:58 |
gsams |
JBoyer++ #I'm just happy it all worked out in the end, havoc and all. |
| 11:06 |
* berick |
can haz hatch in windows on chrome and FF now, woohoo |
| 11:07 |
berick |
I've also updated the install docs on https://evergreen-ils.org/egdownloads/ |
| 11:07 |
berick |
but we need someone from the web team to change the Hatch download link |
| 11:07 |
berick |
https://evergreen-ils.org/downloads/Hatch-Installer-0.2.0.exe |
| 11:09 |
|
stephengwills joined #evergreen |
| 11:17 |
csharp |
berick++ gsams++ JBoyer++ |
| 11:18 |
gsams |
berick++ |
| 11:29 |
abneiman |
berick: I can update download link -- do you have an updated md5 link? is the docs link the same? |
| 11:37 |
berick |
abneiman: oh, forgot md5, one sec |
| 11:37 |
berick |
abneiman: yes, doc link is the same, no changes needed there |
| 11:38 |
berick |
abneiman: https://evergreen-ils.org/downloads/Hatch-Installer-0.2.0.exe.md5 |
| 11:40 |
abneiman |
berick: thanks -- done! |
| 11:43 |
berick |
abneiman++ |
| 11:48 |
|
jvwoolf joined #evergreen |
| 11:52 |
|
yboston joined #evergreen |
| 11:59 |
* jeff |
shakes fist at MODS |
| 12:00 |
berick |
*MODS shakes fist back* |
| 12:01 |
jeff |
I want more namePart elements. |
| 12:02 |
jeff |
currently MODS merges (at least) subfields a and q of a name (say, in a 100 tag). |
| 12:02 |
jeff |
subfield d gets its own namePart type="date" |
| 12:03 |
jeff |
but that doesn't help break apart "Heinlein, Robert A." and "(Robert Anson)" |
| 12:09 |
|
jihpringle joined #evergreen |
| 12:20 |
|
jvwoolf joined #evergreen |
| 12:32 |
|
sandbergja joined #evergreen |
| 12:41 |
Dyrcona |
Hmm.. Trying to build Evergreen 3.0 with prereqs installed from master and it don't work, at least the web staff client stuff blows up on the grunt all step. |
| 12:47 |
jeff |
on what distro/version? |
| 12:47 |
berick |
mast won't install Grunt |
| 12:47 |
berick |
er, master |
| 13:00 |
|
terran joined #evergreen |
| 13:02 |
|
yboston joined #evergreen |
| 13:06 |
mmorgan |
What's the siginficance of the 'active' flag in biblio.record_entry? |
| 13:06 |
csharp |
are grid column settings only per-workstation? or are they also possible per user? |
| 13:07 |
csharp |
looking at the setting types for each, looks like workstation only |
| 13:07 |
mmorgan |
We discovered that if you undelete a bib record in the web client, the active flag is not set to TRUE and wondered if that mattered. |
| 13:09 |
mmorgan |
csharp: I may have imagined this, but I thought there was some way to make them into user settings. |
| 13:09 |
csharp |
I know some stuff like that was per-user in the XUL client |
| 13:11 |
mmorgan |
Simplified holds pull list column settings were per user in xul, not sure if there was anything else. |
| 13:13 |
csharp |
seems like it wouldn't be a terribly difficult thing to do (if there's a user setting for this grid, use that, else fall back to workstation, then to default) |
| 13:16 |
|
jvwoolf joined #evergreen |
| 13:20 |
|
jvwoolf left #evergreen |
| 13:22 |
mmorgan |
csharp: xul toolbars had user/workstation/org unit affiliation options, iirc |
| 13:22 |
csharp |
yeah |
| 13:34 |
|
Christineb joined #evergreen |
| 13:46 |
berick |
csharp: grid settings (and other browser client settings) may be workstation OR user. they can also be org settings. |
| 13:47 |
berick |
workstation / user are mutually exclusive. org settings can be applied regardless as a fall-back value |
| 13:48 |
berick |
we've been creation settings only as workstation settings in the seed data so for for backwards-compat with the 3.0 / 3.1 browser client settings |
| 13:48 |
berick |
but any of those could be moved around |
| 13:49 |
berick |
*creating |
| 14:01 |
csharp |
berick: thanks - makes sense - we're finally understanding over here :-) |
| 14:01 |
csharp |
we got per-user/per-ws/per-org all twisted up |
| 14:38 |
mmorgan |
berick: So, just to confrim, column settings can be org settings? |
| 14:40 |
berick |
mmorgan: yes. |
| 14:40 |
berick |
you have copy the workstation setting type over (as-is) to an org setting |
| 14:40 |
berick |
if you want to enforce a grid config, you could then remove the workstation setting |
| 14:40 |
berick |
that way people can't change it |
| 14:41 |
berick |
we're doing that for some circ UI's |
| 14:41 |
mmorgan |
Awesome! Thanks! That makes me happy :) |
| 14:41 |
berick |
if you leave the workstation setting type in place, then the grid value will be the default, but it can be overidden |
| 14:41 |
berick |
i mean, the org setting value will be the default |
| 14:42 |
mmorgan |
Ok, gotcha. |
| 14:43 |
* berick |
has big dreams of creating a unified settings type manager UI |
| 14:43 |
berick |
and moving over time to all settings functioning as the new-style cascade settings, depending on local config |
| 14:44 |
mmorgan |
Grand Unified Settings :) |
| 14:44 |
berick |
darn, i should have called the new ones Quantum Settings |
| 14:46 |
mmorgan |
:) |
| 14:48 |
terran |
berick++ |
| 14:49 |
mmorgan |
Oh yeah, berick++ |
| 14:50 |
|
jammin joined #evergreen |
| 14:53 |
csharp |
having trouble getting websocketd working on my master test server - does anyone know where websocketd logs by default (running as opensrf behind an nginx proxy) |
| 14:53 |
csharp |
apache2-websockets was working fine before - I've changed nothing in nginx or apache |
| 14:53 |
|
jammin joined #evergreen |
| 14:55 |
Dyrcona |
csharp: It logs to the console, so you'll have to redirect it. |
| 14:55 |
csharp |
oh -hmm |
| 14:55 |
Dyrcona |
I.E. it doesn't log, nor properly close STDOUT and STDERR like a good daemon should. |
| 14:55 |
csharp |
all I'm getting in the console is "Firefox can’t establish a connection to the server at wss://csharp-master.gapines.org/osrf-websocket-translator." |
| 14:56 |
Dyrcona |
Clark is also guilty of that. |
| 14:56 |
Dyrcona |
No, the UNIX console where the daemon was started. |
| 14:56 |
csharp |
oh, I see what you mean |
| 14:56 |
Dyrcona |
console/terminal... :) |
| 14:56 |
berick |
csharp: running directly or via systemd? |
| 14:57 |
Dyrcona |
systemd-- |
| 14:57 |
csharp |
~$ /usr/local/bin/websocketd --port 7682 /openils/bin/osrf-websocket-stdio --loglevel=debug & |
| 14:57 |
csharp |
that's how I invoked it |
| 14:57 |
berick |
k |
| 14:57 |
berick |
csharp: using nginx, right? |
| 14:57 |
csharp |
yep |
| 14:57 |
Dyrcona |
So the messages go to the terminal where you started it. |
| 14:57 |
berick |
is your proxy_pass set to http:// ? |
| 14:57 |
csharp |
yeah, and I see them |
| 14:57 |
csharp |
sec.. |
| 14:58 |
csharp |
for 80 it's http and for 443 it's https |
| 14:58 |
csharp |
proxy_pass http://localhost:7080; and proxy_pass https://localhost:7443; |
| 14:58 |
berick |
under /osrf-websocket-translator you need proxy_pass http://localhost:7682; |
| 14:59 |
Dyrcona |
csharp: If you're trying to us SSL for websocketd, you need to tell it where to get the cert and key, and if you have a chain file it needs to be concatenated after the cert in a combined file. |
| 14:59 |
csharp |
proxy_pass https://localhost:7682; |
| 14:59 |
berick |
csharp: that's your problem |
| 14:59 |
csharp |
so that^^ needs to be http? |
| 14:59 |
berick |
right |
| 14:59 |
csharp |
ok |
| 14:59 |
csharp |
oh - duh |
| 14:59 |
csharp |
it's documented right here :-) |
| 14:59 |
Dyrcona |
Well, it can be https... See my previous comment. :) |
| 15:00 |
csharp |
Dyrcona: makes sense - thanks |
| 15:00 |
berick |
yeah, https def. works |
| 15:00 |
jammin |
Howdy... going nuts while testing some stuff. In what sort of scenario might some libraries (such as osrf_math.so) in /openils/lib not be found, while others (such as libopensrf.so) are? |
| 15:00 |
csharp |
jammin: try (as root) 'ldconfig' |
| 15:00 |
Dyrcona |
The options are --sslcert=/path/to/cert --sslkey=/path/to/key |
| 15:01 |
csharp |
Dyrcona: awesome - thank you |
| 15:01 |
Dyrcona |
You can use the same one you use for Apache/nginx. |
| 15:01 |
jammin |
I've done ldconfig dozens of times |
| 15:01 |
jammin |
These (and some others) work: osrf_control --localhost --service router --start osrf_control --localhost --service opensrf.settings --start |
| 15:01 |
berick |
jammin: the library files were renamed not too long ago too. make sure the entries in opensrf.xml show libosrf_math.so instead of osrf_math.sh |
| 15:02 |
berick |
er, .so |
| 15:02 |
jammin |
This (and a few others) does not: osrf_control --localhost --service opensrf.math --start |
| 15:02 |
jammin |
For even more fun... this actually does work: |
| 15:02 |
jammin |
OK, doesn't wanna take that. |
| 15:03 |
jammin |
Basically, calling opensrf-c directly with ld-linux-x86-64.so.2 and feeding it a library path... that works. |
| 15:04 |
Dyrcona |
jammin: What distro and release? |
| 15:04 |
csharp |
berick++ Dyrcona++ # works now! |
| 15:04 |
jammin |
I'll take a look at opensrf.xml, thank you |
| 15:04 |
jammin |
just upgraded from debian jessie to stretch, trying to get opensrf 2.5.0 working again |
| 15:05 |
Dyrcona |
Did you reinstall OpenSRF after the upgrade? |
| 15:05 |
jammin |
had to tinker with the prerequisite scripts to make it go, but so far so good... everything is working except a few services with libs in /openils/lib |
| 15:05 |
jammin |
yep, reinstalled |
| 15:06 |
berick |
csharp: awesome |
| 15:06 |
Dyrcona |
I think OpenSRF 2.5.0 is too old for stretch. I think that predates adding lib to the library names, and I think stretch is the reason it was done. |
| 15:06 |
Dyrcona |
The dynamic linker doesn't like C libs whose names do not start with lib.... |
| 15:07 |
jammin |
That sounds interesting enough to be it. I did try 3.0.0 and had the same problem, but I might've done some foot shooting along the way somewhere |
| 15:08 |
csharp |
Dyrcona: if the daemon is run as opensrf and the keys are in apache2/ssl, it's saying I don't have perms to read the files - did you hit that issue? |
| 15:08 |
csharp |
also, since nginx is SSL, does it matter that I use SSL for this? |
| 15:08 |
berick |
csharp: i'm not using SSL, since it's a localhost connection |
| 15:08 |
csharp |
yeah, I was wondering if there was an advantage, security-wise |
| 15:08 |
csharp |
I think I'll do non-SSL then |
| 15:09 |
Dyrcona |
csharp: Q1: No, because I start websocketd with sudo. Q2: If nginx is handling SSL, you don't. |
| 15:09 |
csharp |
gotcha - thanks, Dyrcona |
| 15:09 |
Dyrcona |
I don't use nginx, so I need websocketd to do ssl. |
| 15:09 |
Dyrcona |
jammin: I'm looking for the bug about the libraries. |
| 15:10 |
csharp |
wow - this is dead simple - I was thinking it had to be more complicated :-) |
| 15:11 |
Dyrcona |
jammin: bug 1708048 |
| 15:11 |
pinesol |
Launchpad bug 1708048 in OpenSRF "Add support for Debian 9 Stretch" [Wishlist,Fix released] https://launchpad.net/bugs/1708048 |
| 15:11 |
Dyrcona |
Yeah, websocketd is much easier than apache-websocket. |
| 15:13 |
csharp |
Dyrcona: berick: you're both running it in production, right? anything of concern? |
| 15:13 |
* csharp |
is tired of stomping out spinning apache2-websockets procs |
| 15:13 |
berick |
csharp: not in production yet, rolling out soon. |
| 15:14 |
csharp |
JBoyer: didn't you mention you were running websocketd? |
| 15:14 |
Dyrcona |
jammin: Looks like you will have to mess with opensrf.xml and add library versions as suggested in https://bugs.launchpad.net/opensrf/+bug/1708048/comments/5 or you should upgrade to OpenSRF 3.0+. |
| 15:14 |
pinesol |
Launchpad bug 1708048 in OpenSRF "Add support for Debian 9 Stretch" [Wishlist,Fix released] |
| 15:14 |
rjackson_isl |
csharp: JBoyer is ooo today |
| 15:14 |
csharp |
rjackson_isl: ah - thanks - no bigz |
| 15:15 |
berick |
csharp: jeffdavis is running it in production |
| 15:15 |
csharp |
cool |
| 15:15 |
* Dyrcona |
has been running websocketd in production since October. I backported the OpenSRF patches. |
| 15:15 |
csharp |
ok - awesome |
| 15:15 |
berick |
we just have it on a test cluster now. no issues. |
| 15:15 |
csharp |
that's my next step - get it running in a cluster |
| 15:15 |
csharp |
and build it into our cluster-install scripts |
| 15:16 |
jammin |
Dyrcona: thanks, yeah, that looks like what I'm hitting. I've got 3.0.0 on there now, still does it, but haven't touched my config yet... heading there now |
| 15:16 |
Dyrcona |
I have had 0 issues with websocketd in production. |
| 15:17 |
rjackson_isl |
csharp: confirmed we are running |
| 15:17 |
csharp |
Dyrcona: great to hear |
| 15:18 |
csharp |
rjackson_isl: awesome - thanks! |
| 15:19 |
berick |
csharp: fwiw, the systemd integration makes it easier to manage (daemonization, pid tracking, signal passing by proc name, etc.) |
| 15:20 |
* csharp |
looks for docs on that |
| 15:20 |
berick |
csharp: https://wiki.evergreen-ils.org/doku.php?id=dev:websockets:gateway:websocketd#optional_systemd_setup |
| 15:21 |
* Dyrcona |
hasn't had to manage websocketd, fwiw. I wrote a simple start and stop script and that's all I've needed, YMMV. |
| 15:22 |
berick |
yeah, pretty easy to manage either way |
| 15:22 |
csharp |
berick: thanks! |
| 15:26 |
jammin |
Dyrcona: OK, installed 3.0.0 and fixed lib references in opensrf.xml... it's working now. Thanks! |
| 15:26 |
csharp |
systemd working great |
| 15:26 |
Dyrcona |
jammin: If you've installed Evergreen, you'll need to upgrade to Evergreen 3.0, also. |
| 15:26 |
csharp |
so is OpenSRF 3.1 good for EG 3.2? |
| 15:27 |
* Dyrcona |
has been using master, but I think so, csharp. |
| 15:27 |
Dyrcona |
i.e. in my testing of 3.2 |
| 15:28 |
jammin |
Dyrcona: at one point I was doing LD_DEBUG and saw it looking right at the right lib file, but it skipped right on to the next path... I said "whaaa?" :) |
| 15:28 |
Dyrcona |
jammin: It's because of changes in GCC 6. |
| 15:28 |
gsams |
csharp: Supposedly we are running OpenSRF 3.1 on EG 3.2.3 right now. |
| 15:28 |
Dyrcona |
Rereading the bug history refreshed my memory. |
| 15:30 |
jammin |
Dyrcona: got it, thanks. my actual target here is EG 3.1.2, so yeah will be doing that |
| 15:31 |
Dyrcona |
jammin: I think OpenSRF 3.1 should work for you, too. Might as well go with the latest and greatest. :) |
| 15:31 |
jammin |
Dyrcona: was testing upgrade to stretch before upgrading to 3.1.2. I guess the result is "don't" |
| 15:31 |
Dyrcona |
:) |
| 15:32 |
jammin |
Dyrcona: so opensrf 3.1 good to go for eg 3.1.2, then? |
| 15:33 |
Dyrcona |
I don't know of any incompatibilities. |
| 15:33 |
Dyrcona |
I've kind of skipped Evergreen 3.1 in my testing, though, so take that with a teaspoon of salt. |
| 15:34 |
* csharp |
chokes down a teaspoon of salt |
| 15:34 |
Dyrcona |
I think 3.1 works with 3.0 also.... At least parts of it do, because I backported some patches to our production servers. |
| 15:34 |
jammin |
Will know in a bit, gonna take a break, roll the vm back, and give it a go |
| 15:34 |
Dyrcona |
Wer're still on 3.0 in production, but will upgrade to 3.2 soonish. |
| 15:35 |
csharp |
Dyrcona: that transition was very smooth for us, all told |
| 15:35 |
csharp |
and we're completely XUL-free in the libraries :-) |
| 15:35 |
csharp |
no one is throwing rocks yet |
| 15:35 |
Dyrcona |
csharp: good to hear. |
| 15:36 |
gsams |
csharp, Dyrcona: having literally just updated this week it's been incredibly smooth. |
| 15:36 |
Dyrcona |
Our members are making use of the web client in 3.0. |
| 15:36 |
csharp |
gsams: awesome |
| 15:36 |
jammin |
Our production is 3.1.2 on opensrf 3.0.1, I'm messing around with the test server while bringing it up to speed |
| 15:36 |
Dyrcona |
My testing looks like the upgrade will be straightforward. |
| 15:36 |
gsams |
If I can get the dymo hatch printer fix in place I'll be all set I think. |
| 15:36 |
csharp |
we expected more outcry from libraries who hadn't made the transition from circ yet |
| 15:37 |
jammin |
I need to get our RFID stuff playing nicely with the web client before can move up to 3.2 |
| 15:37 |
* csharp |
has to run pick up the teenager |
| 15:37 |
Dyrcona |
jammin: When it comes to upgrading the O/S on VMs, I usually don't. I just build a new VM, but I assume you wanted to test because you plan to upgrade production hardware? |
| 15:40 |
jammin |
Dyrcona: Not sure which way I'm going to go about it yet... rebuild VMs and fresh install, or dist-upgrade and EG upgrade. Figured either way, I should figure out how to "make it work". |
| 15:41 |
jammin |
Dyrcona: If I can fix a worst case, the easy cases will be that much easier. :) |
| 15:41 |
Dyrcona |
Yes. :) |
| 15:42 |
Dyrcona |
Fun with git: reverting a revert. :) |
| 15:43 |
Dyrcona |
Revert "Revert "More complication in rbdigital_urls.pl"" |
| 15:43 |
Dyrcona |
Something local.... |
| 15:44 |
berick |
csharp: nice! re: xul-free |
| 15:45 |
Dyrcona |
XUL is dead! Long live XUL! |
| 15:45 |
jammin |
When XUL dies... is it sticky? |
| 15:46 |
jammin |
Or is that just Gozer? |
| 15:47 |
Dyrcona |
:) |
| 15:47 |
Dyrcona |
There is no Dana, only Xul! |
| 15:51 |
jammin |
I'm interested in moving up to debian-buster. Am I inviting similar library insanity? |
| 15:51 |
Dyrcona |
Probably not, but I don't think anyone has worked out the prerequisites for buster, yet. |
| 15:53 |
Dyrcona |
jammin: If you'd like to do that, feel free. Patches welcome! :) |
| 15:53 |
jeff |
Do not use unreleased testing versions of Linux distributions for production. :-) |
| 15:54 |
jammin |
I'm thinking I'll finish getting this thing going on stretch & 3.1.2 like I'm supposed to. Then take another snapshot, then see how buster goes... just because. |
| 15:55 |
Dyrcona |
It should be OK to start testing with buster, soon. The full freeze is supposed to happen in March. |
| 15:55 |
jeff |
Testing with buster and reporting issues is a useful thing, and appreciated. |
| 15:55 |
jeff |
But don't run it in production. :-) |
| 15:55 |
jammin |
No, not on production! But hey, Debian testing (in soft freeze, or close to it) isn't your average unreleased testing version. :) |
| 15:56 |
* jeff |
nods |
| 16:26 |
sandbergja |
Quick indexing question: In this doc, it says that it's required to do a "service restart" after making changes to Administration > Server > MARC Search/Facet Fields (metabib fields): http://docs.evergreen-ils.org/dev/_virtual_index_definitions.html |
| 16:26 |
sandbergja |
Which services exactly need to be restarted? |
| 16:36 |
sandbergja |
i.e. just restart Opensrf? Just restart a specific Opensrf service? Restart apache or some other service that might be running on the server? |
| 16:47 |
Bmagic |
sandbergja: to be safe, I always restart all of the services, opensrf and apache |
| 16:48 |
sandbergja |
Bmagic: good to know. Thanks! |
| 16:48 |
sandbergja |
Bmagic++ |
| 16:49 |
Bmagic |
I've got a sample set of commands around somewhere |
| 16:50 |
pastebot |
"Bmagic" at 64.57.241.14 pasted "restarting services" (32 lines) at http://paste.evergreen-ils.org/14398 |
| 16:51 |
sandbergja |
Oh, cool! Thanks! |
| 17:00 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live/test.42.html#2019-02-01T16:58:45,062820692-0500 -0> |
| 17:14 |
csharp |
opensrf 3.1.0 and websocketd are now running on our 3.2.3 test server |
| 17:14 |
csharp |
all seems fine so far |
| 17:18 |
|
mmorgan left #evergreen |
| 17:23 |
Bmagic |
csharp++ |
| 18:58 |
|
beanjammin joined #evergreen |
| 20:28 |
|
sandbergja joined #evergreen |
| 20:46 |
|
sandbergja joined #evergreen |
