| 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> |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:24 |
|
collum joined #evergreen |
| 07:28 |
|
rjackson_isl_hom joined #evergreen |
| 08:29 |
|
mmorgan joined #evergreen |
| 15:47 |
* Dyrcona |
hasn't actually used MariaDB. I've stuck mainly with MySQL despite it being acquired by the Evil Empire. |
| 15:48 |
jeff |
Dyrcona: can you share steps to reproduce the issue you're seeing, and the symptoms? I'm curious. |
| 15:48 |
Dyrcona |
OK. Thought I'd ask, because a lot of people don't like table inheritance. |
| 15:48 |
Dyrcona |
jeff: Just --load-all-sample on Pg11+ and watch the tests fail, particularly, live_t/20-hold-targeter.t |
| 15:49 |
Dyrcona |
I'm comparing between Pg10 and Pg11 side by side and they get different numbers of copies in different copy locations. |
| 15:50 |
Dyrcona |
I'm assuming parallel execution is the problem, but it could be something else. Unfortunately, there are no errors or other useful messages logged. |
| 15:50 |
rhamby |
just a straight up count(*) from asset.copy where location = foo; ? |
| 15:53 |
Dyrcona |
Since Evergreen paste is busted, I'll paste a one-liner here: |
| 15:53 |
Dyrcona |
select copy_location.id, copy_location.name, copy_location.holdable from asset.copy_location join asset.copy on copy.location = copy_location.id join asset.call_number on copy.call_number = call_number.id and call_number.record = 42 order by id; |
| 15:54 |
Dyrcona |
On Pg 11 you get 10 copies in non-holdable locations. On Pg 10, I get 7 copies in non-holdable copy locations. Also the location names are different. |
| 15:55 |
Dyrcona |
Also, if you do 'request open-ils.hold-targeter open-ils.hold-targeter.target {"hold":263}' in srfsh, you get different results. This is from the failing hold-targeter test and record 42 is the record in question. |
| 15:55 |
Dyrcona |
I should also mention that the copies and call numbers tend to get different ids in either Pg version. |
| 15:57 |
Dyrcona |
I'm going to bug the good people of #postgresql about disabling parallel workers while running a script. |
| 16:01 |
Dyrcona |
I'm also starting to think that the problem isn't parallel execution per se. |
| 16:17 |
jeff |
I suspect it's "test data load relies on assumptions about sequences that are no longer valid", but I haven't gotten hands-on with it yet. Might carve out time tonight. |
| 16:18 |
Dyrcona |
jeff: It's more than that. |
| 16:23 |
jeff |
ah, I see. |
| 16:29 |
Dyrcona |
That query I pasted gives very different results, so I think it is more than just assumptions about ids. Setting max_parallel_workers_per_gather to 0 doesn't help, so I'm starting to think the problem is something else. |
| 16:46 |
Dyrcona |
There is such a thing as being too clever. |
| 17:27 |
|
mmorgan left #evergreen |
| 17:28 |
abneiman |
belatedly mmorgan++ for also release-notes-ing for those two monster releases! & pursuant to what sandbergja said above, I'm always willing to help but don'tspend a lot of time in IRC (and windows doesn't like to give me Quassel notificaitons), so, alternate methods of flagging me down are always OK :) |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 19:43 |
|
Christineb joined #evergreen |
| 19:43 |
|
troy joined #evergreen |
| 19:51 |
|
troy joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:57 |
|
bgillap_ joined #evergreen |
| 06:58 |
|
bgillap__ joined #evergreen |
| 07:15 |
|
rjackson_isl_hom joined #evergreen |
| 15:03 |
sandbergja |
#info sandbergja = Jane Sandberg, LBCC |
| 15:04 |
JBoyer |
Feel free to #info up if you're joining us later. |
| 15:04 |
JBoyer |
#topic Action Items from Last Meeting |
| 15:04 |
JBoyer |
#info shulabear will test out the staff client in Microsoft Edge |
| 15:04 |
JBoyer |
Any luck in this testing pursuit shulabear? |
| 15:04 |
JBoyer |
Who I just noticed didn't say anything above, so may not be available... |
| 15:05 |
Dyrcona |
#info Dyrcona = Jason Stephenson, CW MARS |
| 15:05 |
JBoyer |
We can come back to this if shulabear is available later. |
| 15:11 |
Dyrcona |
JBoyer: Pidgin |
| 15:12 |
JBoyer |
Dyrcona, I'll check it out. |
| 15:12 |
JBoyer |
shulabear, any word on staff client functionality in MS Edge? |
| 15:13 |
shulabear |
Everything I tested - which was, admittedly, mainly circ and OPAC functions - worked fine in Edge |
| 15:13 |
JBoyer |
shulabear++ |
| 15:13 |
terranm |
shulabear++ |
| 15:13 |
JBoyer |
Those are things that see a lot of use |
| 15:16 |
JBoyer |
Hey, the agenda has been updated. :D |
| 15:16 |
Dyrcona |
:) |
| 15:17 |
JBoyer |
(and I sure did miss those 2 point release announcements. :-/ ) |
| 15:17 |
Dyrcona |
Yeah, so I know that JBoyer had mentioned wanting to have a look at some of the tests. I just wanted to see if anyone else is interested in having a look. If not, I will. |
| 15:18 |
Dyrcona |
It's important that we get moving on more recent PostgreSQL support in Evergreen because 9.6 is EOL on Thursday, and 10 is EOL in about a year. |
| 15:18 |
JBoyer |
I think the one I was kind of poking at during my last few hours at the hackaway may have been updated already. I'd like to have a look at more of them, but that's probably a couple weeks off. |
| 15:19 |
csharp_ |
upgrading to 10 over the next month or so |
| 15:19 |
Dyrcona |
JBoyer: OK. I can revisit the tests with more recent master and update the bug. |
| 15:19 |
Dyrcona |
We're running 10 in production, FWIW. |
| 15:19 |
csharp_ |
Dyrcona++ |
| 15:20 |
JBoyer |
Dyrcona++ |
| 15:20 |
Dyrcona |
In testing newer Pg releases, I've noticed performance gains in some areas and performance degradation in some others. |
| 15:21 |
Dyrcona |
I'm inclined at the moment to add support for newer releases in 3.9 regardless of whether or not all of the performance issues have been addressed. We can sort that out later. |
| 15:21 |
JBoyer |
+1 |
| 15:22 |
Dyrcona |
Maybe we can get a more comprehensive test suite along the way? |
| 15:22 |
JBoyer |
What did you have in mind, pgtap, live db, something else? |
| 15:23 |
JBoyer |
(Aside from "some of everything" because that would be great, but... ;) ) |
| 15:24 |
Dyrcona |
I'd like to figure out a way to combine pgtap with plprofiler. However, I got no output with plprofiler on Pg 14, but haven't had time to investigate. |
| 15:25 |
Dyrcona |
Testing performance can be tricky because some issues don't crop up until you have thousands or millions of records. |
| 15:26 |
alynn26 |
There is work on a large dataset for testing for Evergreen. |
| 15:26 |
Dyrcona |
I'm going to info the link to the Google drive folder where I've been making notes about what I've done so far. |
| 15:26 |
JBoyer |
Yeah, a performance testing suite might be something that has to be put together and expected to run on live-ish data, not so much for concerto. That would still be a useful thing. (and wouldn't necessarily need to be tied to any particular verison) |
| 15:26 |
Dyrcona |
#info Dyrcona's notes on PostgreSQL testing: https://drive.google.com/drive/folders/1sRZ8P1RHCOcZx42DxUehvOpoNkJJnfqn |
| 15:28 |
|
bgillap joined #evergreen |
| 15:28 |
Dyrcona |
So, in the meantime, I'll look at fixing the tests on newer Pg versions. It looks like the breakage is identical for Pg 12 through Pg 14. |
| 15:30 |
|
bgillap_ joined #evergreen |
| 15:30 |
JBoyer |
I know the version numbering change is somewhat symbolic, but it does feel like they're a lot more comfortable breaking things lately. We've hit issues with 10 in the past and now 12+ in just the last couple of years. |
| 15:31 |
|
bgillap_ left #evergreen |
| 15:32 |
JBoyer |
#info array_accum Aggregate and PostgreSQL 14 ( lp 1947595 ) |
| 15:32 |
pinesol |
Launchpad bug 1947595 in Evergreen "array_accum Aggregate and PostgreSQL 14" [Undecided,New] https://launchpad.net/bugs/1947595 |
| 15:33 |
Dyrcona |
This one is more concrete. There's a branch on that bug that replaces our custom array_accum function with array_agg from Pg. If someone would like to look at it, that would be great! |
| 15:35 |
JBoyer |
It does seem pretty straightforward, does anyone want to volunteer to put a test system together to make sure that 2-3 calls of array_accum work the way we think they do? (which they almost certainly do) |
| 15:35 |
JBoyer |
I can get to it in a week or two if not. |
| 15:37 |
JBoyer |
I'd like to add that *anywhere* we have a func that largely duplicates (or because of age, exactly duplicates) an internal function we do whatever we can to remove it. I keep giving evergreen.upper and .lower sideeye but I know it's something to do with consistency in the face of multiple potential Unicode implementations, etc. |
| 15:38 |
JBoyer |
#action JBoyer will test out the branch in lp 1947595 |
| 15:38 |
pinesol |
Launchpad bug 1947595 in Evergreen "array_accum Aggregate and PostgreSQL 14" [Undecided,New] https://launchpad.net/bugs/1947595 |
| 15:38 |
JBoyer |
Moving on with less than 20 before I vanish, |
| 15:38 |
JBoyer |
#info Hackaway followup: Automating point release notes (abneiman) |
| 17:02 |
|
mmorgan left #evergreen |
| 17:21 |
JBoyer |
bgillap_, check out https://github.com/HitScan/systemd-evergreen |
| 17:22 |
JBoyer |
shouldn't be version-specific, though you'll want to make sure that they cover your needs (may need to remove some things from Requires or things along those lines) |
| 17:23 |
JBoyer |
they've been developed and well-tested against single server setups, but will likely need tweaking for production use. |
| 18:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
