| Time |
Nick |
Message |
| 01:50 |
|
jaswinder joined #evergreen |
| 05:50 |
|
jaswinder joined #evergreen |
| 06:30 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:52 |
|
agoben joined #evergreen |
| 06:52 |
|
JBoyer joined #evergreen |
| 07:17 |
|
rjackson_isl joined #evergreen |
| 07:32 |
|
rlefaive joined #evergreen |
| 08:00 |
|
rlefaive joined #evergreen |
| 08:33 |
|
collum joined #evergreen |
| 08:43 |
|
mmorgan joined #evergreen |
| 08:57 |
|
idjit joined #evergreen |
| 09:14 |
|
yboston joined #evergreen |
| 09:17 |
|
tlittle joined #evergreen |
| 09:18 |
|
rlefaive joined #evergreen |
| 10:01 |
|
jaswinder joined #evergreen |
| 10:12 |
* bshum |
waits for the bionic beaver to come out |
| 10:21 |
|
jaswinder joined #evergreen |
| 10:24 |
|
jwoodard joined #evergreen |
| 10:26 |
|
dwgreen joined #evergreen |
| 10:27 |
Bmagic |
Is there a trick to running reports on a postgres replica? Sometimes we are getting "The row dissappeared" for long running reports |
| 10:34 |
|
bwicksall joined #evergreen |
| 10:38 |
bwicksall |
What version of Node.js should I have for Evergreen 3.0? Back when I setup my test server LTS was 6.X and now it is 8.11.1. I'm having some odd issues in the web staff client. |
| 10:38 |
JBoyer |
Bmagic, where are you seeing that and is it a postgres error or something from evergreen? |
| 10:38 |
Bmagic |
It's a postgres error that surfaces in the error message in the reporter GUI |
| 10:39 |
Bmagic |
FATAL: terminating connection due to conflict with recovery |
| 10:39 |
Bmagic |
DETAIL: User query might have needed to see row versions that must be removed. |
| 10:42 |
JBoyer |
I know there are some things you can tweak in regard to how long to delay replication that would affect current transactions, maybe those settings need to be looked at? Not certain what they are at the moment since we're not using Pg replication here yet. |
| 10:42 |
Bmagic |
bwicksall: Node.js should be automatically installed during the standard Evergreen installation procedure. |
| 10:42 |
bshum |
Yeah, and 8.x is too new |
| 10:42 |
bshum |
It should be 6.x as far as I knew |
| 10:43 |
bshum |
6.11.3, to be specific |
| 10:43 |
|
rlefaive joined #evergreen |
| 10:43 |
bshum |
(though I think there's newer 6.x versions out there now) |
| 10:44 |
bwicksall |
I've got 6.14.1 and I'm installing from master |
| 10:44 |
bshum |
8.11.1 is the latest LTS stable, but it's not compatible with Evergreen last I tried it |
| 10:44 |
bshum |
It's supposed to be pinned I thought by the makefile script |
| 10:44 |
bshum |
Unless you're installing nodejs another way, hmm |
| 10:44 |
bshum |
Or we're updating it from some package list? |
| 10:45 |
Bmagic |
JBoyer: this might be my answer https://www.postgresql.org/docs/9.0/static/hot-standby.html |
| 10:45 |
bwicksall |
I'm following the instructions on https://evergreen-ils.org/documentation/install/README_3_0.html to install from Git |
| 10:46 |
bshum |
bwicksall: Okay, are you following the step 4.1.1 where it says to get the latest Nodejs LTS? |
| 10:47 |
bshum |
I think maybe it's tripping you up if you're actually going out to get / install it |
| 10:47 |
bshum |
And not using the optional developer addition make target |
| 10:47 |
bshum |
Cause yeah, the nodejs website does have newer options available out there |
| 10:47 |
bshum |
And they're too new for Evergreen |
| 10:47 |
* bshum |
thinks we should revise that step |
| 10:47 |
bwicksall |
Yes, I'm following 4.1.1. |
| 10:48 |
bwicksall |
I'll try to roll back |
| 10:48 |
bshum |
6.14.1 should be fine, in theory. I think I tested up through 6.13 when I was poking around |
| 10:49 |
bshum |
But the makefile script is supposed to download 6.11.3 specifically |
| 10:49 |
|
kmlussier joined #evergreen |
| 10:49 |
bshum |
Which is considered "stable" from testing |
| 10:49 |
bwicksall |
Ok, se here is my problem. On the patron registration we are using org unit settings to hide alias. It will not hide on my test server. |
| 10:50 |
bwicksall |
Works find on my Equinox hosted live server |
| 10:50 |
JBoyer |
Bmagic, Yeah, I think those are what I was thinking of, but I didn't think hot_standby was necessary. May be. Setting those slightly longer than the timeout on your reports queries should prevent them from causing too much trouble. |
| 10:54 |
kmlussier |
Does anyone know why we include 260b in the author bit for the biblio fingerprint? |
| 10:55 |
bshum |
bwicksall: Hard to say then, might be code differences between versions (you said 3.0, but which .x point release is it) and whatever Equinox is running for your other instance |
| 10:55 |
bshum |
It's possible there's some bug fix or something |
| 10:57 |
bwicksall |
Equinox is running 3.0.6 and I have the issue on 3.0.4, 3.0.5, 3.0.6. I'm downgrading Node.js now. Lets see what happens |
| 10:59 |
bshum |
The version of nodejs you have would affect what happens during the compile/make/install of web client files in the next set of steps. And then that stuff all gets install later on when you do the main make install for all the rest of the Evergreen files. So follow through the rest of the steps completely to rebuild the full files for web client |
| 10:59 |
bshum |
kmlussier: Publisher? |
| 10:59 |
bshum |
Hmm |
| 11:02 |
berick |
bwicksall: are you having problems building the staff client or using the staff client? |
| 11:03 |
bwicksall |
The problems are using the client. Just a couple of small glitches that don't happen on our live site |
| 11:07 |
berick |
bwicksall: ok, that's likely not a nodejs issue. unless it threw visible errors during the build. |
| 11:07 |
berick |
node is not used at run time |
| 11:12 |
jeff |
Bmagic: I can confirm that you're on the right track with regard to your long-running queries being cancelled. This specific section of the page you already found covers the issue well (adjust to whatever version of postgres you're running): https://www.postgresql.org/docs/9.6/static/hot-standby.html#HOT-STANDBY-CONFLICT |
| 11:12 |
Bmagic |
jeff: yep! max_standby_archive_delay and max_standby_streaming_delay were set to 240s. Changed them to 2700s and the report finished |
| 11:14 |
jeff |
My understanding is that now this means other reports may show data which is up to 45 minutes "stale" when you have a long-running query that would have otherwise been cancelled. |
| 11:14 |
jeff |
So, just something to keep in mind. It may not matter for you. |
| 11:14 |
Bmagic |
yep, that is what I understood from the docs as well |
| 11:14 |
|
book` joined #evergreen |
| 11:15 |
jeff |
If fresh data is more important and you're willing to delay the actual cleanup on the primary, hot_standby_feedback would be the next thing to look into. |
| 11:16 |
Bmagic |
jeff++ |
| 11:16 |
jeff |
docs++ |
| 11:16 |
Bmagic |
JBoyer++ |
| 11:19 |
jeff |
Bmagic: did you figure out that From address issue from yesterday? I'm still curious. |
| 11:19 |
Bmagic |
jeff: lol, yes, just this morning, I decided to query the entire actor.org_unit_settings table for anything resembling the email address and I got a hit |
| 11:20 |
Bmagic |
I must have got the wrong pickup_lib ID number when using the function to find the setting or otherwise some sort of typo |
| 11:20 |
Bmagic |
so, that was dumb |
| 11:27 |
jeff |
for problems like these, a known reason is better than an unknown reason. :-) |
| 11:37 |
mmorgan |
Does anyone know offhand what generates the Browse Holds Shelf list in the client? |
| 11:39 |
mmorgan |
More specifically, filtered to the Clearable Holds |
| 11:43 |
berick |
mmorgan: open-ils.circ.captured_holds.id_list.expired_on_shelf_or_wrong_shelf.retrieve |
| 11:43 |
berick |
API call with a filter |
| 11:44 |
mmorgan |
berick++ |
| 11:44 |
mmorgan |
Thanks! |
| 11:58 |
|
jaswinder joined #evergreen |
| 12:08 |
|
jvwoolf joined #evergreen |
| 12:11 |
|
Christineb joined #evergreen |
| 12:33 |
|
derekz joined #evergreen |
| 12:40 |
|
jihpringle joined #evergreen |
| 12:41 |
dbs |
kmlussier: I guess as a fallback for those records that don't include a 700$a, 100$a, 110$a, or 111$a? Seems like it would be a very small % that would get that far... |
| 12:43 |
kmlussier |
dbs: Yeah, I need to look at this more closely, but my recollection is that it goes through the fields in the order they are listed in the MARC record, meaning the 260 would be hit before the 700, I think. |
| 12:44 |
* jeff |
scrolls back in an attempt to find context |
| 12:44 |
jeff |
ah, there it is! |
| 12:44 |
kmlussier |
I'm guessing it would get used a lot with videos. But if it does make sense to continue to include the publisher, we would need to add the 264b |
| 12:44 |
dbs |
kmlussier: ours has the 260$b at the end |
| 12:45 |
kmlussier |
dbs: In the configuration? Yes, ours does too, but when I tested it a few years ago, the order in the config didn't seem to matter. |
| 12:45 |
dbs |
oooh, right, I see |
| 12:45 |
kmlussier |
Unfortunately, I don't have much time to look at it more closely now. I also found a record that made me think authors from the 700$a weren't being added at all. |
| 12:46 |
kmlussier |
Maybe something to explore further at the hackfest! :) |
| 12:46 |
dbs |
the 700$a also needs to have a $t if I'm reading the XPath correclty |
| 12:46 |
kmlussier |
Ah, ok! I misread that. I thought it was the opposite - couldn't have a $t. |
| 12:52 |
|
kmlussier joined #evergreen |
| 13:14 |
|
jaswinder joined #evergreen |
| 13:21 |
|
jaswinder joined #evergreen |
| 13:49 |
|
alynn26 joined #evergreen |
| 13:56 |
|
rlefaive joined #evergreen |
| 14:13 |
|
alynn26_away joined #evergreen |
| 14:37 |
|
jvwoolf joined #evergreen |
| 14:44 |
|
derekz left #evergreen |
| 14:51 |
|
stephengwills joined #evergreen |
| 14:51 |
stephengwills |
Can one create a max fine rule that is percentage of book price unless price is $0 (Null), in which case set max to $15.00? |
| 14:58 |
jeff |
I think that there are org unit settings for establishing a default price in the case of a null price. I don't know if they're used when calculating max_fine percent rules. If not, they probably should be. |
| 14:58 |
* jeff |
looks |
| 15:03 |
jeff |
stephengwills: what percent do you want to use? |
| 15:04 |
stephengwills |
so, the consortium sets a max_fine at 100%…I assume that means 100% of the item price? |
| 15:04 |
jeff |
likely, yes. |
| 15:05 |
stephengwills |
but it turns out that very few of our items have the price set on them, so no the fine_generator is ignoring those circulation records. |
| 15:05 |
jeff |
do you know if you have copies with a null price or a price of 0.00? they can be treated differently. |
| 15:05 |
stephengwills |
since max_fine is set to 0 on the record |
| 15:05 |
stephengwills |
I’ll look into default value. assume that is a local settting? |
| 15:08 |
|
mmorgan joined #evergreen |
| 15:09 |
stephengwills |
Item Attribute editor, maybe? |
| 15:10 |
jeff |
"Default Item Price" in the org unit settings. |
| 15:11 |
bshum |
I thought default item price was used for acqusitions |
| 15:11 |
bshum |
Or did that start applying to copy creation too? |
| 15:11 |
jeff |
bshum: the setting in question is not used when creating new copies. |
| 15:13 |
|
rlefaive joined #evergreen |
| 15:13 |
jeff |
stephengwills: if you want to use the default price when a copy has a price of 0.00, you may need to also set "Charge lost on zero" |
| 15:14 |
bshum |
That one wins worst named org unit setting of all time in my book. |
| 15:14 |
stephengwills |
ok. I’ll play with it.thanks |
| 15:16 |
jeff |
stephengwills: when it comes to max fine amount, the settings are consulted when a circulation is created -- so you shouldn't expect to see it change existing circulations. |
| 15:17 |
jeff |
bshum: there are a number of org unit settings that have outgrown their original name. this one may have had a bit of an awkward / unclear name to begin with. :-) |
| 15:17 |
stephengwills |
if I can get it right for the future, I’m not above a quick, “update blah.blah set deleted = ’t’ for everyone” :) |
| 15:17 |
stephengwills |
thanks |
| 15:18 |
stephengwills |
or something like that. |
| 15:19 |
bshum |
stephengwills++ # my kind of SQL :D |
| 15:19 |
stephengwills |
just a step below my fav: rm -Rf * |
| 15:21 |
rjackson_isl |
rjackson_isl mumbles something about coding an rm -rf command from a perl script in a past life... |
| 15:22 |
rjackson_isl |
was exciting watching my account be deleted... |
| 15:42 |
|
jaswinder joined #evergreen |
| 15:57 |
bwicksall |
berick my earlier issues with the web client seem to be the result of insufficient caffeine. My install was working fine with Node.js 6.14.1 and it's working fine with v6.11.3 |
| 15:58 |
berick |
insufficient caffeine does have far reaching effects |
| 15:59 |
bshum |
Speaking of, I wouldn't mind bumping us to 6.14.1 in master,etc. for the base nodejs version installed via makefile target. |
| 16:00 |
bshum |
But I guess the bigger question is how we get to the next real level up :) |
| 16:36 |
|
jvwoolf left #evergreen |
| 16:46 |
|
stephengwills left #evergreen |
| 16:54 |
|
mmorgan1 joined #evergreen |
| 16:59 |
|
jaswinder joined #evergreen |
| 17:02 |
|
mmorgan1 left #evergreen |
| 17:45 |
|
jaswinde_ joined #evergreen |
| 18:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 21:42 |
|
jaswinder joined #evergreen |
| 22:13 |
|
jaswinder joined #evergreen |
| 22:55 |
|
jaswinder joined #evergreen |
