| 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 |
