| Time |
Nick |
Message |
| 00:33 |
|
phasefx joined #evergreen |
| 01:23 |
|
phasefx joined #evergreen |
| 01:35 |
paxed |
bshum: at least we're not trying to automatically grab translatable strings (it's how Koha does things) |
| 01:39 |
jeff |
i'd be interested in picking bshum's brain on what he has learned, especially as it may pertain to future interfaces |
| 01:40 |
|
phasefx joined #evergreen |
| 01:41 |
jeff |
bouncing phasefx |
| 01:42 |
paxed |
he's just looking for the lowest energy phase ... |
| 01:49 |
jeff |
i find myself finally playing with JuiceSSH |
| 01:55 |
paxed |
ugh. gcc complaints. -Wformat-security -Wunused-result seem to be set by default on ubuntu 13.10 |
| 02:09 |
|
phasefx joined #evergreen |
| 02:31 |
|
phasefx joined #evergreen |
| 03:14 |
|
phasefx joined #evergreen |
| 04:21 |
|
phasefx joined #evergreen |
| 04:37 |
|
phasefx joined #evergreen |
| 04:54 |
|
phasefx joined #evergreen |
| 06:20 |
|
phasefx joined #evergreen |
| 06:44 |
|
phasefx joined #evergreen |
| 07:08 |
|
phasefx joined #evergreen |
| 07:18 |
|
tater joined #evergreen |
| 07:19 |
|
phasefx joined #evergreen |
| 07:21 |
|
jboyer-isl joined #evergreen |
| 08:23 |
|
misilot joined #evergreen |
| 08:28 |
* jeff |
yawns |
| 08:31 |
|
collum joined #evergreen |
| 08:34 |
|
akilsdonk joined #evergreen |
| 08:36 |
|
rjackson-isl joined #evergreen |
| 08:38 |
|
tater joined #evergreen |
| 08:41 |
|
kbeswick joined #evergreen |
| 08:42 |
|
mrpeters joined #evergreen |
| 08:46 |
|
Dyrcona joined #evergreen |
| 08:47 |
Dyrcona |
tsbere: Conclusion: The web sucks. |
| 08:49 |
jboyer-isl |
Somebody reading about web standards? |
| 08:51 |
Dyrcona |
The best thing about standards is that there arent' any! |
| 08:52 |
rjackson-isl |
and here I thought it was there were so many to chose from and they were all different! |
| 08:52 |
|
timf joined #evergreen |
| 08:52 |
Dyrcona |
rjackson-isl: Same thing. :) |
| 08:54 |
|
mmorgan1 joined #evergreen |
| 09:04 |
|
ericar joined #evergreen |
| 09:05 |
egbuilder |
build #405 of evergreen-master-debian-6.00-x86_64 is complete: Success [build successful] Build details are at http://testing.evergreen-ils.org/buildbot/builders/evergreen-master-debian-6.00-x86_64/builds/405 |
| 09:06 |
dbs |
Many thanks to Peter Lux at UPEI for getting me access to that build machine again :) |
| 09:09 |
dbs |
@later tell bshum GSoC summit is _so_ good for expanding horizons, eh? |
| 09:09 |
pinesol_green |
dbs: The operation succeeded. |
| 09:09 |
jeff |
dbs++ UPEI++ |
| 09:14 |
|
kmlussier joined #evergreen |
| 09:22 |
|
Callender joined #evergreen |
| 09:26 |
csharp |
okay - this is a question so I can put in a wishlist bug/feature request... |
| 09:27 |
csharp |
many of our circ/hold rules are built around things like "if the pickup library is the same as the patron home library, allow the hold" |
| 09:27 |
|
remingtron joined #evergreen |
| 09:27 |
csharp |
but there's not currently a mechanism in in-db circ/holds that compares fields, right? |
| 09:28 |
csharp |
which results in inefficient repeating of the same hold/circ rules for each library/system/whatever in an interface that is already error-prone |
| 09:28 |
csharp |
are others in agreement about that need? |
| 09:34 |
jeff |
not sure i'm following, but i'm interested. |
| 09:34 |
jeff |
your rules are built around things like that -- and does in-db support those criteria in rules, but it's just a display issue? |
| 09:34 |
jeff |
or do in-db hold/circ rules not even support what you wish it supported, in this case? |
| 09:35 |
berick |
it's a proliferation of rules issue |
| 09:35 |
berick |
a rule for every combination of org units as oppose to one rule that says "circ lib == patron home lib" |
| 09:35 |
berick |
IIUC |
| 09:36 |
jeff |
berick++ it all becomes more clear now |
| 09:36 |
berick |
s/circ lib/pickup lib/ |
| 09:36 |
jeff |
i also mis-read "repeating" as "reporting". |
| 09:37 |
csharp |
berick: correct |
| 09:38 |
* csharp |
wants one rule to rule them all |
| 09:38 |
berick |
csharp: it's been a while since I dove into that code, but i'm pretty sure your assessment is correct |
| 09:38 |
csharp |
ok - thanks |
| 09:38 |
csharp |
that allows me to move with a feature request that I think EG admins would @love |
| 09:40 |
kmlussier |
csharp: I don't think we have that particular need here, but I'm in favor of anything that cuts down the number of circ or hold rules. :) |
| 09:41 |
|
yboston joined #evergreen |
| 09:42 |
csharp |
kmlussier: I think if the functionality were more generic, something like "if the value of this field == or != the value of that field, allow/deny the circ/hold" |
| 09:42 |
csharp |
it would probably accomplish a further reduction of rules |
| 09:42 |
dbs |
csharp: so... embed Javascript in one column? #bwahaha |
| 09:42 |
csharp |
heh - right! |
| 09:45 |
jboyer-isl |
So, does the transit range field not help with this? (0 for same lib, 1 for that sys and related branches?) |
| 09:46 |
csharp |
jboyer-isl: it helps, but some libraries don't even want users from other libraries to place holds on their items at all |
| 09:46 |
csharp |
in PINES, we use the transit range limit to work around the lack of what I'm talking about |
| 09:46 |
dbs |
csharp: yeah, we're like that |
| 09:47 |
csharp |
so a PINES patron can place a hold on anybody's item anywhere, but the item won't transit out for the hold |
| 09:48 |
csharp |
the intention of policy is that those patrons shouldn't even be able to place the hold in the first place |
| 09:48 |
jboyer-isl |
Ugh. I see. So that field will allow them to change the pickup lib and then it will pass the check. |
| 09:49 |
jboyer-isl |
We also have profiles that can only place holds/use materials at their home libs. Now I want your feature too. :( |
| 09:50 |
paxed |
that feature would be nice... |
| 09:53 |
mrpeters |
jboyer-isl: you're going to have a fun time each time you add a new branch |
| 09:53 |
|
BigRig joined #evergreen |
| 09:53 |
mrpeters |
you have like 15 circ modifiers that allow intra-branch transit |
| 09:53 |
mrpeters |
times 158 branches |
| 09:54 |
mrpeters |
awitter is looking at over 2200 rules for your current state |
| 09:54 |
jboyer-isl |
csharp: Rather than building much logic into it (field1 (!/=)= field2) what about a field "limit to requestor home_ou" that accepts a depth setting? |
| 09:54 |
csharp |
that works too |
| 09:54 |
mrpeters |
yeah, that would be nice |
| 09:54 |
jboyer-isl |
mrpeters: Well, I know bibliomation uses scripts to manage theirs, I suppose we can go that route... |
| 09:55 |
mrpeters |
yeah, i mean, you've seen the code so im sure you have an idea of how you have to do the inserts |
| 09:55 |
mrpeters |
it wouldnt be difficult to take the block for those 14 circ mods and one branch and s/ the org id's |
| 09:55 |
jboyer-isl |
yeah. Just have to take the time to genericise it. :/ |
| 09:55 |
mrpeters |
go convince Ana to allow holds to be placed on ANY item, but they will never transit if they're in the disallowed list |
| 09:56 |
jboyer-isl |
I want something like that to go through anyway. "Only our patrons can place holds on our items!" Librarian, please. |
| 09:56 |
mrpeters |
well, they still wouldnt get the items |
| 09:57 |
mrpeters |
it would just fail hold tests until the 9 months expired |
| 09:57 |
jeff |
What's the logic behind showing the patrons items then saying that they can't request them? |
| 09:57 |
mrpeters |
thats how PINES does it |
| 09:57 |
mrpeters |
lol jefff |
| 09:57 |
jeff |
I mean, I suppose reference material is also shown in the catalog, but there's some difference there. Not sure what difference... |
| 09:57 |
mrpeters |
dvds are too sensitive! |
| 09:57 |
mrpeters |
they can't transit! they will get stolen/sold on ebay/broken |
| 09:58 |
mrpeters |
yet, they can go to a library, pick up a dvd, and then return it to their home ou where it then has to transit anyway, risking it to the same potential damage |
| 09:58 |
mrpeters |
this particular situation was cake with javascript |
| 09:59 |
mrpeters |
in-db just isn't developed quite to the point to suit depths in the *_ou fields, like jboyer-isl suggests |
| 09:59 |
jboyer-isl |
Maybe if we didn't have that much flexibility at the time we could have forced some more simplification. :/ |
| 09:59 |
csharp |
bug 1242708 created |
| 09:59 |
pinesol_green |
Launchpad bug 1242708 in Evergreen "Evergreen needs the ability for comparison of columns in in-db circ/holds" (affected: 1, heat: 6) [Wishlist,New] https://launchpad.net/bugs/1242708 |
| 10:00 |
paxed |
hm. i wonder if i should file a wishlist bug for a wiki-like help, similar to Koha... |
| 10:00 |
csharp |
jeff: we allow the hold, and the patron can drive to the owning library and pick up the hold, but it won't transit if it's an A/V or new item |
| 10:01 |
csharp |
but that's a workaround |
| 10:01 |
csharp |
paxed: I like that idea a lot |
| 10:02 |
csharp |
paxed++ |
| 10:02 |
jeff |
paxed: are you envisioning something local to each system, or central? |
| 10:06 |
paxed |
jeff: i was thinking of having YAOU for wiki.{opac,staff}.help.url with default value of 'http://help.evergreen-ils.org/wiki/$EGVERSION/$LOCALE/$TEMPLATE.NAME/$COMPONENT.NAME#$SECTION' or something... |
| 10:06 |
paxed |
+S |
| 10:07 |
mrpeters |
paxed, that would be cool. even better if you could customize the URL |
| 10:07 |
mrpeters |
if you wanted to point to internal wiki |
| 10:08 |
mrpeters |
and have it make the "help" menu in Evergreen point to that wiki |
| 10:09 |
paxed |
the only thing i don't know is how it would handle logging in to the wiki, or letting staff with EDIT_WIKI_HELP rights editing it ... |
| 10:10 |
paxed |
Koha pops up a window with edit field, and it tries to save the "wiki" help to a local directory (which needs to be writable by koha/apache, of course...) |
| 10:11 |
mrpeters |
heck, i think just linking to the wiki would be good. wasn't there some concern about displaying external urls in the staff client though? |
| 10:11 |
mrpeters |
so maybe it should pop up the default browser instead |
| 10:11 |
paxed |
yeah, default browser would be better |
| 10:12 |
|
Dyrcona joined #evergreen |
| 10:20 |
paxed |
quickly added bug 1242717 |
| 10:20 |
pinesol_green |
Launchpad bug 1242717 in Evergreen "Wiki-like integrated help" (affected: 1, heat: 6) [Wishlist,New] https://launchpad.net/bugs/1242717 |
| 10:23 |
Dyrcona |
Kill it! Kill it with fire! |
| 10:23 |
jboyer-isl |
Dyrcona: Anticipating wiki-rage from local staff? ;) |
| 10:24 |
Dyrcona |
Conclusion: Software sucks! |
| 10:24 |
paxed |
no, no. the conclusion is: Evergreen sucks. :P |
| 10:24 |
Dyrcona |
jboyer-isl: That was a more general scream of frustration. |
| 10:24 |
Dyrcona |
paxed: Evergreen is software, therefore Evergreen sucks. |
| 10:24 |
jboyer-isl |
Ah. Completely understandable in that case. |
| 10:24 |
Dyrcona |
All software sucks. |
| 10:25 |
paxed |
hello world? |
| 10:25 |
jboyer-isl |
Except for Hello World, drats, paxed beat me to it. :D |
| 10:25 |
Dyrcona |
Even hello world sucks. What does it actually do, anyway? ;) |
| 10:26 |
* Dyrcona |
is not having a good day with software on his first day back from a week off. |
| 10:26 |
* paxed |
is not having a good 1.5 months. |
| 10:26 |
* Dyrcona |
throws a pity party for any who want to join in. :) |
| 10:27 |
paxed |
yay, party. i'll be the wallflower. |
| 10:27 |
jboyer-isl |
I have a tiny violin, kind of hard to see though. |
| 10:32 |
|
artunit joined #evergreen |
| 10:59 |
csharp |
@blame hello world for being software |
| 10:59 |
pinesol_green |
csharp: hello world broke Evergreen. for being software |
| 11:13 |
gmcharlt |
csharp: personally, I prefer to blame Helo, World |
| 11:13 |
csharp |
gmcharlt++ |
| 11:13 |
Dyrcona |
HELO or EHLO ? ;) |
| 11:13 |
gmcharlt |
heh |
| 11:13 |
Dyrcona |
@blame E.L.O. |
| 11:13 |
pinesol_green |
Dyrcona: E.L.O. is why we can never have nice things! |
| 11:16 |
pinesol_green |
[evergreen|Dan Scott] Fix "elfield" typo noted by Ben Ostrowsky - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=fc01be2> |
| 11:16 |
dbs |
ELOfield |
| 11:18 |
Dyrcona |
dbs++ |
| 11:19 |
|
smyers_ joined #evergreen |
| 11:29 |
|
smyers_ joined #evergreen |
| 11:29 |
|
ktomita joined #evergreen |
| 11:29 |
|
sseng joined #evergreen |
| 11:37 |
|
ktomita_ joined #evergreen |
| 11:37 |
|
sseng_ joined #evergreen |
| 11:38 |
|
fparks joined #evergreen |
| 11:38 |
|
mllewellyn joined #evergreen |
| 11:40 |
|
dMiller_ joined #evergreen |
| 11:45 |
|
sseng joined #evergreen |
| 11:45 |
|
smyers__ joined #evergreen |
| 11:45 |
|
fparks joined #evergreen |
| 11:45 |
|
ktomita joined #evergreen |
| 11:46 |
|
dMiller__ joined #evergreen |
| 11:52 |
dbs |
gmcharlt: so it seems that the problem with naco_normalize and other similar functions is that we need to wrap the decode_utf8() in an NFD() call, as of the new Encode module version. |
| 11:52 |
* dbs |
is plugging away |
| 11:53 |
|
zxiiro joined #evergreen |
| 11:54 |
|
dMiller_ joined #evergreen |
| 11:57 |
dbs |
or... just use NFD() and throw away decode_utf8() entirely. hmm |
| 11:58 |
gmcharlt |
dbs: noted -- happy to look at patches when you've finished plugging away |
| 11:59 |
dbs |
gmcharlt: I have something that at least makes --load-all work :) |
| 12:00 |
* gmcharlt |
sets up to do a (pg)TAP dance |
| 12:01 |
|
smyers_ joined #evergreen |
| 12:06 |
dbs |
working/user/dbs/encode-changed-behaviour - as of yet untested on anything other than Encode 2.54 on Fedora, so definitely experimental |
| 12:12 |
|
dMiller__ joined #evergreen |
| 12:22 |
* csharp |
plans to test Opensrf 2.2.1 as soon as he can come up for air on another project |
| 12:50 |
|
Sato`kun joined #evergreen |
| 13:11 |
|
smyers__ joined #evergreen |
| 13:19 |
|
dMiller_ joined #evergreen |
| 13:28 |
|
dMiller__ joined #evergreen |
| 13:44 |
|
RoganH joined #evergreen |
| 14:01 |
|
AaronZ-PLS joined #evergreen |
| 14:06 |
|
smyers_ joined #evergreen |
| 14:22 |
|
tsbere joined #evergreen |
| 14:31 |
bshum |
dbs: Yes! GSoC was quite interesting. Just wish I had more time to see/do everything. |
| 14:35 |
bshum |
Now for the fun part. Getting home and getting reacquainted with east coast time. |
| 14:37 |
jcamins |
bshum: my fingers are crossed for you, that you have as smooth a security experience as I did. |
| 14:38 |
jcamins |
I just walked straight through to the gate, basically. |
| 14:38 |
jcamins |
I didn't even have time to untie my shoelaces before they were ready to x-ray my shoes. |
| 14:39 |
bshum |
Oh I'm through security and all that. Waiting quietly in the lounge for my flight to board sometime in the next 20 minutes. |
| 14:40 |
* jcamins |
has an hour and a half before boarding. |
| 14:40 |
jcamins |
I really thought that it would take longer. |
| 14:41 |
bshum |
The part that drives me nuts was the stupid tram |
| 14:42 |
jcamins |
I've never spent any time in LAX. |
| 14:43 |
bshum |
I got stuck in LAX once for an extra night due to delays. |
| 14:43 |
bshum |
Fortunately this is SFO? |
| 14:45 |
jcamins |
Oh, right. San Francisco, Los Angeles... they're both cities in California. |
| 14:48 |
bshum |
Heh |
| 14:48 |
* bshum |
is going to go try finding some real food. Looks like my flight home stops in Denver but I won't actually get out... |
| 14:49 |
bshum |
jcamins: Safe flight home for you too. |
| 14:49 |
jcamins |
Thanks. Safe travels. |
| 14:54 |
|
fparks joined #evergreen |
| 14:54 |
|
sseng joined #evergreen |
| 14:54 |
|
ktomita_ joined #evergreen |
| 14:54 |
|
smyers_ joined #evergreen |
| 15:04 |
|
sseng joined #evergreen |
| 15:04 |
|
ktomita joined #evergreen |
| 15:05 |
|
smyers_ joined #evergreen |
| 15:05 |
|
fparks joined #evergreen |
| 15:11 |
Bmagic |
I am new to evergreen. I encountered something that probably has a quick answer.... Scoping. We have 13 libraries on our system and searches in the opac return bibs correctly however, when searching in the staff client for the same material with the same scope, the results are from all entities. Where is this setting? |
| 15:11 |
|
sseng joined #evergreen |
| 15:11 |
|
ktomita joined #evergreen |
| 15:11 |
|
fparks joined #evergreen |
| 15:11 |
|
smyers_ joined #evergreen |
| 15:15 |
|
gsams joined #evergreen |
| 15:18 |
phasefx |
Bmagic: you may be seeing "empty" bibs with no holdings |
| 15:18 |
Bmagic |
yes |
| 15:18 |
phasefx |
no setting to control that, though the Limit to Available checkbox should still be available |
| 15:19 |
Bmagic |
phasefx: ah, I appreciate the info! |
| 15:19 |
phasefx |
happy to help |
| 15:20 |
jeff |
i sometimes wonder if there's enough support for a change in that behavior -- hide no-item bibs by default, and catalogers can turn it off so they see the empty bibs (since presumably that's the intended target audience for those bibs?) |
| 15:20 |
kmlussier |
jeff: I would support that change. |
| 15:21 |
jeff |
i've not looked to see how deeply that particular rabbithole goes. |
| 15:21 |
jeff |
s/deeply/deep/ |
| 15:22 |
|
dMiller_ joined #evergreen |
| 15:23 |
mmorgan1 |
jeff: We at NOBLE would definitely support that change! We get many questions about empty bib records that show up in library scopes. |
| 15:24 |
Dyrcona |
jeff: What about a workstation setting to auto-check the limit to available box? |
| 15:24 |
phasefx |
it's a .staff variant of the search method. Just an if-statement and YAOUS away from simply using the non-staff version |
| 15:24 |
phasefx |
or, at least it was in the jspac |
| 15:24 |
jeff |
Dyrcona: limit to available isn't the same thing as "don't show me empty things", though. |
| 15:25 |
jeff |
Dyrcona: but that would be the idea, either a user pref or a workstation pref to say "show me the empty bibs, too!" |
| 15:25 |
jeff |
of course, I also wonder what workflows lead to lots of empty bibs... |
| 15:25 |
kmlussier |
A user or workstation pref would be good, but I think it would also be nice to have a readily-accessible toggle to switch the behavior. |
| 15:25 |
jeff |
i know we have had lots of empty bibs at various points due to migrations in and out. |
| 15:25 |
gsams |
jeff: NTLC supports that change, though I haven't seen an empty bib outside of cataloging in a while. |
| 15:28 |
|
dconnor joined #evergreen |
| 15:28 |
|
smyers__ joined #evergreen |
| 15:28 |
|
sseng_ joined #evergreen |
| 15:29 |
|
fparks_ joined #evergreen |
| 15:29 |
|
ktomita_ joined #evergreen |
| 15:48 |
gsams |
Is it possible to put permission groups in a particular order within the dropdown box for editing and creating patrons? |
| 15:51 |
|
fparks joined #evergreen |
| 15:52 |
|
dconnor joined #evergreen |
| 15:52 |
|
ktomita joined #evergreen |
| 15:53 |
|
sseng joined #evergreen |
| 15:54 |
mmorgan1 |
gsams: don't have an answer, but have wondered the same thing... |
| 15:55 |
gsams |
mmorgan1: I'm glad I'm not the only one! I'd really like to reorder the list for my account at the very least, but the current list for just patrons is in an odd order |
| 15:56 |
gsams |
I'd say it's actually in the opposite order I'd prefer |
| 15:59 |
mmorgan1 |
Our is in an odd order, too, and I think it changed when an attribute of one of the groups was changed. |
| 16:00 |
|
dMiller__ joined #evergreen |
| 16:01 |
Dyrcona |
It's not an odd order. It's the order that the data appears in the database table's file, which is also why it would change if you edit one of the groups. |
| 16:01 |
mmorgan1 |
suspected as much :( |
| 16:02 |
Dyrcona |
It could probably be sorted when it is retrieved, though. |
| 16:04 |
mmorgan1 |
Imposing an order would be a good start. Especially if it's apt to change if a group is edited. |
| 16:04 |
gsams |
ah, I see that now |
| 16:05 |
mmorgan1 |
The ability to limit the displayed groups per library would also be useful. |
| 16:06 |
gsams |
mmorgan1: I can't argue with that addition myself. At least I can get creative and make this work a bit better for everyone. |
| 16:06 |
gsams |
Dyrcona++ |
| 16:06 |
gsams |
Thanks for pointing that out! |
| 16:07 |
Dyrcona |
I'll also point out Launchpad where you could open a wishlist bug to request the feature. |
| 16:07 |
Dyrcona |
That doesn't mean it will happen, but.... |
| 16:07 |
|
smyers_ joined #evergreen |
| 16:07 |
gsams |
never hurts to try |
| 16:44 |
mmorgan1 |
gsams++ lp1242877 |
| 16:44 |
mmorgan1 |
lp 1242877 |
| 16:44 |
pinesol_green |
Launchpad bug 1242877 in Evergreen "Permission Group Drop Down lacks imposed order" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1242877 |
| 16:46 |
gsams |
I'm relatively new to reporting bugs and launchpad in general. I figure someone of more authority can label it as wishlist? |
| 16:47 |
kmlussier |
gsams: Done! :) |
| 16:47 |
gsams |
kmlussier: Thanks! |
| 16:48 |
eeevil |
mmorgan1: for your second part, limiting by library, you can already limit by permission per user. it's not the same, certainly, but similar |
| 16:50 |
Dyrcona |
kmlussier: If you'd like to review lp103167, it is on my development server. |
| 16:51 |
* Dyrcona |
has lost the magic. |
| 16:51 |
kmlussier |
Dyrcona: That brings me to an Ubuntu bug? |
| 16:52 |
Dyrcona |
Of course it does... |
| 16:52 |
mmorgan1 |
eeevil: Yes, we do some of that. But in a given library, staff have permission to edit patrons in a number of permission groups, but they would never register a patron with those groups. |
| 16:52 |
Dyrcona |
lp 1031067 |
| 16:52 |
pinesol_green |
Launchpad bug 1031067 in Evergreen 2.5 "Mark Claims Never Checked Out gives Useless Dialog" (affected: 2, heat: 12) [Undecided,Confirmed] https://launchpad.net/bugs/1031067 |
| 16:52 |
kmlussier |
Dyrcona++ |
| 16:52 |
* Dyrcona |
drinks potion of mana. |
| 16:53 |
kmlussier |
Dyrcona: Is that how you spent your vacation? Drinking potion of mana? |
| 16:53 |
Dyrcona |
I wish. |
| 16:54 |
|
smyers_ joined #evergreen |
| 16:54 |
eeevil |
mmorgan1: ah, I see. thanks for clarifying |
| 16:55 |
mmorgan1 |
eeevil: Thanks for the suggestion, though! :) |
| 16:56 |
* eeevil |
is always happy to supply redundant info |
| 16:56 |
eeevil |
:) |
| 17:05 |
|
mmorgan1 left #evergreen |
| 17:06 |
|
mrpeters left #evergreen |
| 17:23 |
|
stevenyvr2 joined #evergreen |
| 17:23 |
|
moodaepo_nb joined #evergreen |
| 17:36 |
|
dMiller joined #evergreen |
| 17:53 |
|
moodaepo_nb joined #evergreen |
| 17:58 |
|
smyers_ joined #evergreen |
| 17:58 |
|
dMiller_ joined #evergreen |
| 18:54 |
|
dMiller joined #evergreen |
| 19:15 |
|
dMiller joined #evergreen |
