| 02:54 |
|
beanjammin joined #evergreen |
| 06:30 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:01 |
|
agoben joined #evergreen |
| 07:13 |
|
rjackson_isl joined #evergreen |
| 07:40 |
|
rlefaive joined #evergreen |
| 08:53 |
* Dyrcona |
wonders if he should ask in here or in #postgresql..... |
| 08:53 |
Dyrcona |
But, first, a paste! |
| 09:01 |
Dyrcona |
So, I came up with this script to remove old action_trigger events and event output this week: https://pastebin.com/34t5AY1z |
| 09:02 |
Dyrcona |
I have tested it on a copy of production data from Wednesday around midnight. |
| 09:02 |
Dyrcona |
It works, and it drops about 30GB of useless data from our database. |
| 09:03 |
Dyrcona |
My question is, when I run this in production, should I shut down cron jobs and anything else that may touch the action_trigger tables while it runs? |
| 09:03 |
Dyrcona |
Or, will normal database locking take care of any problems? |
| 09:04 |
Dyrcona |
My final, working, test ran in about 6 minutes 46 seconds on my test db server. |
| 09:06 |
|
jvwoolf joined #evergreen |
| 09:08 |
|
jvwoolf1 joined #evergreen |
| 09:12 |
|
lsach joined #evergreen |
| 09:33 |
Dyrcona |
Oh, good. Postgres died on the replicant server.... |
| 09:42 |
Dyrcona |
We've also had some issues with Apache processes spinning with high CPU since the upgrade, and I don't think it's a websockets issue or not the same that was patched, because we are on OpenSRF 3.0.1. |
| 09:47 |
Dyrcona |
Also, Overdrive integration appears to be not working, or sort of not working.... |
| 09:48 |
Dyrcona |
Overdrive's test environment requiring different credentials and configuration from production is less than ideal. |
| 09:56 |
JBoyer |
re: deferrable, it is helpful if you're doing much else in a transaction, but if deleting from action_trigger.evtent_output is the last thing before the commit it doesn't really make a difference. |
| 09:57 |
JBoyer |
Since it's ~20s per ateo for me I'll probably only ever drop constraint; delete; alter table; to clean it up. :/ |
| 09:57 |
|
terran joined #evergreen |
| 09:59 |
Dyrcona |
JBoyer: Ok. Have you tried the cleanup db function and configure the retention_interval? |
| 09:59 |
Dyrcona |
I was wondering if the function would work without deferred constraints. |
| 10:00 |
Dyrcona |
I want to test that but I have more immediate things going on. |
| 10:00 |
berick |
we're using retention_interval locally, but only after a big initial cleanup |
| 10:00 |
berick |
w/ truncates |
| 10:01 |
Bmagic |
Dyrcona++ # nice script |
| 10:41 |
Dyrcona |
More or less. |
| 10:41 |
Dyrcona |
And, yeah, I was thinking February would be special. |
| 10:41 |
miker |
so, we just need to use the constructor that looks like this: var d = new Date(year, month, day, hours, minutes, seconds, milliseconds); |
| 10:41 |
terran |
dbwells: In my testing it didn't matter what the day is |
| 10:42 |
berick |
miker: yeah, that's what I was thinking... |
| 10:42 |
miker |
terran: but it matters what day you test on! :) |
| 10:42 |
dbwells |
terran: right, what miker said :) |
| 10:42 |
terran |
miker: oh! |
| 10:42 |
terran |
:D |
| 10:56 |
Dyrcona |
So, I have apache2-websockets instances spinning out of control. |
| 10:58 |
Dyrcona |
Oh, that's lovely: [Wed May 30 10:53:18.447792 2018] [core:notice] [pid 3491] AH00051: child pid 14598 exit signal Segmentation fault (11), possible coredump in /etc/apache2-websockets |
| 11:00 |
Dyrcona |
Of course, those are dead and not spinning doing nothing. |
| 11:13 |
JBoyer |
Dyrcona, oh, I wasn't following the actual question, I assumed the truncate was a one-time cleanup before using the built-in cleanup. I would assume that deferrable would work, but I wasn't testing that before. I may give that a shot soon. |
| 11:20 |
Dyrcona |
So, we appear to be having issues with websockets. |
| 11:21 |
csharp |
berick++ |
| 11:21 |
Dyrcona |
I guess that's too vague. I'll have to do some research and open a Lp bug. |
| 13:33 |
csharp |
I'm sure we're dealing with massive JSON blobs |
| 13:33 |
Dyrcona |
Well, I'm going to finally kill some of these on one of the bricks. I'm getting load warnings for the brick head, now. |
| 13:33 |
Dyrcona |
I still have 'em spinning on two other bricks if more strace data is needed. |
| 13:35 |
jeffdavis |
It's not consistently reproducible in our environment either. Retrieving the same big JSON blob works sometimes and fails other times. I want to test the specific step of copying XUL templates to the new web client copy template user setting (see the load_remote_acp_templates() function in cat/volcopy/app.js), but haven't had time yet. |
| 13:43 |
Dyrcona |
Wow! |
| 13:44 |
Dyrcona |
One of them is now using 192.7% cpu and refuses to TERM. Time to KILL. |
| 13:44 |
|
rlefaive joined #evergreen |
| 14:11 |
|
jeffdavis joined #evergreen |
| 14:15 |
Dyrcona |
dbs did you identify yourself with bot to add the quote? if not, I can add it. |
| 14:16 |
berick |
strace is not helping me too much, unfortunately. suffice to say if someone can reliably reproduce, I'm all over it. |
| 14:17 |
Dyrcona |
That's the thing. I haven't seen it on a test environment, so I'm not sure what it triggering it. I'll look into the copy templates angle later. |
| 14:21 |
|
kmlussier joined #evergreen |
| 14:25 |
* Dyrcona |
wishes he could copy and paste text from an image, but doesn't have OCR for the clipboard. |
| 14:25 |
* berick |
wishes he could copy/paste from his eyes |
| 17:19 |
|
mmorgan left #evergreen |
| 17:33 |
|
abowling left #evergreen |
| 18:05 |
|
rlefaive joined #evergreen |
| 18:30 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 19:30 |
|
rlefaive joined #evergreen |
| 20:16 |
|
book` joined #evergreen |
| 20:25 |
|
rlefaive joined #evergreen |
| 00:58 |
|
fteto joined #evergreen |
| 00:59 |
jeffdavis |
What a jerk. |
| 02:30 |
|
beanjammin joined #evergreen |
| 06:30 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:07 |
|
rjackson_isl joined #evergreen |
| 07:30 |
|
collum joined #evergreen |
| 07:31 |
|
agoben joined #evergreen |
| 14:52 |
dbs |
I consider the hairs well-split now |
| 14:52 |
dbs |
and will vanish to focus on actually trying to run EG 3.1.1 again |
| 14:54 |
Dyrcona |
:) |
| 14:55 |
* Dyrcona |
prepares to push some more signedoff and tested branches. |
| 14:57 |
kmlussier |
Dyrcona++ |
| 14:57 |
kmlussier |
gmcharlt++ |
| 15:00 |
pinesol_green |
[evergreen|gcollum] LP#1743782 Copy Status not available in Check-In Screen - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=0eac25e> |
| 15:04 |
pinesol_green |
[evergreen|Garry Collum] LP#1745232 - Bill History Receipt doesn't have Finish Date - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=fc25b34> |
| 15:08 |
pinesol_green |
[evergreen|Garry Collum] LP#1745240: Hold Alias Missing from Hold Shelf Slip - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=510284d> |
| 15:25 |
|
dkyle1 left #evergreen |
| 15:27 |
idjit |
jeffdavis: what'd you do to test bug 1761276? i can't replicate. i've got patches for bugs 1761276 and 1724348, and suspect you may need them both. |
| 15:27 |
pinesol_green |
Launchpad bug 1761276 in Evergreen "Odd behaviour when clicking on title hyperlink " [High,Confirmed] https://launchpad.net/bugs/1761276 |
| 15:27 |
pinesol_green |
Launchpad bug 1724348 in Evergreen "Web client: set default view not sticky" [Undecided,Confirmed] https://launchpad.net/bugs/1724348 |
| 15:29 |
idjit |
sorry, that should've been be patches for bugs 1731272 and 1724348. |
| 15:36 |
miker |
ah, nevermind :) |
| 15:36 |
miker |
global notice tells the tale |
| 15:40 |
|
rjackson_isl joined #evergreen |
| 15:40 |
jeffdavis |
idjit: It's intermittent so hard to replicate, I think it's more visible when record retrieval is slow. Maybe try clearing cache, then clicking the title hyperlink in record summary. |
| 15:40 |
jeffdavis |
I am definitely interested in testing patches. :) |
| 15:42 |
idjit |
jeffdavis: ok, i'll keep trying. cache gets cleared pretty frequently. i'll see about slowing the connection down. let me know if you figure out a repeatable test. |
| 15:42 |
|
bshum_ joined #evergreen |
| 15:42 |
jeffdavis |
csharp (aka Guest83209): you mentioned yesterday that you were seeing NOT CONNECTED TO THE NETWORK errors possibly related to retrieving XUL copy templates in the web client. Are you also seeing websockets processing stuck at 100% CPU? |
| 15:44 |
pinesol_green |
[evergreen|Mike Rylander] LP#1755220: Return value checking in offline session fetch - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=23719d9> |
| 17:15 |
jeff |
if the current polling method is timing out due to number of matching patrons, you might consider. i think that PINES and/or EI use the "initiate then poll" method. |
| 17:15 |
jeff |
I'm not recommending that you switch to the penalty method to solve this -- that's a little different overall. |
| 17:15 |
jeff |
(and now that i think of it, i don't know if the penalty method is the only way to do the batch / poll-later method) |
| 17:16 |
Bmagic |
the initial unfleshed set of patrons for my test case is 7100 patrons. Followed by 7100 DB look ups in process_users_of_interest_results which takes more than the 7200 threshold |
| 17:16 |
jeff |
(sorry, on my way afk, so can't be more specific right now.) |
| 17:16 |
Bmagic |
no worries! Thanks! |
| 17:16 |
Bmagic |
jeff++ |
| 17:17 |
Bmagic |
roughly |
| 17:18 |
|
beanjammin joined #evergreen |
| 18:26 |
|
sandbergja joined #evergreen |
| 18:32 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 23:57 |
|
beanjammin joined #evergreen |
| 00:10 |
|
yboston joined #evergreen |
| 01:33 |
|
beanjammin joined #evergreen |
| 06:30 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:05 |
|
agoben joined #evergreen |
| 07:13 |
|
rjackson_isl joined #evergreen |
| 07:40 |
|
bdljohn joined #evergreen |
| 09:48 |
rjackson_isl |
bringing back the "snap, crackle and pop" to your listening enjoyment! |
| 09:48 |
* idjit |
is reminded of this wallpaper https://i.imgur.com/cMn17t9.png |
| 09:49 |
rjackson_isl |
ah yes, 9 volt transister radios - those were the days... |
| 09:52 |
Dyrcona |
kmlussier: Do you want me to load the branch from bug 1741997 somewhere you can test it with our data? |
| 09:52 |
pinesol_green |
Launchpad bug 1741997 in Evergreen "additional browse improvements" [Medium,Confirmed] https://launchpad.net/bugs/1741997 |
| 09:53 |
* Dyrcona |
times his work with his music....When the Dire Straits collection finishes, it will be time to call in for the meeting. |
| 09:57 |
pinesol_green |
[evergreen|Bill Erickson] LP#1639022 Webstaff convert change to credit - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=835bac8> |
| 10:04 |
kmlussier |
Dyrcona: Yes, please. I'm having authority issues on my own VMS, and I'm not quite sure why. Since I know cross-references are displaying on your servers, I'm hoping the patch could just be applied and I could see if it fixes the specific bugs. |
| 10:04 |
Dyrcona |
Ok. I'll add it to testing.cwmars.org. |
| 10:05 |
Dyrcona |
Looks like it is currently at 3.0.3. |
| 10:13 |
* Dyrcona |
upgrades it to 3.0.7. |
| 10:14 |
|
jwoodard joined #evergreen |
| 10:16 |
|
beanjammin joined #evergreen |
| 10:18 |
Dyrcona |
kmlussier: Do you want me to do anything in particular after installing the branch, like running the linker or anything like that? |
| 10:19 |
kmlussier |
Dyrcona: I don't think the linking is required, but I'm not sure about an authority reingest. gmcharlt: do you know if a reingest is required to test bug 1741997? |
| 10:19 |
pinesol_green |
Launchpad bug 1741997 in Evergreen "additional browse improvements" [Medium,Confirmed] https://launchpad.net/bugs/1741997 |
| 10:20 |
kmlussier |
Well, the linking is required to show the cross-references. I should say I don't think re-linking is required. |
| 10:21 |
gmcharlt |
linking is required, yes, if it hasn't already been done; reingest should not be |
| 14:45 |
Dyrcona |
jeffdavis: Good to know. |
| 14:45 |
jeffdavis |
Dyrcona++ |
| 14:47 |
Dyrcona |
bshum++ # For throwing the bug # at me while I was searching for it. |
| 15:14 |
* Dyrcona |
has one more tested branch to commit. |
| 15:18 |
pinesol_green |
[evergreen|Mike Rylander] LP#1770478: Offline org unit tree can break - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=0a8b5ae> |
| 15:26 |
miker |
jeffdavis: for the record, the reason we skip attr update is that it creates a loop of bib updates which will eventually blow out the stack. the function that updates the attr vector does not have access to NEW (though it is called from within the trigger) so it has to update the table, which triggers another update, and force-on-same fires the trigger again, etc |
| 15:40 |
|
bdljohn joined #evergreen |
| 18:23 |
jeffdavis |
we're seeing some open-ils.actor NOT CONNECTED TO THE NETWORK errors which I suspect are due to retrieving staff_client.copy_editor.templates in cat/volcopy/app.js |
| 18:23 |
jeffdavis |
open-ils.cstore open-ils.cstore.direct.actor.user_setting.search.atomic {"usr":<usrid>,"name":"staff_client.copy_editor.templates"} |
| 18:24 |
jeffdavis |
^ returns a chunked response, followed in the logs by the NOT CONNECTED errors |
| 18:30 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:50 |
pinesol_green |
[evergreen|Jane Sandberg] Docs: Adding to and reorganizing the 3.0.8 release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=31c0b28> |
| 18:54 |
pinesol_green |
[evergreen|Jane Sandberg] Docs: Adding to and reorganizing the 3.1.2 release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=0901349> |
| 19:02 |
|
Dyrcona joined #evergreen |
| 19:02 |
Dyrcona |
sandbergja++ # More release notes |
| 19:58 |
csharp |
jeffdavis: can confirm the same thing happening in today's PINES logs |
| 01:36 |
|
beanjammin joined #evergreen |
| 05:26 |
|
beanjammin joined #evergreen |
| 06:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:59 |
|
agoben joined #evergreen |
| 07:12 |
|
rjackson_isl joined #evergreen |
| 07:37 |
JBoyer |
jeffdavis++ |
| 08:43 |
|
remingtron joined #evergreen |
| 08:46 |
|
mmorgan joined #evergreen |
| 09:07 |
|
bos20k joined #evergreen |
| 09:07 |
bshum |
@later tell kmlussier https://i18n.evergreener.net -- master (as of this morning) demo server with i18n enabled - I'll leave it in place for the week for testing |
| 09:07 |
pinesol_green |
bshum: The operation succeeded. |
| 09:19 |
|
dickreckard joined #evergreen |
| 09:19 |
dickreckard |
uhm the documentation to upgrade to 3.1 links to some old documentation on how to update to 2.12 |
| 13:08 |
|
rlefaive joined #evergreen |
| 13:09 |
|
collum_ joined #evergreen |
| 13:19 |
|
eady joined #evergreen |
| 13:24 |
csharp |
berick: testing bug 1727557... the file appears to download fine but when I enter a patron barcode from the blocklist, firefox dies - I haven't tried in Chrome yet |
| 13:24 |
pinesol_green |
Launchpad bug 1727557 in Evergreen "Web Client: Download Block List causes unresponsive page with large file" [High,Confirmed] https://launchpad.net/bugs/1727557 - Assigned to Dawn Dale (ddale) |
| 13:25 |
* csharp |
tries Chrome |
| 13:30 |
csharp |
same behavior in Chrome |
| 13:35 |
csharp |
yeah - trying to navigate the DB tree in FF makes it die |
| 13:37 |
csharp |
ok - Chrome is at least letting me look |
| 13:37 |
csharp |
yes, I see valid data in the offline blocks table |
| 13:38 |
berick |
does the browser differentiate between the different block types? |
| 13:39 |
berick |
i notice lots of dupes in my test file |
| 13:39 |
berick |
dupe barcodes, that is |
| 13:39 |
csharp |
finally got FF to stay open - seeing valid data there too now |
| 13:40 |
csharp |
the browser shows L, D, etc. under "reason" |
| 13:40 |
csharp |
let me look for dupes |
| 14:04 |
pinesol_green |
JBoyer: Unlikely. |
| 14:05 |
JBoyer |
Sorry kmlussier, that sounds pretty ironclad. ;) |
| 14:07 |
kmlussier |
JBoyer: I'm still shooting for Friday afternoon. Maybe pinesol_green knows of some workplace crisis that will deter me. |
| 14:09 |
csharp |
kmlussier: this is a bad week for me too - also, I usually don't get much direct squashing done because I'm helping terran and others get patches installed on test servers (which I'm happy to do) |
| 14:09 |
berick |
@who will blast [band] to get kmlussier pumped for bug squashing! |
| 14:09 |
pinesol_green |
yboston will blast All The Jeffs to get kmlussier pumped for bug squashing. |
| 14:09 |
berick |
all the other Jeffs with their pumped up kicks... |
| 15:22 |
dbs |
mrca_vlist_idx failed because operator class "evergreen.gin__int_ops" does not exist for access method "gin" - heh |
| 15:22 |
* dbs |
recently picked up some nice gin from our local https://crosscutdistillery.ca/ |
| 15:23 |
dbs |
dump method was: pg_dump --cluster <dbcluster> -U <dbuser> -i -Fd -Z 9 -f <dumpfile> --serializable-deferrable <dbname> |
| 15:35 |
jeff |
Yeah. Maybe in a previous chain of events CREATE EXTENSION intarray; was called without an explicit schema, and the default object creation schema thanks to search_path was "evergreen"... then when it came time to CREATE FUNCTIOn metabib.compile_composite_attr, the search path no longer contained "evergreen" and someone modified the function definition to reference evergreen.query_int... |
| 15:37 |
jeff |
(haven't tested, and not sure that I can test that theory) |
| 15:37 |
jeff |
I'll take a stab at writing up some of the challenges and known issues and maybe some recommendation for devs and admins. |
| 15:38 |
jeff |
Seems worthwhile. |
| 15:39 |
|
mmorgan joined #evergreen |
| 15:39 |
dbs |
That would be awesome |
| 15:45 |
jeff |
I've also been thinking again about how best to audit existing databases for issues including things like "oops, we ended up with two versions of this function in different schemas" |
| 15:46 |
jeff |
...maybe in a few days. :P |
| 15:47 |
* dbs |
heads home |
| 15:56 |
pinesol_green |
[evergreen|Galen Charlton] LP#1497322: add Perl live_t regression and unit tests for patron searching - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=28f155f> |
| 15:56 |
pinesol_green |
[evergreen|Jason Boyer] LP14973322: Search for Users by Profile - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ce419b5> |
| 15:56 |
pinesol_green |
[evergreen|Galen Charlton] LP#14973322: (follow-up) allow profile-only patron searches - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1e1e83a> |
| 16:53 |
jeffdavis |
Is it reasonable to think that bug 1765444 might be the proximate cause of open-ils.cat NOT CONNECTED errors? |
| 16:53 |
pinesol_green |
Launchpad bug 1765444 in Evergreen "webstaff MARC editor can spam requests for fixed field metadata" [Medium,New] https://launchpad.net/bugs/1765444 |
| 17:06 |
|
mmorgan left #evergreen |
| 17:29 |
|
abowling1 joined #evergreen |
| 18:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 20:26 |
|
jvwoolf joined #evergreen |
| 20:28 |
|
jvwoolf1 joined #evergreen |
| 21:01 |
pinesol_green |
[evergreen|Jane Sandberg] Docs: updating 3.0.8 release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1b8bbc3> |
| 21:01 |
pinesol_green |
[evergreen|Jane Sandberg] Docs: updating 3.1.2 release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=aa6020b> |
| 21:15 |
|
jvwoolf1 left #evergreen |
| 22:29 |
|
abowling joined #evergreen |
| 06:31 |
pinesol_green |
News from qatests: Failed Installing Evergreen database pre-requisites <http://testing.evergreen-ils.org/~live> |
| 06:31 |
pinesol_green |
News from qatests: Failed configure database <http://testing.evergreen-ils.org/~live> |
| 06:31 |
pinesol_green |
News from qatests: Failed Starting Evergreen <http://testing.evergreen-ils.org/~live> |
| 06:31 |
pinesol_green |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live> |
| 06:31 |
pinesol_green |
News from qatests: Failed Log Output: osrfsys.log - Expected 3 errors but encountered 4539. <http://testing.evergreen-ils.org/~live> |
| 06:40 |
csharp |
psql: could not connect to server: Connection refused |
| 06:40 |
csharp |
^^ those errors |
| 06:45 |
|
JBoyer joined #evergreen |
| 10:29 |
berick |
sandbergja++ # solo feedback fest |
| 10:43 |
|
kmlussier joined #evergreen |
| 10:54 |
miker |
csharp: there's still the issue of the template editor. I only addressed the live editor due to lack of tuits -- the request is, IIUC, to create a different code path for the template editor that uses staff permissions rather than selected copies to populate the dropdown. as for my fix in comment 2, I don't know if it's still needed or not, strictly, but it's a belt to wear with whatever suspenders have been added since the bug was reported |
| 11:03 |
csharp |
miker: ok - if it's useful to apply the patch you created way back when I'll test and sign off on it and sounds like the template editor issue should be a separate bug report |
| 11:11 |
miker |
csharp: I think it's probably useful to retest the patch. I honestly don't recall OTTOMH what else has changed in there over the last 5 months ... or if the "need to treat numbers as numbers" bug might still be lurking somewhere |
| 11:20 |
|
mmorgan1 joined #evergreen |
| 11:48 |
|
khuckins joined #evergreen |
| 15:59 |
abneiman |
terran++ |
| 16:15 |
|
mmorgan1 joined #evergreen |
| 16:17 |
|
agoben joined #evergreen |
| 16:23 |
jeffdavis |
we're seeing some web client admin interfaces (mostly acq related) fail to work in a load-balanced environment on 3.1 |
| 16:23 |
jeffdavis |
not sure yet if it's a configuration issue or what |
| 16:23 |
jeffdavis |
e.g. attempting to create a new acq funding source gives a 400 Bad Request error |
| 16:25 |
jeffdavis |
on POST to /osrf-http-translator |
| 16:26 |
jeffdavis |
I don't see the same issue in a non-load-balanced test environment |
| 16:26 |
miker |
jeffdavis: some things to check (which you probably have, but just in case): 1) every time? 2) are the memcache instance(s) shared? (they should be) 3) are services cross-registered amongst routers (and if not, are any down) |
| 16:26 |
miker |
and for (1) I mean is it intermittent |
| 16:29 |
jeffdavis |
seems to be consistent, at least for acq admin |
| 18:16 |
jeffdavis |
The SQL that I pasted above is how we fixed the issue. Run that before the 3.0.6-3.1.0 upgrade script. |
| 18:16 |
jeffdavis |
I thought there was a Launchpad bug for that but I can't find one. |
| 18:17 |
frank_g |
jeffdavis: thanks for your help |
| 18:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 19:14 |
|
bdljohn joined #evergreen |
| 23:59 |
|
beanjammin joined #evergreen |
| 01:14 |
|
book` joined #evergreen |
| 05:35 |
|
beanjammin joined #evergreen |
| 06:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:59 |
|
agoben joined #evergreen |
| 07:15 |
|
rjackson_isl joined #evergreen |
| 07:42 |
|
rlefaive joined #evergreen |
| 08:59 |
|
jvwoolf1 joined #evergreen |
| 09:00 |
|
bos20k joined #evergreen |
| 09:03 |
|
Dyrcona joined #evergreen |
| 09:10 |
csharp |
so I'm still having issues on my master test server (ubuntu 16.04), reinstalled today. When I pull up a bib record the Record Summary is not loading data. In the console (FF 60.0) I see "Possibly unhandled rejection: {}" |
| 09:11 |
csharp |
followed by "TypeError: cp.copy_alerts is not a function" and |
| 09:11 |
csharp |
"TypeError: rec.flat_display_entries is not a function" |
| 09:12 |
csharp |
as mentioned last week(?), I think this may be related to the version of Angular I'm using |
| 09:14 |
csharp |
Object { full: "1.6.9", major: 1, minor: 6, dot: 9, codeName: "fiery-basilisk" } |
| 09:14 |
csharp |
(output of "angular.version" in the dev console |
| 09:14 |
csharp |
) |
| 09:18 |
csharp |
same behavior on chrome 66 |
| 09:18 |
csharp |
same console errors |
| 09:19 |
csharp |
can anyone confirm or disprove? |
| 09:24 |
JBoyer |
csharp, I don't have a master install at the moment but I do have a server running angular 1.6.10 so I don't think it's the angular verison. |
| 09:29 |
csharp |
JBoyer: ok - thanks |
| 09:36 |
miker |
csharp: that sounds more like a mismatching fm_IDL.xml |
| 09:36 |
miker |
did you install over the top of an existing instance from source? |
| 09:40 |
|
bos20k joined #evergreen |
| 09:47 |
csharp |
miker: hmmm - I'll test that - yeah, it's been installed over and over |
| 09:53 |
csharp |
hmm 'diff /openils/conf/fm_IDL.xml Open-ILS/examples/fm_IDL.xml' shows no differences |
| 09:57 |
miker |
csharp: ah, but there's one exposed in the reporting area that's used by the JS |
| 09:58 |
miker |
fwiw, I tend to make that one a symlink to the one in /openils/conf/ to avoid them getting out of sync, unless you need i18n on the dev/test system |
| 09:59 |
|
Christineb joined #evergreen |
| 10:00 |
csharp |
oh... |
| 10:02 |
csharp |
miker++ # that fixed it |
| 10:29 |
Dyrcona |
So, the deleted field was apparently added "recently" and I have holds pointing to deleted parts where the parts were actually deleted from the database. |
| 10:30 |
Dyrcona |
Inconsistencies like that are a pain. |
| 10:41 |
|
jvwoolf joined #evergreen |
| 10:48 |
Dyrcona |
pingest-- # It's clobbering my test db server, and another script running on another database on the same server can't get any time to run. |
| 10:48 |
Dyrcona |
spoke too soon. looks like it is doing something now. :) |
| 10:58 |
idjit |
question about bug 1724348: what would be correct behavior if i set "holdings view" as the default view, open a record, switch to "marc view", go back to search results and open a new record? |
| 10:58 |
idjit |
should it load the holdings because that's my default or should it load marc view because that's the last tab i was looking at on a record? |
| 11:02 |
csharp |
are others seeing this? |
| 11:02 |
csharp |
even before attempting miker 's fix there, I'm not able to reproduce |
| 11:04 |
csharp |
since it's marked as a blocker, I'm hoping to either move it to invalid or at least remove the tag if others aren't seeing the problem |
| 11:04 |
* berick |
can test in a few minutes |
| 11:04 |
kmlussier |
csharp: I had hoped to look at that one, but I don't think I ever found that time to confirm or do any testing. |
| 11:07 |
csharp |
well, it's fairly simple to test on a concerto server - just create vols/copies for each branch in the system and see if they appear in the list - so far I'm not seeing the originally-reported problem |
| 11:07 |
csharp |
this was reported before we went live and was one of the bugs that led to our decision to not move cataloging to the web client yet |
| 11:35 |
kmlussier |
Dyrcona: Are those old holds where the parts were deleted before the patch from bug 937789 was added? |
| 11:35 |
pinesol_green |
Launchpad bug 937789 in Evergreen 2.8 "Deleting parts breaks hold interfaces" [Medium,Fix released] https://launchpad.net/bugs/937789 |
| 11:35 |
berick |
csharp: curious, are you still seeing one of the errors you mentioned earlier? i'm getting a "annot read property 'length' of undefined" on the hold maint. page. |
| 17:06 |
idjit |
haha, if we're real lucky it'll even work :-P |
| 17:07 |
Dyrcona |
:) |
| 17:09 |
|
mmorgan left #evergreen |
| 18:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 02:27 |
|
rjackson_isl_ joined #evergreen |
| 06:32 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:02 |
|
agoben joined #evergreen |
| 07:18 |
|
rjackson_isl_ left #evergreen |
| 07:22 |
|
rlefaive joined #evergreen |
| 11:06 |
|
abowling joined #evergreen |
| 11:14 |
berick |
i'd appreciate an eyeball on this before posting to mail lists for reivew: https://wiki.evergreen-ils.org/doku.php?id=dev:browser_staff:angjs_to_ang_migration |
| 11:15 |
berick |
i'm way too close to it. |
| 11:16 |
gmcharlt |
berick: a couple things immediately jump out at me |
| 11:18 |
gmcharlt |
one, there should probably be something that (a) uses the <blink> tag (b) and the <marquee> tag, and (c) 72-point type to the effect that unit tests are /crucial/ for core services |
| 11:18 |
* berick |
dons geocities cap |
| 11:19 |
berick |
good point, thanks gmcharlt |
| 11:20 |
gmcharlt |
secondly, the project to angularize acquisitions falls in an uncomfortable place in the timeline you're proposing |
| 12:09 |
miker |
I don't much care where i18n happens, tbh. I'm concerned with that actual purpose of tt2 ... the i18n stuff we do there is really an add on of our own devising |
| 12:10 |
miker |
berick: I think that's not so true from some perspectives (TTFB more important that flexibility of configuration) |
| 12:18 |
|
khuckins joined #evergreen |
| 12:23 |
* berick |
updates doc to clarify proposal of bypassing TT2 and including unit tests for core services. |
| 12:25 |
berick |
i'll post to mail list later so we can resume discussion |
| 12:37 |
|
Christineb joined #evergreen |
| 13:01 |
miker |
thanks berick! |
| 13:10 |
miker |
re my comment about speed vs flexibility: in a "web app" world, while lazy loading is still a thing, most of the cost that tt2 imposes would still be paid on the initial app load, not on each interaction as it is right now in the tpac. the separation of display customization/restriction from page element rendering (in that, today, the "whole page" is rendered only after all logic completes, whereas that cost can be frontloaded in a web app so renderin |
| 15:05 |
_bott_ |
kmlussier: which indexes, specifically? It was a DB upgrade, so there were existing changes in legacy tables. |
| 15:11 |
kmlussier |
_bott_: IIRC, it's important to ensure that your search fields are also enabled as display fields. You're right, that change should have been made to legacy tables in the upgrade script. |
| 15:12 |
kmlussier |
The display fields also need to be used in the tt2 files, but, if you're using out-of-the box templates, that should already be there. Also, the reingest is required. |
| 15:19 |
_bott_ |
kmlussier: yes, I caught the display_field updates, those are good to go. The logs show the cstore calls to search.highlight_display_fields, I'm trying to parse one of those out to test it directly, but it looks to be returning successfully. |
| 15:20 |
kmlussier |
_bott_: OK, that's all I've got. |
| 15:26 |
JBoyer |
_bott_, Nothing else is coming to me either, I just realized I kind of wandered off there. The only trouble I had with highlighting is deciding what color I'm going to change the default to for the production upgrade. |
| 15:26 |
_bott_ |
DOH! metabib.display_entry table is empty! |
| 16:17 |
|
khuckins joined #evergreen |
| 17:04 |
Bmagic |
jeff++ # Forensic science |
| 17:09 |
|
mmorgan left #evergreen |
| 17:14 |
pinesol_green |
[evergreen|Remington Steed] Docs: Update Long-overdue docs for web client - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e9b08bc> |
| 17:54 |
|
Christineb joined #evergreen |
| 18:32 |
|
beanjammin joined #evergreen |
| 18:32 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 23:05 |
|
jeff_ joined #evergreen |
| 23:12 |
|
jeff__ joined #evergreen |
| 01:48 |
|
beanjammin joined #evergreen |
| 06:30 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:07 |
|
rlefaive joined #evergreen |
| 07:12 |
|
rjackson_isl joined #evergreen |
| 07:14 |
|
agoben joined #evergreen |
| 09:30 |
pinesol_green |
Launchpad bug 1747664 in Evergreen "Web Client: Cannot batch edit Volume/Call Numbers from Copy Bucket" [Medium,Confirmed] https://launchpad.net/bugs/1747664 |
| 09:31 |
JBoyer |
mmorgan, yes, it should have been removed, and now it is. |
| 09:32 |
mmorgan |
Thanks! |
| 09:32 |
kmlussier |
I'm having a bit of trouble building the web client on master this morning. |
| 09:32 |
kmlussier |
When I run 'npm run test', I'm seeing the following. https://pastebin.com/CA5frnuf |
| 09:34 |
jeff |
you're getting a lawnmower ad? |
| 09:34 |
* jeff |
ducks |
| 09:34 |
jeff |
pastebin-- |
| 09:35 |
jeff |
are each of the ✗ symbols representing a failed test? |
| 09:35 |
jeff |
the only explicit error seems to be: |
| 09:35 |
jeff |
TypeError: undefined is not an object (evaluating 'reportEditScope._mergePaths') in test/unit/egReporter.js (line 174) |
| 09:35 |
jeff |
test/unit/egReporter.js:174:39 |
| 09:36 |
kmlussier |
jeff: Yes, those do represent a failed test. |
| 09:43 |
|
rlefaive joined #evergreen |
| 09:43 |
|
mmorgan joined #evergreen |
| 09:46 |
jeff |
it doesn't look like the automated live tester runs the web client tests. is that right? |
| 09:47 |
bshum |
jeff: I'm pretty sure it should |
| 09:47 |
bshum |
There's at least a linked step there for "Running Evergreen browser client build/test" |
| 09:47 |
jeff |
bah. I scanned/searched for "web" :-) |
| 09:47 |
jeff |
bshum++ |
| 09:48 |
jeff |
looks like it doesn't call out failure: PhantomJS 2.1.1 (Linux 0.0.0): Executed 32 of 32[31m (32 FAILED)[39m[31m ERROR[39m (0.207 secs / 0.202 secs) |
| 09:48 |
kmlussier |
If I ignore the errors and proceed with building the web client, I get a blank screen when trying to access to staff login page. I see this in the console - https://pastebin.com/xr7dbL4y |
| 09:48 |
JBoyer |
I had every single test fail on me last night building 3.1 on U16.04 but I didn't give it much thought since I was just playing around at home and assumed I missed something |
| 09:48 |
kmlussier |
I'm on Ubuntu 14.04 |
| 09:49 |
jeff |
okay then. looks like i probably won't have trouble reproducing this locally, then. :-) |
| 09:49 |
* Dyrcona |
can test it also in a bit. |
| 09:49 |
Dyrcona |
I haven't tested master in a while. I've been focused on 3.0 and our upgrade. |
| 09:50 |
* kmlussier |
tries on 3.0 |
| 09:51 |
jeff |
perhaps unrelated to the current errors, but a conversation the other day caused me to look into how we're handling packages... it doesn't look like we're currently checking in the package-log.json file, and we probably should. |
| 09:51 |
JBoyer |
I did notice an alert to that effect. |
| 09:52 |
jeff |
oh? i didn't know that anything would alert on that. handy, since people often think "that's a generated file, i shouldn't check that in" |
| 09:52 |
jeff |
(but like with bundler and various other things, it's meant to be checked in) |
| 09:53 |
JBoyer |
I think tsc specifically calls out that you should commit package-log.json once it's done it's thing |
| 09:53 |
jeff |
so that package updates and intermediate package updates are intentional and tested before breaking things -- again, possibly completely unrelated to the failed tests at hand, just seemed like a good time to compose my thoughts and mention it here. :-) |
| 09:54 |
Dyrcona |
Maybe it's a problem with fresh installations or with Ubuntu 14.04? |
| 09:54 |
JBoyer |
No, probably npm run. It's been a while since I was messing with taht |
| 09:54 |
Dyrcona |
I just pulled master on Ubuntu 16.04, rand npm update and npm run test and got no errors. |
| 09:54 |
Dyrcona |
s/rand/ran/ |
| 09:59 |
jeff |
er, typo above that i didn't notice. i was referring to package-lock.json. |
| 10:03 |
Dyrcona |
Well, that's a bad name for a file that one should keep around. |
| 10:05 |
Dyrcona |
Oh, nice. While run test reported no problems, my web staff login page comes up blank. |
| 10:06 |
Dyrcona |
Lots of failure to instantiate module errors in the console. Looks like it is pulling in AngularJS 1.7. |
| 10:07 |
bshum |
Well that sounds bad |
| 10:07 |
* Dyrcona |
recalls someone suggesting we should "pin" the AngularJS version recently. |
| 10:11 |
kmlussier |
Dyrcona: Yes, that was the first error in my Console messages too. |
| 10:12 |
Dyrcona |
Then the URI for the error string goes to an AngularJS 1.7.0 reference for injector module error. |
| 10:12 |
Dyrcona |
Well, I guess it's the error documentation reference. |
| 10:13 |
Dyrcona |
kmlussier: So, looks like the same problem even though tests passed for me. |
| 10:13 |
kmlussier |
Dyrcona: I guess that's enough confirmation to file a bug, then. |
| 10:14 |
jeff |
Dyrcona: if you're unfamiliar with the concept, this does a decent job of explaining package-lock.json: https://docs.npmjs.com/files/package-locks |
| 10:15 |
jeff |
in general, it can be summed up as: if you use and commit package-lock.json, you will reduce the number of times that things break unexpectedly due to the release of a new version of one of your dependencies. :-) |
| 10:15 |
Dyrcona |
Looking at my scrollback, npm update definitely pulled in AngularJS 1.7.0, and changing package.json as bshum suggested pulls in AngularJS 1.6.10. |
| 10:16 |
Dyrcona |
jeff: I don't know that much about AngularJS, Angular, or Node.js. I know the barebones to work on the code. I haven't gotten into the guts. |
| 10:16 |
Dyrcona |
Frankly, I'd rather not have to. :) |
| 10:18 |
Dyrcona |
Oh, now, my tests fail. :( |
| 10:18 |
Dyrcona |
After doing what bshum suggested and doing npm update followed by npm run test the test fail. |
| 10:25 |
bshum |
Dyrcona: If I edit my package.json file to pin the version, then removed my node_modules and build dirs |
| 10:25 |
bshum |
Then ran new npm install / npm run build-prod / npm run test |
| 10:25 |
bshum |
And that all seems to pass the tests for me |
| 10:26 |
bshum |
Well, npm update, then npm install, etc. |
| 10:26 |
Dyrcona |
I didn't go through all of those steps because a) ignorant and b) lazy. |
| 10:29 |
bshum |
And voila, happy new test VM with master + that tiny tweak to pin to AngularJS 1.6 |
| 10:29 |
bshum |
Well, Ubuntu 16.04 anyways |
| 10:31 |
kmlussier |
I can build a branch and test it on 14.04. |
| 10:32 |
Dyrcona |
npm run test still fails for me after npm run build. |
| 10:33 |
|
Christineb joined #evergreen |
| 10:33 |
Dyrcona |
And with npm run build-prod. |
| 10:34 |
|
bdljohn joined #evergreen |
| 10:54 |
bshum |
We'll probably rip it all apart soon anyways |
| 10:54 |
kmlussier |
bshum: And when you say all, you mean everything, not just the 1.6.7 stuff, right? |
| 10:55 |
Dyrcona |
I'll make a followup/signoff branch. |
| 10:57 |
bshum |
kmlussier: That's what I want to say, but I don't know if there's any reason we haven't been checking the versions specified in the file and making sure all the deps are up to date. |
| 10:57 |
bshum |
Like I'd worry that hotkeys being ^ all this time, might break if we're expecting some new hotkey version than the one specified, etc. |
| 10:57 |
bshum |
So maybe we do want some expert advice from berick/gmcharlt/miker on the deps |
| 10:57 |
bshum |
Course it's easy enough to test what'll happen either way :D |
| 10:58 |
kmlussier |
bshum: Well, sure, it's easy to test what happens now, but not what happens in the future when version change. |
| 11:00 |
jeff |
if anyone has a recent working-not-broken package-lock.json file lying around, i'd be interested in getting a copy of it. |
| 11:03 |
bshum |
jeff: Where does that file get generated into? |
| 11:04 |
Dyrcona |
http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dyrcona/lp1771371-pin-to-angular-js-1-6 |
| 11:04 |
Dyrcona |
For anyone who wants to test the follow-up commit. |
| 11:05 |
Dyrcona |
jeff: I can't find one on my test vm. |
| 11:05 |
kmlussier |
And the first commit works! bshum++ Dyrcona++ jeff++ |
| 11:06 |
bshum |
Yeah neither can I. I found a package-lock.json.#date# one, but it's empty |
| 11:06 |
bshum |
No other files with a similar name in the whole VM |
| 12:13 |
berick |
I'll bring the moonshine jug |
| 12:16 |
|
khuckins joined #evergreen |
| 12:18 |
jeff |
gsams: need more info. reducing workflow/UI steps? speed of "renew all"? speed of individual renewal of an item where there may be item or record-specific circumstances leading to a delay in renewing? something else? |
| 12:19 |
gsams |
jeff: Apologies, meant to go into more detail. At the moment just speed of "renew all" seems to be the biggest thing |
| 12:21 |
gsams |
I've run a few tests and it takes up to a minute and a half for 50 items, which I'm not sure how that ranks for folks, but I feel it's pretty slow. |
| 12:21 |
miker |
jeffdavis: yay! I'll be testing that here, too. thanks for digging into it! |
| 12:22 |
mmorgan |
gsams: Have your test items had several renewals already? |
| 12:22 |
gsams |
My tests have had none and a few. I've run multiple tests on the same account/items |
| 12:25 |
gsams |
It didn't seem to make any difference either way. |
| 12:26 |
|
jihpringle joined #evergreen |
| 12:27 |
berick |
yay, just updated my ang5 demo site to ang6. https://35.186.179.218/eg2/staff/login Going to post install docs to the wiki soon and share to dev list. |
| 12:28 |
Dyrcona |
Well, a lot goes with a single renewal, so multiply that by 50 and there you go. |
| 12:53 |
pinesol_green |
kmlussier: Karma for "comcast" has been increased 0 times and decreased 10 times for a total karma of -10. |
| 13:13 |
jeffdavis |
We're upgrading to 3.1 this weekend. Just in time for Bug Squashing Week! :) |
| 13:22 |
JBoyer |
jeffdavis, I'll be looking forward to seeing how things go for you since we decided to wait until the first week of June. :) |
| 13:49 |
kmlussier |
Oh fun! UI wonkiness on a test system with 5 different patches with no obvious candidate as to which one is causing the problem. |
| 13:49 |
kmlussier |
jeffdavis: Best wishes on the upgrade! |
| 13:57 |
* dbs |
is also looking forward to seeing how the jeffdavis upgrade goes |
| 13:59 |
|
jvwoolf1 joined #evergreen |
| 14:15 |
jeffdavis |
Would it be worth pinning AngularJS to the latest 1.6 release (1.6.10) rather than 1.6.7? |
| 17:01 |
|
lsach left #evergreen |
| 17:01 |
|
mmorgan left #evergreen |
| 17:15 |
kmlussier |
Calling 1110 |
| 17:27 |
pinesol_green |
[evergreen|Galen Charlton] LP#1756912: restore display of copy counts for preferred library - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3e311c3> |
| 17:27 |
pinesol_green |
[evergreen|Kathy Lussier] LP#1756912: Stamping upgrade script for add preferred lib to unapi feeds - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1dab670> |
| 18:30 |
|
jvwoolf joined #evergreen |
| 18:30 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 20:21 |
|
jvwoolf joined #evergreen |
freenode/staff/exherbo.christel)- [Global Notice] Hi all, you may have noticed that the network is being hit by oh so hilarious (not) spam -- fear not, your passwords are all