Evergreen ILS Website

IRC log for #evergreen, 2015-04-27

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat

All times shown according to the server's local time.

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

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat