| Time |
Nick |
Message |
| 01:52 |
|
jeffdavis joined #evergreen |
| 03:09 |
|
gsams joined #evergreen |
| 05:03 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:34 |
|
rjackson_isl joined #evergreen |
| 07:39 |
|
graced joined #evergreen |
| 07:39 |
|
sarabee joined #evergreen |
| 07:59 |
csharp |
@hate the EDI ruby bits |
| 07:59 |
csharp |
pinesol_green: you there? |
| 07:59 |
pinesol_green |
csharp: The operation succeeded. csharp hates the EDI ruby bits. |
| 07:59 |
pinesol_green |
csharp: Leave me alone, I'm busy right now. |
| 07:59 |
|
ericar joined #evergreen |
| 07:59 |
csharp |
pinesol_green: obviously |
| 07:59 |
pinesol_green |
csharp: <shaggy>We're, like, doomed.</shaggy> |
| 08:04 |
|
jboyer-isl joined #evergreen |
| 08:09 |
csharp |
all the ruby pieces are so variable, it's proving nearly impossible to script EDI installation |
| 08:27 |
|
akilsdonk joined #evergreen |
| 08:35 |
|
mmorgan joined #evergreen |
| 08:44 |
|
pmurray_away joined #evergreen |
| 08:45 |
|
RoganH joined #evergreen |
| 08:46 |
|
pmurray joined #evergreen |
| 08:49 |
|
Shae joined #evergreen |
| 08:54 |
|
Dyrcona joined #evergreen |
| 09:23 |
|
Newziky joined #evergreen |
| 09:24 |
|
ningalls_ joined #evergreen |
| 09:25 |
|
maryj joined #evergreen |
| 09:43 |
|
yboston joined #evergreen |
| 10:00 |
|
mrpeters joined #evergreen |
| 10:26 |
mmorgan |
Hmm, webby seems to be sleeping in this morning. I can't login. |
| 10:30 |
kmlussier |
mmorgan: I had that problem last week, but then it suddently started working. |
| 10:30 |
kmlussier |
I can login now. |
| 10:31 |
mmorgan |
Ah, ok. I had to reload the page, but I'm in now :) |
| 10:33 |
eeevil |
it's back now |
| 10:34 |
mmorgan |
Thanks! |
| 11:05 |
jeff |
csharp: are you trying to script edi_translator install, or package? |
| 11:13 |
csharp |
jeff: edi_translator install |
| 11:14 |
csharp |
I pulled it off for my local server, but was trying for something more portable |
| 11:16 |
pinesol_green |
[evergreen|Jason Stephenson] LP 1444130: Add max_chunk_size guards to Holds.pm. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7ec3ea5> |
| 11:21 |
jeff |
csharp: are you trying to script or package? |
| 11:21 |
jeff |
(i think you answered the part i already knew) |
| 11:27 |
|
TaraC joined #evergreen |
| 11:30 |
jeff |
(and upon re-reading, i think you said "script" to begin with -- oops) |
| 11:30 |
csharp |
jeff: script for now |
| 11:31 |
csharp |
honestly, I'm hoping "generate EDI within A/T" feature is completed before packaging comes up ;-) |
| 11:31 |
jeff |
--bwlimit does not do wonders for rsync's --progress accuracy |
| 11:31 |
csharp |
jeff: this is what I ended up with for now: http://paste.fedoraproject.org/215851/14868814/ |
| 11:32 |
jeff |
very xkcd 612 |
| 11:32 |
jeff |
(the rsync thing, not your paste) |
| 11:32 |
csharp |
jeff: I understood ;-) |
| 11:32 |
* berick |
reminds everyone we're cutting the next point releases wednesday |
| 11:33 |
berick |
merge ye bug fixes while ye may |
| 11:33 |
berick |
csharp: it's so close... |
| 11:33 |
berick |
"generate EDI within A/T" i mean |
| 11:34 |
csharp |
berick: I could see that you made a lot of progress on it ;-) |
| 11:34 |
berick |
maybe we can get some progress on that at egcon |
| 11:34 |
csharp |
I'll totally help with that if I can |
| 11:34 |
berick |
yes, you can help test |
| 11:34 |
csharp |
perfect |
| 11:34 |
berick |
IIRC, there's just a few fields remaining that have to be mapped. |
| 11:34 |
berick |
then it's testing time |
| 11:35 |
csharp |
awesome |
| 11:37 |
csharp |
so once the A/T thing is in place, it might be worth incorporating edi /openils stuff into the standard installation process |
| 11:38 |
csharp |
"thing"... "stuff" - technical jargon be damned! |
| 11:39 |
berick |
csharp: you mean edi_pusher / edi_fetcher ? |
| 11:39 |
berick |
if so, yes |
| 11:39 |
berick |
we should do that regarldess |
| 11:40 |
|
jihpringle joined #evergreen |
| 11:45 |
|
buzzy joined #evergreen |
| 12:02 |
|
sarabee joined #evergreen |
| 12:18 |
csharp |
berick: yeah, that's what I meant |
| 12:35 |
|
sandbergja joined #evergreen |
| 13:03 |
|
tsbere joined #evergreen |
| 13:20 |
|
RoganH joined #evergreen |
| 13:21 |
|
ericar_ joined #evergreen |
| 13:37 |
eeevil |
has anyone other than gmcharlt looked at LP 1438136? |
| 13:37 |
pinesol_green |
Launchpad bug 1438136 in Evergreen "OPAC searching significantly slowed by adding format filters" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1438136 |
| 13:37 |
eeevil |
or, the linked branch, more correctly |
| 13:40 |
csharp |
eeevil: I applied it to a test server and see far faster search times - I don't have an opinion about the implementation beyond that though |
| 13:40 |
Dyrcona |
eeevil: I loaded it on my dev system, which is 9.1 and apparently didn't need it, but I can say it caused no problems there. |
| 13:40 |
eeevil |
just hoping for a merge before the next point release, is all |
| 13:41 |
RoganH |
I can add it to our test and measure results tonight. |
| 13:48 |
|
dac joined #evergreen |
| 13:52 |
kmlussier |
eeevil: Is C/W MARS in production? If so, would it help if they added a comment to the LP bug reporting that it's working well for them? |
| 13:53 |
eeevil |
kmlussier: they're using it, and I think it would. I'm trying to avoid self-merging, but if that's what is needed to get it in, I will |
| 13:57 |
Dyrcona |
I'd sign off, but I didn't really need it. |
| 13:57 |
Dyrcona |
I'd be more comfortable if someone else did. |
| 14:04 |
jboyer-isl |
Dyrcona: It can provide benefits for 9.1 installations, it's just that only 1 of the code paths ever gets used. Your bib count determines whether your specific site would benefit or not. I don't particularly feel comfortable signing off on it either since I can't currently exercise the other code path. |
| 14:05 |
|
jonadab_znc joined #evergreen |
| 14:05 |
jboyer-isl |
(Also, time works ever against me. :( ) |
| 14:05 |
Dyrcona |
Well, I have no business signing off, since I obviously didn't look hard enough. :) |
| 14:22 |
RoganH |
I was just looking at our current search return numbers but they're even on our low powered test system orders of magnitude faster than csharp's. I don't know if I'd find anything worth signing off on other than "this didn't screw up an existing system" |
| 14:28 |
kmlussier |
After talking to C/W MARS, I'm not comfortable signing off either. They aren't seeing the huge difference between limited searches and non-limited searches anymore. However, they are seeing slower overall search performance since their upgrade. |
| 14:28 |
kmlussier |
Since the patch was applied as part of their upgrade, it's difficult for me to know if that change was partially caused by the patch or whether it was due to something else. |
| 14:39 |
csharp |
kmlussier: Terran was just testing here, and the challenge was trying to find search terms that weren't already cached by the live server - dunno if that's a factor there, but after a number of tries, Terran definitely sees the difference between pre- and post-fix |
| 14:42 |
kmlussier |
csharp: Yeah. I can definitely say that the format limiting problem was resolved. Their format-limited searches were timing out on their test system before their upgrade. |
| 14:43 |
kmlussier |
I just don't know if the other reported search slowness was a result of the patch, a result of the upgrade, or the result of something else. Too many moving parts. |
| 14:44 |
csharp |
kmlussier: well, the sure fire way to know is with an actual query from the postgres logs |
| 14:44 |
csharp |
that can be EXPLAIN ANALYZEd |
| 14:49 |
kmlussier |
I'll forward that along to them |
| 14:51 |
csharp |
kmlussier: my comments in the bug report might serve as examples for them |
| 14:51 |
csharp |
LP 1438136 |
| 14:51 |
pinesol_green |
Launchpad bug 1438136 in Evergreen "OPAC searching significantly slowed by adding format filters" (affected: 1, heat: 6) [High,New] https://launchpad.net/bugs/1438136 |
| 14:51 |
jeff |
eeevil++ csharp++ kmlussier++ |
| 14:56 |
|
akilsdonk joined #evergreen |
| 15:00 |
eeevil |
thanks, folks! sorry, was in a meeting |
| 15:08 |
gmcharlt |
upgraded the EG website to WP 4.2.1 |
| 15:09 |
gmcharlt |
*mumble mumble zero day get off my lawn mumble mumble* |
| 15:14 |
Dyrcona |
WordPress: a remote hole masquerading as a blogging platform. |
| 15:17 |
jonadab |
PHP, ugh. |
| 15:20 |
|
ericar_ joined #evergreen |
| 15:29 |
mmorgan |
Precat question: The precat's owning_lib is always the consortium (owner of call_number.id -1). I'm guessing there's no way to change that? |
| 15:30 |
jboyer-isl |
mmorgan: no, but the circ_lib is the location that created it. |
| 15:30 |
jboyer-isl |
Is this about reporting, or finding out what happened with some items? |
| 15:31 |
mmorgan |
Actually, it's circ policies. |
| 15:31 |
jeff |
the copy has a circ lib of the creating library, but it is attached to a call number that has an owning_lib of the top of tree. sometimes that can create challenges in terms of permissions. |
| 15:32 |
jboyer-isl |
Ah. That might be a pain then. I've not dealt with circ policies that looked at volumes for anything. |
| 15:34 |
* mmorgan |
started a bad precedent including owning_lib in circ policies way back when. |
| 15:35 |
mmorgan |
I guess this is a good reason to remove them. |
| 15:35 |
csharp |
gmcharlt++ |
| 15:37 |
Dyrcona |
Well, you could move them to the circ_lib. |
| 15:37 |
jboyer-isl |
mmorgan: If no one there uses floating it may be as easy as just shifting from owning to circ and things will just work. Depends on how you're using them, of course. |
| 15:40 |
mmorgan |
circ_lib will work just as well for the rules, I'll just move them over. |
| 15:41 |
tsbere |
I seem to recall several parts of the system saying "use circ_lib instead of owning_lib for permission check when call number is -1", but I don't recall if rules do anything like that... |
| 15:43 |
tsbere |
Wouldn't be *hard*, persay. Precats should never have holds so only circ policies need adjusting. "If call_number ID = -1 use the circ lib as the owning lib" would probably be only a line or two in the DB func. |
| 15:44 |
jeff |
tsbere: may not matter for your current thinking, but precats are designed to be able to have copy-level holds now. |
| 15:44 |
tsbere |
jeff: Hmmmm. Ok, so double the number of additional DB func lines. :P |
| 15:46 |
tsbere |
Could take it further by defining "precat owning lib is at depth X for circ/hold rules" somewhere, then "fake in" the ancestor at that depth instead of the circ lib itself. |
| 15:58 |
|
ericar_ joined #evergreen |
| 16:24 |
|
ericar_ joined #evergreen |
| 17:09 |
|
mmorgan left #evergreen |
| 17:49 |
|
Newziky left #evergreen |
| 18:51 |
|
chatley joined #evergreen |
| 18:54 |
|
mglass joined #evergreen |
