| Time |
Nick |
Message |
| 05:56 |
|
stevenyvr2 joined #evergreen |
| 05:57 |
|
stevenyvr2 left #evergreen |
| 06:48 |
|
stevenyvr2 joined #evergreen |
| 06:48 |
|
stevenyvr2 left #evergreen |
| 06:59 |
|
timlaptop joined #evergreen |
| 07:21 |
|
akilsdonk joined #evergreen |
| 07:42 |
|
gdunbar joined #evergreen |
| 07:43 |
|
phasefx2 joined #evergreen |
| 07:43 |
|
goooood joined #evergreen |
| 07:57 |
|
goood joined #evergreen |
| 08:04 |
|
collum joined #evergreen |
| 08:07 |
|
kmlussier joined #evergreen |
| 08:33 |
|
RoganH joined #evergreen |
| 08:34 |
csharp |
kmlussier: I was looking at bug 1234220 and started wondering... do we have *any* renewal block messages? |
| 08:35 |
pinesol_green |
Launchpad bug 1234220 in Evergreen "Renewal blocked due to holds ratio does not display block message" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1234220 |
| 08:35 |
kmlussier |
csharp: Off the top of my head, I know if you use the OU setting to block renewals for titles with holds, there is a nice user friendly message that displays. |
| 08:35 |
csharp |
I got a PINES ticket about a patron who tried to renew, was blocked because there was a hold on the item, but was not *told* that was why. She only saw that she had 2 renewals left |
| 08:36 |
csharp |
oh |
| 08:36 |
csharp |
I'm pretty sure that's set in PINES - lemme check |
| 08:37 |
csharp |
yes it is |
| 08:37 |
csharp |
hmm |
| 08:37 |
kmlussier |
csharp: I'm pretty sure a message displays. I kept forgetting to turn off that OU setting when testing the holds ratio, so I saw it a few times. |
| 08:37 |
|
mmorgan joined #evergreen |
| 08:38 |
csharp |
yeah - that was my original assumption - then I started digging around in the template code and didn't see anything :-/ |
| 08:42 |
|
ericar joined #evergreen |
| 08:43 |
|
akilsdonk joined #evergreen |
| 08:48 |
csharp |
okay, yeah, I see "Copy is needed to fulfill a hold" in red |
| 08:48 |
csharp |
but I can see how a patron might miss it |
| 08:48 |
csharp |
kmlussier: thanks |
| 09:10 |
|
hopkinsju joined #evergreen |
| 09:16 |
|
Shae joined #evergreen |
| 09:18 |
|
jbfink joined #evergreen |
| 09:51 |
paxed |
like you can search for foo* to find words-starting-with-foo, is there *foo for words-ending-with-foo? |
| 09:53 |
|
yboston joined #evergreen |
| 10:22 |
|
jbfink joined #evergreen |
| 10:33 |
|
ldwhalen joined #evergreen |
| 10:35 |
|
ericar joined #evergreen |
| 10:39 |
Bmagic |
what is the recommended setting for PATRON_EXCEEDS_OVERDUE_COUNT when you dont want the system to check out a book to anyone who has a single overdue? |
| 10:42 |
Bmagic |
We have this setting set to 0.90 - we have a problem where the patron does not get that penalty applied until his account is pulled up into the Staff Client and the refresh button is pressed. What process should be adding the standing penalty? Fine Generator? |
| 11:07 |
|
serflog joined #evergreen |
| 11:07 |
|
Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged. | Large pastes at http://paste.evergreen-ils.org |
| 11:08 |
Bmagic |
jeff: Are you saying that the fine generator should be applying that penalty to the account even if it doesnt add fines |
| 11:09 |
jeff |
the grace period is likely at play here. the overdue_circs sub called by open-ils.storage.action.circulation.overdue.generate_fines excludes circs that are within the grace period. |
| 11:09 |
jeff |
thus, unless there are other overdue circs that are past the grace period, the fine generator will not trigger a calcualtion of system penalties. |
| 11:10 |
jeff |
that's probably what's causing what you're seeing. |
| 11:10 |
Bmagic |
jeff: That is the issue then |
| 11:11 |
jeff |
and it's a bit of an inconsistency, since a manual recalc will add the penalty. we should probably determine if the penalty should count overdues within the grace or not. |
| 11:11 |
jeff |
while this is based on a reading of the code and my current understanding of things, please keep in mind that i haven't tested this theory. :-) |
| 11:12 |
Bmagic |
jeff: right on, sound like an interesting debackle |
| 11:12 |
Bmagic |
jeff: right on, sound like an interesting debacle |
| 11:19 |
Bmagic |
jeff: For now, it sounds like I can use that script that you directed me to on a cronjob? Long term, perhaps the code for fine_generator.pl could be discussed in dev? |
| 11:26 |
jeff |
i wouldn't recommend that script from cron. for one thing, it relies on you to manually supply a list of users to recalc and relies on you providing a manual auth token. |
| 11:26 |
jeff |
it was meant for one-time batch update style use. |
| 11:27 |
jeff |
we had a need to recalc a bunch of users when we changed some thresholds, and we also had no access to the server at the time, so it runs through the gateway, same as the staff client. |
| 11:59 |
|
smyers_ joined #evergreen |
| 12:05 |
|
gsams joined #evergreen |
| 12:06 |
|
dMiller joined #evergreen |
| 12:08 |
|
ldwhalen joined #evergreen |
| 12:11 |
paxed |
~/win 22 |
| 12:11 |
paxed |
oops |
| 12:14 |
|
gmcharlt joined #evergreen |
| 12:16 |
|
gsams joined #evergreen |
| 12:16 |
|
smyers_ joined #evergreen |
| 12:17 |
|
dMiller__ joined #evergreen |
| 12:18 |
jeff |
anyone present using non-3M SIP-based self checkout terminals? i'm wondering how other vendors react to "charge privileges denied" in the patron status field. |
| 12:19 |
jboyer-isl |
JCPL was running Bibliotheca machines when I left. If you've some simple steps to test what you're interested in I could pass them on. |
| 12:20 |
jeff |
in evergreen, standing penalties 1 and 2, as well as any standing penalty with a non-empty block list will result in "charge privileges denied" being set to Y. |
| 12:20 |
jeff |
(this is for standing penalties with an org_unit based on the home_ou and ancestors of the patron in question) |
| 12:21 |
jeff |
so, if you define a max items out limit of 40, a patron with 40 items out has a standing penalty which blocks circ. |
| 12:21 |
jeff |
the patron scans their card on a 3M SelfCheck workstation, and receives an error message and is directed to the desk. |
| 12:21 |
jeff |
this prevents them from using the self checkout terminal to renew items. |
| 12:22 |
jeff |
i'm interested in changing the behavior on the evergreen side of things, and would like to better understand how other SIP clients react to "charge privileges denied" |
| 12:23 |
jeff |
so, it would be interesting to know if patrons with the max number of items out can use a bibliotheca terminal, or if they're refused outright. |
| 12:27 |
eeevil |
jeff: sound primarily like the impedance mismatch between SIP2 and ILSen, where the latter has a separate idea of "renewal" but the former does not, and ties renewal to "charge privileges" ... some ILSs lie about the patron's status and deny circs at attempt time, which the EG SIPServer driver could do, I suppose |
| 12:30 |
jeff |
huge impedance mismatch, yes. |
| 12:30 |
jeff |
and eg does reject at attempt time, of course. |
| 12:31 |
jeff |
and (at least in our environment) we do have at least one case where we want to alert when the patron scans their card -- when they're expired. |
| 12:31 |
jeff |
i'm going to reach out to 3M to see if they can provide more details, but thought i'd seek out others with other vendors here. i don't see sal_, but maybe I'll e-mail her. |
| 12:33 |
jeff |
incidentally, there is also a "renewal privileges denied", which... oh hey, which evergreen sets to match the charge privileges denied value. i suppose it's time to test. |
| 12:34 |
jeff |
because if i can make evergreen "do the right thing" with regard to renewals being permitted as long as there isn't a RENEW-blocking ausp, that would be logical and would avoid a new config for "don't report these standing penalties" or similar. |
| 12:35 |
jeff |
semi-related, does anyone know if we've ever populated a csp block value of INET, or is that just something in our db? |
| 12:37 |
jeff |
_bott_: any idea about the INET block type on some standing penalties? was that a GRPL/ME thing? |
| 12:38 |
|
linuxhiker1 joined #evergreen |
| 12:39 |
tsbere |
jeff: First I have heard of such a thing |
| 12:45 |
|
hopkinsju_ joined #evergreen |
| 12:53 |
csharp |
jeff: yeah - we don't have that type either |
| 12:53 |
|
hopkinsju_ joined #evergreen |
| 12:54 |
|
plux joined #evergreen |
| 12:56 |
jeff |
and the pickaxe confirms -- doesn't seem to have ever been in seed data. |
| 13:00 |
eeevil |
jeff: I don't recall INET being a block type, but it seems valuable. and +1 to doing the right thing in the face of a RENEW block, and not using CIRC |
| 13:01 |
csharp |
@praise the pickaxe |
| 13:01 |
* pinesol_green` |
the pickaxe is the very model of a modern major hacker |
| 13:01 |
csharp |
@nick pinesol_green |
| 13:01 |
pinesol_green` |
csharp: Error: You don't have the admin capability. If you think that you should have this capability, be sure that you are identified before trying again. The 'whoami' command can tell you if you're identified. |
| 13:01 |
csharp |
pinesol_green`: dude |
| 13:01 |
pinesol_green` |
csharp: Mr. Spock: Something fascinating just happened. |
| 13:08 |
|
smyers__ joined #evergreen |
| 13:21 |
|
linuxhiker1 joined #evergreen |
| 13:24 |
|
RoganH joined #evergreen |
| 13:29 |
|
stevenyvr2 joined #evergreen |
| 13:41 |
|
mjingle joined #evergreen |
| 13:44 |
|
smyers__ joined #evergreen |
| 13:49 |
|
dMiller_ joined #evergreen |
| 14:07 |
|
kmlussier joined #evergreen |
| 14:18 |
bshum |
eeevil: I'm finally reading back what you last commented in bug 1185865. When you say sparing DB server CPU cycles, does that refer to a system where hold_targeter is run on the same server as DB? Or do you just mean that because there's in-db logic at play, that we'll use up processing either way. |
| 14:18 |
pinesol_green |
Launchpad bug 1185865 in Evergreen "Hold targeter taking a long time to run" (affected: 2, heat: 10) [Undecided,New] https://launchpad.net/bugs/1185865 |
| 14:22 |
DPearl1 |
I'm specifying OCLC as a record source in Z39.50. What log, if any, are these requests logged in? (OCLC is only returning 4 records when the code asks for more, and I want to figure out why.) |
| 14:35 |
eeevil |
bshum: no, I mean that the in-database part is more complex now. if the load on your db would support more concurrent retargetting, increasing the parallel targeters would help |
| 14:36 |
bshum |
eeevil: Okay, worth looking into then. I don't think our DB load is significantly high, but I'm never entirely sure what that is. |
| 14:36 |
bshum |
Thanks! |
| 14:36 |
eeevil |
np |
| 14:37 |
bshum |
DPearl1: If you mean that you're choosing OCLC as the record source for importing records and you're doing searches on them and not seeing the results you expect? |
| 14:38 |
bshum |
DPearl1: I'm not sure those system requests are logged anywhere in the GUI (doubt it). But maybe there's something in the osrf logging |
| 14:38 |
bshum |
I imagine if you had access to OCLC's z39.50 log that could be fun to see :D |
| 14:39 |
jeff |
do we have too much logic in the db these days? |
| 14:39 |
bshum |
I occasionally dabble looking at our yaz logs to see what people search against when they look at our z39.50 from EG |
| 14:39 |
jeff |
not a particularly focused or productive question, but something i've been thinking about a little bit. |
| 14:40 |
tsbere |
jeff: I find that answer varies. Including on "who you ask". Some people insist that no logic should be done in the DB other than what is required for things like foreign key relationships and not null constraints and such, after all. |
| 14:41 |
jeff |
sure, there's purists like that. i wasn't asking from that point of view. :-) |
| 14:42 |
jeff |
i suspect that things like in-db ingest are not cpu bound, but haven't tested. it might be. |
| 14:55 |
mceraso |
This may be a silly question, but I'm asking anyway :) Would it be okay to join the merchandising committee for Evergreen? Rogan sent out an email yesterday |
| 14:55 |
mceraso |
Apologies, wrong window :) |
| 14:55 |
|
mrpeters joined #evergreen |
| 14:55 |
DPearl1 |
bshum: Yeah. OCLC is record source. It looks like there is a functionality change (a.k.a. degredation) with the new opensrf, I'd guess. I have one system EG2.3/OS2.13 which works as expected, and another EG2.4/OS2.2.1 which doesn't work. Can't spot a log yet... |
| 14:59 |
dbs |
DPearl1: different versions of yaz, too, maybe? |
| 15:03 |
bshum |
Yeah my first gut reaction is to learn what versions of Yaz were being employed. |
| 15:06 |
bshum |
There are some known weirdness with packaged yaz from Precise systems |
| 15:07 |
eeevil |
jeff: in-db ingest is aprox 10x faster than the old way, and breaks a lot less (and when it does, it doesn't leave a mess behind) ... just fwiw |
| 15:07 |
jeff |
eeevil: and that's the kind of experienced perspective i was fishing for. thanks. :-) |
| 15:07 |
DPearl1 |
dbs, bshum: I'll check on yaz... |
| 15:08 |
dbs |
Would be fabulous if PostgreSQL could be more parallel, mind |
| 15:10 |
kmlussier |
eeevil: I'm curious. Would MVF work open up the door to future work to add format facets? |
| 15:13 |
|
tfaile joined #evergreen |
| 15:14 |
eeevil |
kmlussier: not "facet" in the exact way we mean internally in EG today, but yes, a sidebar filter based on MVF would be more useful than one based on SVF. |
| 15:14 |
kmlussier |
eeevil: Thanks! |
| 15:15 |
bshum |
Speaking of Postgres |
| 15:15 |
eeevil |
np |
| 15:15 |
bshum |
Has anyone else read these posts about Ubuntu 12.04 and newer kernel versions? |
| 15:15 |
bshum |
Like http://frosty-postgres.blogspot.com/2013/11/ubuntu-has-released-3110-kernel-for.html |
| 15:15 |
eeevil |
dbs: we should write a background worker to shred xml for us, and have a bunch going at the same time! :) |
| 15:15 |
bshum |
Not sure how many that impacts, we're still bouncing around on Ubuntu 10.04 for our DB server. |
| 15:16 |
eeevil |
bshum: that's why I use debian ;) (in all seriousness, it does look nasty, but we've avoided it afaict) |
| 15:17 |
bshum |
eeevil: Since we're talking redoing our whole server system next year for 14.04, I've been giving some thought towards switching us to Debian instead. |
| 15:17 |
bshum |
But good to know ;) |
| 15:20 |
dbs |
win 19 |
| 15:20 |
dbs |
meh |
| 15:21 |
* jeff |
transforms paxed's earlier ~ into a / and hands it to dbs |
| 15:26 |
Bmagic |
jeff: Do you think that I could alter your perl script to create the auth token with something similar to this: my $script = OpenILS::Utils::Cronscript->new; |
| 15:26 |
Bmagic |
my $authtoken = $script->authenticate( |
| 15:26 |
jeff |
Bmagic: yes, certainly. |
| 15:26 |
jeff |
and if you were going to do that, you could always move away from using LWP and the gateway altogether. |
| 15:27 |
jeff |
it's a very simple script, in terms of it just walks over a bunch of values and calls an opensrf call with that value as an argument. |
| 15:28 |
|
dMiller__ joined #evergreen |
| 15:28 |
Bmagic |
jeff: I have only touched my toes in working with opensrf, so I need some guidance. I haven't been able to make heads or tails of the opensrf documentation that I have found. At least in this context |
| 15:29 |
csharp |
bshum: FWIW, we've been running fine on 12.04 since March |
| 15:30 |
jeff |
csharp: did you see higher-than-before cpu utilization as mentioned in those threads? |
| 15:35 |
collum |
Making sure I'm not missing the obvious. I'm looking for last inhouse checkin for an copy in the staff client. Do you guys know if this is available on any of the copy screens? |
| 15:35 |
tsbere |
collum: "Last inhouse checkin"? |
| 15:35 |
* tsbere |
can think of at least two ways, possibly more, to define that one |
| 15:36 |
collum |
In house use |
| 15:36 |
csharp |
jeff: nope, but we also doubled our RAM along with the upgrade, so that may have mitigated the issue |
| 15:36 |
collum |
Easy enough to pull the most current date out of the in_house_use table, but I was hoping it was in the client. |
| 15:37 |
csharp |
we did see some crazy high load a few months ago, before we moved our data directory to a separate array |
| 15:37 |
csharp |
since early September we've been stable |
| 15:37 |
* csharp |
sacrifices goat to sys admin gods |
| 15:37 |
jeff |
collum: nothing comes to mind other than the reporter or the db. we don't use in-house-use here much if at all, though. |
| 15:38 |
tsbere |
collum: Never actually paid a lot of attention to that functionality, though I would say that is more of a "checkout" then a "checkin" ;) |
| 15:39 |
collum |
Thanks jeff and tsbere. |
| 15:40 |
tsbere |
collum: I don't actually see any significant use of that table, nor do I see any "retrieve" style functions for it in use anywhere. Looks like a "write only, use reporting to get it out" table as a result? |
| 15:40 |
tsbere |
(same for the noncat side, for that matter) |
| 15:40 |
* collum |
defines his terms on how his staff has decided to use the software. :-) |
| 15:41 |
collum |
Thanks tsbere. I will write a jasperreport for them to use. |
| 15:41 |
jeff |
yay! another JasperReports user! |
| 15:42 |
jeff |
collum: how are you liking JasperReports? |
| 15:42 |
tsbere |
collum: For note, when I think "inhouse checkin" I have two scenarios that jump to mind. "The last time the item was checked in at home" and "the last time the item was touched by a computer at home". The first can be determined fairly easily, the latter isn't always obtainable for a large number of reasons right now. |
| 15:42 |
|
RBecker joined #evergreen |
| 15:42 |
* jeff |
still wants a "last seen time" value for copies somewhere. poor man's inventory, among other things. |
| 15:43 |
collum |
jeff: Indeed I do. It's easy for the staff to use, and it's convenient. |
| 15:43 |
jboyer-isl |
A quick Parts mystery. When placing a hold on a title with parts, what determines if choosing a part is required or not? I'm looking at 2 titles, placing a hold on one forces you to choose a part, the other has an "-All Parts-" entry selected initially. |
| 15:43 |
jeff |
collum: excellent. how long have you been using it, and what brought it to your attention? |
| 15:43 |
jboyer-isl |
The only difference I can see is that the one that forces you to choose has all of its items checked out. |
| 15:43 |
collum |
tsbere: we defined in-house-use as an item that was found used in the library, but not checked out. "Found on a table" |
| 15:44 |
tsbere |
collum: We define that entire functionality as "something we don't use" ;) |
| 15:45 |
collum |
jeff: I started using around June 2012. We came live on EG in August. My staff was used to a web based reporting package, so I wanted to have something familiar for them. |
| 15:45 |
collum |
Uh. August 2012 |
| 15:48 |
jeff |
cool. did you come to it independently, or based on some of TADL's experience with it? |
| 15:52 |
collum |
The sequence of events is a blur. |
| 15:53 |
collum |
I believe I came to it because I knew TADL was using it, and I thought I would check it out. |
| 15:53 |
jeff |
heh. got it. |
| 15:54 |
jeff |
well, glad to hear that there's at least one other evergreen library using it. that should motivate me to put up some more of our reports. |
| 16:17 |
eeevil |
jboyer-isl: if the bib has any part-less copies, you can choose the "all parts" option. if all copies are attached to parts, you must choose a part. IIRC, not looking at the code ATM |
| 16:18 |
bshum |
Yeah that sounds about right. |
| 16:19 |
bshum |
"All parts" is basically a title level hold if I remember right. Targeting all the copies that don't have parts. |
| 16:19 |
bshum |
It could be that the bib has a monographic part on it |
| 16:19 |
bshum |
And yet none of the underlying copies have connected parts to them? |
| 16:20 |
jboyer-isl |
I see. So if a single location has a "regular" item, everyone with parts sees the All Parts option? |
| 16:20 |
bshum |
Yes |
| 16:20 |
bshum |
(I still hate the terminology) |
| 16:20 |
bshum |
See this kmlussier! |
| 16:20 |
bshum |
parts-- |
| 16:20 |
bshum |
I said, parts-- !!!!!!!!!!!!!!!!!! |
| 16:21 |
* kmlussier |
is paying attention and formulating a response. ;) |
| 16:21 |
kmlussier |
parts++ |
| 16:21 |
kmlussier |
parts++ |
| 16:21 |
bshum |
Heh |
| 16:21 |
jboyer-isl |
The cataloger that asked the question will be thrilled to hear that as soon as another location gets the same copy of this TV show that All Parts will be back. (they like requiring the choice, but I couldn't see why it was being offered.) |
| 16:21 |
kmlussier |
jboyer-isl: The idea is that, in most cases, if a library added an item without parts, they are most likely circulating it as a whole set. That's where the "All Parts" label comes from. |
| 16:23 |
kmlussier |
jboyer-isl: We have one consortium that requires all branches to add parts to their items on records with parts as a way to require users to select parts. However, that can be problematic when there are already title-level holds on the part. |
| 16:23 |
kmlussier |
Our other two consortia don't make the same requirement. |
| 16:24 |
jboyer-isl |
I see. I guess there's some confusion here since most locations don't use parts, but the ones that do |
| 16:24 |
jboyer-isl |
didn't realize why things were different. |
| 16:24 |
jboyer-isl |
on a single record, that is. |
| 16:26 |
bshum |
In our consortium, it's policy that once a lib starts using parts, everybody has to assign parts to their items as well for that given bib record. |
| 16:27 |
bshum |
We kind of force their hand by changing the code to disallow further new title holds via the all parts option. |
| 16:27 |
bshum |
And making the all parts just a signaler that they need to pick a real part. |
| 16:27 |
bshum |
Wasn't really my choice, just part of how policy was enacted. |
| 16:28 |
jboyer-isl |
I don't think enough libs use them here for that to gain traction, but I may pass it along to the cataloging group. |
| 16:31 |
|
linuxhiker joined #evergreen |
| 16:36 |
kmlussier |
bshum: You don't have issues where there are pre-existing title holds on the record? |
| 16:36 |
bshum |
kmlussier: Pre-existing title holds will slowly fill based on their order using copies that aren't yet parts. |
| 16:36 |
bshum |
So they'll slowly filter out over time. |
| 16:36 |
bshum |
It's the new holds that must be applied once copies are converted to parts. |
| 16:36 |
kmlussier |
Ah, I see. |
| 16:37 |
|
linuxhiker1 joined #evergreen |
| 16:37 |
bshum |
It's generally more likely that the holds finish filling with existing copies from other libs before people realize that new holds aren't targeting their copies anymore |
| 16:37 |
bshum |
Due to them not using parts. |
| 16:37 |
bshum |
The libs that switch to parts quickly never use their copies for parts, but their parts get used for all the new holds |
| 16:38 |
bshum |
So I guess they consider that balanced? |
| 16:38 |
bshum |
Or perhaps libraries are manually canceling title holds and remaking them as part holds once they convert to parts. |
| 16:41 |
* kmlussier |
thinks it's easier to let title holds be placed for people who want the whole thing and parts holds for people who want a part. |
| 16:42 |
kmlussier |
Though I think the interface could use some improvement so the whole parts selector is more visible. NOBLE did some nice custom work for their parts selector to make it more visible. I should think about making a branch out of that someday. |
| 17:03 |
bshum |
Hmm, people grumbly about not having hold shelf expire time or some other wording saying pickup before it expires as part of SMS texts. |
| 17:04 |
bshum |
140 characters really doesn't give alot of room to get wordy |
| 17:04 |
bshum |
Or 160? |
| 17:04 |
bshum |
Either way, *big sigh* |
| 17:08 |
phasefx_ |
start including a tiny url :) |
| 17:09 |
phasefx_ |
might be able to click on it with a smartphone, not sure |
| 17:10 |
bshum |
We probably could click on those with a smartphone |
| 17:10 |
bshum |
Sigh |
| 17:11 |
kmlussier |
bshum: I think the maximum count varies based on carriers. I remember we set the maximum character lower than 140 in our requirements docs after I had done some investigating. |
| 17:11 |
bshum |
Then everybody would want individualized SMS texts with a link to their own policies or whatnot. |
| 17:12 |
bshum |
Maybe we need to include this as extra information around the parts where SMS are setup in patron accounts. Or on each hold. |
| 17:12 |
bshum |
By the way, pick it up in 5 days or else |
| 17:12 |
bshum |
kmlussier: That wouldn't surprise me at all. |
| 17:20 |
|
mmorgan left #evergreen |
| 17:56 |
|
dMiller_ joined #evergreen |
| 18:02 |
|
mtcarlso- joined #evergreen |
| 18:42 |
|
kbeswick joined #evergreen |
| 18:46 |
|
dMiller joined #evergreen |
| 18:50 |
|
stevenyvr2 left #evergreen |
| 19:29 |
|
hopkinsju joined #evergreen |
| 19:43 |
|
hopkinsju_ joined #evergreen |
| 19:54 |
|
hopkinsju_ joined #evergreen |
| 20:20 |
|
mjingle joined #evergreen |
| 20:21 |
|
rangi joined #evergreen |
| 20:23 |
|
mjingle left #evergreen |
| 21:41 |
|
stevenyvr2 joined #evergreen |
| 21:42 |
|
stevenyvr2 left #evergreen |
| 23:31 |
|
mrpeters joined #evergreen |
