| 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: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. |
| 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> |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:19 |
|
rjackson_isl_hom joined #evergreen |
| 08:17 |
rhamby |
Keith-isl fyi, downloading the recorded sessions from the hack-a-way and will have them online later today |
| 08:35 |
|
mantis joined #evergreen |
| 10:43 |
|
terranm joined #evergreen |
| 11:00 |
mmorgan |
terranm: Are you trying to clone yourself? If you figure it out, let me know! |
| 11:00 |
|
mantis joined #evergreen |
| 11:14 |
mantis |
I'm running through the Docker version of the Evergreen test server install: https://wiki.evergreen-ils.org/doku.php?id=newdevs:testserver |
| 11:15 |
mantis |
When trying to mount via cifs, I get a host is down error (mount error 112) |
| 11:15 |
terranm |
I wish! My internet keeps blipping and causing irc to kick me out |
| 11:15 |
mantis |
From what I'm reading based on other isos, it seems to be an issue with something from cifs that isn't supported anymore |
| 11:19 |
Keith-isl |
Something I was hoping to ask some GA Pines folk during the Hack-A-Way but couldn't due to putting out other fires: I am very interested in how you handle student cards from a policy perspective (which isn't as much fun as talking about the technical perspective, I know). |
| 16:25 |
|
jvwoolf left #evergreen |
| 17:10 |
|
mmorgan left #evergreen |
| 17:25 |
jeff |
> Be cautious about sharing sensitive information. MARC listserv.loc.gov is outside your organization and isn't in your contacts. |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 02:59 |
|
phasefx_ joined #evergreen |
| 02:59 |
|
gmcharlt_ joined #evergreen |
| 03:42 |
|
jvwoolf joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:00 |
JBoyer |
Keith-isl++ |
| 07:22 |
|
rjackson_isl_hom joined #evergreen |
| 08:39 |
|
mantis joined #evergreen |
| 11:40 |
|
jihpringle joined #evergreen |
| 11:56 |
Dyrcona |
miker: It looks like array_accum is only used in booking when I grep the code. |
| 13:34 |
|
jihpringle joined #evergreen |
| 13:46 |
Dyrcona |
jeffdavis: I was running live tests and live_t/29-lp1817645-remoteauth-patron-api.t failed. It got 502 instead of the expected 403. Do you think I missed something in my setup? |
| 13:48 |
Dyrcona |
@blame nginx |
| 13:48 |
pinesol |
Dyrcona: nginx 's bugfix broke Dyrcona's feature! |
| 13:50 |
jeffdavis |
yeah, 502 implies a problem with proxy setup to me, but the live test ought to work with stock Apache + concerto data |
| 13:50 |
jeffdavis |
(or at least stock user data if we consider that "concerto") |
| 13:51 |
Dyrcona |
yeah. I usually setup nginx on my test vms just because. |
| 13:52 |
Dyrcona |
Ok. nginx and apache2 disagree on the ports that apache2 is using. |
| 14:02 |
Dyrcona |
That was it. Now that nginx and apache2 are talking to each other, all tests pass. |
| 14:06 |
Dyrcona |
I ran the db tests, too. |
| 14:08 |
Dyrcona |
3.9-beta, really? Maybe we should make like #postgresql and drop the first digit? |
| 14:14 |
Dyrcona |
Well, I guess they actually dropped the second digit, didn't they? |
| 14:17 |
jeff |
third? |
| 16:28 |
abneiman |
csharp_: indeed; the only way I know to do it is painstakingly by hand (for point releases, that is) |
| 16:56 |
|
jvwoolf left #evergreen |
| 17:06 |
|
mmorgan left #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 21:26 |
|
alynn26 joined #evergreen |
| 00:30 |
|
rhamby joined #evergreen |
| 00:32 |
|
book` joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:29 |
|
rjackson_isl_hom joined #evergreen |
| 08:39 |
|
mmorgan joined #evergreen |
| 08:46 |
|
rfrasur joined #evergreen |
| 09:39 |
Bmagic |
collum++ |
| 09:41 |
Dyrcona |
Never go in against a movie when Wallace Shawn is in the cast. :) |
| 09:42 |
mmorgan |
:) |
| 09:43 |
Dyrcona |
So, I've managed to get the array_accum aggregate recreated in my Pg 14 database. I'm going to go ahead with my testing and see what happens. Also, Lp 1947595. |
| 09:43 |
Bmagic |
hahahaha. Side note: I signed up to listen to the cast perform a reading of the script live on zoom last year. That was really fun. Of course Andre the giant wasn't there but Josh Gadd did awesome as the giant |
| 09:43 |
pinesol |
Launchpad bug 1947595 in Evergreen "array_accum Aggregate and PostgreSQL 14" [Undecided,New] https://launchpad.net/bugs/1947595 |
| 09:43 |
Bmagic |
Dyrcona++ |
| 09:54 |
Dyrcona |
Hah. |
| 09:54 |
Dyrcona |
I wasn't talking to you, pinesol. |
| 09:55 |
Bmagic |
I didn't know you would actually* try it on production |
| 09:59 |
Dyrcona |
Bmagic: That's not on production. It's a test db server. |
| 10:00 |
Dyrcona |
It is a copy of production data, though. |
| 10:00 |
|
alynn26 joined #evergreen |
| 10:01 |
Bmagic |
yeah, I was kidding ya |
| 13:58 |
|
mmorgan left #evergreen |
| 15:51 |
|
jihpringle joined #evergreen |
| 16:57 |
|
jvwoolf left #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
