Time |
Nick |
Message |
00:33 |
|
roycroft joined #evergreen |
04:08 |
|
Jillianne joined #evergreen |
05:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
05:35 |
|
rlefaive joined #evergreen |
07:14 |
|
rjackson_isl joined #evergreen |
07:15 |
|
rlefaive joined #evergreen |
08:25 |
|
Jillianne2 joined #evergreen |
08:26 |
|
kmlussier joined #evergreen |
08:37 |
|
mmorgan joined #evergreen |
09:00 |
|
bos20k joined #evergreen |
09:06 |
|
jvwoolf joined #evergreen |
09:08 |
|
_adb joined #evergreen |
09:09 |
|
_bott_ joined #evergreen |
09:10 |
|
Dyrcona joined #evergreen |
09:13 |
Bmagic |
@coffee |
09:13 |
* pinesol_green |
brews and pours a cup of Kenya Gethembwini, and sends it sliding down the bar to Bmagic |
09:18 |
Bmagic |
Soooo delicious |
09:19 |
* Dyrcona |
listens to morning maniac music. |
09:21 |
|
_bott_ joined #evergreen |
09:22 |
|
_adb joined #evergreen |
09:26 |
|
rlefaive_ joined #evergreen |
09:35 |
|
jvwoolf1 joined #evergreen |
09:39 |
|
_adb joined #evergreen |
09:40 |
|
_bott_ joined #evergreen |
09:47 |
Dyrcona |
@tea |
09:47 |
* pinesol_green |
brews and pours a pot of Golden Orchid, and sends it sliding down the bar to Dyrcona (http://ratetea.com/tea/whispering-pines/golden-orchid/7244/) |
10:01 |
|
rlefaive joined #evergreen |
10:03 |
|
mmorgan1 joined #evergreen |
10:11 |
|
collum joined #evergreen |
10:23 |
Dyrcona |
emerge-files++ |
10:29 |
|
yboston joined #evergreen |
10:35 |
Dyrcona |
@coffee everyone for National ${SOMETHING} Day. |
10:35 |
* pinesol_green |
brews and pours a cup of Finca La Tacita, and sends it sliding down the bar to everyone for National ${SOMETHING} Day. |
10:36 |
berick |
@praise Nation [someone] Day! |
10:36 |
* pinesol_green |
Nation fbeaudry_ Day! is the hardest working person in #evergreen. |
10:38 |
Dyrcona |
A little bird tweeting in a meadow told me that today is National IT Professionals Day, and I had a cynical reaction. |
10:43 |
kmlussier |
It's also Talk Like A Pirate Day. |
10:43 |
* fbeaudry_ |
tips her hat to pinesol_green |
10:46 |
fbeaudry_ |
Aye, me hearties - tis indeed Talk Like a Pirate Day. |
10:46 |
fbeaudry_ |
http://www.pirateglossary.com/ |
10:47 |
gmcharlt |
QUAARRK! |
10:47 |
gmcharlt |
</quack_like_a_pirate_day> |
10:49 |
fbeaudry_ |
gmcharlt++ |
10:49 |
abneiman |
gmcharlt++ |
10:49 |
abneiman |
actual LOL |
10:50 |
Dyrcona |
@swill everyone for National Talk Like a Pirate Day |
10:50 |
* pinesol_green |
grabs a can of Sparks and sends it sliding down the bar to everyone for National Talk Like a Pirate Day |
10:55 |
csharp |
@quote add < gmcharlt> QUAARRK! </quack_like_a_pirate_day> |
10:55 |
pinesol_green |
csharp: The operation succeeded. Quote #177 added. |
10:57 |
csharp |
@quote random |
10:57 |
pinesol_green |
csharp: Quote #16: "<berick> why's it broken? just bugcause." (added by gmcharlt at 01:37 PM, October 12, 2011) |
11:22 |
|
mmorgan joined #evergreen |
11:33 |
Bmagic |
I am looking hard at some osrfsys.log logs - trying to detect why a certain action trigger is setting it to "error" |
11:33 |
Bmagic |
I have a question, is it possible for an issue with a different event definition to cause another one to be set to "error" |
11:33 |
Bmagic |
The logs seem to indicate that |
11:35 |
Bmagic |
I have the line that updates the row with "state=reacting" |
11:38 |
Bmagic |
Followed by some fleshing fields lines for another action trigger |
11:40 |
Bmagic |
followed by a perm check for setting it to lost |
11:40 |
Bmagic |
Then this line: Event reacting failed with No field by the name call_nuarcode in Fieldmapper::asset::copy! at /usr/local/share/perl/5.22.1/OpenILS/Utils/Fieldmapper.pm line 273. |
11:42 |
Bmagic |
searching the ated, I found the definition with the munched column name, but that's not related to the at that was marking something else lost, it's like the Thread crashed and affected several other ATE's |
11:44 |
Dyrcona |
Well, if memory gets garbled somehow, no telling what can happen. |
11:45 |
Dyrcona |
But, I've never seen that phenomenon before, so can't say. |
11:45 |
Dyrcona |
You checked all copies of the fm_IDL? |
11:46 |
Dyrcona |
Though that looks more like a code bug than IDL bug from the message. |
11:46 |
Bmagic |
If it's possible for AT to error other AT's when one of them has an issue, then it would all make sense |
11:47 |
Bmagic |
The error message is referencing something located in the configured template - I found the line in the ATED template and corrected it. It was perplexing because that particular ATED is not the ATED in question |
11:50 |
Dyrcona |
Did you check the template for the ATED in question? It may be borked, too. |
11:50 |
berick |
Bmagic: are the 2 related in any way -- e.g. checkout.due and lost.auto -- where one directly affects the creation of another? |
11:50 |
Dyrcona |
And, there's that. |
11:50 |
Bmagic |
berick: no, two different libraries in different system trees |
11:51 |
Bmagic |
One was overdue notice (munched column name) and the other is marking lost |
11:51 |
Bmagic |
The marking lost trigger doesn't have a template |
11:51 |
|
gsams joined #evergreen |
11:53 |
|
_adb joined #evergreen |
11:54 |
berick |
Bmagic: what are the hooks? |
11:56 |
Bmagic |
checkout.due on both |
12:02 |
|
_adb joined #evergreen |
12:07 |
berick |
just to be totally clear, none of this is threaded. (i realize you may have been using the term loosely). each event def is handled within its own process. if you're using parallel, it offloads work to drones that might be used by multiple event-defs over time, but they would never be working on 2 things at once. |
12:08 |
berick |
i've never seen a template error in one process affect another process |
12:09 |
Dyrcona |
Perl5 is not thread safe, and "threads" in Perl5 are a major kludge that blow up on all kinds of libraries, such as Encode.pm. |
12:09 |
Dyrcona |
Threads are the only reason to switch to Perl6, but in that case, I'd switch to Python 3. |
12:10 |
Dyrcona |
In short, we can't use Perl threads, so we don't. |
12:10 |
Dyrcona |
The only way that I could see one process affecting another is bad RAM, but then you got bigger problems. |
12:12 |
berick |
I have seen an oddity with the MarkItemLost reactor. I have yet to collect meaningful data, though. in short, (in parallel anyway) it can sometimes leave events stranded in the 'collected' state. commenting out the call to generate events for 'lost.auto' from within the MarkItemLost reactor fixed it. something about the combo of recursive A/T and parallel handling -- something goes haywire. |
12:15 |
Dyrcona |
Race condition on the reactors and the db? |
12:17 |
Dyrcona |
DB transaction gets committed before 1 process is really done with it and the other picks it up? (For berick's case, shouldn't happen with unrelated reactors.) |
12:18 |
Bmagic |
The logs that I am looking at sure makes me feel like one ATED is affected the other |
12:19 |
|
khuckins joined #evergreen |
12:19 |
pastebot |
"Bmagic" at 64.57.241.14 pasted "ATED's eating eachother" (74 lines) at http://paste.evergreen-ils.org/816 |
12:27 |
Dyrcona |
What in the log makes you think that? |
12:29 |
Dyrcona |
Oh.... |
12:30 |
berick |
Bmagic: you confirmed there's no message_template for this event-def? |
12:30 |
Bmagic |
yes |
12:30 |
berick |
and no call_nuarcode in the event environment? |
12:30 |
Bmagic |
do you have any marklost triggers with templates? |
12:30 |
Bmagic |
berick: right |
12:31 |
Bmagic |
call_nuarcode is only found in another template |
12:31 |
berick |
what about the event-def delay_field or usr_field? |
12:31 |
Bmagic |
id 535 |
12:32 |
berick |
? |
12:33 |
Bmagic |
the ATED 535 contained the template with the munched column name |
12:33 |
Bmagic |
not this one from the pastebin (id 579) |
12:34 |
Bmagic |
looking at the ATED for 579, nothing unusual. delay=14 days, usr_field=null |
12:34 |
berick |
and message_usr_path and message_library_path |
12:35 |
Bmagic |
select * from action_trigger.event_definition where id=579 and template is null and usr_field is null and message_usr_path is null and message_template is null and message_library_path is null |
12:35 |
Bmagic |
1 row returned |
12:36 |
berick |
k |
12:36 |
Bmagic |
furthermore, I deleted all of the error rows from ATE, and I am running the same definition again, all completing with no errors |
12:36 |
Bmagic |
no changes to the definition |
12:37 |
Dyrcona |
Mabye you found a memory/process bug in docker? :P |
12:37 |
Bmagic |
the utility machine is not running in docker |
12:37 |
Dyrcona |
The kernel, then, but I doubt it. |
12:38 |
Dyrcona |
I never do like wading though the mess of the logs, and I honestly can't say I'm convinced. I'm not dissuaded, either. Without seeing the templates, before, I can only speculate, so I'll bow out. |
12:39 |
Dyrcona |
The message about call_nuarcode is definitely coming from process 13876, though, and that was processing an event with definition id 579. |
12:40 |
Dyrcona |
Unless syslog messed up, but that's not likely, either. |
12:41 |
Bmagic |
right, I noticed that the PID was the same, but there is no way that the event definition that it was working on had call_nuarcode anywhere |
12:42 |
|
dwgreen joined #evergreen |
12:43 |
berick |
Bmagic: event def 535 is also checkout.due? |
12:43 |
Bmagic |
yes |
12:43 |
Bmagic |
they both have the same hook in common |
12:51 |
berick |
Bmagic: can you check your /openils/var/log/open-ils.trigger_stderr.log too? |
12:51 |
berick |
starting to think the logged error is a red herring |
12:51 |
|
rlefaive joined #evergreen |
12:51 |
Bmagic |
log is empty |
12:51 |
berick |
the call to set_item_lost did not complete |
12:52 |
berick |
one notable oddity is |
12:52 |
berick |
[2017-09-15 12:02:57] open-ils.trigger [INFO:13876:CStoreEditor.pm:139:] editor[1|1] request en-US open-ils.cstore.json_query.atomic {"from":["actor.org_unit_ancestor_setting",null,273]} |
12:52 |
berick |
an org setting lookup with no setting name |
12:52 |
Bmagic |
interesting |
12:53 |
berick |
I believe that is happening in AppUtils::get_copy_price() |
12:53 |
Bmagic |
makes sense |
12:54 |
berick |
there should be 3 AOUS lookup calls back to back there. there's only 1 and it looks weird |
12:55 |
berick |
suggesting it dies there |
12:58 |
berick |
hm, there should also be a copy update call after void_overdue_on_lost lookup and before the first AOUS lookup in get_copy_price, but there's not one in the logs |
12:59 |
* Dyrcona |
often finds things to be missing from the logs, particularly with syslog to a remote server. |
12:59 |
* berick |
is confuzzled but unfortunately has to step away for a bit |
12:59 |
Dyrcona |
Even after applying JBoyer's suggested configuration. |
13:02 |
mmorgan |
Bmagic: Are you using a granularity or filter in your command to run the trigger? |
13:03 |
Bmagic |
mmorgan: no |
13:03 |
* mmorgan |
thought that without one of those, all the active triggers with the same hook would be looked at. |
13:04 |
Bmagic |
mmorgan: It seems reasonable to me that these two triggers would be executing along side one another |
13:04 |
Bmagic |
and if one crashed the perl code, it could* affect the other |
13:07 |
Dyrcona |
No, it shouldn't. Each is a separate process on the O/S. It's not like there's one copy of Perl running both. It's a separate Perl process for each one. |
13:07 |
Dyrcona |
I think you have data missing from the logs. |
13:43 |
|
acautley joined #evergreen |
14:12 |
|
Dyrcona joined #evergreen |
14:15 |
kmlussier |
Bmagic / dbwells: We have a maintenance release scheduled for tomorrow. Are you both available to build? I should have release notes done first thing in the morning. |
14:15 |
Bmagic |
sure |
14:15 |
dbwells |
kmlussier: sounds fine. |
14:16 |
kmlussier |
For the 2.11 release, it looks like we have just one bug fix. This would also be the last point release for 2.11, unless we have any security fixes over the next three months. |
14:19 |
* Dyrcona |
needs a new laptop.... :( |
14:20 |
kmlussier |
Would anyone have time to review the fix for bug 1706124 before tomorrow? It's small, but would be a nice addition to the other web client fixes going out with 2.12.6. |
14:20 |
pinesol_green |
Launchpad bug 1706124 in Evergreen 2.12 "web client: include inactive option in patron search is not sticky" [Medium,Confirmed] https://launchpad.net/bugs/1706124 |
14:25 |
Dyrcona |
I can probably take a look if my laptop doesn't just shut off again. |
14:25 |
gmcharlt |
upon some discussion - release cutting for 3.0-beta2 is going to be pushed back to Thursday, so tomorrow will be a full day for last minute stuff for the beta |
14:26 |
gmcharlt |
and at this point, I'm satifisfied that we'll make the beta2 goal of having Debian Stretch support |
14:26 |
gmcharlt |
as well as likely resolution of some more i18n issues |
14:26 |
Dyrcona |
Yay! |
14:26 |
kmlussier |
That's this week too? Time flies. |
14:27 |
Dyrcona |
kmlussier: Are you looking for just a sign off or do you want it pushed? |
14:28 |
kmlussier |
Dyrcona: If it looks good to you, go ahead and push it. |
14:29 |
gmcharlt |
dbwells++ # flexibility |
14:55 |
csharp |
@band add Call Nuarcode |
14:55 |
pinesol_green |
csharp: Band 'Call Nuarcode' added to list |
15:16 |
dbwells |
Did a little research, found this: "According to Evergreen legend, the call of the Nuarcode bug is a devastating shriek able to penetrate nearby but otherwise unrelated processes. It has never been successfully logged." |
15:18 |
Dyrcona |
Anyone know why we use Class:DBI::Frozen, and why we can't just use Class::DBI? |
15:18 |
|
jvwoolf joined #evergreen |
15:19 |
csharp |
dbwells++ |
15:19 |
csharp |
@quote add < dbwells> Did a little research, found this: "According to Evergreen legend, the call of the Nuarcode bug is a devastating shriek able to penetrate nearby but otherwise unrelated processes. It has never been successfully logged." |
15:19 |
pinesol_green |
csharp: The operation succeeded. Quote #178 added. |
15:20 |
csharp |
Dyrcona: I've wondered the same thing - was told by berick recently that frozen is still required |
15:21 |
* csharp |
hasn't dug into the differences/why at all |
15:21 |
Dyrcona |
Maybe I'll take a look in my not-so-copious free time. |
15:21 |
Dyrcona |
It has been nagging at me every now and then. |
15:22 |
csharp |
it nags at me every time we build a custom deb for Class::DBI::Frozen::301 ;-) |
15:22 |
* Dyrcona |
waits a bit on npm install.... |
15:22 |
Dyrcona |
:) |
15:23 |
dbwells |
Dyrcona: I think that might have come up in our dev docs research this past year, I'll check. |
15:23 |
berick |
Dyrcona: to use regular Class::DBI requires EG code changes. I don't know what those code changes are, though. |
15:23 |
berick |
dbwells++ |
15:23 |
Dyrcona |
berick: Yes, I figured as much. |
15:23 |
berick |
Dyrcona: glad I could be of service :) |
15:24 |
Dyrcona |
:) |
15:24 |
* csharp |
wonders if that's hack-a-way-able, then looks at all the other more pressing things |
15:24 |
Dyrcona |
berick++ dbwells++ csharp++ |
15:24 |
Dyrcona |
I might take it on at the hack-away. I also want to make changes to our use of autotools in Evergreen. |
15:25 |
Dyrcona |
There are things I think we could more canonically and that would help with portability. |
15:25 |
csharp |
also way down on my TODO list is to ferret out all the C warnings during 'make' on Evergreen |
15:25 |
berick |
i'd be up for some of that, csharp |
15:25 |
csharp |
berick: awesome |
15:25 |
Dyrcona |
Well, that's easy: CFLAGS+=-werror. :) |
15:25 |
berick |
:) |
15:26 |
csharp |
yeah, dh_make fails on those unless we loosen the rules to not care about warnings |
15:27 |
Dyrcona |
Our technical debt has been on my mind lately. |
15:28 |
* csharp |
googles "technical debt"; agrees with Dyrcona |
15:29 |
|
jihpringle joined #evergreen |
15:29 |
dbwells |
d252b2d019d00068efc8277447120704a5a4fa3e is when the change happened, but not a lot of details which couldn't be inferred. |
15:29 |
pinesol_green |
dbwells: [evergreen|dbs] Provide support for Class::DBI::Frozen::301 via UNIVERSAL::require - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d252b2d> |
15:35 |
Dyrcona |
Well, that was inconsiderate of the Class::DBI maintainers. |
15:36 |
Dyrcona |
Incompatible API changes should have warranted a 4.0 release. |
15:36 |
Dyrcona |
Version numbers are meaningless. :) |
15:55 |
dbwells |
Especially in a project which renumbered 0.96 to 3.0.0 :) |
15:58 |
Dyrcona |
heh |
15:58 |
berick |
hm, browser client console showing lovefield error. error url takes me to.. |
15:58 |
berick |
Constraint error: (201) Duplicate keys are not allowed, index: Setting.pkSetting, key: "ui.staff.max_recent_patrons" |
15:59 |
berick |
anyone else getting this? |
15:59 |
Dyrcona |
So, I tested Lp 1708048 on trusty. make check succeeds for OpenSRF and Evergreen. All Evergreen live tests pass. |
15:59 |
pinesol_green |
Launchpad bug 1708048 in OpenSRF "Add support for Debian 9 Stretch" [Wishlist,Confirmed] https://launchpad.net/bugs/1708048 - Assigned to Galen Charlton (gmc) |
15:59 |
* berick |
will just try clearing localStorage |
15:59 |
Dyrcona |
I also commented on the bug, but thought this might be quicker to reach the intended audience. |
16:01 |
berick |
hm, had to delete the offline indexdb |
16:02 |
* berick |
makes mental note to look at the DB next time before clearing |
16:04 |
gmcharlt |
Dyrcona++ |
16:08 |
kmlussier |
berick: I've seen something similar, but not with max_recent_patrons. |
16:09 |
berick |
kmlussier: now i'm seeing it w/ webstaf.format.dates. guessing it has little to do with the actual setting. |
16:11 |
|
acautley joined #evergreen |
16:11 |
kmlussier |
berick: Yeah, I mentioned in #5 here - https://bugs.launchpad.net/evergreen/+bug/1706107/comments/25 |
16:11 |
pinesol_green |
Launchpad bug 1706107 in Evergreen "Offline mode for the Web Client" [Wishlist,Fix released] |
16:13 |
kmlussier |
miker mentioned further in the bug that it would be worth looking into, but I think it fell off of my radar after that. |
16:13 |
berick |
thanks, kmlussier |
16:13 |
berick |
that's the one |
16:14 |
berick |
ugh, it's preventing pages from rendering for me |
16:14 |
berick |
once I delete the DB, it clears up |
16:14 |
berick |
clearly that's not happening for everyone, though |
16:25 |
Dyrcona |
Installing rel_2_12 on xenial, grunt all gives: PhantomJS 2.1.1 (Linux 0.0.0) ERROR ReferenceError: Can't find variable: angular at /home/opensrf/Evergreen/Open-ILS/web/js/ui/default/staff/services/core.js:6 |
16:27 |
Dyrcona |
I know I can --force but I'm trying to remember what broke it last time and what the fix is. |
16:38 |
Dyrcona |
I get this from npm install, didn't see it before:make: Entering directory '/home/opensrf/Evergreen/Open-ILS/web/js/ui/default/staff/node_modules/ws/build' CXX(target) Release/obj.target/bufferutil/src/bufferutil.o bufferutil.target.mk:92: recipe for target 'Release/obj.target/bufferutil/src/bufferutil.o' failed |
16:40 |
Dyrcona |
From googling a bit, looks like an out of date dependency caught up with us. |
16:44 |
Dyrcona |
Right. I forgot bower install. |
16:45 |
* Dyrcona |
walks away whistling.... :) |
16:47 |
* kmlussier |
was about to say we don't install bower anymore, but then read up. |
16:47 |
bshum |
Yeah I didn't notice till I re-traced the steps more carefully too |
16:48 |
bshum |
More reasons that 3.0 will be the bestest Evergreen release soon enough |
16:49 |
Dyrcona |
Yeah, it's still needed on 2.12.... |
17:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
17:04 |
csharp |
dammit! A/T is totally broken |
17:05 |
csharp |
I don't have a good bead on what's happening yet, but something breaks and it's a wall of "No children available" |
17:09 |
|
mmorgan left #evergreen |
17:17 |
csharp |
we need better default (non-debug) logging for what happens when a drone is NOT CONNECTED TO THE NETWORK!!! |
17:17 |
csharp |
all I see is lalala everything's fine, then boom, off the network |
17:18 |
Dyrcona |
csharp: I've been seeing that from time to time on 2.10, still. |
17:18 |
Dyrcona |
But, I'm signing out now, to go to the gym. |
17:20 |
csharp |
even better, "hey, this drone is NOT CONNECTED TO THE NETWORK!!!, let's kill it and respawn instead of continuing to barf about it" |
17:21 |
csharp |
<ralph_wiggum>Software is hard!</ralph_wiggum> |
17:24 |
csharp |
hmm open-ils.trigger.event.gather: Deep recursion on subroutine "OpenSRF::AppSession::connect" at / |
17:24 |
csharp |
usr/local/share/perl/5.18.2/OpenSRF/DomainObject/oilsMessage.pm line 329. |
17:32 |
* csharp |
realizes that the rebuilt utility box post upgrade has half the RAM it did before |
18:14 |
|
_adb joined #evergreen |
18:16 |
|
_adb joined #evergreen |
18:26 |
|
_adb joined #evergreen |
18:28 |
|
_adb joined #evergreen |
18:32 |
|
_adb joined #evergreen |
18:44 |
|
acautley joined #evergreen |
18:46 |
|
khuckins joined #evergreen |
19:21 |
|
jvwoolf joined #evergreen |
20:32 |
pinesol_green |
[evergreen|Kathy Lussier] LP#1706124: Make include inactive patrons checkbox sticky - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3195aac> |
20:32 |
pinesol_green |
[evergreen|Galen Charlton] LP#1706124: minor tweaks - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4d202fc> |
20:47 |
|
eady joined #evergreen |
21:00 |
|
acautley joined #evergreen |
21:49 |
|
acautley joined #evergreen |
22:50 |
|
acautley joined #evergreen |
23:45 |
|
acautley joined #evergreen |
23:48 |
pinesol_green |
[evergreen|Ben Shum] LP#1629078: Add missing strings in web client for i18n - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f92437b> |