Evergreen ILS Website

IRC log for #evergreen, 2017-01-03

| 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
00:12 chatter joined #evergreen
00:13 chatter hey guys
00:13 chatter allah is doing
00:13 chatter sun is not doing allah is doing
00:13 chatter to accept Islam say that i bear witness that there is no deity worthy of worship except Allah and Muhammad peace be upon him is his slave and messenger
05:01 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
07:08 NawJo joined #evergreen
07:17 Callender joined #evergreen
07:19 agoben joined #evergreen
07:25 rjackson_isl joined #evergreen
07:25 JBoyer joined #evergreen
08:00 _bott_ joined #evergreen
08:03 collum joined #evergreen
08:37 kmlussier joined #evergreen
08:47 jeffdavi1 joined #evergreen
08:47 csharp joined #evergreen
08:49 Dyrcona joined #evergreen
08:50 kmlussier Good morning #evergreen. Happy New Year!
08:53 bos20k joined #evergreen
09:03 graced joined #evergreen
09:06 Dyrcona Good morning, and Happy New Year to you, too!
09:08 gsams joined #evergreen
09:11 bos20k joined #evergreen
09:29 jvwoolf joined #evergreen
09:46 Dyrcona JBoyer: re NCIPServer: I would not have used Plack if I'd started it, myself. :)
09:46 Dyrcona Or, Dancer...Though they were interesting choices.
09:46 jeff i like that sipserver isn't inlined within Evergreen, but maybe i'm weird.
09:47 JBoyer I was kind of thinking in the back of my head "complete re-write," but didn't want to say it right out loud. ;)
09:47 jeff well, i am weird, but that's not what i meant here...
09:47 Dyrcona JBoyer: Just the front end would need to change.
09:48 JBoyer Yeah, complete might be a bit much. Significant would probably be more apt.
09:48 Dyrcona jeff: I just threw that up on the bug to see if it sticks.
09:49 Dyrcona Though, if we're not concerned about compatibility with other ILS's, then a complete rewrite as a mod_perl module for NCIPServer would be in order.
09:50 Dyrcona Then, we could have it support NCIP 1.x and 2.x, and have support for different profiles or whatever via configuration. :)
09:50 JBoyer I thought benefits like that might come along for the ride, yes. :)
09:50 Dyrcona Staring out by "merging" iNCIPit and NCIPServer, but not by actually merging.
09:51 Dyrcona heh. Starting out... ;)
09:51 JBoyer And jeff, while it's nice that SIPServer *can* exist separate from Evergreen I don't think it provides much benefit if no one else uses it.
09:52 Dyrcona I think we'd have to leave the repo there for sites that haven't upgraded, but it would not necessarily be maintained.
09:54 Dyrcona Dancer is fun, and I suppose rangi was able to separate the Koha driver enough from Koha so that a full installation wasn't necessary.
09:55 Dyrcona I didn't have time for that, so I came up with the Plack configuration to work it into an existing Evergreen installation.
09:57 Dyrcona Oh my... They're talking about Plack in #koha over at oftc.net. :)
09:57 Dyrcona Funny how that happens.
09:58 rlefaive joined #evergreen
10:00 * jeff spins vague requests into reports
10:01 Dyrcona jeff: You see my bug updates? I think my fix for LP 1463943 and LP 1542495 also fixes LP 1628995.
10:01 pinesol_green Launchpad bug 1463943 in SIPServer "Non-ascii Unicode characters in messages cause SIP client problems" [Undecided,Confirmed] https://launchpad.net/bugs/1463943
10:01 pinesol_green Launchpad bug 1542495 in SIPServer "OpenILS::SIP::clean_text() can crash" [Undecided,Confirmed] https://launchpad.net/bugs/1542495 - Assigned to Jason Stephenson (jstephenson)
10:01 pinesol_green Launchpad bug 1628995 in SIPServer "SIPServer can incorrectly calculate output message length, which can lead to clients hanging" [Medium,Confirmed] https://launchpad.net/bugs/1628995 - Assigned to Jeff Godin (jgodin)
10:01 Dyrcona Turns out an encoded string is treated as bytes.
10:17 catherinedevlin joined #evergreen
10:24 maryj joined #evergreen
10:42 tsbere joined #evergreen
10:56 kmlussier berick++ # Holds pull list sorting and other nice web client fixes over the past week.
11:00 berick thanks for the feedback kmlussier.
11:00 * berick curious how the pull list performs for others
11:25 jeffdavis joined #evergreen
11:39 Christineb joined #evergreen
11:42 Bmagic I know I have had this thought before. When a circulation is created and the due date lands on a day that the library is closed, then the library adds that due date. The fine generator still charges fines for that circulation?
11:43 Bmagic sorry, the library adds that closed date (after the checkout)
11:46 Bmagic It's only when the library changes the "hours" that the fine generator will not act on a circulation that is due on a day where the library is closed (say Mondays for example)
11:51 Dyrcona Bmagic: Could be. Closed dates are taken into account when calculating due dates.
11:52 Bmagic But not generating fines
11:52 Dyrcona Bmagic: There's a setting to not charge fines on closed days. That  might help, but it will start charging on the next open day.
11:52 Dyrcona Bmagic: You can also add a grace period to the circ_matrix_matchpoints or loan rules.
11:53 Dyrcona MVLC typically used a 1 day grace period for daily fines.
11:53 Dyrcona When libraries would add a closed day, and I knew about it, I'd often run a SQL to update due dates for their items due on that day.
11:53 Bmagic Right, thanks. My head is still fuzzy from being on vacation for 2 weeks
11:54 Dyrcona Usually, they'd call or open a ticket asking for the change.
11:56 Dyrcona berick++ # For finding hungry cstores.
12:03 brahmina joined #evergreen
12:10 catherinedevlin joined #evergreen
12:20 jihpringle joined #evergreen
12:27 csharp @play hungry hungry cstores
12:27 pinesol_green csharp: What we have here is a failure to communicate.
12:30 berick heh, i think the cstores are the marbles in this analogy
12:38 JBoyer There's also "Don't Break the CStores" which is a good game because, please, DON'T break those.
12:38 berick JBoyer: upgrade went OK?
12:40 JBoyer Splendidly. From a 2.9 to 2.11 db in less than 10 minutes. (not counting the pingest, of course) Would have been even better had I not just overlaid 2M+ records and caused so much table bloat that I almost ran the volume out of space last night. :/
12:41 JBoyer Still working on mitigating that but things aren't dire anymore.
12:41 csharp JBoyer++
12:42 csharp JBoyer: 10 minutes!? my test runs have taken 2-3 hours
12:42 csharp 2.9.1 - 2.11.1
12:42 JBoyer Had we it to do over again, we probably wouldn't have made a lot of noise about the email receipt feature because no one realized it didn't work with the XUL client. Might have to see how hard it is to wedge in there later. :/
12:43 csharp (we're upgrading over MLK weekend)
12:44 JBoyer I had several thousand lines worth already in our db because I wrote them. ;) (Also, the reingest took bloody ages but I don't generally count that since you can spin services back up while that's running.)
12:45 csharp reingest (pingest.pl with 16 children, batches of 10K) took about 36 hours in my test run
12:47 JBoyer Oh, yes, and as far as our highly misaligned ccvm and ccaed tables, I cloned them from a fresh stock db and replaced everything with an id < 10000 pre-reingest. Now all of our translations line up and we won't have to special case every single new locale or es-ES update that comes along.
12:49 JBoyer csharp, if there's enough time before we "open" again I'll let pingest burn through 35 out of 40 cores. It still only hits a load of around 20 but I don't want to risk it getting too much closer to 40 in case things start taking more oomph than expected..
12:52 csharp hmm - we have 64 cores, so maybe I should up the child count
12:52 JBoyer csharp, oh, and re the 10 mins, that was the DB only. Rebuilding the software itself is obviously slower than that. In the past though we've been at multiple hours for the db alone because we waited too long.
12:52 csharp in the past I've hit table deadlocks with too many concurrent children
12:52 JBoyer too long between upgrades, that is.
12:52 csharp I see
12:54 JBoyer I've had no problems with up to 35, but yeah, if you've hit deadlocks with too high a number maybe play it safer than the 50 or so that I would have tried not knowing that.
13:02 NawJo joined #evergreen
13:02 Dyrcona I've never run pingest with more than 16 --max-children, fwiw.
13:02 Dyrcona Our wal archiving couldn't take that many at the time.
13:03 Dyrcona At some point, you're likely to become I/O bound.
13:04 Dyrcona In the database, that is.
13:55 jvwoolf joined #evergreen
13:59 jeff Interesting/annoying: OS X 10.12.2 running a XUL client seems to lose the menu bar after logging in.
14:04 Bmagic jeff: good timing, I was just talking about the mac client with someone
14:04 Bmagic I heard that most mac users emulate windows for the staff client (wine for mac?)
14:06 jeff A long time ago we used winebottler to make a (2.2, maybe?) XUL client for our mac users. It ran faster at the time, but had some limitations. It then no longer ran faster the next time we upgraded, so we went back to the non-winebottler option.
14:06 jeff Now I suspect that my solution for the "OS X too new to run old XUL, not yet ready to use web client" problem is going to involve guacamole.
14:09 mmorgan joined #evergreen
14:09 berick jeff: even more interesting, i don't see the same thing here.  same os x version.
14:11 jeff well, the good news there might be that moving these two affected workstations to a newer client might help. i think they're still running a 2.7 build that works by virtue of a server-side symlink.
14:11 jeff (or it's not really the OS after all)
14:11 berick fwiw i'm not using a community build, i'm using a custom script that does pretty much the same thing
14:11 JBoyer I didn't see that either with my (admittedly limited) testing on my mac over the weekend. I also may not be packaging the latest "supported" version of XULRunner in my package, which one was included in the client that had the disappearing menubar?
14:14 jeff according to Contents/Frameworks/XUL.framework/Versions in each app bundle, the 2.7 and 2.10 apps i have handy are both 14.0.1
14:18 JBoyer I can't really check until almost 5 or 6, but I'm curious if a different version would have an effect on the transparent background problem even if it turns out this issue is something local.
14:35 phasefx_ joined #evergreen
14:36 dkyle joined #evergreen
14:38 collum_ joined #evergreen
15:02 mmorgan1 joined #evergreen
15:38 NawJo joined #evergreen
16:40 Dyrcona Am I right that the services listed in opensrf_core.xml are basically ignored in favor of opensrf.xml?
16:46 mmorgan joined #evergreen
16:47 mmorgan2 joined #evergreen
16:48 tsbere Dyrcona: Er, which services?
16:49 Dyrcona The open-ils services.
16:49 Dyrcona I guess the file calls them applications.
16:49 tsbere I was under the impression that those were not ignored as opensrf.xml has no public/private switch
16:51 Dyrcona You're probably correct.
16:51 Dyrcona I'll have to look at it some more tomorrow.
16:51 Dyrcona I'm not having any issues, just comparing configurations across twenty some odd servers. :)
17:01 pinesol_green News from qatests: Test Success <http://testing.evergreen-ils.org/~live>
17:07 mmorgan2 left #evergreen
17:15 brahmina joined #evergreen
17:29 rlefaive joined #evergreen
17:39 bshum "I'm not having issues" (yet)
17:53 jvwoolf left #evergreen
17:58 maryj joined #evergreen
19:04 miker Dyrcona: _core says "these are public". the other is the full service list

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