Evergreen ILS Website

Search in #evergreen

Channels | #evergreen index




Results

Result pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143

Results for 2024-11-20

10:32 csharp_ no, it should be considered the new CentOS
10:32 Dyrcona OK. I haven't been keeping up with the RedHats....
10:32 Dyrcona I thought it was the new Fedora.
10:33 csharp_ Fedora's still Fedora - I may try to support it too - but Fedora is the testing ground for RHEL/Rocky
10:34 csharp_ like a more stable Debian sid
10:34 Dyrcona Yeah. I would not object to adding Rocky support, but I'm a bit leery of adding Fedora install support officially.
10:34 Dyrcona I mean, *I* don't want to support it. :)
10:34 csharp_ agreed - I can't imagine anyone running Fedora in production given how quickly the release cycles run
17:02 mantis mmorgan++
17:03 mantis left #evergreen
17:04 Dyrcona mmorgan++ redavis++ csharp_++
17:06 csharp_ starting my test of 3.13
17:06 mmorgan 3.12.9 tarball is set also, files shared.
17:11 mmorgan left #evergreen
17:31 * Dyrcona signs out for now.

Results for 2024-11-19

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/Eve​rgreen.git;a=shortlog;h=refs/heads/user/mike​r/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/Evergr​een.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"

Results for 2024-11-18

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=E​vergreen.git;a=commitdiff;h=79980a​ff138c39b6056f8c0795fa308a8293fa79>
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

Results for 2024-11-15

09:34 mdriscoll joined #evergreen
10:58 Christineb joined #evergreen
11:03 * Dyrcona wonders if doing the translations bits for different releases on the same VM will cause problems. Probably not.
11:06 * Dyrcona does release building on a dedicated vm, then tests it elsewhere.
11:12 jeffdavis We've got a recurring situation where ill-behaved webcrawlers doing ~200 qtype=subject queries per minute can cause OOM problems.
11:12 jeffdavis We're playing whack-a-mole with IP addresses since the crawlers don't properly identify themselves.
11:12 jeffdavis It would be nice if EG handled that volume of requests more gracefully.

Results for 2024-11-14

09:40 sleary I can't get it installed on 15 though; will try again on 18
09:40 terranm joined #evergreen
09:40 terranm https://wiki.evergreen-ils.org/d​oku.php?id=evergreen-reports:rig
10:10 berick csharp_: fyi fixed ansible on 24.04 using include_tasks:  doing final tests now
10:10 sleary scottangel: https://css-tricks.com/com​e-to-the-light-dark-side/
10:13 dguarrac joined #evergreen
10:18 terranm My Hack-a-way update: KPAC overhaul is still in very early stages, but it now has the beginning of an admin interface to create/update the custom categories on the fly - no more XML config file! https://terran-main.gapines.org/eg/kpac/home

Results for 2024-11-13

09:17 sandbergja joined #evergreen
09:18 Bmagic Dyrcona++
09:19 Bmagic berick: I think it's a good thing (non-global).
09:23 berick yay, github pgtap tests already paying off (working on pg17 branch)
09:25 mantis joined #evergreen
09:25 kmlussier joined #evergreen
09:27 kmlussier Zoom link for the hack-a-way is https://us02web.zoom.us/j/88077861312​?pwd=diZubjjUZTrVMs6PLDYRO5Rfxyn3Ao.1
10:21 Dyrcona abneiman++
10:23 eeevil 2083039
10:33 smorrison joined #evergreen
11:03 mantis hey all we are doing some open testing for Ringcentral which will be the conference software platform we'll use for the 2025 conference.  If anyone has some time to spare testing, please let me know and I can send a magic link invite
11:03 mantis or you can register here: https://events.ringcentral.com/​events/eg-committee-test-event
11:11 redavis joined #evergreen
11:11 sleary I am hearing that not everyone here is familiar with the falsehoods programmers believe about names: https://www.kalzumeus.com/2010/06/17/fal​sehoods-programmers-believe-about-names/ and the many other permutations https://github.com/kdeldycke/awesome-falsehood
11:18 Christineb joined #evergreen

Results for 2024-11-12

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=E​vergreen.git;a=commitdiff;h=7e83c5​de8ca1e7530853878bc7562d961ce348c4>
17:50 Bmagic sandbergja++ berick++
18:08 phasefx joined #evergreen
18:08 abneiman joined #evergreen

Results for 2024-11-01

16:56 dashohoxha - https://gitlab.com/docker-scripts/dev/everg​reen/-/blob/redis/Dockerfile?ref_type=heads
16:56 dashohoxha - https://gitlab.com/docker-scripts/dev/evergree​n/-/blob/redis/inject/setup.sh?ref_type=heads
16:56 dashohoxha If someone would like to have a look, you can access it here:
16:56 dashohoxha - https://tmate.io/t/ut7yN3C56e47rpZvMraHSWWNG
17:00 dashohoxha On the other hand, there is some progress with the stable release. I don't know how it is fixed, but the login test now is working (gives SUCCESS), although there are still some other problems.
17:00 dashohoxha The installation scripts are these:
17:00 dashohoxha - https://gitlab.com/docker-scripts/d​ev/evergreen/-/blob/main/Dockerfile
17:00 dashohoxha - https://gitlab.com/docker-scripts/dev/​evergreen/-/blob/main/inject/setup.sh
17:00 dashohoxha It can be accessed here (if someone would like to have a look):
17:00 dashohoxha - https://tmate.io/t/MRNS9CcmuWJ2QG4kjsrPh9xGJ
17:04 dashohoxha Don't be afraid of breaking something, because I can rebuild the containers again from scratch.
17:05 mmorgan left #evergreen
17:07 dashohoxha For example apache2 is giving some errors on the log:
17:07 dashohoxha [WARN:171:osrfConfig.c:251:] No Config object!
17:07 dashohoxha [INFO:171:./osrf_json_gateway.c:72:] Bootstrapping gateway child for requests
17:07 dashohoxha I/O warning : failed to load external entity "/openils/conf/opensrf_core.xml"
17:07 dashohoxha [WARN:174:osrfConfig.c:99:] Unable to parse XML config file /openils/conf/opensrf_core.xml
17:07 dashohoxha [ERR :174:osrf_system.c:350:] No Config File Specified
17:13 dashohoxha I have noticed on the file '/openils/config/opensrf_core.xml' that <config>/<gateway>/<username> is "opensrf" for the jabberd part, and it is "gateway" for the (commented) redis part. Maybe one of them is wrong.
17:20 dashohoxha Also, the container is behind a reverse proxy (nginx) with a basic proxy_pass configuration like this:
17:20 dashohoxha server {
17:20 dashohoxha listen 443 ssl;
17:20 dashohoxha server_name ils.fs.al ;
17:20 dashohoxha location / {
17:20 dashohoxha include conf.d/proxy_params;
17:20 dashohoxha proxy_pass https://ils.fs.al;
17:20 dashohoxha }
17:20 dashohoxha }
17:20 dashohoxha I am afraid that it needs some additional configuration for the websocket. I don't know if the site still works without websocket configured properly.
17:35 JBoyer joined #evergreen
18:15 Christineb joined #evergreen
23:50 ianskelskey joined #evergreen

Results for 2024-10-30

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)

Results for 2024-10-28

08:43 collum joined #evergreen
09:00 mmorgan1 joined #evergreen
09:06 dguarrac joined #evergreen
09:48 jeff there are at least three other issues with that set of tests for Module::Pluggable in CPAN RT: https://rt.cpan.org/Public/Dist/D​isplay.html?Name=Module-Pluggable
09:50 jeff though one was likely fixed by this commit, which annoyingly seems to do more than the commit message suggests: https://github.com/simonwistow/Module-Pluggable/​commit/8c179586ba0edd077e3e12ac63edac70551ed661
09:55 redavis joined #evergreen
10:09 mantis joined #evergreen
10:16 redavis_reloaded joined #evergreen

Results for 2024-10-25

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/u​ser/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.

Results for 2024-10-24

09:24 mmorgan joined #evergreen
09:26 collum joined #evergreen
09:31 dguarrac joined #evergreen
09:36 Bmagic by the way: the 3.14.0 tarbal re-test resulted in the same perl installation issue for Email::Send. In other words: it's not us, it's them.
09:36 Bmagic also:
09:36 Bmagic @coffee [someone]
09:37 * pinesol brews and pours a cup of Colombia Tolima Reynel Perez Micro-Lot, and sends it sliding down the bar to mantis1

Results for 2024-10-23

12:01 mmorgan joined #evergreen
12:01 Bmagic export CPAN_MODULES = \ ... Email::Send \
12:01 Dyrcona I ran `sudo cpan install Email::Send` and got this: "Email::Send is up to date (2.202)."
12:02 Bmagic you'd have to test on a system that doesn't already have it installed
12:02 Dyrcona Of course, and I don't have one of those handy at the moment.
12:02 Bmagic there's a compile error somewhere in the middle
12:02 Dyrcona Well, there's a Lp bug to switch to Email::Sender...

Results for 2024-10-22

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=E​vergreen.git;a=commitdiff;h=6bc0f2​ade724e4e1e083465efc33526edc3d2e59>
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/19p​GPywtrTbohBre-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/downlo​ads/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/downlo​ads/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&amp;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!

Results for 2024-10-21

12:34 Dyrcona I messed them up at first, but the not found messages started after I fixed them.
12:34 Dyrcona I could try it again.
12:49 Dyrcona I have reloaded the database. I'm trying again. (Also, while voting on a bug tracking system for Aspen.)
12:51 Dyrcona live_t/15-lp1533329-opt-in.t ... Failed tests:  5, 13 ... Result: FAIL
12:54 Dyrcona oh, wait a minute.... I should run the tests again.
12:54 Dyrcona I made a change in the database before running them.
13:14 Dyrcona I see that I'm setting the settings wrong. I set the wrong setting for BR4. I should have used a fancy search and replace rather than writing the insert by hand.
13:31 Dyrcona Y'know, putting 'org.' on the beginning of organizational unit setting names is redundant.

Results for 2024-10-18

12:02 mantis left #evergreen
12:03 Dyrcona Which makes upgrading from later point releases trickier, and we don't do anything to help anyone with that.
12:03 redavis right
12:05 Dyrcona I might as well finish installing Evergreen on this vm. I can use it for testing.
12:17 mmorgan Dyrcona: Friday brain talking, but I think regardless of whether you do it from 3.13.4 or 3.13.5, upgrading from later 3.13 point releases will be trickier.
12:17 mmorgan So I would think doing it from whatever is the latest release when you actually build is the best you can do.
12:18 jihpringle joined #evergreen

Results for 2024-10-17

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=E​vergreen.git;a=commitdiff;h=563d36​04c39910d076774b191ff72163f5671b3b>
12:08 pinesol News from commits: LP#2084096: Fix issue with line item cancellation and undefined volume <https://git.evergreen-ils.org/?p=E​vergreen.git;a=commitdiff;h=532d8b​e5391516a743c9ad84c23fa80e47049246>
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/

Result pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143