15:56 |
Bmagic |
ok, I see. Looking at a fresh installation of OpenSRF (main) - comes packed with that line CONFIG SET save "" |
16:04 |
Dyrcona |
berick++ Bmagic++ |
16:04 |
Dyrcona |
I let do-release-upgrade overwrite /etc/redis.conf, so wondered when I didn't see anything in the README about it. |
16:06 |
Dyrcona |
After doing do-release-upgrade, I `rm -rf /openils/*` and reinstalled OpenSRF main and my test branch of Evergreen base on 3.14.0. |
16:07 |
Dyrcona |
It's working so far. |
16:12 |
* Dyrcona |
is also ready for translations and release building tomorrow. |
16:13 |
redavis |
Dyrcona++ |
16:25 |
redavis |
Bmagic, yep. If you can. No pressure if you can't though. |
16:25 |
Bmagic |
:) I'd love to |
16:25 |
redavis |
Rock on. Thank you. |
16:28 |
eeevil |
re the reporter, they last "one more failure" test was not related to the problem at hand, but it's also (as abneiman says) fixed, pending testing. LP may not have sent my email to that effect yet |
16:29 |
Dyrcona |
eeevil: I got the email with your comment. I'm Ok with that going in if someone signs off tonight. |
16:30 |
redavis |
eeevil, I'm just refreshing for comments anyway :-). I think we're waiting on Llewelyn for the actual ticket. Is there another ticket for the "one more failure"? |
16:30 |
redavis |
Oh, eeevil, n/m my question. I see the answer in your comment. |
16:30 |
Bmagic |
I was about to say |
16:30 |
Dyrcona |
:) |
16:31 |
Bmagic |
it seems like we should wait until this tree.js branch receives it's additional commit, and maybe Llewellyn can double check it on his test machine, the same as he did with the first commit |
16:33 |
Dyrcona |
My answer is it depends on how long we have to wait. |
16:33 |
Dyrcona |
I would like to get started tomorrow morning. |
16:34 |
Bmagic |
agreed |
16:44 |
Bmagic |
that's fine, it means we'll wait |
16:54 |
* Dyrcona |
signs out for the day. |
17:01 |
|
mmorgan left #evergreen |
17:01 |
eeevil |
Bmagic: ok! looking at the clock, I'm going to suggest that I push a branch with just (what we've been calling) the followup commit -- it's separate, but discovered during tree.ts testing -- and if you get the signoffs you want/need on the current branch, I recommend we proceed with merging that. then, if you also like the cut of the new branch's jib, and feel like pulling that in, I'm comfortable with it going in quickly. if it has to sit, I won't |
17:01 |
eeevil |
cry too hard. |
17:02 |
Bmagic |
ok then, we have something we can test? |
17:03 |
redavis |
Bmagic, I think it's the current branch listed at https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/lp-2087562-dynamic-tree-node-parent-links |
17:03 |
Bmagic |
that's what I'm looking at. So, roll with that for now, and we'll catch the rest next cycle, is that right? |
17:04 |
eeevil |
to that end, here's the followup commit on a branch by itself: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/fix-virtual-field-link-joins-in-upgraded-templates |
17:05 |
Bmagic |
eeevil: thanks! And you're not comfortable with that second branch just yet? |
17:05 |
eeevil |
Bmagic: next cycle, or this if it looks sane to you. I'm mainly trying to get it out there for others to test/use asap |
17:05 |
eeevil |
oh, /I/ am comfortable, but it's not been tested by not-mike. |
17:05 |
Bmagic |
understandable |
17:06 |
redavis |
How about this, maybe Llewellyn signs off on the first branch tonight.. but probably not. Even if he doesn't, we can get to testing the second branch and have both ready for next month...and for anyone that wants to apply in the meantime. |
17:06 |
Bmagic |
well, like you said, it's three lines. Seems like we should be able to test that with some humans. Sure wish we had some e2e tests to do the job for us |
17:07 |
* eeevil |
imagines the selenium script that would drive the reporter to test this ... shudders, passes out |
17:07 |
redavis |
LOL!!! |
17:08 |
Bmagic |
yeah, it'd be one heck of a test |
17:09 |
eeevil |
the test is ... clone a report that uses a might_have link on a virtual idl field and make sure it uses the left-side pkey column instead of the virtual column name in the join |
17:09 |
abneiman |
I'd be delighted to have the first one go in this evening, for point releases this month |
17:09 |
Bmagic |
it's radio silience over there at Cardinal. Maybe they'll get back with me before the "morning" |
17:10 |
abneiman |
but! I've put my finger(s) on the scale(s) too many times on this particular issue so with that imma head out and go swimmin |
17:13 |
redavis |
lol, or close to the Y |
17:13 |
redavis |
also, rock on for the first branch. So, unless anyone wants to stop me (please stop me), I'm going to open a new LP ticket for the second branch to make sure it doesn't get neglected. |
17:15 |
eeevil |
redavis: this is me, not stopping you! :) |
17:15 |
Bmagic |
yeah, that's a sane course of action I think. Considering the test is nuanced |
17:15 |
eeevil |
redavis++ |
17:15 |
redavis |
Excellent! This is also you not smellin' a burning clutch. |
17:15 |
Bmagic |
digging up an old template that " uses a might_have link on a virtual idl field and make sure it uses the left-side pkey column instead of the virtual column name in the join" |
11:19 |
csharp_ |
ick |
11:19 |
csharp_ |
pinesol: be better |
11:19 |
pinesol |
csharp_: Have you tried taking it apart and putting it back together again? |
11:19 |
Dyrcona |
berick: I'm signing off on your commits for Lp 2083856 and looking into the test failure. I swear it did not do that last Wednesday. Also, I swear I added all of the prerequisites, but maybe I didn't or switched branches and lost 'em? |
11:19 |
pinesol |
Launchpad bug 2083856 in Evergreen "Add Support for PostgreSQL 17" [Wishlist,Confirmed] https://launchpad.net/bugs/2083856 - Assigned to Jason Stephenson (jstephenson) |
11:20 |
csharp_ |
berick++ # don't blame me, I voted for Kodos |
11:20 |
berick |
Dyrcona: cool, yeah, i didn't get a chance to follow up on the failures. |
11:21 |
|
Christineb joined #evergreen |
11:28 |
Dyrcona |
berick: It looks like the same output with the 100 and 600 tags in opposite order. |
11:29 |
Dyrcona |
I'm going to reverse them in one of the copies and see what diff says after. |
11:31 |
Dyrcona |
Yeah, that's it. If I modify a copy of what we're looking for from the test to have the 100 before the 600, and the 905 (to put 110 before 600), the output is the same. |
11:32 |
Dyrcona |
I wonder if we have been depending on undefined behavior again? |
11:32 |
Dyrcona |
Bleh that 110 should be 100... Anyway.... |
11:33 |
Dyrcona |
I suppose I can make the test check the Pg version and do something different if it 17+. It wouldn't be the first time we've done that. |
11:35 |
Dyrcona |
I wonder though if the auth overlay function needs fixing for more predictable output? |
11:38 |
pinesol |
News from commits: LP#1721026: Default owner for copy tags and types <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=79980aff138c39b6056f8c0795fa308a8293fa79> |
11:42 |
csharp_ |
oh, I didn't realize the next Ubuntu release is "noble" - that kind of synergy doesn't happen often, does it NOBLE? |
11:44 |
Dyrcona |
I name my test vms for the release codenames: bullseye, bookworm, jammy, noble, etc. So, I have a test vm named noble.cwmars.org. :) |
11:45 |
csharp_ |
SO CONFUSING |
11:45 |
Dyrcona |
I suppose I could have used the animal name: numbat.cwmars.org.... |
11:47 |
* mmorgan |
wants to say it's cool, but agrees with csharp_ SO CONFUSING! |
13:29 |
abowling |
Dyrcona: It's what csharp_ referenced earlier; my 5.26.1 folder has the dependencies, but not the 5.30.0 folder |
13:30 |
Dyrcona |
Well, 5.26.1 should still be in the Perl path... You could try csharp_'s suggestion of deleting the 5.26.1 stuff and then reinstalling the prerequisites. |
13:31 |
|
jihpringle joined #evergreen |
13:36 |
Dyrcona |
heh.. The test still fails...... |
13:38 |
Bmagic |
tests++ |
13:48 |
Dyrcona |
extraneous space from where I inserted the new output. |
13:50 |
Dyrcona |
The db test passes on pg 17. I'll test on an earlier pg release before committing the changes. |
13:50 |
Dyrcona |
I mean committing them locally and pushing to a working branch. |
14:20 |
|
BDorsey joined #evergreen |
14:34 |
|
collum joined #evergreen |
14:45 |
shulabramble |
15 minute warning to the dev meeting |
14:46 |
|
sandbergja joined #evergreen |
14:50 |
shulabramble |
10 minutes to dev meeting |
14:52 |
berick |
jeff++ # *sigh* i just noticed your Hatch test notes in LP. |
14:52 |
berick |
accidentally marked that email read |
14:55 |
shulabramble |
5 minutes to dev meeting! |
14:56 |
|
smayo joined #evergreen |
14:58 |
jeff |
berick++ glad you saw it! |
15:08 |
shulabramble |
#topic waiting on gmcharlt for access to POEditor for git integration |
15:08 |
shulabramble |
And I assume the same for this unless there's any discussion to be had? |
15:08 |
abneiman |
I will ping gmcharlt in our channel about that 2nd one since Dyrcona is awaiting access |
15:09 |
shulabramble |
abneiman++ |
15:09 |
shulabramble |
#action waiting on gmcharlt for access to POEditor for git integration |
15:09 |
shulabramble |
#topic sleary and sandbergja will report progress on test writing wiki pages next month / at hackaway |
15:10 |
|
smorrison joined #evergreen |
15:10 |
sandbergja |
ooh! We did some work in the wiki. We haven't had a chance to coordinate something for the hackaway |
15:10 |
sleary |
I have not made much progress on my part of that, so let's kick that to next month, please! |
15:10 |
abneiman |
sandbergja++ sleary++ |
15:10 |
shulabramble |
sandbergja++ sleary++ got it |
15:11 |
shulabramble |
and a belated eeevil++ |
15:11 |
shulabramble |
#action sleary and sandbergja will report progress on test writing wiki pages next month / at hackaway |
15:11 |
sandbergja |
very happy if people discuss tests at hackaway though :-D |
15:11 |
shulabramble |
#topic bug 2076921 expected to get more testing and merged, and beta uploaded to store |
15:11 |
pinesol |
Launchpad bug 2076921 in Evergreen "Hatch: Chrome Extension Requires Redevelopment" [High,Confirmed] https://launchpad.net/bugs/2076921 - Assigned to Jeff Godin (jgodin) |
15:12 |
berick |
jeff did some testing, many thanks |
15:12 |
shulabramble |
jeff++ |
15:12 |
abneiman |
jeff++ |
15:12 |
sandbergja |
jeff++ |
15:23 |
sandbergja |
sleary++ |
15:24 |
shulabramble |
#action sleary will make a new LP tag denoting bugs that involve string changes |
15:24 |
shulabramble |
sleary++ |
15:24 |
jeffdavis |
Do we have automated testing (or some such thing) to flag when a string has been added/changed? |
15:24 |
abneiman |
sleary++ |
15:24 |
shulabramble |
jeffdavis++ for the question |
15:25 |
abneiman |
jeffdavis: I do not know - sandbergja? sleary? |
15:26 |
sandbergja |
not that it couldn't be done! |
15:27 |
sandbergja |
on the angular side it might be a bit easier |
15:28 |
shulabramble |
anyone want to look into the feasibility of that probable regex festival? |
15:28 |
jeff |
it's not a boring problem. what output/actions would be useful if we had such testing/monitoring? |
15:29 |
shulabramble |
(to be clear, I love regex problems, so that's a *good* thing) |
15:29 |
abneiman |
@band add Probably Regex Festival |
15:29 |
pinesol |
abneiman: Band 'Probably Regex Festival' added to list |
15:34 |
shulabramble |
jeff++ abneiman++ jihpringle++ |
15:34 |
shulabramble |
phasefx++ |
15:35 |
abneiman |
jihpringle++ |
15:35 |
shulabramble |
#action revisit feasibility of automated testing for string changes |
15:36 |
shulabramble |
alrighty, moving on |
15:36 |
shulabramble |
#topic Updates |
15:36 |
shulabramble |
There's nothing on the agenda for these, but I know we had an Evergreen update since the last meeting. |
15:37 |
shulabramble |
so 3.14 release team++ |
15:37 |
Bmagic |
+1 |
15:37 |
phasefx |
release_team++ |
15:38 |
shulabramble |
is it time to assemble a 3.15 release team? |
16:12 |
shulabramble |
I own four cats. I have experience. |
16:12 |
scottangel |
shulabramble++ |
16:12 |
shulabramble |
#topic Okay to merge LP 2055796? berick mentioned "unclear if there's any additional decision processes re: adding github actions" |
16:12 |
pinesol |
Launchpad bug 2055796 in Evergreen "Have github actions run pgtap tests for us" [Undecided,Confirmed] https://launchpad.net/bugs/2055796 - Assigned to Bill Erickson (berick) |
16:12 |
smayo |
shulabramble++ |
16:12 |
shulabramble |
sandbergja? |
16:12 |
sandbergja |
yes, pasting some text |
16:13 |
sandbergja |
The back story: we used to have our tests automatically running regularly (2x/day?), and alerting IRC if there was a test failure. This has not worked for some time, so currently we don't find out about those bugs we've added to Evergreen until somebody runs the tests manually (which may be a while later). Github offers free infrastructure for running tests, so a year ago, we decided to explore |
16:13 |
sandbergja |
I have a pull request to get our pgtap (database) tests running automatically on github actions, berick has reviewed it but mentioned "unclear if there's any additional decision processes re: adding github actions". |
16:13 |
sandbergja |
I figured this was the place to ask. :-) |
16:13 |
phasefx |
testing would be easier with simpler installations... *runs away* |
16:13 |
sandbergja |
phasefx++ |
16:14 |
sandbergja |
100% agree |
16:14 |
redavis |
phasefx++ #also hahahahahah |
16:14 |
sandbergja |
trying to install an eg-compatible ejabberd in github actions has me totally stumped |
16:14 |
sandbergja |
so I can't wait for redis to be merged |
16:14 |
sandbergja |
but I'm getting off topic hahaha |
16:15 |
berick |
any objections to running pgtap tests via github actions? going once? |
16:15 |
Bmagic |
berick says "strong +1 to merging" |
16:15 |
Bmagic |
no objections at all |
16:15 |
phasefx |
no objections to anyone maintaining testing infrastructure |
16:16 |
abneiman |
tests++ |
16:16 |
berick |
didn't think so, but it's kind of new, so.. |
16:16 |
berick |
sandbergja++ |
16:16 |
shulabramble |
sandbergja++ |
16:17 |
redavis |
berick++ |
16:18 |
shulabramble |
berick++ |
16:18 |
phasefx |
berick: just main? |
16:18 |
Bmagic |
I find it interesting that the server upon which the test run, presumabely don't have the perl dependencies? But that's fine for the scope of the tests? |
16:18 |
* phasefx |
belatedly pulls up the ticket |
16:19 |
shulabramble |
#action it is okay to merge lp2055796, sandberg and berick will attend |
16:19 |
shulabramble |
wrangling before we go a full half hour over |
17:40 |
pinesol |
Launchpad bug 2032835 in OpenSRF "Discussion: Merge OpenSRF Into Evergreen?" [Wishlist,New] https://launchpad.net/bugs/2032835 |
17:41 |
sandbergja |
+1 |
17:42 |
Bmagic |
+1 |
17:48 |
pinesol |
News from commits: LP2055796: run pgtap tests on Github Actions <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=7e83c5de8ca1e7530853878bc7562d961ce348c4> |
17:50 |
Bmagic |
sandbergja++ berick++ |
18:08 |
|
phasefx joined #evergreen |
18:08 |
|
abneiman joined #evergreen |
03:59 |
|
dashohoxha joined #evergreen |
04:05 |
dashohoxha |
Hello. I am trying to install Evergreen on docker container with Debian 12. Everything seems ok, but when I try to test the connection from 'srfsh', by giving 'login admin-user admin-pass', I get LOGIN_FAILED. |
04:06 |
dashohoxha |
srfsh# login admin TL2jEQrvp0aekJqh2Ww9 |
04:06 |
dashohoxha |
Received Data: "$2a$10$9qKCHyTrFu1NE30jX5LE3O" |
04:06 |
dashohoxha |
------------------------------------ |
04:06 |
dashohoxha |
Request Completed Successfully |
04:06 |
dashohoxha |
Request Time in seconds: 0.063436 |
04:06 |
dashohoxha |
------------------------------------ |
04:06 |
dashohoxha |
Received Data: { |
04:06 |
dashohoxha |
"ilsevent":1000, |
04:06 |
dashohoxha |
"textcode":"LOGIN_FAILED", |
04:06 |
dashohoxha |
"desc":"User login failed", |
04:06 |
dashohoxha |
"pid":594, |
04:06 |
dashohoxha |
"stacktrace":"oils_auth.c:794" |
04:06 |
dashohoxha |
} |
04:06 |
dashohoxha |
------------------------------------ |
04:06 |
dashohoxha |
Request Completed Successfully |
04:06 |
dashohoxha |
Request Time in seconds: 0.068730 |
04:06 |
dashohoxha |
------------------------------------ |
04:06 |
dashohoxha |
Login Session: (none). Session timeout: 0.000000 |
04:07 |
dashohoxha |
When I execute 'Open-ILS/src/support-scripts/settings-tester.pl', everything seems to be ok, except for this problem: |
04:08 |
dashohoxha |
Checking postgresql version |
04:08 |
dashohoxha |
psql (PostgreSQL) 16.4 (Debian 16.4-1.pgdg120+2) |
04:08 |
dashohoxha |
Checking libdbi and libdbi-drivers |
04:08 |
dashohoxha |
libdbi PostgreSQL driver not found in shared library path; |
04:08 |
dashohoxha |
you may need to edit /etc/ld.so.conf or add an entry to /etc/ld.so.conf.d/ |
04:08 |
dashohoxha |
and run 'ldconfig' as root |
04:09 |
dashohoxha |
Does anybody have any idea what this means and how to fix it? |
05:12 |
|
dashohoxha joined #evergreen |
06:53 |
|
JBoyer joined #evergreen |
07:03 |
|
collum joined #evergreen |
10:37 |
csharp_ |
dashohoxha: I would make sure ejabberd is functioning - also, look at the system logs at /openils/var/log/osrfsys.log (on a stock install) |
10:42 |
Bmagic |
csharp_: I'm not familiar with the nick, do you know if this is their first time installing? |
10:43 |
Bmagic |
I considered a response the the mailing list, but I wasn't sure where to begin :) |
10:45 |
dashohoxha |
I tried 'ldconfig' again, but this does not make 'settings-tester.pl' happy, it displays the same error message. Actually I looked at the code of 'settings-tester.pl', trying to find the part that outputs this error message, and it is something related to 'libdbpgsql': '/sbin/ldconfig --print | grep libdbdpgsql'. |
10:46 |
dashohoxha |
However I notice that the package 'libdbd-pgsql' (on Debian 12) is already installed. This is the closest that I could find to 'libdbpgsql'. |
10:49 |
dashohoxha |
About ejabberd, I have tested (as root) the commands that are suggested on the debug wiki page (which is a bit outdated by the way): 'ejabberdctl check_password opensrf public.localhost 445b8e76450077718e36effd3717a6486eae4208 ; echo $?' |
10:50 |
dashohoxha |
It gives 0 as a result, which means it is good. The same for the command: 'ejabberdctl check_password opensrf private.localhost 445b8e76450077718e36effd3717a6486eae4208 ; echo $?' |
10:53 |
|
Christineb joined #evergreen |
10:53 |
csharp_ |
dashohoxha: I think the pgdbd "problem" isn't worth investigating - it's more likely something within OpenSRF isn't running correctly - again, check the logfile I mentioned - look for things with "ERR" |
10:53 |
dashohoxha |
Checking '/openils/var/log/osrfsys.log', I see some error messages in it: |
10:54 |
csharp_ |
dashohoxha: use https://pastebin.com/ |
10:55 |
csharp_ |
dashohoxha: (also ensure nothing sensitive is in the logs before pasting) |
11:00 |
|
mmorgan1 joined #evergreen |
11:00 |
dashohoxha |
https://termbin.com/9tyr |
11:01 |
dashohoxha |
There is nothing sensitive in it because I am just trying to make a test installation. |
11:02 |
csharp_ |
sure |
11:03 |
csharp_ |
"Could not authenticate with Jabber server:" - the Jabber server will use whatever you have in username/password in the <opensrf> and <router> elements in /openils/conf/opensrf_core.xml, so first obvious step is to make sure that file is correct |
11:04 |
csharp_ |
does Debian use AppArmor? by default the apparmor profile for ejabberd is strict (on Ubuntu, anyway) |
10:06 |
|
BDorsey_ joined #evergreen |
10:18 |
|
Dyrcona joined #evergreen |
10:47 |
|
sandbergja joined #evergreen |
10:59 |
Dyrcona |
Has anyone gotten this with the 3.13.4 to 3.14.0 upgrade db script? "ERROR: ALTER TYPE ... ADD cannot run inside a transaction block". I'm only asking because I got it with another script that I wrote based on the 3.14 upgrade. However, I'm pretty sure that I didn't get it when I test the 3.14 upgrade after making it earlier this week. |
11:04 |
Dyrcona |
I am going to test the db upgrade again, this time on a Pg 10 database. It was Pg 10 where it failed on me. That behavior could have changed.... |
11:06 |
Dyrcona |
Yeah. It looks like it would fail with the same error... |
11:13 |
Dyrcona |
So, the 3.13.4-3.14.0 db upgrade works on Pg 16, which is where I think I tested it. I'll try Pg 10. |
11:18 |
redavis |
IIRC, we talked about stating that EG 3.14 required a minimum version of PG (I don't remember which) higher than 10 because it's out of support now. |
11:19 |
Dyrcona |
redavis: Yeah, but the release notes actually say it is compatible with Pg 10. We don't support less than Pg 13 for new installations. |
11:19 |
Dyrcona |
And, the upgrade fails on Pg 10. |
11:20 |
Dyrcona |
No, the release notes are correct. We changed it to be compatible. |
11:20 |
redavis |
Oh. okay |
11:20 |
redavis |
makes sense |
11:21 |
Dyrcona |
I swear I tested it on Pg 10, also, but I guess I didn't and thought that I had. |
11:21 |
Dyrcona |
I'll modify the db upgrade and put out a new tarball. |
11:21 |
Dyrcona |
We've had to do this before. |
11:21 |
redavis |
Dyrcona++ |
15:02 |
|
frank_g joined #evergreen |
15:05 |
|
Dyrcona joined #evergreen |
15:06 |
Dyrcona |
Hm.. wifi flaked out on me. |
15:11 |
frank_g |
Hi all, we are migrating from 3.4.2v to 3.12.0v in a new EG server, and a Library Staff is testing the Staff view, but he says that the records migrated dont show the complete information in the Staff view label, He created a new record and it shows the complete information, so I tested just saving the old record (without any change), and now the |
15:11 |
frank_g |
record shows the complete information, My question is, Is there a Script that I have to run to upadte all records to show the complete information in Staff view label? Or the library staff has to open-save each record to update them? I hope I explain it correctly, tks |
15:14 |
Dyrcona |
frank_g: You are pretty much guaranteed to have to run some kind of ingest jumping over that many versions. I recommend running pingest.pl. It's installed in /openils/bin. |
15:17 |
Dyrcona |
I bet the library kicked me off the wifi for going over a data cap. :) |
15:21 |
Dyrcona |
Good thing Verizon doesn't care, so long as I pay my bill. |
16:58 |
Bmagic |
I'm struggling to get Evergreen to install from scratch, and again, I think I've tracked it back to this perl issue |
16:58 |
dbriem |
mmorgan thanks |
16:58 |
Bmagic |
it's not just Email::Send that isn't getting installed |
16:58 |
dbriem |
yeah it has a dependency that's has failing tests |
16:59 |
Bmagic |
Email::Abstract isn't making it either |
17:01 |
Bmagic |
I'm checking to see if I can get a system up and running without having to install from cpan |
17:02 |
dbriem |
if i install Module::Pluggable directly, then Email::Send installs through cpan for me |
17:22 |
Bmagic |
Submitted a patch for it: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/blake/install_pluggable_dependency |
17:22 |
Bmagic |
how annoying |
17:24 |
Bmagic |
that patch is really just for me and anyone else who's intersted, there's no LP yet, and it's just for jammy. I've not explored any of the other supported OSes. And it might just be for docker installs. I'm holding out hope that it will be resolved on the cpan side and we won't have to do anything for real |
17:41 |
dbriem |
i used the ansible installer (by the way, thank you berick for that, it's awesome) and ran into the same issue, hopefully Module::Pluggable can address that test. in the meantime i have your patch, thanks. |
12:25 |
|
jihpringle joined #evergreen |
12:27 |
jeffdavis |
Only 79 more releases until that statement is valid, maybe we should just leave it in. |
12:27 |
Dyrcona |
Heh. |
12:28 |
* Dyrcona |
tests the 3.14.0 db upgrade script because it needed to be modified. |
12:29 |
Dyrcona |
Works for me! |
12:35 |
Bmagic |
are the branches ready for build (I'm mostly asking about "my" branch rel_3_13) ? |
12:35 |
Dyrcona |
Bmagic: I believe so. |
12:57 |
Dyrcona |
IDK. |
12:57 |
pinesol |
News from commits: Forward-port 3.12.7-3.12.8 upgrade script <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=6bc0f2ade724e4e1e083465efc33526edc3d2e59> |
12:58 |
Dyrcona |
It should be the same as main at this point. |
12:58 |
sandbergja |
Bmagic (and anybody else who might wish to test it): 3.12.8 is done building, tarball and other build artifacts are available at https://drive.google.com/drive/folders/19pGPywtrTbohBre-EBpQcoQptHXb6Bgu?usp=sharing |
12:58 |
Dyrcona |
I don't really understand our translation process. I think it all needs to be simplified. |
12:58 |
Dyrcona |
sandbergja++ |
12:59 |
Dyrcona |
3.41.0 is also done. I just copied the files to lupin. |
13:06 |
Dyrcona |
I make mistakes sometimes. This multistep process invites error. |
13:07 |
Bmagic |
I think we all agree with you |
13:07 |
|
sandbergja joined #evergreen |
13:08 |
Dyrcona |
I tested this all yesterday, minus the tarball part, so I think I'm just going to get the files in place once you're ready. I'll put sandbergja's files on the server and put them in place at the same time. |
13:09 |
|
collum joined #evergreen |
13:12 |
Dyrcona |
That's going to take a couple of minutes over the cell network. |
13:17 |
Dyrcona |
Wonder if I've hit a cap on my unlimited plan. Seems like they're slowing me down. |
16:33 |
Dyrcona |
Cool. |
16:33 |
Bmagic |
https://evergreen-ils.org/downloads/Evergreen-ILS-3.13.5.tar.gz |
16:34 |
Dyrcona |
Can you upload it to Lupin, or do you ... |
16:34 |
Bmagic |
you have one for me to test? |
16:35 |
Dyrcona |
https://evergreen-ils.org/downloads/Evergreen-ILS-3.14.0.tar.gz |
16:36 |
Bmagic |
sweet, testing |
16:39 |
Dyrcona |
Hmm... I should see if I have a clean vm on my laptop. If not, I should probably start a new one. The one I was going to use is "contaminated" with the 3.14 prerequisites. |
16:40 |
Bmagic |
we do have the handy dandy docker tarball builder |
16:40 |
Dyrcona |
I'd have to install docker and learn it just enough. I've got a got a clean Debian 12 vm. |
17:01 |
|
mmorgan left #evergreen |
17:02 |
Dyrcona |
Had to force it off. |
17:07 |
|
sandbergja joined #evergreen |
17:08 |
sandbergja |
Bmagic: fyi, I wrote down the steps that I use to test a tarball using your docker magic on the wiki: https://wiki.evergreen-ils.org/doku.php?id=qa:testing_a_tarball&s[]=testing&s[]=tarball |
17:08 |
Bmagic |
sandbergja++ |
17:09 |
sandbergja |
I'm going to try it for the 3.13.5 tarball to see if I wrote them down correctly hahaha |
17:10 |
Bmagic |
heck yeah |
17:12 |
sandbergja |
found some of my typos already whooo! |
17:25 |
Dyrcona |
typos-- |
17:26 |
Dyrcona |
Dang. forgot autogen.sh before running the tests and the usual suspects are failing... |
17:31 |
Dyrcona |
Bmagic: The 3.13.5 tarball gets a thumbs up from me. |
17:31 |
Dyrcona |
I have to pick my daughter up and won't be home for a couple of hours, so I an update the downloads page then. |
17:31 |
Bmagic |
same for 3.14.0 from me, though, for fun, I'm running some of the automated test |
17:32 |
Dyrcona |
I always run the tests. |
17:32 |
Bmagic |
all of em? nightwatch, headless firefox, etc? |
17:32 |
Dyrcona |
Not always ALL of them. I often skip nightwatch. |
17:33 |
Dyrcona |
Anyway, I got to go. |
17:50 |
sandbergja |
the fewer assumptions they make, the better |
17:50 |
Bmagic |
yeah, it's bubbling higher and higher on my priority list. I'm going to take it on |
17:50 |
sandbergja |
Bmagic++ |
17:51 |
Bmagic |
that is to say: I want to make an LP report for our tests in general, with the notion of going over each one, one by one and making them work with any dataset, and maybe eliminating some test that don't make sense. With an end goal of clean and working test sets for each of the languages that we're testing |
17:52 |
sandbergja |
that would be sweet, Bmagic! |
17:53 |
Bmagic |
It's too soon for me to make report though. I don't know what I don't know |
17:54 |
sandbergja |
I opened bug 2053095 earlier -- I guess I should also add the pgtap live tests to this list |
17:54 |
pinesol |
Launchpad bug 2053095 in Evergreen "Make tests compatible with the enhanced concerto data set" [Undecided,New] https://launchpad.net/bugs/2053095 |
17:54 |
Bmagic |
maybe we use that one |
17:55 |
Bmagic |
I will say that the standard concerto set takes much less time to reload/install |
17:55 |
Bmagic |
so, resetting the database each time we run your ansible run_test.yml script, becomes a larger endevour |
17:57 |
sandbergja |
ah! I keep meaning to check that out. |
17:58 |
sandbergja |
I will say, I LOVED building the tarball today with the dev container. Having the repo mounted as a volume worked really nicely. |
17:59 |
Bmagic |
excellent |
17:59 |
sandbergja |
3.13.5 tarball looks good to me too! |
18:00 |
sandbergja |
Bmagic: in case you run the nightwatch tests, there is one failure I get that points to this regression: bug 2067160. |
18:00 |
pinesol |
Launchpad bug 2067160 in Evergreen "Holdings editor regression: Can no longer remove a default item alert type" [Medium,Confirmed] https://launchpad.net/bugs/2067160 - Assigned to Jane Sandberg (sandbergja) |
18:00 |
sandbergja |
I keep meaning to submit a patch for it -- Dan even left a comment saying exactly what needs to be done -- but I haven't gotten around to it yet. |
18:04 |
sandbergja |
heading out -- have a good night, Evergreen! |
11:35 |
sandbergja |
Dyrcona it'll take me a bit to push, I want to run the live tests one last time, and am also getting distracted by a few other things simultaneously. |
11:39 |
* jeffdavis |
enjoys a cup of Ethiopia Washed Yirgacheffe, Koke Grade 1 |
11:46 |
* Dyrcona |
enjoys Sunday dinner leftovers: rib roast, potato and carrot. |
11:48 |
sandbergja |
One of the live tests is failing with "Method [open-ils.actor.user.penalty.remove] not found for OpenILS::Application::Actor" -- did that method get removed recently? |
11:48 |
sandbergja |
I am pretty confident that it's unrelated to this acq/cat patch |
11:48 |
|
collum joined #evergreen |
11:50 |
eeevil |
sandbergja: (mostly for the room and logs) as a general rule, if unrelated methods start failing it's often a perl syntax error earlier in a sub-module, and the methods aren't getting registered because of that |
11:50 |
Dyrcona |
Yeah. I'll take a look. |
11:52 |
jeffdavis |
open-ils.actor.user.penalty.remove was changed to open-ils.actor.user.note.remove |
11:53 |
eeevil |
jeffdavis++ |
11:53 |
Dyrcona |
I was going to check on rel_3_14 on my release vm, but jeffdavis++ |
11:53 |
sandbergja |
jeffdavis++ |
11:53 |
sandbergja |
eeevil: main seems okay as in the test passes on main for you? |
11:53 |
Dyrcona |
That should probably go in an upgrade note. |
11:54 |
eeevil |
sandbergja: sorry, no, I didn't run the tests, I just checked the syntax with `perl -wc` |
11:54 |
sandbergja |
gotcha |
11:55 |
Dyrcona |
I'll make a Lp bug and post a fix if no one else wants to. |
11:57 |
Dyrcona |
eeevil: Do you have a strong opinion on Lp 2083873? Today would be a good time to hash it out. |
11:57 |
pinesol |
Launchpad bug 2083873 in Evergreen "Remove support for PostgreSQL 10, 11 and 12" [Undecided,New] https://launchpad.net/bugs/2083873 |
11:59 |
sandbergja |
Dyrcona++ |
11:59 |
eeevil |
Dyrcona: my preference would be, if testing proves it works for $not_me, to include the back-compat change, and drop fresh-install-support for 10-12... too much to ask? :) |
12:00 |
Dyrcona |
It's not too much to ask. I noticed anycompatible is also used in the reporter, probably the security or Angular update. That would need a fix, too. |
12:01 |
eeevil |
it's the reports security stuff that I offered a change to, IIRC |
12:01 |
Dyrcona |
Oh, OK!. I thought I saw it somewhere twice. I'll double check. I'm probably hallucinating things from looking at too much code over the past couple of weeks. |
12:02 |
|
jihpringle joined #evergreen |
12:02 |
eeevil |
yeah, it is. the patch as offered is meant to modify things in-place for any branch that contains the reports security stuff. no /new/ upgrade script, just pretend that didn't happen |
12:02 |
Dyrcona |
First verify the test failure for myself so I can write a Lp bug and post a fix. After that the anycompatible thing.... Got it! No one should have it in production, yet. |
12:03 |
eeevil |
right, that's my thinking. if they do, they know how to handle pre-release changes :) |
12:03 |
eeevil |
(I HOPE!) |
12:06 |
Dyrcona |
:) |
12:06 |
* Dyrcona |
has had fun with those in the past. |
12:08 |
pinesol |
News from commits: LP#2084096: Add a test for lineitem deletion <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=563d3604c39910d076774b191ff72163f5671b3b> |
12:08 |
pinesol |
News from commits: LP#2084096: Fix issue with line item cancellation and undefined volume <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=532d8be5391516a743c9ad84c23fa80e47049246> |
12:12 |
Dyrcona |
sandbergja++ eeevil++ |
12:31 |
Dyrcona |
Hmm.. Setting up a vm to test a few things and osrf_control is taking a long time to exit. |
12:32 |
|
collum joined #evergreen |
12:35 |
Dyrcona |
This is latest main on Ubuntu 24.04, and osrf_control -l --start-all seems hang after starting opensrf.slooooooow. |
12:37 |
Dyrcona |
Some listeners and drones won't go away with just a plain 'kill.' |
15:26 |
berick |
oh yeah.. i do know it |
15:26 |
Dyrcona |
Just listen to the musicianship... It's near perfection. |
15:27 |
berick |
yeah, they often are |
15:28 |
Dyrcona |
jeffdavis++ the tests pass. |
15:29 |
Dyrcona |
I'm tempted to just push your fix now, but maybe I'll add a signoff and wait a day or two if someone else wants to look. |
15:36 |
redavis |
Dyrcona++ jeffdavis++ |
15:39 |
Dyrcona |
Resist the urge to Push ALL THE THINGS!!!! |
15:39 |
redavis |
Why resist? :D (if they're tested and ready to go) |
15:42 |
Dyrcona |
Yes, some are signedoff. I still like to at least look at the code and run a few tests before. |
15:44 |
redavis |
lol, well, yes. But...once you do... |
15:44 |
redavis |
you get a commit and YOU get a commit |
15:45 |
Dyrcona |
\o/ |