Time |
Nick |
Message |
02:40 |
|
beanjammin joined #evergreen |
03:04 |
|
vibrio12 joined #evergreen |
03:56 |
|
jeaye17 joined #evergreen |
05:27 |
|
aldum18 joined #evergreen |
05:28 |
|
lorimark joined #evergreen |
06:23 |
|
mos_basik24 joined #evergreen |
07:08 |
|
Dyrcona joined #evergreen |
07:18 |
|
Dyrcona joined #evergreen |
07:38 |
|
bdljohn joined #evergreen |
08:07 |
|
sforshee4 joined #evergreen |
08:14 |
|
agoben joined #evergreen |
08:15 |
|
bos20k joined #evergreen |
08:21 |
|
juliushaertl4 joined #evergreen |
08:28 |
|
mllewellyn joined #evergreen |
08:29 |
|
mllewellyn left #evergreen |
08:36 |
|
mmorgan joined #evergreen |
08:41 |
|
kmlussier joined #evergreen |
09:06 |
|
lsach joined #evergreen |
09:12 |
|
jvwoolf joined #evergreen |
09:22 |
|
rlefaive joined #evergreen |
09:26 |
|
jvwoolf1 joined #evergreen |
09:31 |
|
yboston joined #evergreen |
09:35 |
|
nfpl joined #evergreen |
09:39 |
gmcharlt |
noting that webstaffblocker bug 1745427 now has a pull request |
09:39 |
pinesol |
Launchpad bug 1745427 in Evergreen 3.1 "Web Client: Serials - Predict New Issues Defaults to Previous Pattern" [High,Confirmed] https://launchpad.net/bugs/1745427 |
09:41 |
csharp |
well, that's not pretty: https://pastebin.com/nhp1gfux |
09:42 |
csharp |
^^ this is during a vandelay import from an acq marc file |
09:43 |
gmcharlt |
csharp: ouch |
09:43 |
gmcharlt |
what's the other query? |
09:44 |
gmcharlt |
er, blocking query |
09:44 |
|
mllewellyn joined #evergreen |
09:44 |
|
mllewellyn left #evergreen |
09:45 |
|
mllewellyn1 joined #evergreen |
09:47 |
|
mllewellyn1 left #evergreen |
09:47 |
csharp |
doing this forensicly so not sure yet |
09:48 |
csharp |
looks like it happened more than once that day |
09:50 |
jeff |
after much head-scratching and looking for something caching org unit settings or eating events, i remembered that a reload of (at least) a perl opensrf service is insufficient to pick up a code change. :P |
09:50 |
Dyrcona |
csharp: Good luck, I think I've encountered a dead lock only once or twice in my 6+ years of working with Evergreen. Used to happen at least once a month on Horizon. |
09:51 |
mmorgan |
csharp: just a thought, could the marc file possibly have contained the same record more than once? |
09:53 |
csharp |
mmorgan: I don't think postgres knows/cares about MARC at the level where a deadlock happens - basically it's a situation where two processes are stuck, each waiting on the other to complete |
09:54 |
csharp |
more internal to postgres than having to do with the data itself |
09:55 |
csharp |
Dyrcona: I've seen them before, but usually during upgrades where we're doing multi-threaded database updates |
09:55 |
csharp |
like, y'know, pingest :-) |
09:55 |
Dyrcona |
Well, looks like they're both trying to update acq.lineitem, possibly the same one. |
09:56 |
Dyrcona |
csharp: Browse ingest will do that, which is why it is not parallelized any more. |
09:58 |
Dyrcona |
It was sooo much fun on Horizon and Sybase...We'd get a whole cascade of locks to the point where libraries were calling in that the "system was frozen." I wrote a little GUI in Java to list all of the locks, so I could sort them, find the culprit, and kill it. Yeah, I could type Ctrl-k on the line in the table and kill a process with it. |
09:59 |
Dyrcona |
PostgreSQL has been much, much better in that respect. |
10:03 |
Dyrcona |
Is anyone looking at bug 1781480? If not, I'm inclined to push it, since it works for us at CW MARS. |
10:03 |
pinesol |
Launchpad bug 1781480 in Evergreen "Activity metric data isn't always retrieved as expected for searches" [Medium,Confirmed] https://launchpad.net/bugs/1781480 |
10:05 |
Dyrcona |
gmcharlt++ # We're also looking at that pullrequest. |
10:07 |
kmlussier |
Dyrcona: I just finished looking at it and it works for me too. Go ahead and push it. |
10:08 |
JBoyer |
cesardv, you around? |
10:08 |
Dyrcona |
kmlussier: You can push it if you prefer. Please add jlundgren's sign-off if you do. |
10:09 |
csharp |
https://pastebin.com/Qf4jhDfy - both queries |
10:09 |
csharp |
updating consecutive (but still different) rows |
10:10 |
Dyrcona |
csharp: Victim of a page lock. |
10:13 |
|
Putonlalla19 joined #evergreen |
10:16 |
|
Putonlalla19 was kicked by jeff: spam |
10:25 |
|
khuckins joined #evergreen |
10:31 |
pinesol |
[evergreen|Mike Rylander] LP#1781480: Closures remeber values in subtle ways... - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a0a885f> |
10:31 |
pinesol |
[evergreen|Mike Rylander] LP#1781480: Include group owner ancestor badges - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=437e7f8> |
10:36 |
csharp |
this MARC acq file is just 85 records but is creating a deadlock whenever someone has tried uploading it |
10:37 |
csharp |
I'm about to try myself |
10:43 |
Dyrcona |
csharp: Did you load the branch that makes Vandelay run in parallel? |
10:44 |
JBoyer |
Sounds like this might be a helpful collection of records too, if you're able to share it. |
10:46 |
csharp |
Dyrcona: I don't think so... |
10:46 |
csharp |
maybe? |
10:46 |
Dyrcona |
Lp 1514085 |
10:46 |
pinesol |
Launchpad bug 1514085 in Evergreen "Feature Request: Make Vandelay Asynchronous/Stateless" [Wishlist,Fix released] https://launchpad.net/bugs/1514085 |
10:46 |
|
beanjammin joined #evergreen |
10:47 |
csharp |
no, I know I didn't |
10:47 |
csharp |
not on production - we were testing it and I'm not sure where Tiffany left off |
10:47 |
Dyrcona |
Must be something else, then. Carry on. :) |
10:47 |
csharp |
thanks for thinking of it |
10:48 |
Dyrcona |
Might be worth trying with that branch on a test system, though. There's a chance it might resolve your issue. |
10:50 |
cesardv |
JBoyer: hey! Sorry I was in the zone... what's up? |
10:51 |
JBoyer |
No problem, I was just curious why bug 1691263 added select-on-focus, since some of our catalogers are unhappy about it. |
10:51 |
pinesol |
Launchpad bug 1691263 in Evergreen 3.0 "webclient wishlist: wrap long fields in MARC editor" [Medium,Fix released] https://launchpad.net/bugs/1691263 |
10:51 |
berick |
csharp: unrelated to your current issue, do you recall how long your 3.1 SQL upgrade took? these billing updates are a beast... |
10:51 |
JBoyer |
It looks like there is reference to a setting but I don't see any way to change it. |
10:52 |
* cesardv |
looks |
10:52 |
JBoyer |
berick, mine worked out to roughly an hour per 10 million rows. |
10:52 |
JBoyer |
(for that one script, that is) |
10:54 |
berick |
JBoyer: ugh, thanks, that's about what i'm seeing. |
10:54 |
berick |
may have to break this up into post-upgrade update chunks |
10:55 |
jeff |
which updates are taking that long? |
10:55 |
JBoyer |
Careful doing that! I screwed that up because our fine generator started running at one point when I had triggers disabled and so I spent 2-3 more 4 hour sessions fixing things. :/ |
10:55 |
csharp |
berick: 10 hours |
10:55 |
berick |
jeff: bug 1748924 |
10:55 |
pinesol |
Launchpad bug 1748924 in Evergreen "Enhanced Billing Timestamp Support" [Wishlist,Fix released] https://launchpad.net/bugs/1748924 |
10:55 |
csharp |
berick: gonna do some surgical billing deletions |
10:56 |
berick |
JBoyer: good one.. i'll keep that in mind |
10:56 |
jeff |
Do you have any non-stock triggers / etc on the tables in question? |
10:56 |
jeff |
I don't think that matches the time we experienced at all, but I'm looking for my notes. |
10:57 |
jeff |
It was a killer if I didn't take care of a non-stock mmpbbt-related trigger, though. |
10:57 |
cesardv |
JBoyer: it's been a while so my memory is pretty JeffSessions-y lol |
10:57 |
cesardv |
...but IIRC the selecOnFocus thing wasn't working at all, and I just added the bit of js needed to make it actually do what it intended |
10:57 |
csharp |
cesardv++ |
10:58 |
csharp |
@who can't recall? |
10:58 |
pinesol |
cesardv can't recall. |
10:58 |
csharp |
perfect |
10:58 |
berick |
heh |
10:59 |
berick |
jeff: no custom triggers here, just the mat_summary_* triggers |
10:59 |
JBoyer |
cesardv, that's ok, I'll throw an LP out there for it to either be finished or removed and people can discuss preferences. For some reason it seems to take more clicks than you'd expect to get it to finally de-select everything. |
11:00 |
cesardv |
csharp: nice |
11:00 |
JBoyer |
(and people unfamiliar with select on focus usually learn a lot about it once they accidentally type something once...) |
11:01 |
jeff |
as long as we disabled mat_summary_upd_tgr, the three updates ran a little under six minutes for a set of about 7.5 million money.billing rows. |
11:02 |
jeff |
and i believe dbwells did just that in a revised copy of the upgrade script. |
11:02 |
cesardv |
JBoyer: sounds good man, thanks, if I get a sec today I'll check it out |
11:03 |
berick |
jeff: crazy, mat_summary_upd_tgr is disabled here too |
11:03 |
csharp |
jeff: that's very encouragin... oh |
11:04 |
csharp |
I didn't disable any triggers, not having researched anything about what they do |
11:04 |
berick |
csharp: it's in modern versions of the 3.1 upgrade script |
11:05 |
JBoyer |
I thought I disabled most/all of them, but I must not have with those timings. I disabled the *new* one at one point and then bit myself in the foot when that train sailed, or something to that effect. |
11:06 |
csharp |
ah, then yes, that was disabled |
11:06 |
csharp |
just verified |
11:09 |
|
jvwoolf1 left #evergreen |
11:09 |
jeff |
weird. i'm trying to think of where the overall number of rows might impact the rate of the update in this circumstance. maybe something to do with the indexes, but i don't know. |
11:10 |
jeff |
of course, it might be another reason entirely. |
11:11 |
|
jvwoolf1 joined #evergreen |
11:14 |
|
yboston joined #evergreen |
11:22 |
pinesol |
[evergreen|Galen Charlton] LP#1745427: account for change in prediction patterns - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1c3b4a9> |
11:25 |
|
freebullets26 joined #evergreen |
11:25 |
|
freebullets26 was kicked by jeff: spam |
11:30 |
pinesol |
[opensrf|Mike Rylander] LP#1703411: Move OpenSRF XMPP attrs to subelement - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=b44fb86> |
11:30 |
pinesol |
[opensrf|Bill Erickson] LP#1703411 XMPP opensrf sub-element repairs - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=744f0d1> |
11:30 |
pinesol |
[opensrf|Bill Erickson] LP#1703411 XMPP opensrf element make check repairs - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=9682d15> |
11:36 |
|
segy10 joined #evergreen |
11:41 |
|
segy10 was kicked by jeff: spam |
11:54 |
|
beanjammin joined #evergreen |
11:57 |
|
jihpringle joined #evergreen |
12:06 |
|
dmellado21 joined #evergreen |
12:19 |
berick |
anyone here purging billing/payment data for aged circulations? |
12:21 |
* mmorgan |
shakes head "no" |
12:26 |
berick |
thinking money.aged_billing and money.aged_payment would help speed up this grueling 3.1 SQL upgrade. |
12:26 |
berick |
move ~2/3 of the data out of the way |
12:28 |
* berick |
tries to remember of the UI ever loads billing data for aged circs |
12:29 |
mmorgan |
Cash reports? |
12:34 |
csharp |
berick: that was my plan as well |
12:34 |
berick |
csharp: oh, interesting... |
12:34 |
csharp |
but I don't know what it will affect besides reports |
12:35 |
csharp |
if the data isn't used anymore, we should probably be purging billings/payments on those anyway (or at least providing a setting somewhere to do so) |
12:36 |
csharp |
in PINES, we aren't aging circs/holds for a year so it wouldn't affect our users much if it's just reports |
12:36 |
berick |
mmorgan: looks like it would affect cash reports if you ran reports for data old enough to be linked to an aged circulation |
12:37 |
berick |
csharp: same here for circs, 1 year |
12:37 |
* mmorgan |
suspected so. |
12:38 |
berick |
csharp: would you purge or move to aged tables? |
12:38 |
berick |
not sure what we'd do, need to ask |
12:39 |
berick |
maybe a 2-step process, move to aged table during circ-anon, but purge after (say) 3 years |
12:40 |
csharp |
yeah, proabably age rather than fully purge, then actually purge after a configured retention |
12:40 |
csharp |
that makes sense to me |
12:41 |
csharp |
sounds git branch-worthy, but I'm up to my eyeballs today and can't really even look :-/ |
12:41 |
berick |
i'll open a LP |
12:41 |
csharp |
berick++ |
12:42 |
mmorgan |
berick++ |
12:47 |
|
mkaito_15 joined #evergreen |
12:47 |
|
mkaito_15 was kicked by jeff: spam |
12:51 |
csharp |
researching bug 1788223, which is not affecting stock EG, but has broken certain template creation in PINES... |
12:51 |
pinesol |
Launchpad bug 1788223 in Evergreen "Web client reporter: connection between Circulation (& co.) and Simple Record Extracts Broken" [High,Incomplete] https://launchpad.net/bugs/1788223 - Assigned to Chris Sharp (chrissharp123) |
12:51 |
csharp |
I've diffed fm_IDL.xml with stock master and they are not different aside from a couple of custom sources we've had in place for a while |
12:52 |
|
TessaM- joined #evergreen |
12:52 |
csharp |
any other suggestions for where to look? the problem is that the SQL builder thinks there's a "simple_record" column on biblio.record_entry |
12:55 |
miker |
csharp: it's probably the link type on bre.simple_record ... does yours says "has_a" instead of "might_have"? |
12:56 |
|
TessaM- was kicked by jeff: spam |
12:56 |
* csharp |
looks |
12:58 |
csharp |
<link field='simple_record' reltype='might_have' class='rmsr' key='id' map='' /> |
12:58 |
csharp |
nope :-( |
12:58 |
miker |
mmm :( |
13:01 |
miker |
csharp: 88bdd77b97a85bd6c41b174faa2e828c34d3a948 I think |
13:01 |
pinesol |
miker: [evergreen|Galen Charlton] LP#1721807: fix webstaff report templates that have might_have and has_many joins - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=88bdd77> |
13:02 |
csharp |
ah - yeah, I don't have that applied |
13:02 |
miker |
csharp: if you're on 3.0.2-ish, you wouldn't have that |
13:03 |
|
hbrennan joined #evergreen |
13:03 |
csharp |
yeah that's right |
13:04 |
|
yboston joined #evergreen |
13:18 |
csharp |
miker++ # that did it! :-) |
13:26 |
miker |
cool |
14:03 |
berick |
csharp: holler if bug 1793802 varies from expectation |
14:03 |
pinesol |
Launchpad bug 1793802 in Evergreen "Wishlist: Age billing/payment data with circs" [Wishlist,New] https://launchpad.net/bugs/1793802 |
14:03 |
* csharp |
'll be a'hollerin' |
14:05 |
|
khuckins_ joined #evergreen |
14:05 |
csharp |
berick++ # looks good to me! thanks |
14:06 |
berick |
cool, thanks csharp |
14:23 |
abneiman |
berick: can I go ahead and mark bug 1708757 as Fix Released? |
14:23 |
pinesol |
Launchpad bug 1708757 in Evergreen "Publish Hatch to Chrome web store" [Wishlist,Fix committed] https://launchpad.net/bugs/1708757 |
14:24 |
berick |
abneiman: oh, yes, thanks |
14:24 |
abneiman |
coo, done |
14:24 |
abneiman |
*cool |
14:26 |
csharp |
@who is too coo for schoo? |
14:26 |
pinesol |
jonadab is too coo for schoo. |
14:27 |
* csharp |
knows people from his hometown who say "schoo" for "school" |
14:27 |
csharp |
"Carrollton Hah Schoo" |
14:28 |
berick |
:) |
14:33 |
* jonadab |
is actually one of those weird nerds who would've liked school, if only there weren't so many disruptive kids. |
14:34 |
csharp |
jonadab++ |
14:34 |
jonadab |
Except gym class. Gym class can die in a fire. |
14:36 |
Dyrcona |
My 11th grade English teacher: "These are the best years of your life." Me: "If these are the best years of my life, then kill me, now." Turned out she was wrong. |
14:39 |
|
jnatten joined #evergreen |
14:41 |
|
jnatten was kicked by jeff: spam |
14:41 |
kmlussier |
I'm guessing there are very few cases where high school represents the best years of your life. |
14:43 |
mmorgan |
Dyrcona's teacher had an interesting perspective. |
14:44 |
|
psprint-mob joined #evergreen |
14:45 |
|
psprint-mob was kicked by jeff: spam |
14:46 |
jonadab |
Oh, high school wasn't bad. Middle school was pretty bad, though. |
14:46 |
jonadab |
College was fantastic. |
14:50 |
csharp |
I went to high school with the same people I went to kindergarten with, so not a lot of room for rebranding/reinventing yourself |
14:50 |
csharp |
it wasn't until college when I felt "cool" |
14:51 |
bshum |
"It's a miracle these people ever got out of the 20th century." |
14:51 |
csharp |
s/when/that/ |
14:51 |
csharp |
bshum++ |
14:51 |
mmorgan |
bshum++ |
14:51 |
kmlussier |
csharp: Yeah, same here. I grew up on an island so there really was no opportunity to get away, even during non-school hours. |
14:52 |
|
rlefaive joined #evergreen |
14:57 |
Dyrcona |
My High School experience honestly wasn't so bad, but I did have a conversation along those lines with my 11th grade English teacher. |
15:14 |
|
rlefaive joined #evergreen |
15:30 |
|
dholland17 joined #evergreen |
15:32 |
jonadab |
Oh, right: I tend to forget there are people who didn't move every 3 years when they were kids. |
15:32 |
jonadab |
I mean, I *know*, but... |
15:33 |
* bshum |
mostly enjoyed his middle school years |
15:33 |
bshum |
Except that all the kids were crazy about Star Wars. Instead of Star Trek. |
15:33 |
Dyrcona |
:) |
15:33 |
bshum |
That was disappointing. |
15:33 |
gmcharlt |
pull requests are now ready for bug 1552778 and bug 1789442 |
15:33 |
pinesol |
Launchpad bug 1552778 in Evergreen 3.1 "Web client check-in "effective date" and check-out "specific due date" should also include times" [Medium,Confirmed] https://launchpad.net/bugs/1552778 |
15:33 |
pinesol |
Launchpad bug 1789442 in Evergreen 3.1 "Web client: When editing an hourly due date the time is automatically changed to 12:00 am" [Medium,Confirmed] https://launchpad.net/bugs/1789442 |
15:34 |
Dyrcona |
gmcharlt expects us to work.... :) |
15:34 |
* Dyrcona |
is testing bshum's branch for Ubuntu 18 support in Evergreen, and it is going well so far. |
15:35 |
gmcharlt |
of particular note: that branch establishes a clean_ISO8601 in Evergreen, copied and fixed from cleanse_ISO8601 in OpenSRF; other time-manipulation functions are brought over as well, particularly interval_to_seconds() and seconds_to_interval() |
15:35 |
gmcharlt |
so... not only do I want you all to work... I want you to work hard! ;) |
15:35 |
Dyrcona |
:) |
15:35 |
bshum |
Speaking of Ubuntu 18, should we wait till the .1 to put that through? It wouldn't be the first time we ported distro support in a future release if we wanted to give more time to test things around |
15:36 |
bshum |
Though we've also just pushed stuff like that before, and called it "initial support" :D |
15:36 |
bshum |
With more to come later |
15:36 |
gmcharlt |
bshum: works for me if it works for y'all; distro support need not be strictly tied to Evergreen .0 releases |
15:36 |
Dyrcona |
Well, it's not much use without OpenSRF released also. The -RC is Monday, and that's really up to berick. |
15:36 |
bshum |
That's true, OpenSRF is important |
15:36 |
gmcharlt |
and on my plate for next week now that the webstafblockers (I think) all have patches at this point |
15:36 |
Dyrcona |
Anyway, time to run the tests and then kick the tires on the web staff client. |
15:37 |
bshum |
gmcharlt: That's cool, definitely doesn't hurt to test stuff more thoroughly all around, especially since we're going back to CPAN for some of the dependencies again. And new perl, etc. |
15:38 |
Dyrcona |
Tests are failing, but I kind of expected that. :( |
15:38 |
bshum |
Bah humbug :) |
15:38 |
kmlussier |
gmcharlt: If nobody else gets to it, I'll try to take a look at webstaffblocker patches over the next couple of days. |
15:38 |
gmcharlt |
kmlussier++ |
15:40 |
Dyrcona |
Actually, has anyone run make check on master, lately? |
15:40 |
bshum |
Dyrcona: Err, not for a few days :( |
15:40 |
bshum |
Well not since last week |
15:40 |
bshum |
When we were doing the bug week |
15:41 |
Dyrcona |
Well, it might be a problem with newer Perl versions and something odd that we're doing: Failed test 'use OpenILS::Application::Circ::HoldNotify;' |
15:42 |
Dyrcona |
Yeahp, that's what it looks like: Unescaped left brace in regex is illegal here in regex; marked by <-- HERE in m/\${ <-- HERE EMAIL_SENDER}/ at /usr/local/share/perl/5.26.1/OpenILS/Application/Circ/HoldNotify.pm line 358. |
15:42 |
Dyrcona |
I think that used to just raise a warning. |
15:45 |
Dyrcona |
Yeahp, in perl 5.22 it says that construction is deprecated, not illegal. |
15:50 |
|
spont4e4 joined #evergreen |
15:57 |
berick |
can we delete HoldNotify yet? |
15:58 |
Dyrcona |
No idea, but the fix isn't too hard. However, I get some nice warnings including a vulnerability from CGI.pm. |
16:00 |
bshum |
Dyrcona: fwiw, all live tests pass clean for current master as of this writing on my new ubuntu 16.04 box. So guess it's a unique issue to 18.04's new perl. |
16:01 |
Dyrcona |
It's something that was deprecated and then became illegal, i.e. it throws a warning on ubuntu 16.04. bshum: Did you also run make check or just make live-check? |
16:02 |
bshum |
Dyrcona: I just ran livecheck first |
16:02 |
bshum |
I can go back and do the other |
16:02 |
bshum |
make check passes, though I do see all those deprecation warnings you speak of |
16:03 |
Dyrcona |
live tests are also blowing up, but I'm about to call it a day. |
16:08 |
Dyrcona |
We're definitely not ready for Ubuntu 18.04 and Perl 5.26.1. |
16:20 |
|
kmlussier joined #evergreen |
16:49 |
pinesol |
[evergreen|Dan Wells] LP#1791340 Webstaff: Don't backdate when we're not - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c09dd9a> |
16:49 |
pinesol |
[evergreen|Galen Charlton] LP#1791340: expand on comment about backdated checkin times - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f6cea03> |
17:08 |
|
mmorgan left #evergreen |
17:19 |
pinesol |
[evergreen|Mike Rylander] LP#1791335: Retain stat cats on item transfer - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=8cdf97e> |
17:44 |
|
s5529 joined #evergreen |
19:12 |
|
repys16 joined #evergreen |
19:50 |
|
LyndsySimon11 joined #evergreen |
22:11 |
|
YaknotiS22 joined #evergreen |
23:34 |
|
Lilium20 joined #evergreen |
23:46 |
|
geosmin8 joined #evergreen |