| Time |
Nick |
Message |
| 01:08 |
|
Mark__T joined #evergreen |
| 07:29 |
|
graced joined #evergreen |
| 07:45 |
|
ericar joined #evergreen |
| 07:59 |
|
rjackson_isl joined #evergreen |
| 08:01 |
|
_bott_ joined #evergreen |
| 08:10 |
|
mrpeters joined #evergreen |
| 08:13 |
|
jboyer-isl joined #evergreen |
| 08:41 |
csharp |
hmm - looks like the PO HTML action trigger event is timing out when processing a large (317-item) PO - anyone else see this kind of thing? |
| 08:43 |
|
collum joined #evergreen |
| 08:45 |
bshum |
csharp: I've never had anything time out on our system. Though I'm working up a query to find out if people ever make orders that big :) |
| 08:48 |
|
Dyrcona joined #evergreen |
| 08:49 |
|
Stompro joined #evergreen |
| 08:50 |
bshum |
Okay, so we've had orders before where the number of lineitems exceeded 300+ (one as many as 809 apparently) |
| 08:51 |
bshum |
csharp: Are you using a/t granularity to split your events into multiple run processes? |
| 08:51 |
bshum |
i.e. is acq run on its own, or alongside all the rest of the other a/t events? |
| 08:52 |
bshum |
And also, did you mean PO JEDI? |
| 08:57 |
Bmagic |
jeff: I tried this morning in hopes that the cache would expire. Still nothing in the log about lc.gif |
| 08:58 |
|
ericar_ joined #evergreen |
| 09:01 |
|
abowling1 joined #evergreen |
| 09:02 |
|
abowling1 left #evergreen |
| 09:04 |
csharp |
bshum: not using a/t granularity for that at this point, but this is also on a test server, so no real competition for resources |
| 09:05 |
csharp |
bshum: I do mean PO HTML (printing the PO) |
| 09:05 |
csharp |
log is here http://pastebin.com/NzzJfkTF |
| 09:05 |
csharp |
the error messages indicate that there is no active DB transaction |
| 09:08 |
* bshum |
contemplates this and why his system doesn't seem to have a PO HTML at all. |
| 09:08 |
csharp |
hmm - do your acq people print POs? |
| 09:09 |
bshum |
Oh wait there it is |
| 09:09 |
bshum |
Way up high |
| 09:09 |
csharp |
what I think is happening is that the UI times out before the DB is done with all the necessary queries |
| 09:10 |
bshum |
I'm not sure if they print the POs. I'd have to ask mllewellyn what their usage is like. |
| 09:10 |
bshum |
Or I could check for any A/T events with the ID. |
| 09:10 |
bshum |
And see how they've fared |
| 09:10 |
bshum |
Well one happened as recent as 2015-09-23 |
| 09:11 |
bshum |
So I guess people do it from time to time, rarely |
| 09:12 |
|
krvmga joined #evergreen |
| 09:13 |
jeff |
Bmagic: well, lc.gif would be the "large cover". |
| 09:13 |
Bmagic |
right |
| 09:13 |
jeff |
but sc/mc/lc all load for me in a browser. |
| 09:13 |
jeff |
hrm. |
| 09:14 |
Bmagic |
I am starting to think that the code isn't attempting to query Syndetics for this title for some reason |
| 09:15 |
Bmagic |
I think I am going to introduce some more logging lines in the code for some additional diagnosis |
| 09:15 |
jeff |
oh. |
| 09:16 |
jeff |
https://missourievergreen.org/opac/extras/ac/jacket/large/r/1177127 loads just fine. I suspect that the templates are skipping the loading of that image because of something like lack of isbn and upc. |
| 09:16 |
* bshum |
hopes that the 2.9 cache clear for added content works better than the mess you're jumping through :) |
| 09:17 |
jeff |
bshum: completely unrelated. :-) |
| 09:17 |
bshum |
:( |
| 09:17 |
jeff |
Bmagic: so, check your templates. If the issue is present in stock, it's probably my fault. :-) |
| 09:17 |
Bmagic |
oh! |
| 09:17 |
jeff |
I think ISSN support was added right on the cusp between JSPAC and TPAC. |
| 09:18 |
Bmagic |
jeff++ nice catch |
| 09:19 |
* tsbere |
was just noting the lack of an img tag for the jacket |
| 09:19 |
Bmagic |
ident = attrs.isbn_clean || attrs.upc; IF ident; |
| 09:19 |
tsbere |
If there is a "only render the jacket if there is at least one ISBN" block in the templates (to avoid missing images and such) that could explain it |
| 09:20 |
jeff |
Bmagic: yeah, bad. |
| 09:21 |
Bmagic |
man, this is way simpler than I thought. Wow, it was staring me in the face! |
| 09:21 |
Bmagic |
http://upgrade.missourievergreen.org/eg/opac/record/1177127 and there we go |
| 09:22 |
Bmagic |
At some point, that if statement was in the EG code, and through upgrades, it must have been removed from the stock code but remained in our templates |
| 09:28 |
jeff |
yup! |
| 09:28 |
Bmagic |
jeff++ tsbere++ #awesome catch |
| 09:34 |
|
yboston joined #evergreen |
| 09:43 |
|
Shae joined #evergreen |
| 10:01 |
kmlussier |
Sanity check. If we are creating new icons with new CVM entries, do we need to do a reingest? |
| 10:01 |
bshum |
kmlussier: I want to say yes. |
| 10:02 |
kmlussier |
It seems like I answered this question for somebody else once. |
| 10:02 |
kmlussier |
The record attributes are already ingested. |
| 10:02 |
tsbere |
kmlussier: Only if records that match your new icons already exist. |
| 10:02 |
Dyrcona |
I was gonna say you probably just need a record attr ingest. |
| 10:04 |
|
sarabee joined #evergreen |
| 10:05 |
|
maryj joined #evergreen |
| 10:11 |
|
jwoodard joined #evergreen |
| 10:17 |
|
RoganH joined #evergreen |
| 10:49 |
|
mllewellyn joined #evergreen |
| 11:06 |
|
Christineb joined #evergreen |
| 11:42 |
|
maryj joined #evergreen |
| 11:53 |
|
bmills joined #evergreen |
| 11:59 |
|
bmills joined #evergreen |
| 12:04 |
|
ericar_ joined #evergreen |
| 12:06 |
|
sandbergja joined #evergreen |
| 12:11 |
|
jihpringle joined #evergreen |
| 12:15 |
|
jeffdavis joined #evergreen |
| 12:21 |
|
bmills joined #evergreen |
| 13:01 |
|
jihpringle joined #evergreen |
| 13:01 |
|
sandbergja joined #evergreen |
| 13:01 |
|
ericar joined #evergreen |
| 13:01 |
|
maryj joined #evergreen |
| 13:01 |
|
Christineb joined #evergreen |
| 13:01 |
|
mllewellyn joined #evergreen |
| 13:01 |
|
jwoodard joined #evergreen |
| 13:01 |
|
sarabee joined #evergreen |
| 13:01 |
|
Shae joined #evergreen |
| 13:01 |
|
yboston joined #evergreen |
| 13:01 |
|
krvmga joined #evergreen |
| 13:01 |
|
Stompro joined #evergreen |
| 13:01 |
|
Dyrcona joined #evergreen |
| 13:01 |
|
jboyer-isl joined #evergreen |
| 13:01 |
|
mrpeters joined #evergreen |
| 13:01 |
|
_bott_ joined #evergreen |
| 13:01 |
|
rjackson_isl joined #evergreen |
| 13:01 |
|
graced joined #evergreen |
| 13:01 |
|
remingtron joined #evergreen |
| 13:01 |
|
gsams joined #evergreen |
| 13:01 |
|
b_bonner joined #evergreen |
| 13:01 |
|
eady joined #evergreen |
| 13:01 |
|
RBecker joined #evergreen |
| 13:01 |
|
book` joined #evergreen |
| 13:01 |
|
Callender joined #evergreen |
| 13:01 |
|
tsbere joined #evergreen |
| 13:01 |
|
jeffdavis joined #evergreen |
| 13:01 |
|
phasefx__ joined #evergreen |
| 13:01 |
|
abowling joined #evergreen |
| 13:01 |
|
kitteh_ joined #evergreen |
| 13:01 |
|
jonadab joined #evergreen |
| 13:01 |
|
eby joined #evergreen |
| 13:01 |
|
rangi joined #evergreen |
| 13:01 |
|
akilsdonk joined #evergreen |
| 13:01 |
|
mceraso joined #evergreen |
| 13:01 |
|
miker joined #evergreen |
| 13:01 |
|
bshum joined #evergreen |
| 13:01 |
|
phasefx joined #evergreen |
| 13:01 |
|
gmcharlt joined #evergreen |
| 13:01 |
|
pinesol_green joined #evergreen |
| 13:01 |
|
jyorio joined #evergreen |
| 13:01 |
|
BigRig joined #evergreen |
| 13:01 |
|
mtj_ joined #evergreen |
| 13:01 |
|
DPearl joined #evergreen |
| 13:01 |
|
ldw joined #evergreen |
| 13:01 |
|
kmlussier joined #evergreen |
| 13:01 |
|
taterrr joined #evergreen |
| 13:01 |
|
dbwells joined #evergreen |
| 13:01 |
|
collinanderson joined #evergreen |
| 13:01 |
|
jeff joined #evergreen |
| 13:01 |
|
wjr joined #evergreen |
| 13:01 |
|
rashma joined #evergreen |
| 13:01 |
|
mnsri joined #evergreen |
| 13:01 |
|
jcamins joined #evergreen |
| 13:01 |
|
csharp joined #evergreen |
| 13:01 |
|
dbs joined #evergreen |
| 13:01 |
|
berick joined #evergreen |
| 13:01 |
|
egbuilder joined #evergreen |
| 13:11 |
|
pastebot joined #evergreen |
| 13:11 |
|
collum joined #evergreen |
| 13:11 |
|
ningalls joined #evergreen |
| 13:11 |
|
jihpringle joined #evergreen |
| 13:11 |
|
sandbergja joined #evergreen |
| 13:11 |
|
ericar joined #evergreen |
| 13:11 |
|
maryj joined #evergreen |
| 13:11 |
|
Christineb joined #evergreen |
| 13:11 |
|
mllewellyn joined #evergreen |
| 13:11 |
|
jwoodard joined #evergreen |
| 13:11 |
|
sarabee joined #evergreen |
| 13:11 |
|
Shae joined #evergreen |
| 13:11 |
|
yboston joined #evergreen |
| 13:11 |
|
krvmga joined #evergreen |
| 13:11 |
|
Stompro joined #evergreen |
| 13:11 |
|
Dyrcona joined #evergreen |
| 13:11 |
|
jboyer-isl joined #evergreen |
| 13:11 |
|
mrpeters joined #evergreen |
| 13:11 |
|
_bott_ joined #evergreen |
| 13:11 |
|
rjackson_isl joined #evergreen |
| 13:11 |
|
graced joined #evergreen |
| 13:11 |
|
remingtron joined #evergreen |
| 13:11 |
|
gsams joined #evergreen |
| 13:11 |
|
b_bonner joined #evergreen |
| 13:11 |
|
eady joined #evergreen |
| 13:11 |
|
RBecker joined #evergreen |
| 13:11 |
|
book` joined #evergreen |
| 13:11 |
|
Callender joined #evergreen |
| 13:11 |
|
tsbere joined #evergreen |
| 13:11 |
|
jeffdavis joined #evergreen |
| 13:11 |
|
phasefx__ joined #evergreen |
| 13:11 |
|
abowling joined #evergreen |
| 13:11 |
|
kitteh_ joined #evergreen |
| 13:11 |
|
jonadab joined #evergreen |
| 13:11 |
|
eby joined #evergreen |
| 13:11 |
|
rangi joined #evergreen |
| 13:11 |
|
akilsdonk joined #evergreen |
| 13:11 |
|
mceraso joined #evergreen |
| 13:11 |
|
miker joined #evergreen |
| 13:11 |
|
bshum joined #evergreen |
| 13:11 |
|
phasefx joined #evergreen |
| 13:11 |
|
gmcharlt joined #evergreen |
| 13:11 |
|
pinesol_green joined #evergreen |
| 13:11 |
|
jyorio joined #evergreen |
| 13:11 |
|
BigRig joined #evergreen |
| 13:11 |
|
mtj_ joined #evergreen |
| 13:11 |
|
DPearl joined #evergreen |
| 13:11 |
|
ldw joined #evergreen |
| 13:11 |
|
kmlussier joined #evergreen |
| 13:11 |
|
taterrr joined #evergreen |
| 13:11 |
|
dbwells joined #evergreen |
| 13:11 |
|
collinanderson joined #evergreen |
| 13:11 |
|
jeff joined #evergreen |
| 13:11 |
|
wjr joined #evergreen |
| 13:11 |
|
rashma joined #evergreen |
| 13:11 |
|
mnsri joined #evergreen |
| 13:11 |
|
jcamins joined #evergreen |
| 13:11 |
|
csharp joined #evergreen |
| 13:11 |
|
dbs joined #evergreen |
| 13:11 |
|
berick joined #evergreen |
| 13:11 |
|
egbuilder joined #evergreen |
| 14:09 |
|
bmills joined #evergreen |
| 14:37 |
bmills |
just out of curiosity, what distribution are people using if you're running debian as your OS for evergreen? |
| 14:37 |
jeff |
Has anyone here created a function for use with batch SQL updates that would accept a copy id and a call number label and either 1) move the copy to an existing call_number with that label or 2) create a new call number with that label? |
| 14:39 |
jeff |
bmills: we dev on Wheezy and Jessie at this time. production is on ESI's Sequoia product, whose 2.7 cluster is probably Wheezy, but I can't speak authoritatively to that. |
| 14:42 |
bmills |
jeff++ |
| 14:43 |
tsbere |
jeff: That sounds familiar. I have one for moving copies across libraries to find/create call numbers... |
| 14:43 |
tsbere |
and a "change the call number label" that operates on the call number, not the copy (but will move copies to an already existing call number) |
| 14:44 |
jeff |
tsbere: I'm not ruling out the possibility of something suitable already existing, but the requirement of "works for SQL updates" might exclude some code that exists in OpenILS::Application::* somewhere. |
| 14:44 |
tsbere |
jeff: I am referring to DB functions specifically |
| 14:54 |
bshum |
We should do a new survey of systems to see what distributions folks are using. |
| 14:54 |
bshum |
For fun reference |
| 14:54 |
kmlussier |
bshum: +1 |
| 14:57 |
Dyrcona |
bmills: We use Ubuntu 14.04 for almost everything. I still keep a 12.04 vm handy for testing. |
| 14:58 |
Dyrcona |
jeff: I usually do that sort of thing in Perl or Python and manage the transactions at that level. |
| 14:58 |
Dyrcona |
jeff: Mainly because I usually need logic to either update a call number or alter the copy, and it's kind a tricky to do that in one transaction without a function. |
| 14:59 |
Dyrcona |
Plus, I'm usually doing batches. |
| 14:59 |
Dyrcona |
But, usually, what I'm doing is not exactly what you're asking about. |
| 14:59 |
Dyrcona |
Either undeleting copies that just "mysteriously" showed up again, or altering call number labels. |
| 15:02 |
bmills |
bshum: that would be great. i'd be interested to know, for sure. most of our setup is on squeeze, so i think we're a bit overdue for an upgrade, but i wanted to get a feel for what the community was using |
| 15:02 |
bmills |
Dyrcona++ |
| 15:02 |
bshum |
Our primary platform is Ubuntu, but we've dabbled in a bit of everything at some point. |
| 15:03 |
bshum |
Except Fedora. I just can't get behind the whole yum vs. apt-get dealio |
| 15:03 |
* bshum |
only half-jokes about that |
| 15:03 |
* Dyrcona |
was gonna make it work on FreeBSD, but something more practical came up.... ;) |
| 15:04 |
csharp |
PINES is on a mix of Ubuntu 12.04 and 14.04, soon to fully move to 14.04 (just in time for 16.04 ;-)) |
| 15:05 |
csharp |
I've always wanted us to keep the RHEL/CentOS distros supported, but not enough hours in the day ;-) |
| 15:07 |
* Dyrcona |
wonders how someone is getting along with the OpenBSD port. |
| 15:08 |
bshum |
Oh right... 16.04 :( |
| 15:08 |
bshum |
Sigh. |
| 15:08 |
bshum |
Once again. |
| 15:09 |
* Dyrcona |
will start poking it in December, maybe. |
| 15:09 |
Dyrcona |
Sometimes that is too early. |
| 15:09 |
csharp |
yeah - big changes between 14.04/16.04 |
| 15:09 |
bshum |
Indeed. |
| 15:10 |
bshum |
I wonder if that'll impact our plans for 2.next too. |
| 15:10 |
bshum |
Or we'll just work on it much, much later. |
| 15:10 |
csharp |
though jessie users have a preview of new-style ejabberd config and systemd |
| 15:13 |
Dyrcona |
yaml...instead of an erlang data structure. |
| 15:14 |
Dyrcona |
Remember, kids! ejabberd is OTP compliant! ;) |
| 15:15 |
* Dyrcona |
has been staring at logs for too long. |
| 15:15 |
kmlussier |
yboston / jcamins: I was just talking to somebody here at NOBLE. She lives right near Oak Grove Station on the Orange Line. That might be another way to get up here from Boston if the timing's right. |
| 15:16 |
yboston |
kmlussier: thanks |
| 15:16 |
yboston |
kmlussier: I reserved a hotel room, so I migh only need a ride the first and last day |
| 15:17 |
kmlussier |
When were you planning to come up? Tuesday or Wednesday? |
| 15:19 |
yboston |
I was thinking Wednesday, sice I thought that is when folks would start arriving, but I could be wrong |
| 15:19 |
yboston |
I see now most folks are coming on Tuesday |
| 15:20 |
yboston |
I guess I can go Tuesday or Maybe WEdnesday morning. Will need to think about it. |
| 15:21 |
kmlussier |
yboston: If you come up Wednesday morning, that would work out well for the Orange Line idea because she could just pick you up on her way into work for the day. |
| 15:21 |
yboston |
makes sense |
| 15:22 |
yboston |
can you privately send me the NOBLE person's name for my notes while I ponder my choices |
| 15:31 |
gmcharlt |
poll for setting a date for the RM election: http://doodle.com/poll/6f2v5v9526phe85d |
| 15:31 |
csharp |
okay - I'm hitting a new acq issue - I'm (as the admin user) transferring money from one fund to another - the UI prompts me with an "are you sure" dialog, which I say "yes" to, but the amount in the origin fund doesn't change and there is not a transfer created |
| 15:31 |
csharp |
no errors in the logs or otherwise |
| 15:32 |
csharp |
I can see the query going through in the DB: SELECT * FROM acq.transfer_fund( '525', '200', '527', '200', '1', 'misallocation' ) AS "acq.transfer_fund" ; |
| 15:32 |
csharp |
and it returns "1" as expected via srfsh |
| 15:32 |
csharp |
I can see that transfers have worked in the past, but for whatever reason, it's not working now |
| 15:33 |
csharp |
both funds are owned by the same org |
| 15:33 |
kmlussier |
csharp: It doesn't sound familiar to me. Sorry. |
| 15:34 |
csharp |
kmlussier: thanks |
| 15:34 |
Dyrcona |
csharp: Have you checked the funds in the database? Maybe it happened and the client doesn't know it. |
| 15:34 |
* csharp |
will add debugging statements to the SQL function |
| 15:34 |
csharp |
Dyrcona: no change in the DB |
| 15:35 |
Dyrcona |
Well, I'm out of ideas. :) |
| 15:35 |
csharp |
Dyrcona: thanks for responding, anyway |
| 15:36 |
Dyrcona |
I thought you probably already looked, but didn't think it would hurt to mention it. |
| 15:36 |
berick |
csharp: confirmed the API call is being made? |
| 15:37 |
berick |
i.e. it's not dying in the client before API call goes out |
| 15:37 |
csharp |
berick: yes - I can see it in the osrf and PG logs |
| 15:38 |
* csharp |
expects that some local config change is probably the cause |
| 15:39 |
tsbere |
csharp: And the money you are transferring isn't all encumbered or whatever? |
| 15:41 |
csharp |
tsbere: I don't think so - I would expect an error message if so |
| 15:41 |
csharp |
@hate acq |
| 15:41 |
pinesol_green |
csharp: The operation succeeded. csharp hates acq. |
| 15:42 |
tsbere |
I dunno, does the function have a raise error at the end for "we didn't find enough money to transfer"? |
| 15:42 |
|
jlitrell joined #evergreen |
| 15:42 |
csharp |
tsbere: absolutely no errors whatsoever when running in the client, via srfsh, or via the SQL function :-( |
| 15:44 |
tsbere |
csharp: Not what I asked. Looking at our DB's version of that function, when the final loop terminates it doesn't check if there was remaining requested transfer left. |
| 15:45 |
|
LGPL-Ryan joined #evergreen |
| 15:45 |
LGPL-Ryan |
Brent? Are you available momentarily? |
| 15:45 |
tsbere |
AKA, if it loops over everything and finds nothing that it is "allowed" to transfer it exits without error having done nothing |
| 15:45 |
csharp |
tsbere: ah |
| 15:45 |
csharp |
I'll look |
| 15:46 |
LGPL-Ryan |
BMills, are you present, or AFK? |
| 15:46 |
bmills |
LGPL-Ryan: i'm here |
| 15:46 |
LGPL-Ryan |
What's the Kpac Website for Sage? |
| 15:47 |
LGPL-Ryan |
Specifically, what do i add to the end of lpl.sage.eou.edu/ in order to get the KPAC site? |
| 15:48 |
bmills |
LGPL-Ryan: sent over to you in a private message |
| 15:48 |
bshum |
o.k. |
| 15:49 |
LGPL-Ryan |
I don't know how to access PM in the #evergreen IRC...I access it through the web portal... |
| 15:49 |
LGPL-Ryan |
You can email it to me at my email address though. |
| 15:49 |
bmills |
LGPL-Ryan: you can append /eg/kpac/home to that address |
| 15:49 |
bmills |
so https://lpl.sage.eou.edu/eg/kpac/home for example |
| 15:49 |
LGPL-Ryan |
ok...Thanks! |
| 15:51 |
csharp |
tsbere: the fund has been allocated 873.81 and 538.45 is encumbered, leaving 335.36 (I'm trying to transfer out 200). |
| 15:52 |
tsbere |
csharp: It was a guess. Could there be a problem with the destination fund? |
| 15:53 |
berick |
yeah, are both active=true? |
| 15:55 |
csharp |
yes, both funds are active |
| 15:55 |
csharp |
gonna look more closely at the dest fund |
| 15:56 |
csharp |
nothing is obviously wrong |
| 15:57 |
csharp |
@eightball is it time to RAISE some NOTICES? |
| 15:57 |
pinesol_green |
csharp: It is possible. |
| 15:58 |
bshum |
bmills: Fancy carousel there on the KPAC. |
| 15:59 |
bmills |
bshum: that's thanks to Bmagic's slider presentation |
| 15:59 |
csharp |
bshum: I'm looking to add a carousel to our governor's mansion EG instance - been looking at these: http://www.jssor.com/ (MIT licensed, lots o' options) |
| 15:59 |
csharp |
but I was gonna do photos of the mansion library |
| 16:02 |
Dyrcona |
Does anything much in evergreen use the osrf_http_translator? |
| 16:03 |
berick |
Dyrcona: practically all the dojo stuff |
| 16:03 |
Dyrcona |
berick: thanks. |
| 16:04 |
Dyrcona |
I'm combing through logs trying to figure out what happened at around 6:30 this morning, and I see a failed login attempt via the translator. |
| 16:04 |
Dyrcona |
authenticate called before init message. |
| 16:05 |
* Dyrcona |
wonders if someone is playing around. |
| 16:09 |
Dyrcona |
Nope. Comparing with the apache logs, it looks like it took this person two tries to login. |
| 16:09 |
Dyrcona |
The first got a 500 error and the second got a 200 response. |
| 16:09 |
Dyrcona |
Both coming from the opac login page. |
| 16:09 |
Dyrcona |
Probably a red herring. |
| 16:13 |
kmlussier |
Ugh. That moment when you make a typo in a Launchpad comment, can see the typo while the comment is saving, but are helpless from fixing the typo before the comment is saved. |
| 16:39 |
jeff |
I wonder if the replies to bug 1503903 were ill-timed. I think Sitka had an outage that day. :-) |
| 16:39 |
pinesol_green |
Launchpad bug 1503903 in Evergreen "Rollback on shelfcheck (3M, etc.) triggers holds?" [Undecided,New] https://launchpad.net/bugs/1503903 |
| 16:48 |
Dyrcona |
People should know to check their bugs periodically anyway. |
| 17:02 |
|
ericar joined #evergreen |
| 17:20 |
|
bmills joined #evergreen |
| 17:33 |
|
artunit joined #evergreen |
| 18:56 |
jeffdavis |
jeff: Tina has seen the responses on that bug but hasn't had a chance to follow up on them yet. |
| 18:57 |
jeffdavis |
And yeah, we had an outage at the datacentre that day apparently. Good time for me to be on vacation. :P |
| 19:13 |
|
bmills joined #evergreen |
| 19:20 |
|
mnsri_ joined #evergreen |
| 19:57 |
|
dbwells_ joined #evergreen |
| 23:22 |
|
sarabee joined #evergreen |
| 23:27 |
|
pmurray_away joined #evergreen |
