| Time |
Nick |
Message |
| 00:36 |
|
jihpringle joined #evergreen |
| 00:52 |
|
bmills joined #evergreen |
| 07:28 |
|
rjackson_isl joined #evergreen |
| 07:49 |
|
Stompro joined #evergreen |
| 08:07 |
|
ericar joined #evergreen |
| 08:09 |
|
JBoyer joined #evergreen |
| 08:25 |
csharp |
Bmagic: regarding DB differences between 2.8.2/2.9.1 and autosuggest, what's more likely (from our experience with moving to 9.3 and 9.4) is that the query planner in postgres is working differently than before - if you have (or can assemble) a test server with the old version of EG/PG, you might be able to track the difference in the queries created - then it's a matter of DB and EG query tuning |
| 08:43 |
|
mmorgan joined #evergreen |
| 08:46 |
|
mrpeters joined #evergreen |
| 09:05 |
|
Dyrcona joined #evergreen |
| 09:08 |
kmlussier |
Good morning #evergreen! |
| 09:15 |
kmlussier |
berick++ # Angular patron editor is looking very nice! |
| 09:24 |
Dyrcona |
Good morning, kmlussier. |
| 09:24 |
Dyrcona |
I was just going to mention that I updated my dev server with the latest changes to the sprint2-sprint3 branch. |
| 09:26 |
Bmagic |
csharp: That is what we were thinking! Thanks for the tip! |
| 09:28 |
kmlussier |
Dyrcona: Thanks! I was just poking around there. |
| 09:29 |
Bmagic |
csharp: one problem is it's not a table, it's a function |
| 09:29 |
Dyrcona |
kmlussier: I just copied the changed files in place. I think that is all that was needed. |
| 09:30 |
kmlussier |
Dyrcona: I think it was a bad idea to ask you to load those additional branches. There is a bit of funkiness in one of the displays, and I have no idea which branch might have caused it. |
| 09:31 |
kmlussier |
I'm fairly sure it's not the sprint2-sprint3 branch or the patron editor branch. |
| 09:31 |
Dyrcona |
That happens. :) |
| 09:31 |
Dyrcona |
It could be that I need to do the install dance, too. |
| 09:31 |
Dyrcona |
Not sure if copying the files was enough, really. |
| 09:33 |
Dyrcona |
I'll run the npm install and other commands and do a make install just to see. |
| 09:34 |
|
yboston joined #evergreen |
| 09:34 |
Dyrcona |
Hmm. That's not good: PhantomJS 1.9.8 (Linux 0.0.0): Executed 27 of 27 (27 FAILED) ERROR (0.335 secs / 0.065 secs) |
| 09:34 |
Dyrcona |
Happened with grunt all. |
| 09:35 |
Dyrcona |
I wonder if I'm just hitting it at a bad time again. |
| 09:36 |
Dyrcona |
The real problem is not in my scroll back buffer. |
| 09:36 |
csharp |
Bmagic: in psql you might do a \df+ on the function (\x for readability first) and explain analyze the isolated SQL |
| 09:37 |
kmlussier |
Dyrcona: On another topic, I'll try to put my eyes on the code from bug 1499123 this week. |
| 09:37 |
pinesol_green |
Launchpad bug 1499123 in Evergreen "Ability to Ignore Certain Standing Penalties Within a Proximity to the Patron's Home Library" [Wishlist,New] https://launchpad.net/bugs/1499123 |
| 09:38 |
|
maryj joined #evergreen |
| 09:38 |
Dyrcona |
Hmm. It appears to blow up on idl2js with phantom.js talking to karma. |
| 09:38 |
Dyrcona |
Wonder if it did that yesterday and I missed it. |
| 09:38 |
Dyrcona |
kmlussier: Thanks! |
| 09:40 |
Dyrcona |
I don't really have time to sort this right now. I'd have to do a clean install. It could be something going on with running the scripts twice. |
| 09:47 |
JBoyer |
Dyrcona: Does it have that problem with just grunt build, or only grunt all? Skipping the tests may not be ideal, but if it gets things moving on your test server it could always be investigated later. |
| 09:48 |
Dyrcona |
JBoyer: Good question, and if I knew enough about it, I would have tried that before blowing out the VM and building a fresh one. :) |
| 09:48 |
Dyrcona |
JBoyer: Don't think I'm intelligent. I am only a bot following a script. :) |
| 09:49 |
* Dyrcona |
is a total newb when it comes to Node.js and friends. |
| 09:50 |
JBoyer |
Me too, but I happened to run into something similar on my dev server sometime back |
| 09:52 |
Dyrcona |
Well, I'm going to build again without a couple of the extra branches. |
| 09:53 |
Dyrcona |
I was really loading too many: 15 MVLC customization branches (though 4 or 5 are just configuration) and 7 development branches. |
| 09:56 |
Dyrcona |
Our customizations branches don't usually cause problems because we stay on top of that. |
| 09:59 |
Dyrcona |
BTW, kmlussier, I've been loading the branch from the LP bug you sited for some time on my development system. |
| 09:59 |
* kmlussier |
nods |
| 09:59 |
Dyrcona |
sited...cited...sighted? English..... |
| 10:05 |
|
jwoodard joined #evergreen |
| 10:19 |
Dyrcona |
I'm not so sure grunt all succeeded clean. |
| 10:19 |
Dyrcona |
It flashed by too quickly. |
| 10:20 |
Dyrcona |
When this finishes, I'll try just grunt build. |
| 10:22 |
Dyrcona |
Ah, great... Now, it won't download nsis..... |
| 10:22 |
Dyrcona |
So, I'm going to work on something else. |
| 10:23 |
Dyrcona |
Or, rather the access control stuff for nsis. |
| 10:41 |
mmorgan |
Sigh. Whenever I think I understand how to follow data paths in the fm_IDL, it never works. I'm always breaking my action triggers :-( |
| 10:43 |
mmorgan |
Trying to add a barcode to the trigger money.payment_receipt.print, but adding xact.circulation.target_copy to the environment breaks the trigger. |
| 10:46 |
berick |
mmorgan: it shouldn't matter, but try changing the existing xact.circulation entry to xact.circulation.target_copy instead of adding a new environment entry. |
| 10:46 |
berick |
you only need the longer of the two |
| 10:48 |
mmorgan |
berick: ok, will give that a try... |
| 10:52 |
mmorgan |
Hmm. Internal server error :-( Lemme try again. |
| 10:54 |
|
Christineb joined #evergreen |
| 10:56 |
mmorgan |
Nope. Changing xact.circulation to xact.circulation.target_copy results in an internal server error. Maybe the logs will have something useful. |
| 10:57 |
berick |
mmorgan: crazy. all you changed was the environment? |
| 10:57 |
berick |
not the template |
| 10:57 |
berick |
? |
| 10:59 |
mmorgan |
Yes, just the environment. When I added xact.circulation.target_copy to the environment before, I got a message in the opac in red that it couldn't create the receipt. Somewhat friendlier, but still failure. |
| 11:00 |
berick |
odd, yeah, logs should have a message |
| 11:05 |
Dyrcona |
mmorgan: There's some configuration for action triggers somewhere that says what is fleshed. |
| 11:05 |
Dyrcona |
mmorgan: You probably need to flesh xact.circulation.target_copy. |
| 11:06 |
Dyrcona |
Or maybe xact.circulation.... |
| 11:06 |
Dyrcona |
Not sure. |
| 11:07 |
berick |
Dyrcona: the fleshing (adding it to the environment) is what appears to be causing the problem. |
| 11:07 |
berick |
no template changes have been made, just env changes. |
| 11:08 |
Dyrcona |
maybe do xact.circulation.target_copy.barcode ? |
| 11:09 |
tsbere |
mmorgan: If you want you can email me the template data and I will take a look? |
| 11:09 |
* Dyrcona |
doesn't mess with templates much. |
| 11:09 |
* tsbere |
has had this kind of issue before |
| 11:10 |
tsbere |
Granted, the last time I had it was with an emailed template, but the same issues tend to apply |
| 11:12 |
dbwells |
berick: So, new auth code has been a mild disaster here. Boils down to changes made to oilsAuthCheckLoginPerm(). |
| 11:12 |
berick |
dbwells: uh oh! |
| 11:13 |
* mmorgan |
got pulled away for a bit. |
| 11:13 |
dbwells |
berick: The old code had the org_unit hardcoded to -1, which apparently searches and finds the root org. The new code passes through whatever you pass in. |
| 11:13 |
bshum |
mmorgan: To add a barcode to the template I wouldn't expect a need to change the environment beyond the default of xact.circulation. I would just add the variable to the template like what Dyrcona wrote |
| 11:13 |
dbwells |
berick: I guess we have a lot of logins which don't pass an org_id at all, which then end up getting the perm checked at '0', which fails. |
| 11:13 |
bshum |
xact.circulation.target_copy.barcode |
| 11:14 |
berick |
dbwells: ugh, ok, so if the code finds org_id == 0, set it to -1 to recover the default behavior? |
| 11:15 |
pastebot |
"berick" at 64.57.241.14 pasted "like this dbwells?" (10 lines) at http://paste.evergreen-ils.org/17 |
| 11:16 |
dbwells |
berick: That sounds like the right idea. I guess I am kinda surprised it never honored the org id for perm checking in the first place. |
| 11:16 |
berick |
bshum: you don't need to flesh .barcode |
| 11:16 |
berick |
bshum: since it's not an object unto itself. it's just a string |
| 11:16 |
mmorgan |
bshum: so looking at circ in the idl, I don't see barcode there. Will give it a try, but still trying to understand how it all works. |
| 11:17 |
bshum |
berick: In the template definition? |
| 11:17 |
berick |
dbwells: want me to push that change or are you adding it to your patches? |
| 11:17 |
bshum |
I was saying template definition, not environment. |
| 11:17 |
berick |
bshum: sorry. ignore me. i'm butting in w/o context |
| 11:18 |
berick |
bshum: thought we were still in the pre-template-changes phase of this |
| 11:18 |
bshum |
no worries, I'm only looking at things on my phone while I contemplate lunch options... |
| 11:18 |
dbwells |
berick: Go for it, it's definitely an improvement. I'm still mulling over a bit what it might mean to now treat those perms as scoped in a way we didn't before. |
| 11:19 |
berick |
dbwells: yeah, that's a good question. to reduce disruption, it might make more sense for now to keep the old behavior |
| 11:19 |
tsbere |
mmorgan: Just for reference, if when you added xact.circulation.target_copy to the environment (so that .barcode would work off of it) your template had *existing* references to xact.circulation.target_copy you need to add .id to those |
| 11:20 |
|
afterl joined #evergreen |
| 11:20 |
berick |
dbwells: come to think of it, I'd be surprised if login perms were ever non-global. |
| 11:21 |
berick |
once you have an authtoken, where you were allowed to get the authtoken is irrelevant |
| 11:21 |
berick |
all that matters at that point is what perms you have to perform each action |
| 11:23 |
mmorgan |
bshum: will definitely try that in a bit, other hands are working on the template now, and I don't want to mess them up. |
| 11:23 |
dbwells |
berick: I think you are right. I've been trying to imagine when it might matter, but coming up empty. |
| 11:23 |
mmorgan |
tsbere: meaning add .id to any xact.circulation.target_copy in the template? |
| 11:23 |
bshum |
mmorgan: i think tsbere might be on something with the potential impact to environment |
| 11:23 |
berick |
dbwells: ok, I'll push a patch to recover the old all-global behavior. |
| 11:24 |
dbwells |
berick++ # sounds good, thank you |
| 11:24 |
tsbere |
mmorgan: If xact.circulation.target_copy existed in the template as a reference but not in the environment (stopping at circulation) then yes. But don't do something like xact.circulation.target_copy.id.barcode |
| 11:26 |
mmorgan |
Ok, thanks. Have a bit to go on when I can get back to it. |
| 11:26 |
mmorgan |
berick++ Dyrcona++ bshum++ tsbere++ |
| 11:30 |
kmlussier |
@decide copy or item |
| 11:30 |
pinesol_green |
kmlussier: go with item |
| 11:31 |
kmlussier |
pinesol_green: I think I'm going to have to disagree |
| 11:31 |
pinesol_green |
kmlussier: connect to host dev port 22: Connection refused |
| 11:31 |
pinesol_green |
kmlussier: I am only a bot, please don't think I'm intelligent :) |
| 11:48 |
berick |
dbwells: fix pushed. I'm working on a follow up patch to make some things more efficient. specifically, reduce the number of times we have to look up the root unit unit ID from the database and use cstore instead of storage for perm checks. |
| 11:48 |
berick |
the API call will get (intentionally) slower w/ bcrypt, so may as well make some other parts faster/leaner |
| 11:49 |
Dyrcona |
JBoyer: grunt build works. Guess it is a test that fails. |
| 11:55 |
JBoyer |
That's good. (for certain values of good...) The specific test that I had fail on me was somehow related to our fmIDL.xml file and either permissions or paths, so I wasn't too worried about it at the time, |
| 11:55 |
JBoyer |
. |
| 11:56 |
Dyrcona |
kmlussier: FWIW, my dev vm is running with the branches we discussed. |
| 11:56 |
kmlussier |
Dyrcona: Great, thank you! |
| 11:56 |
kmlussier |
Dyrcona++ |
| 11:57 |
Dyrcona |
JBoyer: I can't really make heads or tails out of the error. Seems to be something about idl2js and a lot of gibberish that looks like a really long URL and then some line number references. |
| 12:00 |
|
ohiojoe joined #evergreen |
| 12:05 |
JBoyer |
I didn't have time to figure out what was going stray either. My thinking was if there is really something wrong with the IDL or parsing it, it would be very obvious, very quickly. |
| 12:09 |
|
bmills joined #evergreen |
| 12:18 |
berick |
dbwells: fyi, pushed 2nd promised commit. |
| 12:18 |
|
kitteh__ joined #evergreen |
| 12:19 |
mrpeters |
tsbere: following up on yesterday when we talked about the error with uninitialized array's -- seems only to occur in KPAC when placing a hold |
| 12:19 |
mrpeters |
on the getit_results page |
| 12:22 |
Bmagic |
anyone had trouble with osrf_control --localhost --stop-all and acq timing out? |
| 12:23 |
berick |
Bmagic: i have seen that before. not sure what's going on |
| 12:23 |
berick |
have not investigated |
| 12:23 |
Bmagic |
it's a new thing happening with 2.9.1 |
| 12:23 |
Bmagic |
for us I should say |
| 12:24 |
* mmorgan |
has also seen that on occasion, prior to 2.9.1 |
| 12:29 |
tsbere |
mrpeters: Unless something weird like "ctx->aou_tree isn't being loaded on the results page" is happening I dunno. |
| 12:35 |
Bmagic |
berick: mmorgan: another thing i noticed is autogen returns a different hash for each app server that runs it - before it would return the same accross all of them |
| 12:39 |
jeff |
that's... interesting. |
| 12:39 |
Bmagic |
I thought so as well - doesnt seem to be a problem though, we are in production with it like that |
| 12:43 |
|
jihpringle joined #evergreen |
| 12:45 |
Dyrcona |
Bmagic: I used to have that acq timing out problem a lot, then it just stopped. |
| 12:46 |
Dyrcona |
Bmagic: It eventually gets killed, so I never figured it out. |
| 12:48 |
mrpeters |
tsbere: no worries -- im going to try to reproduce in master and then file a bug |
| 12:48 |
mrpeters |
can't help to have the db getting hit with invalid queries -- this goes back to 2.7.2 (at least) |
| 12:49 |
Dyrcona |
Bmagic: Sometimes, I think not only acq would have that problem, but I don't remember which other service. |
| 12:50 |
Dyrcona |
I haven't noticed it in several months. |
| 12:50 |
Dyrcona |
And, that would be on my development vm as well as training and production, btw. |
| 12:51 |
Dyrcona |
IOW, the behavior predates 2.9.1. |
| 12:51 |
Bmagic |
right on |
| 12:57 |
csharp |
I've seen timeouts like that when stopping opensrf services on 2.9.1, but I was chalking it up to our system instabililty |
| 12:57 |
csharp |
(which btw, has yet to reappear) |
| 13:49 |
csharp |
JBoyer: on pgbadger, do you filter out reports queries? I'm fully set up now, but I'm probably missing some slow queries because reports queries are taking up slots |
| 13:51 |
JBoyer |
csharp: I have each db separated into their own log files and run pgbadger multiple times, once for production, once for reports, etc. reports is also only logging Qs over 10 seconds or something to keep the # down. |
| 13:51 |
csharp |
got it - I was considering that approach too |
| 13:51 |
JBoyer |
Otherwise, 10-20 long running reports breaks your whole Top Queries page. :) |
| 13:52 |
csharp |
yep |
| 13:52 |
csharp |
thanks |
| 14:11 |
kmlussier |
@dessert |
| 14:11 |
* pinesol_green |
grabs some Pecan Pie for kmlussier |
| 14:27 |
JBoyer |
Quick marc_stream_importer.pl question in case anyone can remember before I find it by digging through the code: If you don't specify any match options, will it just import every record, or leave them in a queue? (using a spool file if that matters) |
| 14:30 |
berick |
JBoyer: pretty sure if you choose --import-no-match and no match_set is assigned to the selected qeue, every record in the queue will be imported as a new record. |
| 14:31 |
JBoyer |
berick, cool. I didn't know if it would work that way or if on seeing there was no way to "match" anything it would give up, dump them in the queue, and wonder off. |
| 14:32 |
yboston |
kmlussier+++ for LP 1538691 |
| 14:32 |
JBoyer |
I thought it worked that way in the client at one time, but it's been a long time since i've played with it. :0 |
| 14:32 |
pinesol_green |
Launchpad bug 1538691 in Evergreen "webclient: Consistency for terminology in cataloging" [Undecided,New] https://launchpad.net/bugs/1538691 |
| 14:40 |
kmlussier |
gmcharlt++ # For suggesting I create LP 1538691 on a separate ESI ticket. |
| 14:40 |
pinesol_green |
Launchpad bug 1538691 in Evergreen "webclient: Consistency for terminology in cataloging" [Undecided,New] https://launchpad.net/bugs/1538691 |
| 14:52 |
|
mmorgan1 joined #evergreen |
| 14:55 |
csharp |
JBoyer++ # more pgbadger/rsyslog help |
| 14:55 |
JBoyer |
Configure all the things! |
| 15:16 |
|
ericar_ joined #evergreen |
| 15:53 |
|
jlitrell joined #evergreen |
| 16:40 |
|
mmorgan joined #evergreen |
| 16:45 |
|
afterl left #evergreen |
| 17:12 |
|
jihpringle_ joined #evergreen |
| 17:16 |
|
mmorgan left #evergreen |
| 18:49 |
|
gsams joined #evergreen |
| 18:55 |
|
bmills joined #evergreen |
| 19:01 |
|
bmills1 joined #evergreen |
| 20:05 |
gmcharlt |
berick: hey, are your slides from the sqitch session you did at the hackaway online anywhere? somebody on twitter was asking about them |
| 21:21 |
|
jeff_ joined #evergreen |
| 23:08 |
|
jeff_ joined #evergreen |
| 23:13 |
|
bmills joined #evergreen |
