| Time |
Nick |
Message |
| 02:57 |
|
StomproJosh joined #evergreen |
| 03:03 |
|
ssieb joined #evergreen |
| 06:40 |
|
rlefaive joined #evergreen |
| 07:02 |
|
agoben joined #evergreen |
| 07:22 |
|
rjackson_isl joined #evergreen |
| 07:25 |
graced |
good morning #evergreen |
| 08:28 |
miker |
Bmagic: the to_bool() thinko is fixed in that branch now |
| 08:44 |
|
mmorgan joined #evergreen |
| 08:49 |
|
bos20k joined #evergreen |
| 08:57 |
|
Dyrcona joined #evergreen |
| 09:02 |
|
yboston joined #evergreen |
| 09:08 |
csharp |
@blame oclc |
| 09:08 |
pinesol_green |
csharp: oclc WILL PERISH UNDER MAXIMUM DELETION! DELETE. DELETE. DELETE! |
| 09:17 |
tsbere |
csharp: What kind of oclc issues are you having today? |
| 09:18 |
|
maryj joined #evergreen |
| 09:19 |
csharp |
tsbere: honestly, just trying to get logged into their worldshare interface has halted progress for me :-/ |
| 09:20 |
csharp |
yesterday it was dealing with one of their frontline support staff who assumed that I was asking her to write a bash script for me |
| 09:23 |
|
remingtron joined #evergreen |
| 09:40 |
JBoyer |
gmcharlt, before I get too comfortable playing with regular expressions and MARC::Record, I notice currently field() turns tagspec into a plain re with qr/^$tag$/ even though only using . as a wildcard is specified in the docs. Any plans to leave that a plain re or tighten it up to plain text + '.' wildcards? |
| 09:41 |
JBoyer |
(It doens't matter either way for the timeline I'm working with, but I'd hate to have things like $marc->field('26[04]'); stop working. :) ) |
| 09:41 |
gmcharlt |
JBoyer: my inclination would be to leave functionality as is, and update the POD |
| 09:42 |
|
rjackson_isl joined #evergreen |
| 09:42 |
JBoyer |
Excellent. Just wanted to check before I start throwing it around all over. :) |
| 09:42 |
Dyrcona |
JBoyer: No danger of it not working, I'm pretty sure that any perlre will work and will continue to work. |
| 09:42 |
Dyrcona |
The obvious implementation is =~ :) |
| 09:43 |
gmcharlt |
=~ /LDR/ # are we running ALEPH?... |
| 09:44 |
JBoyer |
Dyrcona, sure, I just meant that I could see arguments for removing the ability to allow anyone to specify a complete re as an external argument and wanted to get an opinion on it. I could always do what I'm after by building a list from fields(), but that's more work for ME. ;) |
| 09:54 |
|
kmlussier joined #evergreen |
| 09:56 |
dbs |
Starting to think a server with 12GB of RAM isn't enough to handle all of our Apache / OpenSRF / ejabberd / memcached needs on 2.10 (postgresql is on a separate dedicated server) |
| 10:03 |
|
collum joined #evergreen |
| 10:05 |
|
Dyrcona joined #evergreen |
| 10:07 |
csharp |
dbs: I suspect it's something with Ubuntu 14.04 since we saw the same higher resource consumption (on our apache/opensrf servers) after our 2.9/14.04 upgrade |
| 10:08 |
csharp |
we had to up the RAM on our VMs and many problems went away |
| 10:09 |
dbs |
so with respect to bug 1617556 is the custom dojo build no longer useful (and thus csharp's commit should be merged) or are we saying that we should document what it is and how to get it if you're not using a release tarball per bug 1076582? |
| 10:09 |
pinesol_green |
Launchpad bug 1076582 in Evergreen "duplicate for #1617556 Documentation explaining openils_dojo.js" [Low,Confirmed] https://launchpad.net/bugs/1076582 |
| 10:09 |
pinesol_green |
Launchpad bug 1076582 in Evergreen "Documentation explaining openils_dojo.js" [Low,Confirmed] https://launchpad.net/bugs/1076582 |
| 10:09 |
csharp |
that was lots of fun - app servers AND database problems |
| 10:09 |
dbs |
csharp: ah, well that's good to know :) |
| 10:10 |
JBoyer |
dbs, it's also nice to have at least 2 app servers so changes that don't touch the db can be seamless. |
| 10:10 |
dbs |
I can't quite believe how much memory a single open-ils.storage process consumes but I guess it autovivifies all those perl classes |
| 10:10 |
dbs |
JBoyer: We've run for 7 years on a single app server, the simplicity has been nice |
| 10:11 |
* Dyrcona |
has fun with Internets. Could drop again without notice. |
| 10:14 |
JBoyer |
dbs, there is something to be said for simplicity. |
| 10:16 |
kmlussier |
I keep coming across bug 1013786 whenever I'm getting ready for Bug Squashing Day. I think we need to decide whether we want to push the code that's there, which already has two signoffs, or if we want to wait until the password strength test is moved to a self-contained routine, in which case we should remove the pullrequest tag. |
| 10:17 |
pinesol_green |
Launchpad bug 1013786 in Evergreen "tpac: Check for password strength at login" [Medium,Confirmed] https://launchpad.net/bugs/1013786 |
| 10:17 |
kmlussier |
Any thoughts? |
| 10:17 |
* kmlussier |
guesses that nobody is actively working on it at the moment. |
| 10:19 |
* Dyrcona |
tries something. |
| 10:19 |
miker |
dbs: then there's us, with 298 distinct {opensrf|apache} instances and 110 ejabberd instances ... complexity a spectrum ;) |
| 10:20 |
|
Dyrcona joined #evergreen |
| 10:20 |
* JBoyer |
does not envy whoever's job it is to keeping Sequoia running |
| 10:22 |
miker |
JBoyer: with human error removed, it ain't so bad. 3 commands to rule them all |
| 10:22 |
JBoyer |
That does sound quite a bit better. |
| 10:22 |
bshum |
start/stop/restart ? |
| 10:22 |
bshum |
:) |
| 10:23 |
berick |
stop/start/turbo |
| 10:23 |
miker |
bshum: ha! something like that... |
| 10:23 |
bshum |
berick: Ooooh, turbo! I like that :) |
| 10:24 |
miker |
heh |
| 10:24 |
|
Dyrcona joined #evergreen |
| 10:26 |
|
Dyrcona joined #evergreen |
| 10:28 |
|
Dyrcona joined #evergreen |
| 10:33 |
|
Dyrcona joined #evergreen |
| 10:33 |
JBoyer |
Freenode doesn't like Dyrcona's IPv6 address because it sees 2600 and thinks "h4x!" |
| 10:33 |
Dyrcona |
JBoyer: That must be it. |
| 10:34 |
Dyrcona |
But I've been switching networks, too. |
| 10:39 |
dbs |
miker: yeah, a little different when you focus on something every day all day vs. once every year or two (unless things go poorly) :/ |
| 10:40 |
miker |
dbs: aye, tis true. nice to hear it's once every year or to ... that's quite the testimonial, really |
| 10:46 |
dbs |
for sure, I'd like to have been able to give it more attention but so many other work things. now, though, with the Ubuntu 14.04 + 2.7-2.10 shenanigans, it's getting lots of (increasingly) bleary-eyed attention |
| 10:48 |
dbs |
so openils_dojo.js, re 1617556 - do we want to nuke references to it or no? |
| 10:50 |
Stompro |
What defines an open circulation? There is an A/T validator called CircIsOpen that just seems to check to see if the checkin_time is not set? But what about paid for items? Doesn't the xact_finish being set also mean that a circulation is closed? |
| 10:51 |
Dyrcona |
xact_finish is null on an open circulation. |
| 10:51 |
Dyrcona |
Or should be. |
| 10:51 |
Dyrcona |
Maybe there's bugs. Maybe I'm wrong. Maybe there's not a consensus? |
| 10:52 |
jeff |
the view action.open_circulation is defined as WHERE checkin_time IS NULL |
| 10:52 |
Dyrcona |
Right. I'm wrong. Cause xact_finish is null if it's checked in but bills remain. |
| 10:52 |
* Dyrcona |
goes back to fiddling before the 11:00 am meeting. |
| 10:54 |
jeff |
i believe that currently some circulations remain "open" forever, based on other things like stop_fines or xact_finish or maybe even in some cases the copy's status or deleted value they are treated differently or presented differently in interfaces. |
| 10:54 |
jeff |
I don't know offhand what the CircIsOpen validator is used for in stock, to know if a different/additional validator might be useful. |
| 10:54 |
tsbere |
Open circulation vs Open Transaction? |
| 10:55 |
Dyrcona |
Well, see that can also mean the same thing depending on whom you talk to. |
| 10:56 |
jeff |
Also, the most recent thing that comes to mind that would be in this same area is the "lost and paid" status added in 2.7. There might have also been some changes in the last year or so with regard to "still open, but we no longer care about them" circulations in one or more staff interfaces. |
| 10:56 |
tsbere |
Well, every circulation is a transaction, but the opposite isn't true... |
| 10:57 |
Dyrcona |
tsbere: That is true. |
| 10:57 |
jeff |
circulations are open/closed, transactions are unfinished/finished. :-) |
| 10:57 |
Dyrcona |
It's a big ball of wibbly-wobbly circulationy-transactiony stuff.... |
| 10:58 |
berick |
Dyrcona: how's that workin' out for ya? |
| 10:58 |
jeff |
and since circs are transactions, circs therefore can be unfinished/finished. :-) |
| 10:58 |
jeff |
but yeah. |
| 10:59 |
mmorgan |
Dyrcona++ |
| 11:02 |
Stompro |
Hehe, thanks all, I think I understand, that it is complicated. But maybe not so bad. I'm trying to exclude lost checkouts that have been delt with already. If I look at both the ac.checking_time and the target_copy status I should be covered. |
| 11:03 |
* mmorgan |
also looks to stop_fines for the status of transactions. |
| 11:03 |
jeff |
Stompro: is action.circulation.xact_finish helpful for you, rather than the copy status? |
| 11:04 |
* mmorgan |
is uncomfortable looking at copy status since subsequent actions on the copy can change that. |
| 11:07 |
Stompro |
jeff, I'm assuming that for the status to no longer be lost, then it would have had to be checked in, which would set the ac.checkin_time on the open transaction. Or if it was paid off fully, then the status of the copy would be lost and paid. If a lost and paid item is returned and checked in, would it set the ac.checking_time for the last transaction? Or would it skip it because it was finished??? |
| 11:08 |
mmorgan |
Stompro: For items that were checked out, lost and paid for, you should see a null checkin_time, LOST stop_fines and a not null xact_finish |
| 11:09 |
jeff |
there is also the mostly-parallel "long overdue" set of stop fines reasons and copy statuses, etc. |
| 11:12 |
mmorgan |
Yes, adds to the fun! |
| 11:13 |
* mmorgan |
believes that checkin_time is set if the item has been paid for and subsequently returned. |
| 11:14 |
|
collum joined #evergreen |
| 11:15 |
jeff |
yes. |
| 11:15 |
Stompro |
So maybe something like this in sql to include only circs that have been checked in or paid off? and ( (ac.checkin_time is null and ac.xact_finish is not null) |
| 11:15 |
Stompro |
or (ac.checkin_time is not null) ) |
| 11:15 |
jeff |
because otherwise the item would be unable to circulate again. |
| 11:17 |
jeff |
Stompro: what are you trying to do? can you paste your entire query someplace like https://gist.github.com/ ? |
| 11:26 |
Stompro |
jeff, ok, I'll try to be brief. I ran the move to lost A/T a few months back and marked 10k circulations as lost. I didn't realize at the time that the email/postal lost.auto event_defs were triggered by that. So I want to search through all the completed events for mark lost, and create new events for our email and postal notices. |
| 11:27 |
Stompro |
So I want to exclude circulations that have been taken care of from creating new events. |
| 11:29 |
Stompro |
The A/T validators CircIsOpen and CircIsOverdue won't work for just validating the events when I run them again from what I can tell. |
| 11:31 |
pastebot |
"Stompro" at 64.57.241.14 pasted "Lost circs that have been taken care of" (16 lines) at http://paste.evergreen-ils.org/26 |
| 11:34 |
miker |
Stompro: you probably want to use an A/T filter file for that, instead of a validator |
| 11:34 |
miker |
or, in addition to, I suppose |
| 11:35 |
miker |
so you don't have 9.9k invalid events after |
| 11:38 |
kmlussier |
remingtron++ #Every time I refer to the DIG Style Guide, my appreciation for it grows. |
| 11:40 |
remingtron |
kmlussier: thanks for the kind words! |
| 11:41 |
Stompro |
miker, I'm not sure how I would use a filter file in this case, the events get created by the markitemlost reactor. I thought the filter controls which event gets created, not which already created event gets processed. |
| 11:42 |
miker |
Stompro: ah, I thought you were trying to create new events for a new purpose based on the old 10k events. nevermind if I misunderstood |
| 11:45 |
Stompro |
miker, no, you are correct in your understanding. I'm just thinking that my only option is to do it directly via sql inserts. I'll trying to exclude events that would be marked invalid if there was a validator that would do what I need. |
| 11:47 |
|
bmills joined #evergreen |
| 11:48 |
Stompro |
Trying to recover from past mistakes is my hobby lately. |
| 11:49 |
mmorgan |
Stompro: It sounds like your goal is to create notifications based on those transactions that were marked Lost and haven't yet been resolved? |
| 11:51 |
miker |
Stompro: gotcha. I think you could also create a new def, segregated by granularity, and use the normal scripts. that way you'd avoid the risk of the normal cron jobs coming along and grabbing your new events before you had a chance to look at them. that would also avoid the possibility of missing something by hand crafting artisanal events ;) |
| 11:56 |
Stompro |
miker, I'm not sure how to do that, and this is just a one off situation. I'll have my events_defs that use the lost.auto hook setup now, so in the future the system will just work like it should. |
| 11:57 |
|
brahmina joined #evergreen |
| 11:59 |
Stompro |
mmorgan, yes that is right, with the added limitation of only including the circs that already have an event generated from the markitemlost event_def. Going forward things will work automatically. |
| 12:01 |
Stompro |
Ohh, maybe the filter file could be used to limit to events that already have an event entry of the specfic type and state? |
| 12:02 |
mmorgan |
Stompro: It sounds like your plan is just about set, but you could send a notification using a processing delay and max_validity in the range of your automatically marked Lost items, and use the filter to specify those that haven't been resolved. |
| 12:03 |
|
jvwoolf joined #evergreen |
| 12:03 |
mmorgan |
Might need to do them in smallish batches by date since there are a lot of them. |
| 12:05 |
mmorgan |
Using a filter that looks something like ... |
| 12:05 |
pastebot |
"mmorgan" at 64.57.241.14 pasted "Lost notification filter" (10 lines) at http://paste.evergreen-ils.org/27 |
| 12:06 |
mmorgan |
Note that that's untested. |
| 12:06 |
Stompro |
If I did that instead of using the lost.auto hook events, I could also exclude/exclude patrons that have email addresses which would be nice... although that migh cause old bills to trigger when a patron gets an email address added or removed. hmm |
| 12:08 |
Stompro |
miker++ mmorgan++ I get caught up in seeing a problem in just one light, thanks for showing me other ways. |
| 12:08 |
mmorgan |
Oops, extra comma in the paste :-( |
| 12:10 |
miker |
mmorgan++ # 'splaining how to actually do what I was alluding to :) |
| 12:10 |
Stompro |
mmorgan, would that have the added benefit of including items that are marked lost by staff. It seems like the lost.auto method woudn't include those. |
| 12:12 |
mmorgan |
Yes, I would say so, since you're filtering to any transactions that are LOST, not checked in and not paid for. |
| 12:46 |
kmlussier |
miker / Bmagic / jeff: The SIP changes that you all were discussing yesterday, does it change the behavior in a way that will require an update to the release note entry as it's written here?: https://evergreen-ils.org/documentation/release/RELEASE_NOTES_2_11.html#_sip |
| 12:46 |
kmlussier |
And if the answer is 'yes', can one of you update the release note entry accordingly? |
| 12:48 |
miker |
kmlussier: well, the change is on the sipserver side, so ... arguably, the evergreen docs are as accurate as they can be. but, in practice, we should mention the change there because we don't do releases of sipserver, per se. |
| 12:48 |
miker |
specifically, the new change would allow the admin to disable (or override) the feature, so just the start of the sentence needs changing for EG |
| 12:49 |
miker |
that's if it goes in, obv |
| 12:50 |
|
jihpringle joined #evergreen |
| 12:51 |
|
jihpringle_ joined #evergreen |
| 12:51 |
kmlussier |
OK, well, I'll try to pay attention to whether it goes in before worrying about it. |
| 12:52 |
* kmlussier |
generally doesn't pay attention to SIP server changes |
| 12:53 |
pinesol_green |
[evergreen|Kathy Lussier] Docs: Adding acknowledgements to the 2.11 release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b6da36c> |
| 12:53 |
pinesol_green |
[evergreen|Kathy Lussier] Docs: 2.11 release note fixes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2a7a6e8> |
| 12:55 |
JBoyer |
Seems I could have been a bit more permissive about how that feature works. :/ Thanks to everyone working toward making it less hassle for admins. |
| 13:41 |
dbs |
jeez, I run mpm_prefork with startservers 30, minspare 15, maxspare 30, maximum 75 and run out of memory. I drop to 25/10/20/75 and I have almost half my 12GB of RAM still free |
| 13:47 |
dbs |
I did drop MaxConnectionsPerChild from 2500 to 1000 but wouldn't expect the memory leak situation to balloon them _that_ much |
| 13:48 |
dbs |
(and then of course syslog says "server seems busy, you might want to increase startservers / minspare", okay okay, how's about 28/14/28/75 then... meh) |
| 13:52 |
kmlussier |
kmlussier-- #Forgetting translators and NOBLE in the acknowledgements. |
| 13:52 |
bshum |
kmlussier++ # for working on the notes in the first place |
| 13:52 |
Dyrcona |
dbs: I know, right? |
| 13:53 |
kmlussier |
bshum: Yeah, sure, but if I'm going to forget an organization in the Release Notes, it shouldn't be the one that is providing me with my office space for the day. |
| 13:53 |
tsbere |
dbs: some days the memory leak seems to be a bigger issue than others. I imagine it has more to do with what each child ends up doing, but still annoying. |
| 13:54 |
* Dyrcona |
never did track it down. Just played "chicken" with the settings until I found something that worked most of the time. |
| 13:54 |
dbs |
Dyrcona++ tsbere++ # our company loves misery! |
| 13:55 |
dbs |
kmlussier++ # for contributing and making me laugh |
| 13:55 |
berick |
Dyrcona: tsbere: when-abouts did this leak start for you? |
| 13:55 |
dbs |
truth is if we ever hit 75 workers we're doomed |
| 13:56 |
* dbs |
has Dyrcona's excellent blog post bookmarked, one second |
| 13:56 |
Dyrcona |
'Bout the time we upgraded to Ubuntu 14.04 and Apache 2.4. |
| 13:56 |
* tsbere |
isn't sure it *started* then, it just became a *problem* then >_> |
| 13:56 |
Dyrcona |
Maybe sooner. |
| 13:57 |
dbs |
http://blog.mvlcstaff.org/2013/05/what-has-been-going-on.html |
| 13:57 |
dbs |
Definitely pre-14.04 |
| 13:57 |
berick |
thanks |
| 13:59 |
|
ssieb joined #evergreen |
| 15:28 |
Dyrcona |
Hmm... It isn't always quick to branchify configs that are generated from .in files if you're not starting from git but from the modified output of the .in files. |
| 15:34 |
|
mmorgan1 joined #evergreen |
| 15:37 |
Dyrcona |
Because of things like this: 3 out of 10 hunks FAILED -- saving rejects to file eg_vhost.conf.in.rej |
| 15:45 |
Bmagic |
miker: I am still testing this branch ( just resuming now ) |
| 16:04 |
Dyrcona |
One thing I've discovered in this process is that it helps to check out the rel_* branch for the release that your production server is on and do the comparisons/updates in that branch. |
| 16:06 |
Dyrcona |
Then cherry-pick the resulting commits to a copy of master and/or any later rel_* branches. |
| 16:10 |
|
berick_ joined #evergreen |
| 16:17 |
miker |
Bmagic: thanks! |
| 16:36 |
|
vlewis joined #evergreen |
| 16:58 |
|
mmorgan joined #evergreen |
| 17:02 |
|
mmorgan left #evergreen |
| 17:10 |
|
jvwoolf left #evergreen |
| 17:34 |
ssieb |
I'm trying to have different checkout limits for different user groups, but I can't quite figure it out. |
| 17:35 |
ssieb |
I found the circulation limits, but I didn't see how to connect it to the user groups even though the documentation suggests that it's possible. |
| 17:40 |
dbwells |
ssieb: There are a number of different ways to limit circulations, some more flexible, some easier to use. |
| 17:40 |
dbwells |
We use "Group Penalty Thresholds" to limit circulations for different user groups. |
| 17:41 |
dbwells |
It is a simple count across all items types, all circulations. |
| 17:43 |
dbwells |
So to limit checkout for Group A to 10 items, use "PATRON_EXCEEDS_CHECKOUT_COUNT" as the penalty, Threshold of 10 (will show as 10.00), group of "Group A". |
| 17:53 |
ssieb |
dbwells: I found the circulation limit sets, isn't that what is supposed to be used? |
| 17:55 |
ssieb |
but if it works, your way does look like it might be simpler |
| 17:56 |
dbwells |
ssieb: limit sets allow you to be more specific, such as different limits for DVDs and books. We do not use them. It just depends on your needs. |
| 17:57 |
Bmagic |
What is the issue when you see NOT CONNECTED to the network but only related to vandelay? I have logs in postgres that look ok |
| 17:57 |
Bmagic |
duration: 16964.817 ms statement: INSERT INTO vandelay.queued_bib_record (id,..... |
| 17:57 |
ssieb |
How do you connect a limit set to a user group though? That was the part I couldn't figure out. |
| 17:58 |
ssieb |
Also, the calendar widget seems completely broken. It always sets the month to January... |
| 17:59 |
dbwells |
ssieb: Limit sets are applied to circulation policies, and circulation policies are applied to certain user groups. Outside of that, I don't know the ins and outs. |
| 17:59 |
Bmagic |
Maybe I have underpowered my settings? <max_requests>100 <min_children>1 <max_children>15 |
| 18:00 |
ssieb |
ok, that might be the connection I need |
| 18:03 |
Bmagic |
ssieb: You can create your limit set first, then attach a circulation policy to that set. This approach is usually related to limit sets that target a certain item circulation modifier or shelving location Admin -> Local Administrationr -> Circulation Limit Sets |
| 18:04 |
Bmagic |
ssieb: there is some documentation here http://docs.evergreen-ils.org/2.10/_circulation_limit_sets.html |
| 18:12 |
ssieb |
Bmagic: yes, I read through all that. I was just missing how to link it to a user group. |
| 18:12 |
Bmagic |
ah |
| 18:13 |
Bmagic |
We don't use user groups, so I am less familiar |
| 18:13 |
Bmagic |
At first I thought you were talking about permission groups |
| 18:14 |
ssieb |
It's a school and different grades have different limits on how many books they can have checked out at a time. |
| 18:14 |
ssieb |
I'm trying to figure out how to implement that. |
| 18:21 |
Bmagic |
gotcha |
| 18:28 |
ssieb |
Oh! I missed that the view of circulation policies doesn't contain all the information... :-/ |
| 18:28 |
ssieb |
If you edit it, there are more options. |
| 18:32 |
csharp |
ssieb: circ policies can get pretty complex - I'm sure you've seen http://docs.evergreen-ils.org/2.10/_creating_circulation_policies.html? |
| 18:34 |
csharp |
ssieb: but basically the procedure is to 1) create the user groups in Admin -> Server Administration -> Permission Groups 2) create circulation policies for each group 3) create circulation limit sets for each group 4) link each circ limit set to each policy (policy = matchpoint) |
| 18:36 |
ssieb |
Yes, thank you. I did finally figure out with the clues here. And I had read through that document several times. :-) |
| 18:37 |
ssieb |
I have a problem with the hard due dates though. The calendar won't use the month and always sets it to January. |
| 18:37 |
ssieb |
And on a related note, is there any way to change the date format? |
| 19:23 |
phasefx |
ssieb: still around? |
| 19:40 |
ssieb |
phasefx: I'm just about to leave, but I'll be back on later this evening or tomorrow. |
| 19:42 |
phasefx |
ssieb: no problem. I wasn't able to reproduce your trouble with the calendar widget with hard due dates. Library Settings has a way to change date formats in some contexts, with some limitations |
| 19:43 |
ssieb |
hmm, I wonder what is different in my case |
| 19:43 |
ssieb |
well, it's not critical at this point |
| 19:43 |
* ssieb |
is away |
| 20:04 |
|
dcook joined #evergreen |
| 22:18 |
|
ssieb joined #evergreen |
| 23:15 |
|
gmcharlt joined #evergreen |
| 23:24 |
|
gmcharlt joined #evergreen |
| 23:43 |
|
gmcharlt joined #evergreen |
