| Time |
Nick |
Message |
| 01:35 |
|
serflog joined #evergreen |
| 01:35 |
|
Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged: http://irc.evergreen-ils.org/evergreen | Large pastes at http://paste.evergreen-ils.org |
| 06:40 |
|
rlefaive joined #evergreen |
| 07:08 |
|
agoben joined #evergreen |
| 07:15 |
|
rjackson_isl joined #evergreen |
| 07:29 |
|
JBoyer joined #evergreen |
| 07:54 |
csharp |
@nick pinesol_green |
| 08:11 |
|
jeff___ joined #evergreen |
| 08:13 |
rhamby |
morning #evergreen |
| 08:35 |
* dbs |
waves |
| 08:38 |
|
mmorgan joined #evergreen |
| 08:42 |
|
krvmga joined #evergreen |
| 08:49 |
|
kmlussier joined #evergreen |
| 08:49 |
|
Dyrcona joined #evergreen |
| 09:02 |
kmlussier |
rhamby: Good morning! |
| 09:03 |
|
Callender joined #evergreen |
| 09:22 |
|
yboston joined #evergreen |
| 09:29 |
kmlussier |
This will be a non-issue in the web client, but I've always wished that the XUL client had a way to copy the URL that appears when you hover over the Debug button while using the staff client catalog. |
| 09:30 |
kmlussier |
I think it would help troubleshoot problems like the one in the Polar Express thread on the list. |
| 09:30 |
csharp |
kmlussier: rather than having to click on Debug and select "Modify URL", you mean? |
| 09:31 |
kmlussier |
Ha! I was clicking it so quickly, I missed that option. I was just getting the View Source. |
| 09:31 |
kmlussier |
csharp++ |
| 09:31 |
csharp |
:-) |
| 09:31 |
csharp |
it's a little tricky, so I was assuming your comment was about that |
| 09:31 |
* kmlussier |
sends a new message to the list. |
| 09:45 |
dbwells |
Perhaps an easy question: what is the simplest way for staff to change their own password? |
| 09:47 |
jeff |
by logging into the public catalog and changing it there. |
| 09:49 |
dbwells |
Was afraid of that. We have password modification diabled in the OPAC since we use LDAP auth, but not for staff accounts. Guess we need a more refined solution. |
| 09:53 |
* csharp |
gets tired of typing the same thing over and over so creates script to do his coding for him |
| 10:14 |
Dyrcona |
Crazy: I have an entry in osrfsyslog for a SIP2 patron information response, but I can't find the corresponding message in the SIP server's logs. The osrfsyslog even includes which SIP server the response came from. |
| 10:23 |
|
sandbergja joined #evergreen |
| 10:28 |
|
jvwoolf joined #evergreen |
| 10:29 |
dbs |
dbwells: we do the same, fwiw |
| 10:34 |
Dyrcona |
There isn't a cron job required to send reports emails is there? |
| 10:34 |
Dyrcona |
I mean the emails that say your recurring report is ready. |
| 10:36 |
dbs |
Dyrcona: clark-kent.pl uses Email::Send directly, so I think not |
| 10:36 |
Dyrcona |
dbs: Thanks! That is what I thought, but I'm not having the best of luck this morning, so thought it was worth asking. |
| 10:37 |
dbs |
so maybe it's just not getting relayed (via email_notify -> smtp_server) from the config? |
| 10:37 |
dbs |
I hate those kinds of mornings |
| 10:41 |
Dyrcona |
dbs: Yeah, I think it might not be getting relayed properly, we recently changed the email configuration on the server that does this. Notices are working, and they come from the same server. |
| 10:42 |
Dyrcona |
I'm having trouble finding anything in the logs, though, and I've not been given an actual email address, yet. |
| 10:43 |
dbs |
that makes it tough! |
| 10:44 |
krvmga |
since no one mentioned it, launchpad is down atm due to network switch problems. |
| 10:44 |
|
remingtron joined #evergreen |
| 10:45 |
krvmga |
https://twitter.com/launchpadstatus |
| 10:48 |
Dyrcona |
Well, I'm given two email addresses and I don't find any reports emails going to those addresses, though 1 has two notice emails. |
| 10:48 |
mmorgan |
Boo. I was going to look for bugs to squash :-( |
| 10:50 |
mmorgan |
Dyrcona: Maybe email was not chosen for the specific reports? The email address should be in reporter.schedule.email for the specific report instance. |
| 10:50 |
Dyrcona |
mmorgan: Thanks, I was about to ask if reporter.schedule.email would be the right place to look. :) |
| 10:51 |
Dyrcona |
mmorgan++ #psychic powers. :) |
| 10:51 |
dbs |
Dyrcona: note that clark still appears to pull settings from email_notify/smtp_server whereas other processes pull from notifications/smtp_server - just in case those are different in your opensrf.xml |
| 10:52 |
Dyrcona |
dbs: Duly noted, thanks. The former settings look OK, but I'll check again. |
| 10:52 |
kmlussier |
krvmga: Yeah, I've been having trouble accessing LP for about a half hour now. |
| 10:53 |
kmlussier |
Launchpad should know better than to go down on the day Sandbox request deadline day. ;) |
| 10:57 |
Dyrcona |
So, no emails in the logs for the time that the one user's last reports ran, and notices and reports are configured the same. :( |
| 10:58 |
Dyrcona |
And, nothing stuck in the queue. |
| 11:06 |
Dyrcona |
Fun. Nothing but syslog saying it lost/dropped messages. |
| 11:12 |
csharp |
Dyrcona: does your report pull its config from a server that may not have the new smtp setting? (just asking since we used to have the reports server pull opensrf config from a utility box) |
| 11:12 |
csharp |
s/report/reports server/ |
| 11:13 |
Dyrcona |
csharp: That's a possibility. I'll make sure. |
| 11:13 |
Dyrcona |
I just assumed.... ;) |
| 11:15 |
Dyrcona |
So, routers are set to that machine and opensrf.settings is running there. I assume that means it gets the settings from itself. |
| 11:15 |
* Dyrcona |
double checks nfs. |
| 11:16 |
csharp |
right - that's how ours is now - we have a full opensrf stack running on our reporter so it doesn't depend on another machine for settings |
| 11:17 |
Dyrcona |
No NFS mounts locally. I think the others actually mount some directories from this one. |
| 11:18 |
StomproJ |
Good morning, can someone explain what the "FULFILL" block in standing penalties does? Blocks a checkout from fulfilling a hold? Does that mean a user can still check out, but it keeps the checkout from marking the hold as fulfilled? |
| 11:18 |
Dyrcona |
If I changed the configuration, would I need to restart clark-kent? I wonder if I did that? |
| 11:18 |
* Dyrcona |
gives that a shot. |
| 11:19 |
|
jeffdavis joined #evergreen |
| 11:19 |
* jeff |
blinks |
| 11:19 |
jeff |
is jeffdavis clark-kent.pl? |
| 11:20 |
jeffdavis |
I admit nothing! |
| 11:20 |
csharp |
@blame jeffdavis's glasses for making jeff think he's clark_kent.pl |
| 11:20 |
pinesol_green |
csharp: It's all jeffdavis's glasses's fault! for making jeff think he's clark_kent.pl |
| 11:21 |
jeff |
of course, jeffdavis is probably the only one here who didn't see jeffdavis part/join immediately after Dyrcona said he was restarting clark-kent. :-) |
| 11:21 |
csharp |
Dyrcona: yeah, you |
| 11:21 |
csharp |
'd need to restart clark to have it re-read the config |
| 11:21 |
berick |
StomproJ: it would prevent the checkout. |
| 11:21 |
Dyrcona |
Hey, you! -- Who, me? --- Yeaaahhh, Yoouuu! |
| 11:22 |
csharp |
:-) |
| 11:22 |
Dyrcona |
Oh, 'scuse me. I thought you were somebody else. |
| 11:22 |
kmlussier |
StomproJ: There's also a bit of discussion on this at http://markmail.org/message/6cnjtjmjsugzqkyc |
| 11:24 |
berick |
hm, git.evergreen-ils.org having issues? |
| 11:25 |
csharp |
berick: I'm able to load gitweb |
| 11:25 |
jeff |
berick: i was just able to fetch from it. |
| 11:25 |
berick |
interesting |
| 11:25 |
berick |
thanks guys |
| 11:25 |
berick |
unusably slow here. |
| 11:26 |
* berick |
tries some other sites |
| 11:27 |
dbs |
Dyrcona: I think you might need to restart the whole opensrf stack, since the settings in opensrf.xml get cached by opensrf.settings |
| 11:27 |
StomproJ |
kmlussier++ thanks. |
| 11:27 |
Dyrcona |
dbs++ csharp++ |
| 11:27 |
berick |
Dyrcona: dbs: or --restart --service opensrf.settings |
| 11:27 |
dbs |
(and if you're really paranoid, restart memcached too, can't remember if opensrf.settings forces cached keys to get cleared or not) |
| 11:28 |
|
phasefx joined #evergreen |
| 11:28 |
Dyrcona |
dbs: yeah, I'm pretty sure that I restarted the services, at least opensrf.settings. |
| 11:28 |
Dyrcona |
Looks Clark was running since July, so I just restarted it. We'll see if that fixes it. |
| 11:28 |
berick |
anything I fetch from the ATL area is slow. (also tried esi site). other stuff is fine. oh well. |
| 11:29 |
jeff |
maybe another Zayo fiber cut. backhoes travel in packs down south, i hear. |
| 11:31 |
|
jihpringle joined #evergreen |
| 11:31 |
dbs |
Wow, since July! nice |
| 11:32 |
berick |
jeff: beware the alpha backhoe |
| 11:34 |
* mmorgan |
read that as "blackhole" which sounded oddly plausible ;-) |
| 11:35 |
berick |
mmorgan: totally :) |
| 11:43 |
csharp |
berick: ATL is building an ITP/OTP wall to keep outsiders away, it may affect your internet performance :-P |
| 11:43 |
berick |
csharp: since LP is down, I'll mention it here. looking at code for bug #1627373 to see what it does, i see: my @array = [ stuff ]; i'm guessing you want my @array = ( stuff ); instead. |
| 11:43 |
berick |
csharp: oh, and lemme guess, I'm paying for it |
| 11:43 |
csharp |
berick: exactly |
| 11:43 |
csharp |
berick: thanks for the perl tip |
| 11:43 |
pinesol_green |
berick: Error: Could not gather data from Launchpad for bug #1627373 (https://launchpad.net/bugs/1627373). The error has been logged |
| 11:44 |
csharp |
berick: I'm actually creating an alternate working branch that adds tables of all order and availability status codes so we can map them per provider (rather than my hack-y bandaid for a single vendor) |
| 11:45 |
berick |
csharp++ |
| 11:45 |
* Dyrcona |
thinks certain email from the servers is going to a blackhole. |
| 11:45 |
|
drigeny joined #evergreen |
| 11:45 |
berick |
Dyrcona: a backhoe blackhole? |
| 11:46 |
csharp |
now we need a @band plugin so I can add Backhoe Blackhole to the list |
| 11:46 |
Dyrcona |
:) |
| 11:46 |
berick |
csharp: yes! one of my favorite plugins |
| 11:46 |
Dyrcona |
Blackhole Backhoe |
| 11:47 |
Dyrcona |
Well, google says that the message was accepted for delivery, but it is not showing up, and I checked Google Groups because this list is a Group. |
| 11:48 |
* Dyrcona |
is not in charge of the Gmail setup. |
| 11:48 |
jeff |
the group admin/moderator may want to check the spam / moderation queue for the list. |
| 11:49 |
jeff |
once you enter into Google Groups land, the number of things that may be preventing you from seeing the mail... increases. |
| 11:49 |
Dyrcona |
Thanks, jeff. |
| 11:50 |
csharp |
since we added proper SPF records to our DNS, most of the "I never received my notification" complaints have dissipated |
| 11:50 |
|
dbwells joined #evergreen |
| 11:51 |
Dyrcona |
SPF is good. |
| 11:51 |
Dyrcona |
I don't think this is a SPF issue. |
| 11:58 |
kmlussier |
LP appears to be up again. |
| 12:02 |
csharp |
hooray! |
| 12:05 |
|
brahmina joined #evergreen |
| 12:06 |
berick |
who wants to get EG running here? http://bellard.org/jslinux/ |
| 12:08 |
Dyrcona |
Good luck with that. :) |
| 12:09 |
* csharp |
quickly adds jslinux targets to makefiles |
| 12:09 |
csharp |
wget and make are installed, so we should be good :-) |
| 12:09 |
phasefx |
vim # <- Your new ILS; has search feature |
| 12:09 |
berick |
and gcc |
| 12:10 |
berick |
what we don't have, we can build |
| 12:10 |
Dyrcona |
VFS: mounting root filesystem readonly |
| 12:12 |
berick |
much fun to be had http://copy.sh/v86/ |
| 12:31 |
csharp |
berick: my more complete solution to bug 1627373 is going to need some discussion because it may result in rearchitecting the way we handle ORDRSP messages in general |
| 12:31 |
pinesol_green |
Launchpad bug 1627373 in Evergreen "Acq: We need to fully implement EDI availability codes" [Wishlist,New] https://launchpad.net/bugs/1627373 |
| 12:31 |
csharp |
my working branch is here: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/csharp/lp1627373_edi_status_codes_db |
| 12:32 |
csharp |
I haven't added it to the bug report because I didn't want it to be confusing (and it's very incomplete) |
| 12:32 |
csharp |
incomplete = I haven't touched the perl layer because that's where it's starting to get hairy ;-) |
| 12:55 |
kmlussier |
Is the 2.11.0 release official now? If so, is there any way I can help to get the word out to the community? |
| 13:02 |
* dbs |
needs to merge some updates for installing on Ubuntu 14.04 at some point |
| 13:05 |
Ilie` |
:-D |
| 13:05 |
Ilie` |
hello hello |
| 13:12 |
kmlussier |
Ilie`: hello |
| 13:13 |
Ilie` |
what's going on ? |
| 13:42 |
Dyrcona |
So, upgrading SIPServer should be as simple as stopping it, doing git pull, and restarting it, no? |
| 13:44 |
csharp |
Dyrcona: looks like it |
| 13:45 |
Dyrcona |
Ah, so, one of the sip servers is logging to a different log.... :) |
| 13:45 |
Dyrcona |
csharp: As I've said, I'm having one of those days where all the little weirdness is getting to me. :) |
| 13:45 |
csharp |
yep |
| 13:45 |
csharp |
@who has a case of the Mondays? |
| 13:45 |
pinesol_green |
jeffdavis has a case of the Mondays. |
| 13:46 |
dbs |
That's assuming that nothing surprising changed in SIPServer in between your current version and new version :) |
| 13:46 |
Dyrcona |
I guess I shouldn't expect it to get flooded with requests if I disabled it in the ldirectord and then re-enabled it. |
| 13:47 |
Dyrcona |
dbs: I don't think anything requires a configuration change... There are some new options, IIRC, but an old configuration should still work. |
| 13:47 |
* dbs |
squints at http://irc.evergreen-ils.org/evergreen/2016-09-23#i_269077 |
| 13:47 |
dbs |
which is probably more reflective of a supercat / unAPI change than a SIPServer change, but still |
| 13:49 |
Dyrcona |
Yeah, and it would produce corrupted data, not prevent SIP from working at all. |
| 13:49 |
Dyrcona |
I'm just being overly paranoid today. |
| 13:49 |
Dyrcona |
It must be working, the number of running daemons changes from time to time... ;) |
| 13:52 |
Dyrcona |
A distinct lack of log messages is bothering me. |
| 13:53 |
Dyrcona |
hmm. login failed is all I can find. |
| 13:55 |
Dyrcona |
Ah. Maybe its the location code changes. I'm resetting to the commit prior to that to see if it helps. |
| 14:01 |
Dyrcona |
Ah ha! |
| 14:02 |
Dyrcona |
I think I found my culprit, and I think it is a code/config mismatch. |
| 14:02 |
|
brahmina joined #evergreen |
| 14:02 |
jeff |
Dyrcona: interested in details, especially if it's something we could be more tolerant of. |
| 14:03 |
Dyrcona |
I think 69fd4653d871a26c1ea532cacf762ac81ddeeb5c was causing me issues. |
| 14:03 |
pinesol_green |
Dyrcona: [sipserver|Jason Boyer] LP1579144: On Login, Send Location to ILS - <http://git.evergreen-ils.org/?p=SIPServer.git;a=commit;h=69fd465> |
| 14:03 |
Dyrcona |
I reset to that commit and it still didn't work. |
| 14:03 |
Dyrcona |
I reset to the commit before and suddenly things were working. |
| 14:04 |
Dyrcona |
I'll look into what I need to do to get past that commit, later. ;) |
| 14:04 |
Dyrcona |
I wouldn't be surprised if permissions come into this. :) |
| 14:05 |
|
kmlussier joined #evergreen |
| 14:06 |
Dyrcona |
berick: I think you sent that backhoe up this way. My connection to the servers feels laggy. :) |
| 14:08 |
dbs |
Dyrcona: it prevents our Bibliotheca sip clients from working because it produces corrupted data |
| 14:08 |
dbs |
They reach the unexpected CTRL character in the SIP response and barf |
| 14:09 |
Dyrcona |
dbs: Yes. I've seen something similar happen with other clients. |
| 14:10 |
Dyrcona |
I was concerned that all I saw was login failed. I can worry about the other later. |
| 14:10 |
dbs |
oh yeah, definitely! |
| 14:13 |
Dyrcona |
Doesn't help that the machines I am updating have git checkouts from different remotes and manually applied patches that mostly look like they bring them up to a certain git revision. |
| 14:15 |
berick |
Dyrcona: oh no, they're migrating |
| 14:15 |
* berick |
ponders the average land speed of an unladen backhoe |
| 14:17 |
Dyrcona |
:) |
| 14:39 |
|
kmlussier joined #evergreen |
| 14:50 |
Dyrcona |
And, to followup with this mornings' big issue: Reports emails are indeed being sent now. Restarting Clark did the trick. I kind of thought I should at the time, but guess that got lost in everything else. |
| 14:53 |
csharp |
7c995398 |
| 14:53 |
pinesol_green |
csharp: [evergreen|Josh Stompro] LP#1550495 - Add EDI Cancel Code 85 - used by Baker & Taylor - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7c99539> |
| 14:54 |
csharp |
bug 1550495 |
| 14:54 |
pinesol_green |
Launchpad bug 1550495 in Evergreen 2.9 "EDI Default Cancel Reason for Baker & Taylor not included: Code 85" [Medium,Fix released] https://launchpad.net/bugs/1550495 |
| 15:03 |
|
mmorgan1 joined #evergreen |
| 15:20 |
Dyrcona |
So, I get a report that "sip is down" but it doesn't look down. |
| 15:21 |
Dyrcona |
And, I've noticed that although I did not change logging or the configuration, the sip servers are logging to a different file on the syslogger than they were before I restarted them. |
| 15:23 |
berick |
Dyrcona: that could be related to bug #1473479 |
| 15:23 |
pinesol_green |
Launchpad bug 1473479 in OpenSRF "Mixing syslog configs leads to logging chaos" [Wishlist,Confirmed] https://launchpad.net/bugs/1473479 |
| 15:50 |
JBoyer |
Dyrcona, What kind of problems were you seeing with 69fd4653d871a26c1ea532cacf762ac81ddeeb5c applied? :( If you're running a new enough version of Evergreen there will need to be workstation entries for any values sent in the 93 message CN field. (or CP, I forget at the moment.) |
| 15:50 |
pinesol_green |
JBoyer: [sipserver|Jason Boyer] LP1579144: On Login, Send Location to ILS - <http://git.evergreen-ils.org/?p=SIPServer.git;a=commit;h=69fd465> |
| 16:01 |
Dyrcona |
JBoyer: I believe it is the lack of workstation entries. This "update" was an almost spur of the moment thing, prompted by some performance complaints last week. |
| 16:02 |
Dyrcona |
We're also seeing fewing SIPServer processes running. I don't know if that is because of the mid-day restart or if the mux code has actually taken effect. |
| 16:03 |
JBoyer |
I wouldn't think those fields are filled in on most self checks, but that will cause a problem if it's being sent but one doesn't exist. :/ |
| 16:04 |
Dyrcona |
I don't think I've ever had a Monday that was quite so Monday as today. |
| 16:05 |
Dyrcona |
I'm not ever sure it is "Monday," just everything seem weird and kind of off. |
| 16:06 |
JBoyer |
Dyrcona, also, what version of Eg are you running now? There was talk about adding some changes on the Eg side to avoid that. |
| 16:06 |
Dyrcona |
I believe we're on 2.9.5. |
| 16:07 |
Dyrcona |
Upgrading to 2.10.7 next month. |
| 16:08 |
|
mmorgan joined #evergreen |
| 16:09 |
Dyrcona |
Would the mux code make a 90% difference in the number of processes running? |
| 16:12 |
Dyrcona |
All right. We're using Prefork because we haven't set personality. |
| 16:12 |
* Dyrcona |
is surprised that the phone is not ringing off the hook. |
| 16:15 |
JBoyer |
Dyrcona, this will let you use the most recent SIPServer code, there's a config change to turn off the login workstation code. |
| 16:15 |
JBoyer |
super ugly url: http://git.evergreen-ils.org/?p=SIPServer.git;a=blobdiff;f=SIPconfig.xml;h=180f4d4200aff984a1afa803d11911821d6d247b;hp=6ba05a201f840fbf0f9d90de8c9bd1a69fa33cb1;hb=133bf03274eceaac4950e62f8f66c6c077474fbb;hpb=8404478ec651a57eab8c39274925d64b79a6dda6 |
| 16:15 |
pinesol_green |
JBoyer: [sipserver|Mike Rylander] LP1579144: Let admin decide on the precedence of the location codes per institution - <http://git.evergreen-ils.org/?p=SIPServer.git;a=commit;h=133bf03> |
| 16:15 |
pinesol_green |
JBoyer: [sipserver|Mike Rylander] LP1579144: On Login, Send Location to ILS - <http://git.evergreen-ils.org/?p=SIPServer.git;a=commit;h=8404478> |
| 16:16 |
JBoyer |
short version: add client_location_code="false" to the attributes of the <policy> entry for your institution. |
| 16:18 |
csharp |
Dyrcona: we saw a huge drop in the number of sipserver processes after moving to multiplex, but it sounds like that's not relevant to your situation |
| 16:18 |
JBoyer |
(Ideally when most places don't need it...) |
| 16:21 |
Dyrcona |
JBoyer: Thanks. I'll discuss that with the other folks here and see what they think. If we're still having "issues" tomorrow, we might just go with that. |
| 16:22 |
Dyrcona |
It should be pretty easy to add. |
| 16:22 |
JBoyer |
I'm not sure why it would be necessary though, if you don't have a value at all I think it should still be false. :/ (I haven't had a chance to test that change myself.) |
| 16:23 |
Dyrcona |
Well, I haven't looked into it much. I just know that resetting to prior to that commit "fixed" it. :) |
| 16:24 |
Dyrcona |
I only have 53 policy tags each for four oils_sip.xmls on as many servers... |
| 16:24 |
Dyrcona |
Nothing that cssh and sed can't handle. :) |
| 16:28 |
* Dyrcona |
shakes his fist at the wireless... |
| 16:30 |
Dyrcona |
Or, no. Maybe I just lost my connection to the colocation facility? |
| 16:32 |
Dyrcona |
Man, ssh is flaking out on me, too. Maybe I should call it a day? |
| 16:33 |
kmlussier |
Dyrcona: Technology is sending you a message. |
| 16:33 |
kmlussier |
@swill Dyrcona |
| 16:33 |
* pinesol_green |
grabs a bottle of Extra Dry Champale and sends it sliding down the bar to Dyrcona |
| 16:34 |
mmorgan |
another bad technology day :-( |
| 16:35 |
Dyrcona |
Champale....I has been ages since I've even heard the name, and I'm not sure that I've ever had any... |
| 16:36 |
kmlussier |
This is the first I've heard of it. I see it's from Pabst Brewing Company. I didn't know Pabst still was a thing. |
| 16:46 |
Dyrcona |
Pabst brews Tsingtao? I did not know that. |
| 16:51 |
|
jvwoolf left #evergreen |
| 16:52 |
Dyrcona |
Ah, so the complaint about SIP not working has to do with timeouts from an idle client. |
| 16:54 |
|
afterl joined #evergreen |
| 16:54 |
Dyrcona |
It looks like we can bypass that by setting timeout to 0. |
| 16:55 |
|
afterl left #evergreen |
| 17:01 |
Dyrcona |
I am not sure if the timeout set in the policy of the Institution gets used. More digging tomorrow. |
| 17:15 |
|
mmorgan left #evergreen |
