| 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 |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:29 |
|
rjackson_isl_hom joined #evergreen |
| 08:34 |
|
mmorgan joined #evergreen |
| 08:37 |
|
mantis joined #evergreen |
| 12:22 |
|
jeffdavis joined #evergreen |
| 12:22 |
|
troy joined #evergreen |
| 12:22 |
|
bshum joined #evergreen |
| 14:57 |
pinesol |
[evergreen|Galen Charlton] LP#1949910: serialize deleting items from item bucket - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=8a568b0> |
| 16:15 |
|
sandbergja joined #evergreen |
| 16:25 |
sandbergja |
We have got a question about MarkItemLost action triggers. Are those affected by closed dates at all? Like will Evergreen avoid doing the whole MarkItemLost procedure if the Library is closed that day? |
| 16:44 |
jeff |
I don't think so. What makes you ask? |
| 16:49 |
sandbergja |
Or, be mentally prepared for the day when everything is marked lost and we have angry patrons :-) |
| 17:15 |
|
mmorgan left #evergreen |
| 17:35 |
|
jamin joined #evergreen |
| 17:45 |
jamin |
Wanting to setup & test the new(ish) III Patron API thing, details for two of the steps in the docs leave a lot to be desired. What/where else might I find something on adding user activity types and remote authentication profiles? |
| 17:47 |
jamin |
Doc in question is here: https://docs.evergreen-ils.org/eg/docs/latest/integrations/patron-api.html |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:01 |
jamin |
sandbergja: fwiw, all of our markitemlost triggers were turned off pretty early on. some have been turned on since, paying close attention to max_delay. we also did a lot of manipulating of due dates. and no, pretty sure it pays no heed to closed dates. |
| 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 |
| 00:56 |
|
jvwoolf joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:24 |
|
ejk joined #evergreen |
| 06:37 |
|
troy joined #evergreen |
| 07:33 |
|
rjackson_isl_hom joined #evergreen |
| 09:20 |
|
jvwoolf joined #evergreen |
| 09:30 |
|
mmorgan joined #evergreen |
| 09:45 |
Dyrcona |
Hrm..... When I run vandelay.merge_record_xml with the same arguments from authority.propagate_changes() it gives the same output on Pg 10, 11, and 14, after I've made a fix to authority.generate_overlay_template() even though the latter function produces different output. |
| 09:46 |
Dyrcona |
However, authority.propagate_changes() appears to fail when run as part of the test. |
| 09:47 |
Bmagic |
Function Overloaded is fodder for one of our Bands IMO |
| 09:48 |
Bmagic |
"Function Overloaded - missing bits be damned" |
| 09:48 |
Bmagic |
Or maybe drop "ed" and it's just Function Overload |
| 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 |
| 00:38 |
|
alynn26_away joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:33 |
|
rjackson_isl_hom joined #evergreen |
| 07:54 |
|
collum joined #evergreen |
| 08:33 |
|
rfrasur joined #evergreen |
| 13:54 |
pinesol |
[evergreen|Jason Stephenson] LP1951030: Remove OpenILS/Utils/ISBN from Manifest - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f4e4bdb> |
| 13:58 |
|
jihpringle16 joined #evergreen |
| 14:06 |
mmorgan |
The thought of non-unique barcodes hurts my head |
| 14:09 |
jeff |
all barcodes are unique. also, no barcodes ever have whitespace, and barcodes always scan in a way that matches 1) what's on the label and 2) what's recorded in the ILS |
| 14:10 |
jeff |
this is a variation on "X, Y, or Z. pick two!" |
| 14:10 |
jeff |
only in this case, you get to pick zero. |
| 14:10 |
jeff |
(in honor of the leading zeros that need to be discarded and/or turned into whitespace) |
| 14:11 |
jeff |
anyway, it was nice to have staff testing the transforms, run into a previously-unseen variation, and be able to fix it by adding a new transform to the config table. |
| 14:11 |
jeff |
I still just wonder/worry about how much trouble you can get yourself into with unsafe/unwise regex. |
| 14:17 |
Dyrcona |
jeff: Well, now you've got two problems. :) |
| 14:17 |
jeff |
:-) |
| 14:53 |
|
jvwoolf left #evergreen |
| 16:01 |
gmcharlt |
the question of item templates came up during a presentation that abneiman gave about new features in 3.8 to the Cataloging Interest Group today |
| 16:09 |
Dyrcona |
Hmm... XML changes in Pg11+ are a pain. |
| 16:11 |
Dyrcona |
I fix a couple of expressions to use proper xpath and all of a sudden the XML output contains entities where it didn't before the fix. |
| 16:27 |
Dyrcona |
Well, the entities don't break the test on Pg10, but the test is still borked on Pg 14. |
| 16:38 |
Dyrcona |
<- That's a newline, right? |
| 16:40 |
Dyrcona |
Yeahp. so we're getting newlines added on Pg10 but not on Pg14.... |
| 16:44 |
Dyrcona |
So, now, I think it could be this change in Pg 12: Do not pretty-print the result of xpath() or the XMLTABLE construct. In some cases, these functions would insert extra whitespace (newlines and/or spaces) in nodeset values. This is undesirable since depending on usage, the whitespace might be considered semantically significant. |
| 16:45 |
Dyrcona |
Think I'll see what happens with this test on Pg 11. |
| 16:50 |
Dyrcona |
It fails on Pg 11. |
| 16:54 |
Dyrcona |
Well. something more to look at tomorrow. Think I'll write up a little script to dump some output for comparison before I clock out |
| 17:04 |
|
mmorgan left #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 19:22 |
|
jihpringle joined #evergreen |
| 01:58 |
|
dbs joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:26 |
|
rjackson_isl_hom joined #evergreen |
| 08:12 |
|
collum joined #evergreen |
| 08:13 |
|
Dyrcona joined #evergreen |
| 12:29 |
berick |
in any event, you can configure the login timeout in oils_sip.xml. default is 60 seconds |
| 12:30 |
berick |
but the login eval can fail for other reasons, which should show in the error logs |
| 12:47 |
Dyrcona |
Bmagic: You might try installing the Socket::Linux Perl module. SIPServer will only use it if it is available, and it helps with timeout issues and clients. (I'm not saying it will fix your current problem, but it won't hurt.) |
| 12:50 |
csharp_ |
this issue reminds me that I want to get back to testing berick's SIP proxy thing :-) |
| 12:51 |
csharp_ |
gmcharlt++ # great presentation this morning on VuFind/Evergreen |
| 12:56 |
|
collum joined #evergreen |
| 13:10 |
|
jvwoolf1 joined #evergreen |
| 13:11 |
|
jvwoolf2 joined #evergreen |
| 13:55 |
Dyrcona |
Assuming this is a VM... |
| 13:55 |
Dyrcona |
On an unrelated note, I think that I may have fixed the data load issues with new Pg versions. |
| 14:02 |
Bmagic |
I did consider increasing the number of CPU's - thinking that it was dogpiling to a point where ejabberd died. It's theoretical at this point. It's strange that it worked and worked for years on the same machine until the upgrade.... |
| 14:03 |
Dyrcona |
Could be the software is botched. I sometimes get a bad install when building test VMs and have to redo it. |
| 14:04 |
Dyrcona |
You upgraded from what version to which vesion? |
| 14:06 |
Bmagic |
3.5.4 -> 3.7.2 |
| 14:06 |
Bmagic |
I'm on my 4th rebuilt VM |
| 14:07 |
Bmagic |
I wonder if I could install 3.5.4 and SIP would still work |
| 14:07 |
Dyrcona |
Bmagic: It probably would. |
| 14:07 |
Bmagic |
I'm gonna try it |
| 14:17 |
Dyrcona |
Yeah. Making a minor change to the env_create.sql solves the Perl test failure. Some of the pgtap tests still fail on Pg 14. |
| 14:17 |
Dyrcona |
The data load fix is to add ORDER BY id in two of the functions. |
| 14:26 |
jeff |
well that's embarassingly obvious in hindsight. nice catch! |
| 14:26 |
jeff |
Don't I feel silly for combing release notes looking for subtle breaking-to-us changes. |
| 14:27 |
|
jihpringle joined #evergreen |
| 14:34 |
Dyrcona |
:) |
| 14:35 |
Dyrcona |
jeff: We may still have some of those. I'm looking at a vandelay test that breaks, and it looks like the import item is not being created. |
| 14:37 |
Dyrcona |
import.item.invalid.circ_modifier Hm.... |
| 14:38 |
Dyrcona |
That's bizarre because the TEST circ modifier is there, and that's what the record tries to use. |
| 15:01 |
Dyrcona |
ugh. I think this might be a change in xpath, libxml behavior. |
| 15:06 |
Keith-isl |
I find myself stumped: have a library that gets an 'Offline transaction upload failed' error when they...well...try and upload (not process) offline transactions. |
| 15:07 |
Keith-isl |
Issue occurs on all the workstations in their system, but offline uploads seem to work fine for different OU's. |
| 16:07 |
Bmagic |
at no point during you incoherent ramblings could anything be considered a rational thought. I award you no points and may god have mercy on your soul |
| 16:08 |
jeff |
about four years before that movie. :-) |
| 16:09 |
Bmagic |
:) |
| 16:14 |
Dyrcona |
Interesting. I've found a record that produces a metabib.metarecord entry on Pg 14, but doesn't on Pg 10. It's one of the two inserted for the lp1731960_test_preserving_bookbag_entries.pg tests. |
| 16:18 |
Dyrcona |
Ah, bizarre. It's the opposite of the behavior on Pg 10. So, the first one gets the metarecord created in Pg 11, but it's the second one that does in Pg 10. |
| 16:19 |
Dyrcona |
Or, I should say, gets chosen as the master record. |
| 16:21 |
Dyrcona |
Looks like we get different numbers of metarecords created with Pg11+. So that's something to look into. I probably won't fix it today. |
| 16:33 |
Dyrcona |
Crazy. Looks like a bad XPATH was causing a bug in pre-Pg11 with metarecord creation. |
| 16:34 |
Dyrcona |
After fixing a XPath value in biblio.extract_quality, I now get the same results in Pg10 that I get/got in Pg14. |
| 16:35 |
Dyrcona |
That seems weird.... Maybe I had the versions backwards earlier when I said that I got less on Pg 14? |
| 16:36 |
Dyrcona |
However, now that it's fixed, the same record is chosen as the master record in Pg 10 as on Pg 14, so that fixes the pgtap test. |
| 16:38 |
Dyrcona |
Tests are great! :) |
| 16:43 |
Dyrcona |
I guess I didn't say. I thought that I got fewer on Pg 14, but whatever.... You're tired of my rambling. :) |
| 16:45 |
Bmagic |
Dyrcona: found oom messages in dmesg finally... adding swap |
| 16:45 |
Dyrcona |
Just noticed this with make check: WARNING: the following files are missing in your kit: lib/OpenILS/Utils/ISBN.pm Please inform the author. |
| 17:54 |
Bmagic |
CPU spiked for a short time, and calmed back down. Never saw it go over 4 |
| 17:57 |
Dyrcona |
Bmagic++ |
| 17:58 |
Dyrcona |
Just in time to go home, too! |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:01 |
Dyrcona |
All right. I'm signing out now. Good night, #evergreen! |
| 18:18 |
|
jihpringle joined #evergreen |
| 06:02 |
pinesol |
News from qatests: Failed Running Evergreen tests <http://testing.evergreen-ils.org/~live//archive/2021-11/2021-11-12_04:00:02/test.31.html> |
| 07:29 |
|
rjackson_isl_hom joined #evergreen |
| 08:17 |
|
rfrasur joined #evergreen |
| 08:45 |
|
mantis joined #evergreen |
| 08:46 |
|
Dyrcona joined #evergreen |
| 09:26 |
|
alynn26 joined #evergreen |
| 09:33 |
Dyrcona |
So, turns out the way that we load test database is rubbish, and we've been lucky that undefined behavior hasn't changed from Pg 9.4 through Pg10, but it changed in Pg 11. Upshot: We need to change how we load test data. |
| 09:35 |
|
stephengwills joined #evergreen |
| 09:45 |
csharp_ |
Dyrcona: curious about how you would change it, but I expect you're writing something up :-) |
| 09:47 |
Dyrcona |
https://bugs.launchpad.net/evergreen/+bug/1937294/comments/4 |
| 09:47 |
pinesol |
Launchpad bug 1937294 in Evergreen "Updating Evergreen for Newer PostgreSQL Versions" [Undecided,New] - Assigned to Jason Stephenson (jstephenson) |
| 09:50 |
Dyrcona |
This isn't the only place where we've been lucky by relying on undefined behavior, though mostly unknowingly. |
| 10:05 |
|
jvwoolf joined #evergreen |
| 10:36 |
csharp_ |
Dyrcona: off that topic, but I wanted to mention - I was running pingest on my 3.8 test server post upgrade and it was deadlock central - I experimented with moving the batch size/parallel procs up and down but it just kept happening - have you experienced that? |
| 10:57 |
Dyrcona |
csharp_: Yeah, there's a bug about that. Did you mean breaks parallel ingest. |
| 10:59 |
Dyrcona |
Lp 1931737 |
| 10:59 |
pinesol |
Launchpad bug 1931737 in Evergreen "Did you mean breaks parallel reingest" [Undecided,Confirmed] https://launchpad.net/bugs/1931737 |
| 11:43 |
pinesol |
csharp_: it stole bshum's tux doll! |
| 11:43 |
Bmagic |
lol |
| 11:57 |
|
jihpringle joined #evergreen |
| 12:34 |
phasefx |
Dyrcona: do you remember if when you last worked with character encoding in SIP if the 03checkout.t test was passing with the diacritic title example? |
| 12:44 |
Dyrcona |
phasefx: I don't remember. |
| 12:44 |
phasefx |
Dyrcona: no worries, gracias |
| 14:07 |
mantis |
Has anyone had an issue in the Boopac when more electronic resource links appear than necessary? |
| 15:16 |
gmcharlt |
despite the description, it could well apply to your situation if your catalog happens to have mutiple e-resource bibs getting lumped together under the same metarecord |
| 15:17 |
gmcharlt |
whichever bib is lead in the metarecord would have its links displayed |
| 15:19 |
mantis |
gmchartl++ |
| 15:41 |
pinesol |
[evergreen|Galen Charlton] LP1856906: (follow-up) fix unit test count - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9d72b71> |
| 15:59 |
jeff |
@who left themselves logged in as Evergreen Bug Maintenance? |
| 15:59 |
pinesol |
jeff left themselves logged in as Evergreen Bug Maintenance. |
| 16:00 |
jeff |
(nope) |
| 16:27 |
|
alynn26 joined #evergreen |
| 16:28 |
|
alynn26_away joined #evergreen |
| 16:49 |
|
jvwoolf left #evergreen |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
