| Time |
Nick |
Message |
| 01:25 |
|
sandbergja joined #evergreen |
| 05:45 |
|
awitter joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:38 |
|
agoben joined #evergreen |
| 07:05 |
|
rjackson_isl joined #evergreen |
| 07:22 |
|
rfrasur joined #evergreen |
| 08:10 |
|
alynn26 joined #evergreen |
| 08:38 |
|
mmorgan joined #evergreen |
| 08:40 |
|
mantis1 joined #evergreen |
| 08:54 |
|
Dyrcona joined #evergreen |
| 08:58 |
dbs |
Well that was fun, for some reason search and record display started complaining "Can't locate object method "depth" via package "1"" for lines like "$depth = 1 $org->ou_type->depth;" |
| 08:58 |
dbs |
How does fieldmapper suddenly forget how to access the property depth on ou_type? *sigh* |
| 09:02 |
Dyrcona |
Maybe the code stopped fleshing it? |
| 09:02 |
* dbs |
hacked around it by hardcoding a depth for now but he's concerned |
| 09:02 |
Dyrcona |
Is this after an upgrade? |
| 09:02 |
dbs |
Dyrcona: right but why would that happen? The code in O/WWW/EGCatLoader/Record.pm hasn't changed since 2012 |
| 09:03 |
dbs |
Upgrade was on Dec. 23rd |
| 09:03 |
Dyrcona |
Anyone mess with the org tree lately? |
| 09:03 |
dbs |
This didn't start happening until this morning. |
| 09:03 |
dbs |
hmm, that's an interesting and potentially concerning thought (org tree messing) |
| 09:06 |
dbs |
We haven't had an org unit be a parent of itself since the first day we migrated to Evergreen back in 2009 (at which point I promptly removed such powers from administrators) |
| 09:11 |
Dyrcona |
Well, I wasn't think of that specifically, but it would cause problems. I just thought maybe somebody changed something and autogen.sh wasn't run. |
| 09:13 |
Dyrcona |
Otherwise, I'm not sure why this would suddenly start happening, unless some service needs a restart/crashed. |
| 09:14 |
Dyrcona |
Maybe a corrupted fm_IDL somewhere? Disk issue? |
| 09:15 |
Dyrcona |
I should focus on the test that I'm setting up. I just made a mistake in the crontab that's part of the test. |
| 09:15 |
dbs |
Dyrcona: yes, focus on your stuff, I've got this working-ish for now |
| 09:19 |
Dyrcona |
Well, the mistake was no big deal, I just forgot to add some options and the &>> redirect on the run-pending runner. |
| 09:20 |
Dyrcona |
I'm trying to emulate production, though I think my main problem is just the number of events we're processing. |
| 09:21 |
Dyrcona |
bash_pocket_reference++ # Getting that as part of the Unix Admin. Humble Bundle was worth the price of the bundle. :) |
| 09:22 |
|
dbwells joined #evergreen |
| 09:27 |
Dyrcona |
The courtesy notices granularity doesn't spit out much useful information. |
| 09:30 |
|
jvwoolf joined #evergreen |
| 10:30 |
Dyrcona |
berick: I'm seeing other events get stuck in collected state in production. I don't my problem necessarily has anything to do with chained events. I've got a coupe of 28 day mark lost events that are in collected state. I think I need to get down to the reason for the jabber client disconnections. |
| 10:31 |
berick |
Dyrcona: well mark lost is another chained A/T |
| 10:31 |
berick |
did you see any improvement in the autorenew after the patch? |
| 10:32 |
Dyrcona |
Well, maybe, they didn't blow up on a test server, but our 2-day courtesy notices did. |
| 10:32 |
Dyrcona |
I'm doing a more thorough test today with a bunch of things emulating production. |
| 10:32 |
Dyrcona |
I have the same, but more, data on a slower machine and slower db server. |
| 10:33 |
berick |
well, i can't comment on the predues, but if the patch fixes autorenew, then a similar patch might help mark-lost |
| 10:35 |
Dyrcona |
berick: OK, I'll take a look. I'm not running those on this test. |
| 10:36 |
Dyrcona |
Also, is anyone else having to fix dates in your manually entered db queries this morning? I'm still typing 2019. :) |
| 10:38 |
* mmorgan |
hasn't had occasion to type a date yet, but 2020 does look odd down in the corner of my computer screen :) |
| 10:45 |
Dyrcona |
:) |
| 10:45 |
Dyrcona |
distractions-- |
| 10:47 |
* mmorgan |
tends to use now() in sql queries instead of trying to figure out what the actual date is :) |
| 10:49 |
dbs |
running current rel_3_4 with the recent hatch updates, found that I could only print labels if I installed Hatch + the extension (even though the workstation setting for "use hatch for printing" was disabled) - browser printing failed with an exception in bundle.js IIRC |
| 10:49 |
* dbs |
will try to reproduce this on his own workstation, instead of the rather concerned staff |
| 10:50 |
dbs |
(Of course that could be a symptom of further unhappy fieldmapper stuff, which I'm going to first check to see is due to a localization issue, being a bilingual org...) |
| 10:51 |
|
sandbergja joined #evergreen |
| 10:53 |
Dyrcona |
mmorgan: date(now()) works for today, but yesterday not so much. :) |
| 10:53 |
* mmorgan |
nods |
| 10:53 |
berick |
dbs: confirmed. eg2 honors the setting, but not eg. working on a patch. |
| 10:54 |
dbs |
berick++ |
| 10:56 |
Dyrcona |
date(now()-'1 day'::interval)... who wants to type that? :) |
| 11:00 |
* dbs |
also looking into an issue where item templates all migrated nicely from XUL, but applying a template & hitting Save & Exit doesn't actually change any of the item attributes |
| 11:01 |
dbs |
whereas manually applying the individual changes does |
| 11:04 |
Bmagic |
Dyrcona: RE autorenew notifications not working. I was also working on that and I think I found a flaw in the stock SMTP headers "AutorenewNotify" AT. Specifically the "Date" line and the "From" line |
| 11:05 |
Bmagic |
before I make a bug report, I wanted to bounce it off you (and everyone else) |
| 11:05 |
Dyrcona |
Bmagic: That's interesting, but I don't think that's it. |
| 11:05 |
* dbs |
wonders if the item templates not applying is some variation on bug # 805621 |
| 11:06 |
Dyrcona |
I've filed this one that is related: bug 1837454 |
| 11:06 |
pinesol |
Launchpad bug 1837454 in Evergreen "SendEmail Reactor Will Try to Send Email with no valid To, Cc, or Bcc Headers" [Undecided,New] https://launchpad.net/bugs/1837454 |
| 11:06 |
Dyrcona |
bug 805621 |
| 11:06 |
pinesol |
Launchpad bug 805621 in drupal6 (Ubuntu) "package drupal6 6.20-1ubuntu1 failed to install/upgrade: subprocess installed pre-removal script returned error exit status 1" [Low,Invalid] https://launchpad.net/bugs/805621 |
| 11:06 |
Bmagic |
The From line from stock starts like this "From: [%- helpers.get_or...." - the minus sign removes previous whitespace which results in "From:email domain.com" which tricks the parser. I believe there needs to be a space there |
| 11:07 |
dbs |
err, bug 1805621 |
| 11:07 |
pinesol |
Launchpad bug 1805621 in Evergreen "Newly-created item templates do not always apply settings as expected" [Low,New] https://launchpad.net/bugs/1805621 |
| 11:07 |
Dyrcona |
Bmagic: OK. Our template isn't stock and has the space. |
| 11:07 |
* Dyrcona |
checks just to make sure. |
| 11:08 |
Bmagic |
And the date line "Date: [% date.format(date.now, '%a, %d %b %Y %T -0000', gmt => 1) %]" needs to be expressed like this "Date: [% date.format(format => '%a, %d %b %Y %H:%M:%S %Z') %]" |
| 11:08 |
Dyrcona |
Y'know, sometimes I like using PgAdmin4, but other times, I think psql is better. :) |
| 11:10 |
Dyrcona |
What date.format needs is a RFC 5322 option, similar to the date command's -R. |
| 11:11 |
mmorgan |
Bmagic: Our template has the minus in From: and the stock Date: line and we're not seeing an issue. |
| 11:12 |
mmorgan |
dbs: We have had issues with applied item templates not saving that were due to statistical categories. |
| 11:12 |
mmorgan |
trying to apply statistical categories that no longer existed was one issue. |
| 11:16 |
Dyrcona |
Bmagic: Headers on one of ours that succeeded look good. |
| 11:16 |
Bmagic |
so those are not issues? |
| 11:16 |
Dyrcona |
What I'm seeing is that these never get to the point of even generating the template. |
| 11:16 |
Bmagic |
I arrived at that conclusing while troubleshooting another AT that I based on the Autorenew template |
| 11:16 |
dbs |
mmorgan: thanks, I don't think we got rid of any stat cats but it's a good lead! |
| 11:16 |
Dyrcona |
They get to collected state, which means the data is gathered, but they stop before or during template generation. |
| 11:17 |
Dyrcona |
And, there is a Jabber Client no longer connected message in the stderr log, and sever other events also get a collected state. |
| 11:17 |
Dyrcona |
s/sever/several/ |
| 11:18 |
Dyrcona |
My year is off to a great start, typowise. |
| 11:26 |
mmorgan |
dbs: Also, a statcat with -1 caused problems, and then there was bug 1788680 |
| 11:26 |
pinesol |
Launchpad bug 1788680 in Evergreen 3.3 "Null statcats break copy templates" [High,Fix released] https://launchpad.net/bugs/1788680 |
| 11:32 |
Dyrcona |
Hmm.... Two users with collected a/r notices that have 95 and 73 notices respectively. Think I'll check if they even have email. |
| 11:32 |
Dyrcona |
I think we let people checkout too much material at once. |
| 11:35 |
Dyrcona |
Nope. they have email addresses. |
| 11:36 |
berick |
dbs: pullreq added for bug 1858118 |
| 11:36 |
pinesol |
Launchpad bug 1858118 in Evergreen "AngJS Always Tries To Use Hatch For Printing" [Critical,New] https://launchpad.net/bugs/1858118 - Assigned to Bill Erickson (berick) |
| 11:43 |
dbs |
berick++ # will try to apply and sign-off today |
| 11:54 |
|
jihpringle joined #evergreen |
| 12:10 |
rfrasur |
we're troubleshooting a negative "total encumbered" amount in acquisition fund details. While there are some scenarios we've talked about, does anyone in here have some suggestions? |
| 12:34 |
Dyrcona |
So, I'm resetting the auto-renewal events user by user. I did the first batch, excluding the 3 users with the most items out. Those all processed OK. I just did the user with the 3rd highest number of items out (43) and that worked. Now, to try the user with 79 items out. |
| 13:08 |
Dyrcona |
And, again with the user that has 79 items out: JabberClient disconnected. So I need to up the ejabberd log level to find out what happens there. |
| 13:15 |
|
khuckins joined #evergreen |
| 13:19 |
Dyrcona |
Why, oh why, do they insist on checking items out to a "display" card? I never understand this. Just set the status to "display." |
| 13:20 |
Dyrcona |
One of today's culprits is a "display" patron. |
| 13:33 |
rfrasur |
lol, a display patron |
| 13:34 |
Dyrcona |
Yeahp. |
| 13:35 |
Dyrcona |
I suspect we're hitting max_stanza_size of 2,000,000 with these patrons, but I don't have enough logging enabled to see it. |
| 13:41 |
Dyrcona |
I thought OpenSRF had an error message for that, but I'm not finding it. |
| 13:41 |
|
cmalm joined #evergreen |
| 13:43 |
|
jihpringle joined #evergreen |
| 13:53 |
dbs |
yay, over on our test server getting "egCore.hatch.getWorkstations is not a function" console error at the web staff client login prompt. and getWorkstations() is clearly defined in eg2/src/app/core/store.service.ts - sigh |
| 13:53 |
dbs |
at least it's our test server. |
| 13:54 |
berick |
dbs: one of those is eg2, one is eg. |
| 13:54 |
Dyrcona |
Aint' web development fun? |
| 13:55 |
Dyrcona |
Ain't software development fun? |
| 13:55 |
dbs |
berick: I'm rolling back to the commit before your fix for 1858118 to see what happens |
| 13:56 |
berick |
grep getWorkstations /openils/var/web/js/ui/default/staff/build/js/core.bundle.js |
| 13:56 |
berick |
if it's there, issue is likely a browser caching issue. |
| 13:57 |
Dyrcona |
Well, now that I've left those 174 auto-renewal notice events in collected limbo, my other events that were getting stuck all processed to complete or invalid. |
| 13:57 |
|
lstratton joined #evergreen |
| 13:57 |
Dyrcona |
There are only two hard problems in programming: cache invalidation and naming things. |
| 13:58 |
Dyrcona |
and off by one errors? :P |
| 13:58 |
dbs |
berick: huh, not there, interesting |
| 13:59 |
dbs |
guess I should run the npm build after checking out the new files |
| 13:59 |
dbs |
<-- idiot |
| 14:00 |
|
tkatie217 joined #evergreen |
| 14:01 |
Dyrcona |
s'ok. Everyone misses a step now and then. |
| 14:03 |
|
felicia joined #evergreen |
| 14:04 |
|
tlittle joined #evergreen |
| 14:09 |
Dyrcona |
renewals_remaining: -1... Always a sign of staff override. |
| 14:14 |
|
tkatie217 joined #evergreen |
| 14:22 |
|
jvwoolf joined #evergreen |
| 14:26 |
dbs |
I've had to instruct the handful of people who had run the 3.1 version of the web staff client to open up the Dev Tools -> Network tab and have "Disable cache" checked to flush out cached resources |
| 14:26 |
dbs |
Is that (or CTRL-Shift-R) a normal occurrence on upgrades? |
| 14:29 |
Dyrcona |
dbs: Yes, but I usually open up the dev tools, right click the reload button and choose "Empty Cache and Hard Reload." |
| 14:34 |
Dyrcona |
I think 1cb0d8c63c445979e272f4ad72ea912afcabf7e2 has something to do with it. |
| 14:34 |
pinesol |
Dyrcona: [evergreen|Dan Scott] LP#1681095 Set aggressive default cache expires timelines - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1cb0d8c> |
| 14:39 |
berick |
/eg2 has cache busting, /eg does not. my plan for now is to use short cache expire times for /eg content. we could also work on adding cache busting to /eg. |
| 14:39 |
berick |
cache busting for /eg would require custom intervention, given our use of TT2 |
| 14:40 |
berick |
(but we've done similar before) |
| 14:41 |
Dyrcona |
I think just setting reasonable expires suggestions in eg.conf would be enough. |
| 14:46 |
dbs |
Well, one year was perfectly reasonable when we had cache-busting for everything of consequence |
| 14:51 |
dbs |
I dialled everything back to a default expire time of four hours (for those bits that don't expire in 5 seconds). But that also means that anyone just using the catalogue takes the same performance hit for all those requests. |
| 14:52 |
berick |
dbs: could limit it to /eg/staff |
| 14:52 |
Dyrcona |
dbs: You can set Expires by location, too. |
| 14:52 |
Dyrcona |
:) |
| 14:53 |
dbs |
Dyrcona: did not know about the "Empty Cache and Hard Reload" option! |
| 14:54 |
Dyrcona |
It's only there in Chrome with the dev tools enabled. |
| 14:54 |
Dyrcona |
I find it very handy when testing. |
| 15:02 |
|
mmorgan1 joined #evergreen |
| 15:07 |
dbs |
I guess we should document this expectation for now, and then work on fixing it so it's no longer necessary? |
| 15:09 |
|
jvwoolf joined #evergreen |
| 15:46 |
|
mmorgan joined #evergreen |
| 15:53 |
|
mantis1 left #evergreen |
| 16:04 |
|
jihpringle joined #evergreen |
| 16:37 |
* mmorgan |
seems to remember a lp bug about storing the registered workstation on the server, but can't find one. Does this ring any bells? |
| 16:40 |
berick |
mmorgan: we recently committed a branch to support storing the workstations in Hatch (when available) |
| 16:41 |
berick |
alas we have to keep some kind of workstation data within the browser (or accessible to the browser) so it can bootstrap itself. |
| 16:43 |
Dyrcona |
mmorgan Did you search fix released bugs as well? I believe that made it in. |
| 16:44 |
mmorgan |
Ok, I think that's the one I was thinking of. bug 1825896 |
| 16:44 |
pinesol |
Launchpad bug 1830391 in Evergreen 3.3 "duplicate for #1825896 Hatch omnibus circa 3.3 (Java updates and more)" [Undecided,New] https://launchpad.net/bugs/1830391 |
| 16:45 |
mmorgan |
I searched fix released, but didn't unhide duplicates. |
| 16:46 |
|
sandbergja joined #evergreen |
| 16:46 |
mmorgan |
We still have staff computers annoyingly losing their workstation registration. |
| 16:50 |
mmorgan |
berick++ |
| 16:51 |
berick |
mmorgan: beware if you merge locally, this will also be needed. https://bugs.launchpad.net/evergreen/+bug/1858118 |
| 16:51 |
pinesol |
Launchpad bug 1858118 in Evergreen "AngJS Always Tries To Use Hatch For Printing" [Critical,New] |
| 16:52 |
mmorgan |
Okay, thanks! |
| 17:04 |
|
mmorgan left #evergreen |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:02 |
|
sandbergja joined #evergreen |
| 18:19 |
|
abowling1 joined #evergreen |
| 18:21 |
|
sandbergja joined #evergreen |
| 18:34 |
|
abowling joined #evergreen |
| 19:07 |
|
jihpringle joined #evergreen |
| 20:12 |
|
stephengwills joined #evergreen |
| 20:43 |
|
stephengwills left #evergreen |
| 22:19 |
|
sandbergja joined #evergreen |
