| Time |
Nick |
Message |
| 01:00 |
|
dbwells joined #evergreen |
| 01:00 |
|
remingtron joined #evergreen |
| 02:14 |
|
dbwells joined #evergreen |
| 02:14 |
|
remingtron joined #evergreen |
| 02:22 |
|
dbwells joined #evergreen |
| 03:27 |
|
StomproJ joined #evergreen |
| 05:05 |
|
Stompro joined #evergreen |
| 05:41 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:46 |
|
mtate joined #evergreen |
| 06:46 |
|
eeevil joined #evergreen |
| 06:47 |
|
Callender joined #evergreen |
| 06:47 |
|
phasefx joined #evergreen |
| 06:48 |
|
graced joined #evergreen |
| 07:30 |
|
sarabee joined #evergreen |
| 07:37 |
|
Stompro joined #evergreen |
| 07:39 |
|
graced joined #evergreen |
| 07:41 |
|
gsams joined #evergreen |
| 07:54 |
|
jboyer-isl joined #evergreen |
| 08:19 |
csharp |
I learned from GPLS IT yesterday that the BOR has replaced a large part of its network infrastructure, including its DNS servers, so what we were seeing on lupin was related to that |
| 08:20 |
csharp |
the same issue took down GALILEO (our statewide online reference database provider) for most of that day |
| 08:20 |
csharp |
but, as I understand it, the issue is resolved, and we can reinstate the BOR nameserver addresses if desired (though I'm always fine with 8.8.8.8/8.8.4.4 |
| 08:20 |
csharp |
) |
| 08:21 |
|
akilsdonk joined #evergreen |
| 08:21 |
csharp |
gmcharlt: jeff: bshum: others:^^ |
| 08:21 |
csharp |
@who is one of The Others? |
| 08:21 |
pinesol_green |
Stompro is one of The Others. |
| 08:26 |
|
tspindler joined #evergreen |
| 08:38 |
|
mrpeters joined #evergreen |
| 08:38 |
|
mmorgan1 left #evergreen |
| 08:42 |
|
mmorgan joined #evergreen |
| 08:52 |
|
Dyrcona joined #evergreen |
| 08:53 |
jboyer-isl |
If The Others isn’t already a band name, it should be. |
| 08:58 |
|
jwoodard joined #evergreen |
| 09:03 |
|
RBecker joined #evergreen |
| 09:11 |
jeff |
csharp++ thanks |
| 09:15 |
|
sarabee joined #evergreen |
| 09:24 |
|
komal joined #evergreen |
| 09:34 |
bshum |
csharp++ |
| 09:35 |
|
yboston joined #evergreen |
| 10:20 |
csharp |
my wife wants the two of us to dress up in Dharma Initiative coveralls for Halloween, but I don't think that's going to happen ;-) |
| 10:43 |
|
dreuther_ joined #evergreen |
| 11:07 |
gmcharlt |
csharp: unexpected network maintenance FTW! |
| 11:07 |
gmcharlt |
csharp: thanks for the update |
| 11:12 |
|
sandbergja joined #evergreen |
| 11:27 |
|
whargrove joined #evergreen |
| 11:27 |
|
vlewis joined #evergreen |
| 11:28 |
|
vlewis_ joined #evergreen |
| 11:28 |
|
buzzy joined #evergreen |
| 11:30 |
eeevil |
csharp: IMO, let google share the load :) |
| 11:32 |
csharp |
eeevil: agreed |
| 12:01 |
jboyer-isl |
When the memory leak issues were being worked on, was any work necessary/done in patron registration/editing? |
| 12:02 |
Dyrcona |
I believe so. |
| 12:02 |
Dyrcona |
But I was not directly involved. |
| 12:02 |
jboyer-isl |
Since upgrading to 2.5.2 we’ve seen this happen with each new migration: Library edits tons of users (new evergreen cards to replace their old card) and still after 10-20 edits a 4GB machine is locked up until the client is killed. |
| 12:03 |
Dyrcona |
Umm, why are they replacing cards like that? |
| 12:03 |
jboyer-isl |
Dyrcona: I’m wondering if someone might have been missed since normally a lib doesn’t make many edits, but at the beginning of a new migration there are tons of edits all the time. |
| 12:04 |
Dyrcona |
jboyer-isl: Something is always missed. |
| 12:04 |
jboyer-isl |
It’s a good time to make sure that all of the data is current (addresses, etc.) and we have a consortium-wide card that everyone uses. |
| 12:05 |
mmorgan |
jboyer-isl: So you are linking this to edits of patron records, not patron searches? |
| 12:06 |
jboyer-isl |
mmorgan: Unfortunately I’m working with second hand info, I don’t know if they’re pulling them up by the old card or searching. I’ll try to find out. |
| 12:06 |
mmorgan |
we had seen issues with leaving a tab open with the search screen, had not looked at editing records as being a problem. |
| 12:06 |
mmorgan |
but we still have libraries reporting freezing and can't relate that directly to the searching. |
| 12:10 |
jboyer-isl |
I heard back, and they’re being pulled up by barcode, so it shouldn’t be the search screen thing. |
| 12:14 |
|
komal joined #evergreen |
| 12:29 |
|
nhilton joined #evergreen |
| 12:31 |
|
sandbergja joined #evergreen |
| 12:33 |
|
sandbergja joined #evergreen |
| 12:34 |
mmorgan |
jboyer-isl: we're on 2.6.2, in a highly unscientific test, I just edited barcodes on 20 patrons on our training system and didn't freeze up. Are you able to reproduce?mmmpooj |
| 12:34 |
mmorgan |
oops, sorry about that last... |
| 12:35 |
jboyer-isl |
mmorgan: I’ve started poking around at our migration server but I’m also on a Mac here, so there are multiple variables now. |
| 12:36 |
mmorgan |
never a shortage of variables :) |
| 12:38 |
mmorgan |
freeze ups have been an ongoing elusive problem, we've never looked at patron edit, but we'll keep it in mind to look at now. |
| 12:39 |
Dyrcona |
typos-- |
| 12:44 |
jboyer-isl |
Well, It may not be ram related. I edited maybe 7-8 accounts and the client is completely locked up, only 390MB in use on a 16GB machine. :-/ |
| 12:49 |
mmorgan |
Wow! Are you just editing barcodes? |
| 12:50 |
Dyrcona |
jboyer-isl: Did you say you were doing this on a Mac Book? |
| 12:51 |
jboyer-isl |
I did my personal test on an iMac, the actual issue is on Windows PCs at our new member. |
| 12:51 |
jboyer-isl |
mmorgan: I edited barcodes and added 1 day to their birthdays as if there were other edits to make. |
| 12:52 |
Dyrcona |
Well, I would not be surprised if XulRunner has more problems on a Mac than on other platforms. |
| 12:52 |
Dyrcona |
In my sporadic, and unscientific testing, it certainly appears to. |
| 12:53 |
jboyer-isl |
Dyrcona: I wouldn’t be surprised either, though I am surprised I got it to break. I can’t seem to ever run into problems when I’m trying to. |
| 12:54 |
Dyrcona |
Well, that often happens when you want something to go wrong it doesn't. That usually means your initial impression of the problem is wrong. |
| 12:55 |
Dyrcona |
But, for anyone following the bug email, I solved my Z39.50 problem. I made a typo in the config. |
| 12:56 |
Dyrcona |
I can also say that using Yaz4 or Yaz5 from the Index Data repository works. |
| 12:57 |
jeff |
? cheers for ch?racter encoding! |
| 12:58 |
jeff |
insert_grouped_field seems to be failing on some bad data. not-quite-utf8 in one subfield results in failure to place data in another subfield. |
| 13:04 |
Dyrcona |
alias data="garbage --in --out" |
| 13:05 |
|
whargrov1 joined #evergreen |
| 13:06 |
jeff |
decode_utf8() |
| 13:07 |
Dyrcona |
That function is failing? |
| 13:09 |
jeff |
nope. i needed a call to it. :-) |
| 13:17 |
Dyrcona |
Ah. |
| 13:24 |
|
kmlussier joined #evergreen |
| 13:32 |
|
StephenGWills joined #evergreen |
| 13:35 |
kmlussier |
Hello #evergreen! |
| 13:37 |
kmlussier |
Sending along a reminder to fill out the Bug Squashing Day Doodle poll. http://doodle.com/37t68334m82qb5it |
| 13:37 |
kmlussier |
Monday, Nov. 10 looks like the best day so far. |
| 14:01 |
|
whargrove joined #evergreen |
| 14:02 |
|
nhilton joined #evergreen |
| 14:08 |
|
vanya joined #evergreen |
| 14:12 |
|
StephenGWills left #evergreen |
| 14:29 |
|
StephenGWills joined #evergreen |
| 14:39 |
vanya |
Can someone please tell me how to create an evergreen Wiki account? |
| 14:39 |
kmlussier |
vanya: I can set one up for you. |
| 14:40 |
vanya |
Oh! That would be great! Thank you :D |
| 14:40 |
kmlussier |
Should I use your gmail address? |
| 14:42 |
vanya |
Yes, please. |
| 15:01 |
|
dreuther joined #evergreen |
| 15:04 |
jeffdavis |
after switching memcached to a different server, I'm seeing errors like this in our apache logs: |
| 15:04 |
jeffdavis |
osrf_http_translator: [ERR :14623:osrf_cache.c:63:141391557514623433] Failed to cache key:value [0.78049960034182131413917092970]:[{"ip":"some-ip-address","jid":"opensrf private.localhost/open-ils.pcrud_drone_appserver_blahblah","service":"open-ils.pcrud"}] - SYSTEM ERROR |
| 15:04 |
jeffdavis |
always for pcrud |
| 15:04 |
jeffdavis |
anyone seen something like this before? |
| 15:12 |
jboyer-isl |
jeffdavis: just to be sure, did you change the memcache address in /etc/apache2/eg_vhost.conf? It’s separate from /openils/conf/opensrf.xml |
| 15:15 |
jeffdavis |
jboyer-isl: Ah, thanks! It was changed in our repo for config files, but the updated eg_vhost.conf wasn't actually deployed to our EG servers. *facepalm* |
| 15:17 |
jboyer-isl |
Good to hear it was something simple! |
| 15:22 |
bshum |
berick++ # fun to read about https://bugs.launchpad.net/opensrf/+bug/1383828 |
| 15:22 |
pinesol_green |
Launchpad bug 1383828 in OpenSRF "Jessie / Trusty enable mpm_event by default" (affected: 1, heat: 6) [Undecided,New] |
| 15:23 |
kmlussier |
bshum: Isn't it the middle of the night there? |
| 15:23 |
bshum |
berick: I think the Evergreen readme notes this as a step for configuring Apache. Maybe we can remove that step once that code makes its way to OpenSRF. |
| 15:23 |
bshum |
See Evergreen Readme, step 9? |
| 15:24 |
bshum |
Or was it 8,hmm |
| 15:24 |
bshum |
Hard to tell on a phone screen on a sucky Edge network |
| 15:25 |
bshum |
kmlussier: Yeah I just got up for a minute and was reading. |
| 15:26 |
berick |
bshum: ah, so it does. didn't realize that. still prefer automating it, fwiw |
| 15:26 |
bshum |
Oh definitely. Automation ftw |
| 15:26 |
dbs |
bshum: 8.5.d |
| 15:27 |
bshum |
dbs++ # thanks |
| 15:27 |
dbs |
8.5.d says so much about the complexity of our install process :) |
| 15:32 |
|
dreuther_ joined #evergreen |
| 16:03 |
|
dreuther joined #evergreen |
| 16:10 |
|
whargrove joined #evergreen |
| 16:28 |
|
tspindler left #evergreen |
| 16:31 |
|
whargrove joined #evergreen |
| 16:35 |
eeevil |
berick: re mpm, we probably do want event for the websockets instance |
| 16:36 |
eeevil |
hrm... nm, nope |
| 16:36 |
|
ldwhalen joined #evergreen |
| 16:37 |
|
whargrove left #evergreen |
| 16:50 |
* jeff |
curses acp.circ_modifier not being NOT NULL |
| 16:51 |
jeff |
(even if there's probably a perfectly good reason for it) |
| 16:55 |
tsbere |
jeff: Wait, what? |
| 16:56 |
tsbere |
jeff: NULL would mean "has no circ modifier" - Unless you think *every copy ever* should have a circ modifier? |
| 16:57 |
Dyrcona |
Mine allows NULL. |
| 16:57 |
Dyrcona |
And I doubt that is a cusomization. |
| 16:57 |
Dyrcona |
customization, even. |
| 16:59 |
Dyrcona |
Anyway, time to go. |
| 17:02 |
eeevil |
jeff: IIRC, it was originally NOT NULL and became NULLABLE at some point |
| 17:04 |
|
kmlussier joined #evergreen |
| 17:08 |
jeff |
tsbere: nope, just the usual '' vs NULL gotchas like circ_modifier NOT IN ('FOO', 'BAR') also not matching NULL values. rookie mistake on my part. :-) |
| 17:25 |
|
AliceR joined #evergreen |
| 17:31 |
|
kmlussier joined #evergreen |
| 17:34 |
|
mmorgan left #evergreen |
| 17:44 |
|
dreuther_ joined #evergreen |
| 17:51 |
|
ldwhalen joined #evergreen |
| 17:54 |
|
PotatoePants joined #evergreen |
| 20:25 |
|
phasefx joined #evergreen |
| 20:25 |
|
Callender joined #evergreen |
| 20:25 |
|
rangi joined #evergreen |
| 20:25 |
|
ldw joined #evergreen |
| 20:26 |
|
eeevil joined #evergreen |
| 20:26 |
|
mtate joined #evergreen |
| 21:01 |
|
akilsdonk_ joined #evergreen |
