| 04:41 |
|
denials joined #evergreen |
| 04:41 |
|
tsadok joined #evergreen |
| 04:42 |
|
jweston_ joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:18 |
|
rjackson_isl_hom joined #evergreen |
| 08:25 |
|
mantis joined #evergreen |
| 09:49 |
|
rfrasur joined #evergreen |
| 10:14 |
berick |
could play an error sound too |
| 10:14 |
jeff |
hah, I was just thinking of an amusing error sound. |
| 10:15 |
berick |
*sad trombone* |
| 10:23 |
jeff |
okay, yes. looks like I can happily call egAlertDialog within services/net.js for a method error. I might leave that in place on my test instance for a while and see what it surfaces. |
| 10:24 |
jeff |
in the case of missing pieces where I have a method error and added a second function to the promise to surface that error on that specific action, I end up with two egAlertDialogs. :-) |
| 10:32 |
jeff |
having recently upgraded, I find myself wanting a test instance with our previous version of Evergreen... oops. :-) |
| 10:40 |
|
bshum joined #evergreen |
| 10:42 |
jeff |
bah: |
| 10:42 |
jeff |
> We detected an application built with production configuration. Angular DevTools only supports development builds. |
| 10:59 |
|
mmorgan joined #evergreen |
| 11:21 |
|
abowling joined #evergreen |
| 11:47 |
|
Keith-isl joined #evergreen |
| 15:07 |
Dyrcona |
Mechanical wit, but then it runs out and you have to buy more. Plus it leaves bits all around. |
| 15:07 |
JBoyer |
Ok, people should feel free to #info up as they continue to join. |
| 15:07 |
JBoyer |
#topic Action Items from Last Meeting |
| 15:07 |
JBoyer |
#info JBoyer will test out the branch in lp 1947595 |
| 15:08 |
pinesol |
JBoyer: Error: Could not gather data from Launchpad for bug #1947595 (https://launchpad.net/bugs/1947595). The error has been logged |
| 15:08 |
JBoyer |
I'm as surprised as you all may be, but that did happen and the branch was even signed off on because it does the thing. Dyrcona ++ |
| 15:08 |
Dyrcona |
JBoyer++ |
| 15:18 |
pinesol |
Launchpad bug 1953044 in OpenSRF "Perl services can crash with a "Use of freed value in iteration" error" [Medium,Confirmed] https://launchpad.net/bugs/1953044 |
| 15:18 |
gmcharlt |
the latter two are currently in production at Equinox |
| 15:19 |
gmcharlt |
the first one is a little more prospective |
| 15:19 |
Dyrcona |
I'll see if I can make some time to test a couple of those. |
| 15:19 |
csharp_ |
these are the "think of the children!" branches you mentioned before |
| 15:19 |
gmcharlt |
yup |
| 15:21 |
JBoyer |
Sounds like a plan, hopefully all 3 of those can get some testing and make it in soon. Any other OpenSRF discussion? |
| 15:22 |
jeffdavis |
(testing some of those is on my todo list fwiw) |
| 15:22 |
JBoyer |
jeffdavis++ (and Dyrcona ++ and gmcharlt ++ ) |
| 15:22 |
JBoyer |
If not, and given the placholders holding places we can skip down to |
| 15:23 |
JBoyer |
#topic Launchpad Status |
| 15:27 |
csharp_ |
do we have a sense of how well Edge Just Works™? |
| 15:27 |
csharp_ |
and to be clear, we're talking about Edge that's based on Chrome, yes? |
| 15:27 |
Dyrcona |
I believe so. |
| 15:27 |
JBoyer |
So, with the fact that it's literally Chromium + MS sync instead of Google Sync it works pretty well. shulabear took the client for a test drive and found no potholes. |
| 15:27 |
alynn26 |
I know of several people who use it. it works great for them. |
| 15:28 |
csharp_ |
maybe support it with a huge YMMV warning? |
| 15:28 |
JBoyer |
Yeah, Not-Chromium Edge is no bueno, even for MS. |
| 15:28 |
shulabear |
I've encountered no issues with it in testing, as long as it's the Chromium version. |
| 15:28 |
csharp_ |
that's the way we support MacOS here in PINES |
| 15:28 |
csharp_ |
"feel free, but it's on you" |
| 15:29 |
mmorgan |
What does "supporting Edge" entail? |
| 15:31 |
csharp_ |
I guess Hatch should be in the mix of what "support" means too? |
| 15:32 |
JBoyer |
csharp_, it works fine as-is, just isn't yet on the Edge Extension thing. (though you can install it via the chrome web store I believe) |
| 15:32 |
csharp_ |
I don't have a strong feeling/preference either way, which I guess is effectively "yes" |
| 15:34 |
JBoyer |
It's also possible to test the Angular client with the linux version by setting CHROMIUM_BIN to the right path. (I don't actually recommend using my branch to add the edge npm launcher because there's no good way to handle missing browsers. :/ ) |
| 15:35 |
JBoyer |
I'm for it personally because it's extremely low effort and it's possible that local IT may standardize on it anyway so staff may as well know we'll make sure it works. |
| 15:36 |
alynn26 |
+1 |
| 15:36 |
gmcharlt |
+1 |
| 15:39 |
JBoyer |
oops. Let the minutes show that's 11, 0, 1, not that it was a close call. :) |
| 15:39 |
JBoyer |
#topic Support for Newer PostgreSQL Versions |
| 15:39 |
JBoyer |
Dyrcona, how's things? |
| 15:40 |
Dyrcona |
Well, there are branches, one of which has been tested and signed off. |
| 15:40 |
miker |
soon to be committed :) |
| 15:40 |
Dyrcona |
mker looked at the other and had some questions about the XML changes. I'll go back an make them more consistent, using local-name() instead of namespaces. |
| 15:41 |
Dyrcona |
I'd like to get this in before the next Evergreen release. (3.9?) |
| 15:41 |
miker |
seems likely, imo |
| 15:42 |
Dyrcona |
The tests all pass, but I think there are places, like located URIs where performance suffers on newer Pg versions. |
| 15:42 |
miker |
I think I owe eyes on an old branch for that, in particular |
| 15:43 |
Dyrcona |
my three big questions are: 1. I'd like the Stretch removal branch to go in first, so that we don't have to mess with stretch prerequisites. |
| 15:43 |
JBoyer |
That shouldn't be an issue for 3.9 |
| 15:46 |
miker |
that complicates or delays dealing with some performance issues in 11+ re CTEs, but that's just timing I guess |
| 15:47 |
Dyrcona |
Well, we could remove the non-versioned db prerequisite and word the read me to recommend 10 in production environments. |
| 15:48 |
miker |
And by that I mean CTEs may need 11+ only syntax changes to avoid speed regressions |
| 15:48 |
JBoyer |
True, I kind of meant "if we can knock them out" when I said "other than these problems" :) but since we've had 9.6 and 10 available for some time we should probably have 10 and 14 available for those who want to test |
| 15:50 |
gmcharlt |
yeah, "it works" is sufficient for offering the option to install with newer versions, but I think the production recommendations need to avoid known performance regressions |
| 15:50 |
JBoyer |
I can +1 that. |
| 15:51 |
mmorgan |
+1 |
| 15:57 |
shulabear |
Dyrcona++ |
| 15:57 |
JBoyer |
#topic Migrating to Angular 12 sooner than later? |
| 15:57 |
JBoyer |
berick, how does it look? |
| 15:58 |
berick |
oh sorry |
| 15:58 |
berick |
minus a few broken unit tests, my initial Ang 12 upgrade process worked as expected |
| 15:59 |
JBoyer |
The angular update site makes it look like we can make that jump without any real code changes, which is good. |
| 15:59 |
berick |
if we want to update before EG 3.9 I'd prefer sooner than later |
| 15:59 |
sandbergja |
berick: does the linter still work? I remember something about some linting changes |
| 15:59 |
berick |
yeah, it was not such a big doeal |
| 15:59 |
berick |
sandbergja: don't recall if I tested. I can, though, when I rebase |
| 15:59 |
sandbergja |
berick++ |
| 15:59 |
sandbergja |
thanks |
| 16:00 |
berick |
ideally we could pick a merge date and me and whoever else can help will get it merged |
| 16:38 |
miker |
jboyer++ |
| 16:38 |
|
mmorgan left #evergreen |
| 16:39 |
sandbergja |
claiming 1309 |
| 16:42 |
pinesol |
[evergreen|malexander] lp-1942645 term name uniqueness - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a11ce47> |
| 16:42 |
pinesol |
[evergreen|Jane Sandberg] LP 1942645: stamp upgrade script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e79df5d> |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 00:57 |
|
abowling1 joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:47 |
|
rjackson_isl_hom joined #evergreen |
| 08:36 |
|
mmorgan joined #evergreen |
| 08:52 |
|
rfrasur joined #evergreen |
| 12:02 |
mmorgan |
berick++ # bug 1954301 |
| 12:02 |
pinesol |
Launchpad bug 1954301 in Evergreen "Hatch Browser Extension Sometimes Fails to Respond" [High,Confirmed] https://launchpad.net/bugs/1954301 - Assigned to Bill Erickson (berick) |
| 12:11 |
mmorgan |
berick: Assuming no issues are found with your patch, how does the fix proceed? Does it just come down to an update to the Chrome extension? Just wondering if we should start loading the unpacked extension on affected workstations. |
| 12:17 |
berick |
mmorgan: once it's merged, I'll post it to the Chrome store. after that, the extension should automatically update in the browser. |
| 12:18 |
berick |
csharp_: wondering if you have any cycles to test the extension changes in Firefox... https://launchpad.net/bugs/1954301 |
| 12:18 |
pinesol |
berick: Error: Could not gather data from Launchpad for bug #1954301 (https://launchpad.net/bugs/1954301). The error has been logged |
| 12:18 |
berick |
i'll try to do the same today |
| 12:18 |
mmorgan |
berick: ok, thanks! |
| 12:20 |
mmorgan |
jeff++ |
| 12:20 |
* jeff |
waves |
| 12:34 |
jeff |
oh hey, i should probably remove the .firefox from the this filename if I expect it to work: org.evergreen_ils.hatch.firefox.json |
| 12:42 |
berick |
my initial FF tests show the extension changes working as expected |
| 12:42 |
jeff |
hah, beat me to it. |
| 12:51 |
jeff |
tests well here on 96.0b3 for macOS |
| 12:52 |
jeff |
I can sign off and commit if you want to do the chrome/firefox extension bits on a Friday... |
| 12:57 |
JBoyer |
Does anyone need to print receipts on a weekend? |
| 12:57 |
JBoyer |
;D |
| 13:01 |
berick |
jeff: i'll be squashing the commit post-sign if that's OK w/ you (to remove some cruft, add some more code comments) |
| 13:03 |
jeff |
feel free either way. i haven't pushed a signoff but i could do one after if you like. |
| 13:04 |
berick |
ok, thanks |
| 13:04 |
berick |
lemme push a cleanup.. |
| 13:07 |
jeff |
We did encounter this on a few workstations this week after our upgrade, but when I went looking for workstations to test on, there appeared to be none that still had the issue... so, I'm confirming that it doesn't break anything that I can see, the fix looks logical, and I'm relying on mmorgan and others to confirm that it is an effective fix. :-) |
| 13:08 |
* mmorgan |
has been working in the client with the new extension and has seen no issues. |
| 13:09 |
mmorgan |
But I do wonder about deploying on a Friday... |
| 13:10 |
berick |
jeff: pushed user/berick/lp1954301-ext-tab-message-order-v2 w/ a single cleaned up commit. |
| 15:08 |
|
jvwoolf joined #evergreen |
| 16:22 |
|
jvwoolf left #evergreen |
| 17:10 |
|
mmorgan left #evergreen |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 04:08 |
|
JBoyer joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:33 |
|
rjackson_isl_hom joined #evergreen |
| 07:48 |
|
collum joined #evergreen |
| 08:19 |
|
rfrasur joined #evergreen |
| 10:35 |
pinesol |
Dyrcona: Excel/xlsx WILL PERISH UNDER MAXIMUM DELETION! DELETE. DELETE. DELETE! |
| 10:36 |
Dyrcona |
Looking at the log more carefully, I see this: Dec 9 10:34:05 jasontest open-ils.cstore: [INFO:6887:osrf_application.c:1075:] CALL: open-ils.cstore open-ils.cstore.direct.asset.copy.search {"barcode":"3.0453000494612E13","deleted":"f"},{"flesh_fields":{"acp":["circulations"]},"flesh":1} |
| 10:37 |
jeff |
aha! |
| 10:37 |
Dyrcona |
The barcode is a "number" according to that output. I guess only the barcodes that begin with the letter A are working. Now, why this happens on the test vm and not in production... Hm. I edited the sheet in LibreOffice this morning. Maybe that "fixed" it? |
| 10:38 |
jeff |
(now some fun is to be had with determining if the text->number type confusion happened at log time or before.) |
| 10:39 |
Dyrcona |
jeff: It's before. Excel does that with barcodes. I think the spreadsheet I used in production was editing in LibreOffice. I'll copy it to the test vm again and see what happens. |
| 10:39 |
jeff |
oh, if you're using Spreadsheet::Read and the input barcode file is different between test and production, I suspect the input file is your issue now. |
| 10:40 |
* jeff |
nods |
| 10:42 |
Dyrcona |
yeahp. It's chugging away, now. |
| 10:42 |
Dyrcona |
GIGO |
| 10:44 |
Dyrcona |
So, they want the already deleted copies checked in, so I should go back to the cstore session or editor, remove the deleted=>'f', etc., etc., and so on and so forth. |
| 16:22 |
bott_grpl |
But exactly what I was looking for! |
| 16:22 |
bott_grpl |
berick++ jeffdavis++ |
| 17:31 |
|
jvwoolf left #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:45 |
pinesol |
[evergreen|Jason Stephenson] Lp 1862652: pingest.pl reingest record attributes fix - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=5ac76ef> |
| 23:03 |
|
alynn26_away joined #evergreen |
| 04:15 |
|
alynn26_away joined #evergreen |
| 04:15 |
|
alynn26_away joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:23 |
|
rjackson_isl_hom joined #evergreen |
| 07:26 |
|
rjackson_isl_hom joined #evergreen |
| 08:38 |
|
mmorgan joined #evergreen |
| 11:44 |
mmorgan |
Huge disruption at circ desks when that was introduced. |
| 11:47 |
Dyrcona |
miker: Pg 11 and Pg 12 release notes, plus previous IRC discussion. Guess I typoed the commit header. I'll fix it if I get around to it. |
| 11:48 |
Dyrcona |
Failure mode is database functions don't work. |
| 11:48 |
Dyrcona |
Perl and Pgtap test fail. |
| 11:48 |
miker |
heh, well, I figured /that/ much :) |
| 11:49 |
Dyrcona |
Well, the commits fix the tests, so there you go. |
| 11:49 |
Dyrcona |
I figured this would wait until after next week's dev meeting anyway. |
| 11:49 |
miker |
I was looking for an LP bug as I thought that might have error messages, is all. there's a mix of namespace addition and local-name() and I'm trying to understand the details |
| 11:50 |
miker |
I mean, sure, it can. I just happened to be in some similar areas |
| 12:15 |
|
jonadab joined #evergreen |
| 12:18 |
jeff |
We also ditched the sms_check constraint on action.request, as we don't need or care about sms_carrier. |
| 12:23 |
jeff |
and needed to change some bits on the place hold screen, because sms-related settings that weren't being shown were preventing the form from being submitted. :-) |
| 12:36 |
Dyrcona |
miker: I got the obvious things that have tests. More eyes are welcome. |
| 12:37 |
* miker |
fires up sed |
| 12:52 |
mmorgan |
jeff: bug 1933381 |
| 12:52 |
pinesol |
Launchpad bug 1933381 in Evergreen 3.6 "Angular: place hold fails with a generic error when Notify by SMS is selected without a carrier" [Low,Fix released] https://launchpad.net/bugs/1933381 |
| 16:30 |
|
jamin joined #evergreen |
| 16:35 |
jamin |
Are there any good docs for making proper use of user activity types? As in creating a new one? (Which I've done, and have III Patron API working for one org, but... just making up values to stuff in the fields doesn't seem right, and am not surprised to see nothing end up in the user activity table.) |
| 16:36 |
|
jvwoolf left #evergreen |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:30 |
|
rjackson_isl_hom joined #evergreen |
| 07:47 |
|
collum joined #evergreen |
| 08:36 |
|
mantis joined #evergreen |
| 15:17 |
mmorgan |
It does seem to have something to do with Hatch. My Chrome has the Hatch Chrome plugin installed, but Hatch is not enabled in Evergreen. |
| 15:18 |
mmorgan |
This doc shows screenshots of what the screens look like, and the console: https://docs.google.com/document/d/1d5dC1LhgZgPbXeFDWcmbCjRCotFl3fZSC5-GlJVyBic/edit?usp=sharing |
| 15:18 |
jeff |
do you have steps that you can reliably reproduce? |
| 15:18 |
mmorgan |
When we see the whilte screen, this is the last line in the console: |
| 15:18 |
mmorgan |
sending to Hatch: {"key":"eg.workstation.all","action":"get","msgid":1} |
| 15:20 |
mmorgan |
I didn't want to destroy my test environment, but I *think* this is happening only on angularjs screens. |
| 15:20 |
mmorgan |
Any thoughts? |
| 15:20 |
jeff |
are there any clues in hatch.log? |
| 15:20 |
alynn26 |
That is what we are seeing. We are also seeing it with some of the Angular screens. but not much. |
| 15:22 |
mmorgan |
dumb question time: Where will I find hatch.log? |
| 15:23 |
jeff |
you can usually enter %userprofile% in Start -> Run |
| 15:23 |
jeff |
unless you've changed the location in logging.properties |
| 15:24 |
jeff |
or unless your file permissions on logging.properties prevent it from being read, in which case I forget what the default is. might be "no log" |
| 15:26 |
berick |
cd 'C:\Program Files(x86)\Hatch' ; \.hatch.bat test |
| 15:27 |
berick |
can also be useful |
| 15:27 |
mmorgan |
Hmm. Not seeing a .evergreen directory for my userprofile |
| 15:28 |
berick |
correction: .\hatch.bat |
| 15:29 |
mmorgan |
csharp_: I see the background page for the Hatch extension, but don't see anything that looks like an error there. |
| 15:43 |
mmorgan |
jeff: I think that is true, but will confirm. |
| 15:43 |
jeff |
what version of Evergreen and Hatch are you running? |
| 15:44 |
jeff |
guessing Hatch 0.3.2, but not wanting to assume. |
| 15:45 |
mmorgan |
jeff: Confirmed: no corresponding "Hatch responded to message ID 1" in the browser console. |
| 15:47 |
mmorgan |
I refresh, the screen loads, and I see "Hatch responded to message ID 1" in the browser console. |
| 15:48 |
mmorgan |
jeff: Hatch 0.3.2 |
| 15:50 |
mmorgan |
I logged into the client on 3 different servers this morning, production, test, and dev. I am no longer seeing the problem in production, but am still seeing it in test and dev. |
| 15:51 |
mmorgan |
Neglected to say that this was all in the same Chrome window, different tabs, and all showed the problem. |
| 15:53 |
berick |
i wonder if it's getting hung up on something else.. |
| 15:53 |
berick |
mmorgan: go to chrome://inspect/#workers and click on 'inspect' for https://HOSTNAME/js/ui/default/staff/offline-db-worker.js |
| 15:54 |
berick |
see if anything in there complains when the page fails to load |
| 16:00 |
mmorgan |
3.6.4, 3.7.2 and another flavor of 3.6, I believe. |
| 16:01 |
mmorgan |
berick: the inspect page seems to refresh itself. The listed servers blink on and off depending on whether the screens load or not. |
| 16:01 |
Dyrcona |
If I apply that patch for the symspell stuff on a system where it has already been ingested once before, do I have to do it again? |
| 16:02 |
berick |
mmorgan: hm, it's inconsistent for me. just tested again and had to refresh. *shrug* |
| 16:03 |
jeff |
i wonder what you'd see if you go to chrome://extensions, enable Developer mode, and then select the "background page" link for Hatch Native Messenger. |
| 16:04 |
mmorgan |
berick: tried refreshing several times when on an incomplete screen. The server doesn't show under Shared workers. |
| 16:05 |
jeff |
I get the behavior you've described 100% of the time when I have the hatch browser extension installed but no native messaging host (no Java bits). 100% as in it's not intermittent / fixed with a reload, it just fails every time. |
| 17:00 |
mmorgan |
alynn26++ |
| 17:00 |
mmorgan |
JBoyer++ |
| 17:05 |
|
mmorgan left #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 03:47 |
|
eglogbot joined #evergreen |
| 03:47 |
|
Topic for #evergreen is now Welcome to #evergreen (https://evergreen-ils.org). This channel is publicly logged. |
| 04:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 05:42 |
|
rjackson_isl_hom joined #evergreen |
| 07:13 |
|
rjackson_isl_hom joined #evergreen |
| 07:23 |
|
collum joined #evergreen |
| 11:14 |
pinesol |
Launchpad bug 1904036 in Evergreen "Port patron interfaces to Angular (search, checkout, etc.)" [Wishlist,New] https://launchpad.net/bugs/1904036 |
| 11:34 |
|
rjackson_isl_hom joined #evergreen |
| 12:07 |
|
jihpringle joined #evergreen |
| 12:07 |
jeff |
well that's new. a 3.7 test install does not have my username workstation nor the log out / about menu. |
| 12:07 |
jeff |
a different 3.7 test install has it, and a 3.8 install has it. |
| 12:08 |
jeff |
(tested in ingognito also) |
| 12:12 |
jihpringle |
jeff: I ran into that using the 3.8 community server - I had to clear my cache and cookies and close Chrome to get it back |
| 12:12 |
jihpringle |
I haven't been able to reproduce yet |
| 12:18 |
jeff |
interesting. I would have thought that an incognito window would have addressed all that. so far, I can reproduce it all the time. :-) |
| 13:26 |
jvwoolf |
mmorgan: Yeah, that seems likely |
| 13:26 |
jvwoolf |
mmorgan++ |
| 13:27 |
* mmorgan |
needs to run away for a bit, but it would be great to add heat to that! |
| 14:10 |
jeff |
Hrm. "place hold for this staff account" seems to be working for me in a 3.7.2 test system, but not when I try to place the hold for my 'normal' patron. Place Hold(s) button isn't enabled. |
| 14:10 |
* jeff |
looks |
| 14:32 |
jeff |
ah, users with sms hold notification enabled but no carrier/etc. drat. we'll have to figure a solution there. |
| 14:33 |
jeff |
we might just start using a different opt-in user setting, but that might change too many other things. |
| 14:44 |
|
rjackson_isl_hom joined #evergreen |
| 17:04 |
|
mmorgan left #evergreen |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:17 |
|
jihpringle joined #evergreen |
| 04:42 |
|
troy joined #evergreen |
| 04:42 |
|
jeffdavis joined #evergreen |
| 04:44 |
|
eby joined #evergreen |
| 06:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:46 |
|
collum joined #evergreen |
| 07:23 |
|
rjackson_isl_hom joined #evergreen |
| 08:37 |
|
mmorgan joined #evergreen |
| 10:10 |
Dyrcona |
I guess that should have been "roll in" not "role in." :) |
| 10:17 |
Dyrcona |
I've already based this branch off of the branch for bug 1947595, so what's another one? Squash 3 bugs in one branch.... |
| 10:17 |
pinesol |
Launchpad bug 1947595 in Evergreen "array_accum Aggregate and PostgreSQL 14" [Undecided,New] https://launchpad.net/bugs/1947595 |
| 10:23 |
Dyrcona |
I'm also working on tests and release notes for bug 1883171 and bug 1940663. I'm not sure which I'll get to first. |
| 10:23 |
pinesol |
Launchpad bug 1883171 in Evergreen "duplicate entries for a copy in asset.latest_inventory table" [Undecided,In progress] https://launchpad.net/bugs/1883171 - Assigned to Jason Stephenson (jstephenson) |
| 10:23 |
pinesol |
Launchpad bug 1940663 in Evergreen "Inventory: Staff users can update inventory dates on non-owned items" [Undecided,In progress] https://launchpad.net/bugs/1940663 - Assigned to Jason Stephenson (jstephenson) |
| 10:26 |
csharp_ |
Dyrcona++ |
| 10:55 |
jeff |
Simplest fix is probably to cut a release with the "remove Python" changes, but I don't know if that was waiting for 3.3 and we want to fix 3.2 or not. |
| 10:58 |
mmorgan |
rfrasur: If so, that should be fixed as of 3.6.2: bug 1889128 |
| 10:58 |
pinesol |
Launchpad bug 1889128 in Evergreen "Angular Staff Catalog: Place Another Hold & Multi-Holds" [High,Fix released] https://launchpad.net/bugs/1889128 |
| 10:59 |
mmorgan |
I am able to select a number of copies when placing a hold on our 3.7.2 test system. |
| 11:00 |
rfrasur |
mmorgan, can you screen shot and send to me? |
| 11:01 |
Dyrcona |
jeff: I'm not sure I encountered that, or if I also had the remove Python branch when I installed on Debian 11. |
| 11:03 |
rfrasur |
csharp_, the workflow is go to record, click to place title hold, in the traditional catalog place holds, there's a drop down to select a number of items (that defaults to one). There is no such thing (that I'm seeing) in the angular place holds. |
| 11:10 |
jeff |
Dyrcona: just added a comment: (forgot to specify: affects OpenSRF 3.2.2 / rel_3_2 branch) |
| 11:11 |
Dyrcona |
jeff: The Python removal code shows up in master before the support for Debian 11 is added. |
| 11:11 |
mmorgan |
rfrasur: Will grab a screenshot, but I do notice that the "Number of copies" selector doesn't appear until I enter the patron's barcode. |
| 11:11 |
rfrasur |
Okay. testing. |
| 11:11 |
Dyrcona |
Well, sure, 3.2 is behind, and we should have a 3.3 release in my opinion. I mostly just use master. |
| 11:11 |
jeff |
Dyrcona: the changes in bug 1827055 haven't made it to a release yet. |
| 11:11 |
pinesol |
Launchpad bug 1827055 in OpenSRF "Python binding for OpenSRF and Evergreen" [Medium,Fix committed] https://launchpad.net/bugs/1827055 |
| 16:00 |
|
jvwoolf joined #evergreen |
| 16:33 |
|
jvwoolf left #evergreen |
| 17:10 |
|
mmorgan left #evergreen |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:24 |
|
collum joined #evergreen |
| 07:24 |
|
rjackson_isl_hom joined #evergreen |
| 08:27 |
|
Dyrcona joined #evergreen |
| 08:30 |
|
awitter joined #evergreen |
| 08:35 |
|
mmorgan joined #evergreen |
| 08:38 |
|
mantis joined #evergreen |
| 08:45 |
Dyrcona |
It bugs me that a pgtap test can succeed, but when running one of the inserts outside of a transaction blows up. I believe that is caused by a deferred trigger, which ain't so deferred if there isn't a transaction. |
| 09:02 |
Dyrcona |
All right. All pgtap tests now succeed on Pg 10 and Pg 11 with XPath fixes. |
| 09:04 |
Dyrcona |
Things get more interesting at Pg 12 and beyond. |
| 09:11 |
|
rfrasur joined #evergreen |
| 09:19 |
Dyrcona |
Aight. The unaccent business is a pain. |
| 09:38 |
Dyrcona |
Why can't I type a complete sentence this morning without omitting a word? |
| 09:38 |
Dyrcona |
@blame Friday |
| 09:38 |
pinesol |
Dyrcona: Friday must eat cottage cheese! |
| 09:38 |
Dyrcona |
Aight... Two more tests that fail on Pg 12+.... |
| 09:41 |
Dyrcona |
Looks like I fix them both if I fix one. |
| 10:05 |
Dyrcona |
Y'know, it would be handy to add an option to eg_db_config to create the pgtap extension. |
| 10:06 |
Dyrcona |
But, maybe that's just cause I reload the schema on multiple databases multiple times a day. |
| 13:25 |
mmorgan |
Dyrcona: Are you certain about that? ;-) |
| 13:29 |
Dyrcona |
mmorgan++ |
| 13:34 |
Dyrcona |
I think I've uncovered quantum entanglement in Pg 10. |
| 13:36 |
Dyrcona |
I've loaded the test data for Pg/live_t/lp1145213_test_func_asset.merge_record_assets.pg on both Pg 10 and Pg 12. |
| 13:37 |
Dyrcona |
It then run a modified version of asset.merge_record_assets on the records as is done in the test. |
| 13:37 |
Dyrcona |
On Pg10 I get 4 moved objects: 1 metarecord and 3 call numbers. On Pg 12 I get 3 moved objects, the call numbers. |
| 13:39 |
Dyrcona |
Aight, so I think the metarecord isn't created on Pg 12, so I reload the databases, and reload the test data. I check the metabib.metarecord table with the same query used by asset.merge_record_assets. There's no metarecord entry with 60001 as the master record in either database. |
| 13:41 |
Dyrcona |
Instead, the two inserted records (60000 and 60001) are in the source maps of two other metarecords, 17 and 35, respectively. |
| 13:42 |
Dyrcona |
Somehow, between starting to run the merge_record_assets function and it getting to the master record check, the metabib.metarecord entry is created, but I don't see any updates or anything else that would do that. |
| 13:43 |
Dyrcona |
The function basically just looks for asset.uris, doesn't find any in this case, then looks for the metarecord which shouldn't be there, but is on Pg 10. |
| 14:12 |
Dyrcona |
Lovecraftian |
| 14:24 |
Dyrcona |
Turns out Heisenberg in an Evergreen programmer. :) |
| 14:27 |
Dyrcona |
So, if the quality of two or more bibs is the same, it's undetermined which one becomes the master record. It depends on the order that they come out of the database, which is not always id order. |
| 14:28 |
Dyrcona |
We've been lucky up until now that this test has passed. |
| 14:29 |
Dyrcona |
I'm going to add id ascending on the order by so that that best bib with the lowest id number is picked. It's already excluding deleted bibs. |
| 14:52 |
JBoyer |
Dyrcona++ # Modern Pg support progress |
| 14:54 |
|
rjackson_isl_hom joined #evergreen |
| 14:59 |
Dyrcona |
"All test successful" at least on Pg 10 and Pg 14 for pgtap. I'll get to the Perl tests after I do something else, but the Perl tests were all passing but 1 before and I fixed that one. Hopefully, noting I did causes any new issues. |
| 15:09 |
Bmagic |
Dyrcona++ |
| 15:15 |
mmorgan |
Dyrcona++ |
| 15:17 |
Dyrcona |
Thank you, thank you. I've been wanting to move to more recent PostgreSQL for a while. |
| 15:19 |
Dyrcona |
So Perl tests pass on Pg 10 and Pg 14 on my local VM. I'll run them again on a different vm later. |
| 15:19 |
Dyrcona |
I'm going to do Pg 10 through Pg 14 on a VM that has access to that big database server. |
| 15:20 |
Dyrcona |
I "accidentally" installed Pg 14 along side Pg 10 on this local VM and decided to keep it for testing. |
| 15:45 |
Dyrcona |
This is bad. The Perl live tests succeeded on my local VM but they failed on the remote vm.... /sigh |
| 15:48 |
Dyrcona |
Hrm. I wonder if the IDL was up to date? |
| 15:52 |
Dyrcona |
IDK. It's the same versions of everything, and the Perl live tests are failing..... |
| 15:54 |
Dyrcona |
So, we'll make clean and try again. |
| 15:59 |
Dyrcona |
Aight, make sure to reload the database. |
| 15:59 |
Dyrcona |
Oh! I don't think I set the admin password correctly. |
| 16:04 |
Dyrcona |
oof. I have to reload all of the databases... |
| 16:22 |
Bmagic |
what fun |
| 16:26 |
Dyrcona |
I'm pretty sure that forgetting to set the admin-use and admin-pass was my problem, but I'll probably wait until Monday the 29th before testing it on this vm. |
| 16:26 |
Dyrcona |
It worked on my other vm. |
| 16:26 |
Bmagic |
othre_vm++ |
| 16:26 |
Bmagic |
other_vm++ # also |
| 16:37 |
JBoyer |
Dyrcona++ |
| 17:00 |
|
mmorgan left #evergreen |
| 17:31 |
|
jihpringle joined #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:21 |
|
rjackson_isl_hom joined #evergreen |
| 08:30 |
|
Dyrcona joined #evergreen |
| 08:46 |
|
collum joined #evergreen |
| 09:36 |
Dyrcona |
mmorgan: They will probably have to open the dev tools, go to storage, and nuke all of the cache and settings for Evergreen. |
| 09:36 |
mmorgan |
Dyrcona: Yes, have seen browser updated cause similar issues, but this doesn't seem to be update related. |
| 09:37 |
Dyrcona |
Well, Chrome 96 just came out recently and reportedly has a lot of problems with various sites. |
| 09:37 |
Bmagic |
One way to simulate it, is to setup an Evergreen server on a previous version of Evergreen. Like several versions old. Update your hosts file to point your domain name to this test server. Hard refresh the login page, login, hard refresh a few pages. This gets the old JS code into your browser |
| 09:37 |
Bmagic |
then, change your hosts file back so that it points to production, and try to login |
| 09:39 |
mmorgan |
Bmagic: I don't feel like this is upgrade related, reports started a month after our last upgrade. |
| 09:41 |
JBoyer |
I usually suspect things like chrome addons, some of them get pretty wild. (And they sync if you login to the browser, so even if a machine is fairly new that could still happen.) |
| 09:48 |
Bmagic |
mmorgan: the same page needs hard refreshed every* time to load it? That would be new to me |
| 09:48 |
mmorgan |
We've checked add ons. I'm going to ask a few to try incognito mode. |
| 09:48 |
Dyrcona |
@blame Chrome |
| 09:48 |
pinesol |
Dyrcona: Chrome tests their code on the LIVE SERVERS, then blames the user. SAD! |
| 09:49 |
JBoyer |
That is significantly more annoying. If Hatch is installed have they verified that it's the same version as is currently available to download today? It should either be the newest available or not installed. (turning it off isn't enough anymore) |
| 09:49 |
mmorgan |
Bmagic: Yes, not sure if it's *every* time, but frequently while using evergreen. And I am not sure from reports whether a hard refresh or just a refresh is necessary. But some sort of refresh is. |
| 09:50 |
Bmagic |
I wonder if it's packet loss |
| 09:51 |
Bmagic |
If the library has an inconsistent connection to the Evergreen server, page loads may not deliver 100% of the JS code required, and a refresh (enough times) gets the code delivered |
| 09:51 |
Dyrcona |
Could be anything...Phase of the moon and its gravitational pull disturbing the electrons. |
| 09:52 |
alynn26 |
I thought packet loss, Always blamed Chrome, or chrome extension, I did get that here on my computer the other day, and after I turned off all of my extensions, And everythng worked after that. But I had been on several different versions of Evergreen that day between upgrading different servers and testing |
| 09:52 |
mmorgan |
Bmagic: Doesn't happen on all computers. Happens consistently on "Circ Desk 1" but "Circ Desk 2" is fine. |
| 09:53 |
Bmagic |
It still could be packet loss for that one machine. Faulty cable/wifi adapter,etc |
| 09:54 |
Dyrcona |
Faulty transistor, blown capacitor, bad solder.... You name it. |
| 11:29 |
|
mantis1 joined #evergreen |
| 11:30 |
Dyrcona |
So the 0824.item_import_defaults.pg fails on Pg 11+, but based on what I'm seeing on Pg 11, it should also fail on Pg 10, since I'm getting an invalid circ_modifier error and no circ modifiers seem to exist in a stock database. |
| 11:34 |
|
mantis joined #evergreen |
| 11:36 |
Dyrcona |
OIC. I misunerstood what the test is doing. It's actually looking at the failure message. |
| 11:36 |
Dyrcona |
So, it doesn't really test if items were created or not. |
| 11:37 |
|
eady joined #evergreen |
| 11:42 |
|
troy joined #evergreen |
| 11:42 |
|
jeffdavis joined #evergreen |
| 16:32 |
|
jihpringle joined #evergreen |
| 17:08 |
|
mmorgan left #evergreen |
| 17:31 |
|
jihpringle joined #evergreen |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:08 |
|
jihpringle joined #evergreen |
| 09:55 |
Dyrcona |
Ah wait a minute.... It's being called with a single argument from the trigger, which relies on authority bib linking to work, so authority bib linking must be what's broken, now. |
| 09:55 |
Dyrcona |
The two argument version where you supply the authority and bib ids works. |
| 09:56 |
Dyrcona |
@blame Function Overload |
| 09:56 |
pinesol |
Dyrcona: Function Overload tests their code on the LIVE SERVERS, then blames the user. SAD! |
| 09:56 |
Dyrcona |
@blame [band] |
| 09:56 |
pinesol |
Dyrcona: The EOLI Folk stole Dyrcona's ice cream! |
| 09:57 |
Dyrcona |
@blame XML |
| 16:16 |
Dyrcona |
OMG this is ugly, but it works: oils_xpath('//*/*[contains("'||acsaf.sf_list||'",@code)]',tag_node) |
| 16:30 |
Bmagic |
Dyrcona++ |
| 16:41 |
|
jvwoolf1 left #evergreen |
| 16:41 |
Dyrcona |
Great. A test now fails on Pg10 that used to pass. |
| 16:45 |
Dyrcona |
live_t/0847.auth_overlay_generator.pg relies on undefined behavior. It assumes that the XML code will always generate the same thing, and it changes from Pg10 and beyond. |
| 16:46 |
Bmagic |
well, that's not what we want |
| 16:50 |
Dyrcona |
I think my "fixes" may have broken that one, but when I run authority.generate_overlay_template on some releases, I get embedded newlines that are converted to entities, and on other releases they are not there. Also, there are more entities now that I've changed the xpath so it "works" on all current Pg releases. I think we should drop that test. |
| 16:50 |
Bmagic |
hmm, I'm not familiar with that. |
| 16:52 |
Dyrcona |
That test is designed to test the output of the authority.generate_overlay_template function, and the function's behavior changes depending on Pg release. |
| 16:53 |
Dyrcona |
And, actually, it looks like on Pg versions < 12, it varies by the XPath used. |
| 16:54 |
Dyrcona |
I guess Heisenberg is a PostgreSQL developer. |
| 16:55 |
jeffdavis |
The more I work with ILSes, the more I think card catalogs are a neat idea. |
| 16:57 |
Dyrcona |
Nothing wrong with paper... |
| 16:57 |
Dyrcona |
So, I've made some "progress." |
| 16:58 |
* Dyrcona |
checks out for the day. |
| 17:56 |
pinesol |
[evergreen|Bill Erickson] LP1739277 Angular org selector style callback - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d51454b> |
| 17:56 |
pinesol |
[evergreen|Kyle Huckins] lp1739277 OrgSelect Class Callback Holdings Implementation - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=625c862> |
| 17:56 |
pinesol |
[evergreen|Kyle Huckins] Docs: lp1739277 Release Notes for Org Selector Styling - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=8046fb4> |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:21 |
gmcharlt |
for one thing, card catalogs had ink smudges with semaantic content: https://twitter.com/ruthbrarian/status/1461083016470708226 |
| 18:43 |
|
alynn26_away joined #evergreen |
