Time |
Nick |
Message |
00:00 |
|
jyorio joined #evergreen |
00:08 |
|
jwoodard_tablet joined #evergreen |
01:58 |
|
Mark__T joined #evergreen |
07:59 |
|
rjackson_isl joined #evergreen |
08:10 |
|
jboyer-isl joined #evergreen |
08:18 |
|
akilsdonk joined #evergreen |
08:33 |
|
mmorgan joined #evergreen |
08:37 |
|
Dyrcona joined #evergreen |
08:38 |
|
mrpeters joined #evergreen |
08:46 |
|
RoganH joined #evergreen |
08:46 |
RoganH |
gmcharlt++ |
08:53 |
|
Shae joined #evergreen |
09:01 |
|
yboston joined #evergreen |
09:02 |
|
jwoodard joined #evergreen |
09:15 |
|
maryj joined #evergreen |
09:21 |
gmcharlt |
RoganH++ # not taking ALL of my advice too seriously ;) |
09:35 |
|
collum joined #evergreen |
10:08 |
gsams |
Good Morning #evergreen! |
10:08 |
mmorgan |
gsams: Good Morning! |
10:09 |
* jboyer-isl |
waves, vocalization remains difficult at this "early" hour. |
10:10 |
jboyer-isl |
@coffee |
10:10 |
* pinesol_green |
brews and pours a cup of Ethiopia Sidamo Special Prep, and sends it sliding down the bar to jboyer-isl |
10:10 |
gsams |
@tea |
10:10 |
* pinesol_green |
brews and pours a pot of None, and sends it sliding down the bar to gsams (http://ratetea.com/tea/rishi/bao-zhong-oolong/768/) |
10:10 |
gsams |
Tea appears to be broken, heh. |
10:10 |
gsams |
looks like I get another cup of zen. |
10:10 |
jboyer-isl |
How nice, I'd have also accepted Ethiopia Sidamo standard prep, possibly even sloppy prep. |
10:11 |
gsams |
some mornings, coffee is coffee. |
10:11 |
mmorgan |
@tea |
10:11 |
* pinesol_green |
brews and pours a pot of None, and sends it sliding down the bar to mmorgan (http://ratetea.com/tea/rishi/masala-chai/4495/) |
10:11 |
gsams |
or so I understand it, not a coffee drinker myself. |
10:11 |
gsams |
Zen tea for everyone! |
10:13 |
mmorgan |
Tea is only half broken, the link looks right. |
10:13 |
mmorgan |
@coffee |
10:13 |
* pinesol_green |
brews and pours a cup of Kenya Giakanja, and sends it sliding down the bar to mmorgan |
10:14 |
* mmorgan |
prefers coffee :) |
10:17 |
tsbere |
It feels wrong when a query contains nested sums. |
10:23 |
Dyrcona |
Heh. My local McDonald's hasn't been able to make tea for a week, now. |
10:23 |
tsbere |
Feels just as wrong nesting date_trunc for that matter. :/ |
10:23 |
Dyrcona |
Maybe if we fix supybot.... ;) |
10:23 |
jwoodard |
I see pinesol is still handing out None tea... |
10:24 |
Dyrcona |
Good morning, pinesol_green! |
10:25 |
* Dyrcona |
wonders if pinesol_green is anything like Soylent green? |
10:25 |
Dyrcona |
Yep. The tea plugin is probably busted. |
10:26 |
jwoodard |
speaking of tea I cannot find my teacup... |
10:29 |
mmorgan |
Dyrcona: Seems like a week is an awful long time for them to figure out why they can't make tea and fix it. |
10:29 |
Dyrcona |
Yep. |
10:29 |
Dyrcona |
I've been making my own. It saves me a few cents, I guess. |
10:30 |
* mmorgan |
wonders if the problem is with the boiling water or the tea bags? |
10:37 |
Dyrcona |
Dunno. I should probably just make my own breakfast, anyway. |
10:47 |
|
akilsdonk_ joined #evergreen |
10:49 |
|
akilsdonk__ joined #evergreen |
11:37 |
|
Christineb joined #evergreen |
11:38 |
|
RoganH_ joined #evergreen |
11:50 |
|
jlitrell joined #evergreen |
11:50 |
pinesol_green |
[evergreen|Dan Wells] LP#1484989 Don't close xacts with checkin-generated fines - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4357ab3> |
11:50 |
pinesol_green |
[evergreen|Galen Charlton] LP#1484989: tweak test case - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1f82890> |
11:54 |
gmcharlt |
me notices and smiles at a branch name: kill-jspac-and-friends-with-release-notes |
11:55 |
gmcharlt |
I'm now wondering exactly what kmlussier is up to with her calls for more and more release notes ;) |
11:59 |
jeff |
heh |
11:59 |
jeff |
i think that was my branch name. :-) |
11:59 |
gmcharlt |
yeah |
12:00 |
berick |
the pen is mightier than the sword |
12:01 |
|
bmills joined #evergreen |
12:06 |
|
jihpringle joined #evergreen |
12:34 |
mmorgan |
Anybody using the circ.holds.clear_shelf.copy_status org unit setting? If so, what status are you assigning to items cleared from the holds shelf? |
12:38 |
gsams |
mmorgan: We do not use that setting here, I suppose no one has a good reason to send books to purgatory. |
12:40 |
gsams |
in reference to the description for that setting, I suppose I would probably create a status specifically for the case |
12:40 |
gsams |
something like "Manual check" or something along those lines |
12:41 |
mmorgan |
gsams: We don't currently use it either, so items retain their hold shelf status until they're checked in. |
12:42 |
gsams |
mmorgan: Aye, that's what we do here. |
12:42 |
mmorgan |
Problem is, if they don't get checked in and moved along, it's difficult to tell exactly where they are. |
12:42 |
mmorgan |
... In a consortium, that is. |
12:43 |
gsams |
this is true, I have had a few moments where that has been somewhat of an issue |
12:43 |
* mmorgan |
just reread the description of the setting and got the purgatory reference :) |
12:44 |
gsams |
I could see the use of that setting as an indicator that the item is awaiting processing at a specific library. |
12:45 |
gsams |
probably better as a short code instead of a full blown status "Expired -LibShortname-" |
12:45 |
gsams |
that would certainly bloat the number of status options though. |
12:46 |
miker |
mmorgan / I could see dev to show the last hold shelf lib (if it's not there easily already) as a better option than many status |
12:46 |
miker |
mmorgan / gsams ... |
12:46 |
mmorgan |
yes, a different status could be useful. And yes, that would mean at least 28 statuses for us. |
12:47 |
miker |
but, yes, a special "look on some hold shelf" status would be good |
12:47 |
mmorgan |
miker: Yes, ideally that should come from the applicable hold. |
12:48 |
mmorgan |
Interestingly, whether the clear hold shelf status option is set or not, the item gets updated when the hold shelf is cleared. |
12:48 |
miker |
mmorgan: should be the last hold that targetted the item and is expired/canceled |
12:48 |
miker |
I think? |
12:48 |
mmorgan |
Yes, that sounds right. |
12:51 |
* mmorgan |
will work up a launchpad bug. Gotta run for a bit atm ... |
13:36 |
|
vlewis joined #evergreen |
14:06 |
jeffdavis |
Has anyone else seen really slow load times for bookbags in TPAC? |
14:07 |
jeffdavis |
We are experiencing >20s for the results page to load in some circumstances, possibly due to bad query planning when joining on circ.target_copy = acp.id |
14:09 |
jeffdavis |
My test case is not a large bookbag (10 records) |
14:32 |
tsbere |
jeffdavis: My only quick test bookbags either have zero or a couple thousand items so I don't think they are a good test. >_> |
14:34 |
|
ericar joined #evergreen |
14:39 |
|
akilsdonk joined #evergreen |
14:52 |
gsams |
jeffdavis: I have bookbags with 100 items, load in just about 5 seconds. |
14:54 |
csharp |
@whocares edi |
14:54 |
pinesol_green |
bshum hates edi |
14:54 |
csharp |
@hate edi |
14:54 |
pinesol_green |
csharp: The operation succeeded. csharp hates edi. |
14:55 |
Dyrcona |
@decide to be or not to be |
14:55 |
csharp |
I still can't figure out why EDI order response files from Ingram are choking |
14:55 |
pinesol_green |
Dyrcona: Zoia knows how to make fusilli. |
14:56 |
csharp |
the same three files are failing to be processed nightly |
14:57 |
csharp |
Can't call method "id" on an undefined value at /usr/local/share/perl/5.14.2/OpenILS/Application/Acq/EDI.pm line 855 <-- and that is as meaningless to me now after many hours of trying to figure out why as it was when I began |
14:58 |
csharp |
I can't seem to isolate what data is actually failing there - my attempts at adding debugging statements have been fruitless |
14:59 |
|
TaraC joined #evergreen |
15:00 |
berick |
csharp: is that: $lid->cancel_reason($reason->id); ? |
15:00 |
csharp |
berick: yes |
15:02 |
csharp |
this is one of the EDI messages that fails: http://pastie.org/private/h2dywzzxkujmviihpna2q |
15:02 |
berick |
csharp: just before that happens, there should be a log line "EDI: lineitem has order stutus.." |
15:02 |
berick |
what status does it log? |
15:02 |
csharp |
lemme check |
15:03 |
berick |
ah, i bet it's 200 |
15:03 |
* csharp |
waits for 'less' to search |
15:07 |
berick |
grep + less might be faster :) |
15:07 |
csharp |
berick: yeah, I've switched to that |
15:08 |
berick |
csharp: while that's running, do you have an acq.cancel_reason row with id=1007 ? |
15:09 |
csharp |
berick: no, I don't |
15:09 |
berick |
that's probably the problem. that's a stock acq.cancel_reason |
15:09 |
csharp |
ah |
15:09 |
csharp |
I know the Acq staff have done some editing or removing of stock stuff |
15:10 |
berick |
csharp: if you see the acq.cancel_reason INSERT's in 950.data.seed-values.sql you can see what all you need. |
15:10 |
berick |
the list was trimmed dramatically a couple of releases back |
15:10 |
|
TaraC joined #evergreen |
15:10 |
csharp |
awesome |
15:11 |
csharp |
berick++ # thanks for the hint - I feel pretty confident that's what's going on |
15:14 |
miker |
hrm... we're not protecting reasons we need, a la copy statuses? |
15:17 |
berick |
negatory, but we def. should |
15:18 |
csharp |
berick: is the ID important, or just the label? |
15:18 |
berick |
csharp: the ID |
15:18 |
berick |
is the most important port |
15:19 |
berick |
part |
15:19 |
berick |
the label can be anything |
15:19 |
csharp |
okay - good to know |
15:38 |
Dyrcona |
I hate when I spend most of my day googling a problem, trying every "solution," and nothing works. |
15:45 |
jwoodard |
Dyrcona: Try rubber ducking or just talk to yourself. That fixes most of my problems...sometimes. |
15:53 |
Dyrcona |
Meh. This project is just doomed. |
15:53 |
Dyrcona |
boto and Amazon S3 just hate me. |
15:54 |
Dyrcona |
Or, rather, my server hates Amazon's SSL Certificates. |
15:54 |
Dyrcona |
It works, if I don't mind unencrypted connections, which I do mind. |
16:15 |
|
geoffsams joined #evergreen |
16:20 |
csharp |
berick: that was it! thanks again :-) |
16:20 |
csharp |
berick++ |
16:20 |
jboyer-isl |
Dyrcona: Missing a root cert, or does Amazon expect people to install their roots for AWS? |
16:22 |
Dyrcona |
jboyer-isl: I've found all kinds of nutty stuff on the Internet about it. |
16:22 |
Dyrcona |
"It's being rejected because the keys are weak." |
16:22 |
Dyrcona |
"It's being rejected because the CA's signature is weak." |
16:22 |
Dyrcona |
"It's a bug in boto." |
16:22 |
Dyrcona |
"It's a bug in duplicity." |
16:23 |
Dyrcona |
"It's a missing feature in your libssl." |
16:23 |
jboyer-isl |
I'll admit I don't know anything about boto or duplicity, so I don't know if those are silly or suspect. |
16:24 |
Dyrcona |
Well, I've read posts that blame every party involved: Amazon, boto, duplicity, libssl, the user... :) |
16:25 |
Dyrcona |
This was supposed to be a little, one-hour thing. |
16:26 |
jeff |
@blame Level3/twtelecom |
16:26 |
pinesol_green |
jeff: Level3/twtelecom stole bradl's tux doll! |
16:26 |
gmcharlt |
THEY DONE DID WORSE! |
16:26 |
gmcharlt |
;) |
16:27 |
jboyer-isl |
Hah, "Can't use bucket names with dots" must have been a fun error to stumble on. |
16:28 |
Dyrcona |
Yep. This problem looks like that one, except, guess what... no dots in my bucket name. |
16:29 |
berick |
csharp: yay! |
16:29 |
|
maryj joined #evergreen |
16:30 |
jboyer-isl |
I figured you've come across all of those things, that one just struck me as funny. Only once so far in my career have I had to go to the trouble of collecting tcp traffic to come through it to pinpoint problems, but it sounds like that may help at least narrow your search. |
16:30 |
jboyer-isl |
And will make this "should have been an hour, tops" project significantly longer. :) |
16:32 |
jboyer-isl |
Also, regardless of my sloppy typing, traffic is combed, nothing like an ACK with a comb-over. |
16:32 |
Dyrcona |
Well, to tcp dump the traffic, I have to switch to unencrypted and that works. |
16:33 |
|
afterl left #evergreen |
16:33 |
Dyrcona |
I'm just not keen on having my access key id and details about the files being transferred exposed to every router between here and there. |
16:38 |
jeff |
jboyer-isl: to quote myself from a few months ago: |
16:38 |
jeff |
<jeff> actually, since this is local i can look at the cert with wireshark |
16:38 |
jeff |
<jeff> NOW it's a party! |
17:10 |
|
bmills joined #evergreen |
17:13 |
|
mmorgan left #evergreen |
17:14 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
17:54 |
|
bmills joined #evergreen |
18:09 |
|
finnx joined #evergreen |
18:26 |
|
Dyrcona joined #evergreen |
18:27 |
Dyrcona |
So, if anyone is still paying attention... |
18:27 |
Dyrcona |
Naturally, the Amazon S3 upload works just fine from my Ubuntu 14.04 laptop. |
18:34 |
jeff |
of course. :-) |
19:10 |
Dyrcona |
duplicity and boto are both older version there than on FreeBSD, but I think the "problem" is libssl on the FreeBSD server. |
19:18 |
Dyrcona |
So, 11 minutes to send 1.1 GB....I guess about 6 hours to send almost 50 GB. |
19:19 |
|
bmills joined #evergreen |
19:19 |
Dyrcona |
Maybe 7 or 8 hours. |
19:23 |
|
akilsdonk__ joined #evergreen |
19:23 |
|
akilsdonk___ joined #evergreen |
19:38 |
Dyrcona |
Ugh. |
19:38 |
Dyrcona |
It worked for one set of files. Now it isn't working for another from the laptop. |
19:39 |
Dyrcona |
Oh! Helps to get the bucket name correct. :) |
19:40 |
Dyrcona |
typos-- |
19:50 |
Dyrcona |
Gonna sign off again. |
19:50 |
Dyrcona |
Good night, Irene....er #evergreen. :) |
23:16 |
|
ningalls joined #evergreen |